Re: [REPATCH] Parrot::Embed Take Two
At 18:43 17/08/2006 -0700, chromatic wrote:
Hi there,
Here's a patch for Build.PL that should avoid most of the pkg_config troubles
on platforms that don't have it. I still don't quite know what to do on
Windows when installing from outside of the Parrot tree.
1) in get_parrot_path_external(), the split of PATH is not portable,
File::Spec gives a solution :
for my $path ( File::Spec-path() )
2) consider the use of File::Which instead of get_parrot_path_external
use File::Which;
...
return which('parrot');
François.
-- c
Re: [perl #39868] [CAGE] convert CBEGIN { plan tests = NN; } to Cuse Parrot::Test tests = NN;
Hi again,
I've tried this patch again and fixed only one minor detail, here's
the log of what i did:
$ rm -rf t/
$ make realclean
$ svn up
(...)
Updated to revision 14291.
$ perl Configure.pl
$ make
$ make test 21 | tee BEFORE_PATCH
[apply patch]
$ svn up
At revision 14291.
$ make test 21 | tee AFTER_PATCH
[fix small issue]
$ svn up
At revision 14291.
$ make test 21 | tee AFTER_FIX
$ diff -u BEFORE_PATCH AFTER_FIX
$
No diff for make test before applying patch and after fix, which could
show that it seems safe to apply patch. I've created a new patch file
with:
$ svn diff t/ BEGIN-t.updated.patch
to solve the issue around one file that no longer exists and another
one that failed to patch because the file itself changed. You can find
the new patch attatched to this message.
Best regards,
./smash
Index: t/pmc/lexpad.t
===
--- t/pmc/lexpad.t (revision 14291)
+++ t/pmc/lexpad.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -35,5 +35,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/random.t
===
--- t/pmc/random.t (revision 14291)
+++ t/pmc/random.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -34,5 +34,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/parrotobject.t
===
--- t/pmc/parrotobject.t (revision 14291)
+++ t/pmc/parrotobject.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -36,5 +36,3 @@
# '
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/parrotio.t
===
--- t/pmc/parrotio.t (revision 14291)
+++ t/pmc/parrotio.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -33,5 +33,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/slice.t
===
--- t/pmc/slice.t (revision 14291)
+++ t/pmc/slice.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 2;
=head1 NAME
@@ -57,5 +57,3 @@
1.00
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 2; }
Index: t/pmc/addrregistry.t
===
--- t/pmc/addrregistry.t (revision 14291)
+++ t/pmc/addrregistry.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -34,5 +34,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/unmanagedstruct.t
===
--- t/pmc/unmanagedstruct.t (revision 14291)
+++ t/pmc/unmanagedstruct.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -34,5 +34,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/retcontinuation.t
===
--- t/pmc/retcontinuation.t (revision 14291)
+++ t/pmc/retcontinuation.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -34,5 +34,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/parrotinterpreter.t
===
--- t/pmc/parrotinterpreter.t (revision 14291)
+++ t/pmc/parrotinterpreter.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@ -34,5 +34,3 @@
OUT
-# remember to change the number of tests :-)
-BEGIN { plan tests = 1; }
Index: t/pmc/parrotlibrary.t
===
--- t/pmc/parrotlibrary.t (revision 14291)
+++ t/pmc/parrotlibrary.t (working copy)
@@ -6,7 +6,7 @@
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test;
+use Parrot::Test tests = 1;
=head1 NAME
@@
[perl #40209] [TODO] convert t/compilers/pge/p6regex/01-regex.t to PIR
# New Ticket Created by Will Coleda # Please include the string: [perl #40209] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40209 Running these tests in PIR instead of perl will give us a speedup during 'make test', and serve as a template for other conversions of PGE tests. -- Will Coke Coleda [EMAIL PROTECTED]
Re: SKIPs Are Now a Code Smell
On Sat, Aug 19, 2006 at 07:17:03PM -0700, chromatic wrote: Thus, I suggest that we collectively unskip all of the tests that might possibly pass on all platforms, tighten the skip conditions to their minimum necessities, use TODO instead of SKIP absolutely everywhere possible, and delete the tests that don't matter anymore. I'm Chip Salzenberg, and I approve of this message. I've just checked in a CAGE task for this. Thanks. -- Chip Salzenberg [EMAIL PROTECTED]
[perl #40207] [PATCH] tools/dev/install_files.pl - replace tabs with spaces
Thanks, applied as r14296 In the future, please send patches relative to parrot root: http://www.parrotcode.org/docs/submissions.html This will make it easy to apply them. Thanks again!
[perl #40162] [PATCH] parrot/trunk/docs/art/pp001-intro.pod - spelling
Thanks, applied as r14297.
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 10:48:59AM -0400, Will Coleda wrote: The way you phrase the question, you're not going to get any of these answers. Who is programming parrot on their *physical* VT100? =-). The primary reason for an 80 column limit is developer convenience, I think. Well, that's fair. Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? I don't think any of us will quit if you come back with a higher number. Except maybe Jerry. =-) He'll threaten to quit until I change the pdd and .t files and then he'll start bugging people who write short lines. P.S.: Seems only fair that if we're sticking with C89, we stick with 1989 terminal sizes. =-) Some selectivity is in order, or we'll have to target 1989 memory sizes, disk capacities, and network bandwidth PS: Allison gets to specify the doc formatting, if she likes. Exceptions are technically trivial. See the bottom of the pdds for how a given file can override the default word wrap column. -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
Am Montag, 21. August 2006 17:45 schrieb Chip Salzenberg: Well, that's fair. Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. Due to the rather verbose VTABLE macros, 80 looks a bit too limited (given the impressive amount of needed code changes we got recently (ambs++ BTW)). My preference: soft limit 80 - keep lines shorter, if it's easy hard limit ~100 - you SHALL not exceed it leo [1] reasonable for the old eyes of folks that actually have punched hollerith cards, when they were younger, like e.g. yours sincerly
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, 2006-08-21 at 08:45 -0700, Chip Salzenberg wrote: On Mon, Aug 21, 2006 at 10:48:59AM -0400, Will Coleda wrote: The way you phrase the question, you're not going to get any of these answers. Who is programming parrot on their *physical* VT100? =-). The primary reason for an 80 column limit is developer convenience, I think. Well, that's fair. Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? I typically measure my screen real estate in discrete 80-col units. My layout of terminals, editors (emacs, xemacs, vim and gvim mixed fairly liberally for different purposes) and other applications is suited to editing in 80-column units. When I have to re-size a window to larger than that, it's a pain, but not a terribly hurtful one. I like the Gnome Style document for reference here. They talk about 8-space tabs, but it's the same issue as 80-column text: Using 8-space tabs for indentation provides a number of benefits. It makes the code easier to read, since the indentation is clearly marked. It also helps you keep your code honest by forcing you to split functions into more modular and well-defined chunks - if your indentation goes too far to the right, then it means your function is designed badly and you should split it to make it more modular or re-think it. Just my $0.02. P.S.: Seems only fair that if we're sticking with C89, we stick with 1989 terminal sizes. =-) Some selectivity is in order, or we'll have to target 1989 memory sizes, disk capacities, and network bandwidth There are times that I use emacs, not because it's the right tool for the job that *it* is doing, but because I have to use it over a lossy line, and NOTHING that I've found squeezes quite so much out of curses-like rendering over a slow line. Why? Because it was designed to do multi-window editing over 1200-9600 bps modem lines without making its users want to kill themselves. There is something to be said for working well in low-resource environments, especially when talking about a VM that might need to be placed into the control circuitry of, say, an elevator control system.
Re: End the Hollerith Tyranny? (linelength.t)
On 8/21/06, Leopold Toetsch [EMAIL PROTECTED] wrote:
My preference: soft limit 80 - keep lines shorter, if it's easy
hard limit ~100 - you SHALL not exceed it
coding standards are quite helpful, but cannot be applied absolutely.
there are good reasons why a line of code might exceed some arbitrary
number of characters, like those mentioned above. therefore i'd like
to avoid a *hard* limit, where for example patches will be rejected if
the line length exceeds this amount.
for example, the current incantation for writing perl 5 tests for
parrot goes something like this:
pir_output_is('CODE', 'OUTPUT', some lengthy and verbose test
description, todo = 'write a good test someday');
due to perl 5's limitations wrt heredocs, this cannot be split onto
more than one line. therefore, until the tests are rewritten in PIR,
there will exist many .t files with a line length exceeding even
perhaps 135 characters. rather than modifying a test header to use
multiple statements which can be better formatted (which is ugly and
prone to copy/paste errors,) i recommend that chars-per-line
formatting not apply to test headers in .t files.
further, i believe this should be generalized and extended: coding
standards should be used wherever possible without requiring undue
burden on the developer. therefore, i recommend that absolute words
like qwmust always never shall should not be used. also, any
tools/tests/etc which enforce the standard must (and here i mean
'must') be flexible enough to deal with exceptions to the standard.
~jerry
Re: End the Hollerith Tyranny? (linelength.t)
jerry gay wrote: On 8/21/06, Leopold Toetsch [EMAIL PROTECTED] wrote: My preference: soft limit 80 - keep lines shorter, if it's easy hard limit ~100 - you SHALL not exceed it coding standards are quite helpful, but cannot be applied absolutely. there are good reasons why a line of code might exceed some arbitrary number of characters, like those mentioned above. therefore i'd like to avoid a *hard* limit, where for example patches will be rejected if the line length exceeds this amount. Don't forget that some programs, like mailers, wrap at 80 characters. Although there is not much mailing of code, other programs may unexpectedly wrap it. It is best to keep it under 80 if at all possible. -- __END__ Just my 0.0002 million dollars worth, --- Shawn For the things we have to learn before we can do them, we learn by doing them. Aristotle
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. That's an interesting and modern metric: minimum common screen size divided by minimum readable font size. (For me that comes out to 150 columns; a 12 display triggers my claustrophobia.) [1] reasonable for the old eyes of folks that actually have punched hollerith cards, when they were younger, like e.g. yours sincerly Right there with you. My school's punch card machines were in the same room as the TRS-80 Model I (THE COMPUTER ROOM). These kids today with their hula hoops and fax machines and intarwebs... -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote: Don't forget that some programs, like mailers, wrap at 80 characters. I don't know of any mailer that is hard-coded at any given column width. Do you? -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
Chip Salzenberg wrote: On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote: Don't forget that some programs, like mailers, wrap at 80 characters. I don't know of any mailer that is hard-coded at any given column width. Do you? Thunderbird, Evolution, just to name two. OK, they're not hard-coded; you can change the option (if you can find it). What I'm saying is that we still have the legacy of 80 columns and unless necessary, all ASCII files should fit within it. And yes, I realize that code seldom gets mailed but there may be other programs that have this artificial limit in them and if you're lazy (like me), you couldn't be bother changing their factory settings. In other words, don't exceed 80 columns unless you have a reason for it. The thing about mail programs is that even if you set you're limit to something large like 2048, the person who received your message may still have a limit of 80, which would make any message you send hard to read. Just keep in mind that we're stuck with the 80 column limit the same way we are stuck with the QWERTY keyboard. It's not the best there is, it's only what most expect. -- __END__ Just my 0.0002 million dollars worth, --- Shawn For the things we have to learn before we can do them, we learn by doing them. Aristotle
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: Am Montag, 21. August 2006 17:45 schrieb Chip Salzenberg: Well, that's fair. ?Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. ?So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. Due to the rather verbose VTABLE macros, 80 looks a bit too limited (given the impressive amount of needed code changes we got recently (ambs++ BTW)). My preference: soft limit 80 - keep lines shorter, if it's easy hard limit ~100 - you SHALL not exceed it I agree. At my $day_job we use 110 as the hard limit and this works fine for most desktop users but is rather annoying for those of us that bought 16:9 format laptops just so we can squeeze 2 x 80 column terminals side by side (at an almost legible font size). -J -- pgpqmaKroqvPs.pgp Description: PGP signature
Re: End the Hollerith Tyranny? (linelength.t)
From: Chip Salzenberg [EMAIL PROTECTED] Date: Mon, 21 Aug 2006 15:07:16 -0700 On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. That's an interesting and modern metric: minimum common screen size divided by minimum readable font size. (For me that comes out to 150 columns; a 12 display triggers my claustrophobia.) That equation gives you a line length, but does it give you readability? Can you comfortably read English (or whatever) text at that size if the lines are strung out along 150 columns? I would prefer two-column layout in that case . . . or a font large enough to reduce the text width to, say, 80 columns again. (In fact, my preferred editing config is a pair of side-by-side 80-column Emacs instances on a 19 screen.) And then there is the effect of long lines on code. I am often forced to break or refactor long code lines, which means I have to figure out where to break them, which means I'm adding information by doing so. So maybe it would be more palatable to think of 80 columns as the Hollerith Discipline . . . ;-} [1] reasonable for the old eyes of folks that actually have punched hollerith cards, when they were younger, like e.g. yours sincerly Right there with you. My school's punch card machines were in the same room as the TRS-80 Model I (THE COMPUTER ROOM) . . . We had a Mainframe, complete with attendant priesthood . . . and *lots* of keypunches scattered over campus for the laity, who were not allowed into the inner sanctum. -- Bob Rogers http://rgrjr.dyndns.org/
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 06:49:20PM -0400, Mr. Shawn H. Corey wrote: Chip Salzenberg wrote: On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote: Don't forget that some programs, like mailers, wrap at 80 characters. I don't know of any mailer that is hard-coded at any given column width. Do you? Thunderbird, Evolution, just to name two. OK, they're not hard-coded; you can change the option (if you can find it). What I'm saying is that we still have the legacy of 80 columns and unless necessary, all ASCII files should fit within it. And yes, I realize that code seldom gets mailed but there may be other programs that have this artificial limit in them and if you're lazy (like me), you couldn't be bother changing their factory settings. In other words, don't exceed 80 columns unless you have a reason for it. The thing about mail programs is that even if you set you're limit to something large like 2048, the person who received your message may still have a limit of 80, which would make any message you send hard to read. Just keep in mind that we're stuck with the 80 column limit the same way we are stuck with the QWERTY keyboard. It's not the best there is, it's only what most expect. That's an interesting vantage point. Restated, there are still old systems out there, let's conform to them. I could be suffering a failure of imagination, but I don't see why we would do that. We'd just be perpetuating the tyranny rather than ending it. It seems to me that *if* the line length is ever a problem, we have or can create tools to deal with it (uuencode anyone?). Also by not keeping to 80 columns, we can weed out the modern tools that still have such limitations and encourage the authors to fix them. And if *that* turns out to be too big of an endeavour, we can always go back to 80 columns, but I'm guessing whatever problems there are will be small and localized. just my humble opinion, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
CS == Chip Salzenberg [EMAIL PROTECTED] writes: CS On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. CS That's an interesting and modern metric: minimum common screen CS size divided by minimum readable font size. (For me that comes CS out to 150 columns; a 12 display triggers my claustrophobia.) [1] reasonable for the old eyes of folks that actually have punched hollerith cards, when they were younger, like e.g. yours sincerly CS Right there with you. My school's punch card machines were in the CS same room as the TRS-80 Model I (THE COMPUTER ROOM). These kids CS today with their hula hoops and fax machines and intarwebs... there is another non-technical consideration for 80 columns and that is how eyeballs can scan lines. notice that books are printed in a similar width (though with variable width fonts usually). eyes can scan across a line and then back the next line best at around this size. too short lines (like magazine columns) get tiring going back and forth too often. too long lines make it harder to easily get to the start of the next line. this has been tested and you can easily play with it yourself. so 80 columns of fixed size fonts has a long history and not just from hollerith. 132 column paper was used a bunch too but that was so that 80 column code could be printed with all sorts of extra shit like line numbers and stuff. also some reports wanted that but all the input was 80 columns (good ol' real punch cards). crt's kept that width for compatibility but they also offered 132 column modes (very hard to read with narrow chars on vt100 type terms). i keep all my xterms at 80 columns since it does seem to be a good size for my eyes to scan. and i also keep all my code that way too. i find it very annoying when i have to read long lines of code. i can make my windows wider but why ruin them just for that file? somewhere earlier in this thread a test script with a long string and two here docs was shown and it was very long. why couldn't the long string also be a here doc? the only issue would be the trailing newline but i didn't look carefully at it to see if that mattered. i use here docs all the time in many places where others don't just to keep under 80 columns. anyhow, that is my $.80 worth here. ignore it at your pleasure or peril. back to lurking, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
