Re: dis-junctive patterns
HaloO, Gaal Yahas wrote: In pugs, r7961: my @pats = /1/, /2/; say MATCH if 1 ~~ any @pats; # MATCH say MATCH if 0 ~~ any @pats; # no match So far so good. But: my $junc = any @pats; say MATCH if 1 ~~ $junc; # no match say MATCH if 0 ~~ $junc; # no match Bug? Feature? Ohh, interesting. This reminds me to my proposal that junctions are code types and exert their magic only when recognized as such. The any(@pats) form constructs such a code object right in the match while the $junc var hides it. My idea was to explicitly request a code evaluation by one of my junc = any @pats; # 1: use code sigil say MATCH if 1 ~~ junc; say MATCH if 1 ~~ do $junc; # 2: do operator say MATCH if 1 ~~ $junc(); # 3: call operator But this might just be wishful thinking on my side. --
Problem with perl code - coverage during build
Hello Group, I am trying to test the perl component and find the code coverage for the same.I have wrote a parser that analyses the generated perl test log files. I am using the version 5.8.7 of perl. I am trying to do the code coverage using bullseye. But while I am trying to build the component I am getting the following error. Does any one have any idea on this. It would be great if someone can suggest me something. DiagArchive: File open error: /lhome/dvyas/Dharmesh/tool/perl/src/y.tab.c: No such file or directory DiagArchive: File open error: /lhome/dvyas/Dharmesh/tool/perl/src/y.tab.c: No such file or directory warning cov807: cannot find y.tab.c (in /lhome/dvyas/Dharmesh/tool/perl/src/) Covdata: /lhome/dvyas/Dharmesh/tool/perl/coverage/covrep.cov: cannot find y.tab.c (in /lhome/dvyas/Dharmesh/tool/perl/src/) make: *** [perly.o] Error 1 Thanks Dharmesh Vyas. [SpikeSource India]
Passing a parameter to test files
Hi All, I have been trying to find a way to combine the functionality of Test::Harness with testing scripts that take a parameter. Here is my situation: I am trying to test a database configuration for one specific ID. This ID is essentially part of primary key for several tables and we would like to make sure that the data in the tables follows certain rules. Of course, the rules are rather complicated, so I thought the tests could be written in perl. Basically, the setup I am considering is as follows: - There would be a directory of .t files that all test a different part of the configuration - All of the .t files would take the ID as an argument, so they could be executed as perl testfile.t SPECIFIC-ID - I could use Test::Harness to run all these test files, passing the specific ID in at runtime. I haven't found a way to do this with Test::Harness or Test::TAP as they currently are. I was thinking of extending them, overriding as needed, but ideally I would find an existing package to do this. Does anyone know if there is an existing testing harness with which you can pass a parameter to the test files? thanks, Michael
Re: apo5
On Mon, Nov 21, 2005 at 12:08:08PM -0800, Larry Wall wrote:
On Mon, Nov 21, 2005 at 07:57:59PM +0100, Ruud H.G. van Tol wrote:
: There is a [[:alpha:][:digit:] and a [[:alpha:][:digit]] on the
: A5-page.
Hmm, well, thanks--I went to fix it and I see Patrick beat me to
the fix. But in one of the updates, it says:
+[Update: Actually, that's now written C +alpha+digit , avoiding
+the mistaken impression entirely.]
I went ahead and added the update while fixing the typos. :-)
And it occurs to me that we could probably allow alpha+digit there
since there's no ambiguity what alpha means, and we're already claiming
the next character after the opening word to decide how to process the
rest of the text inside angles. Even if someone writes
alpha + digit
that would fail under the current policy of treating + digit as rule,
since you can't start a rule with +.
Somehow I prefer the explicit leading + or -, so that we *know* this
is a rule composition of some sort. It also fits in well with the
convention that the first character after the '' lets you know
what kind of assertion is being created.
Unfortunately, though,
identchar - digit
would be ambiguous, and/or wrong. Could allow whitespace there if we
picked an explicit this is rule character. Did we remove this is
string?
I didn't recall seeing anything that removed this is string, so it's
currently implemented in PGE. It's kind of a nice shortcut:
bracketed: []()
but it would be no real problem to eliminate it and go
strictly with:
bracketed('[]()')
This is rule is currently whitespace, whatever follows is taken to be
a pattern.
But let me know what you decide so I can make the appropriate
changes. :-)
Pm
Re: apo5
On Mon, Nov 21, 2005 at 07:57:59PM +0100, Ruud H.G. van Tol wrote: There is a [[:alpha:][:digit:] and a [[:alpha:][:digit]] on the A5-page. Now fixed. Besides, you have to be able to distinguish s/^/foo/ from s/$/foo/. 's/$/foo/' becomes 's/after .*/foo/' g Uh, no, because after is still a zero width assertion. :-) Pm
Re: apo5
On Mon, Nov 21, 2005 at 11:19:48PM +0100, Ruud H.G. van Tol wrote: Patrick R. Michaud: 's/$/foo/' becomes 's/after .*/foo/' g Uh, no, because after is still a zero width assertion. :-) That's why I chose it. It is not at the end-of-string? Because .* matches , /after .*/ would be true at every position in the string, including the beginning, and this is where foo would be substituted. Pm
Re: apo5
On Tue, Nov 22, 2005 at 01:09:40AM +0100, Ruud H.G. van Tol wrote: 's/$/foo/' becomes 's/after .*/foo/' Uh, no, because after is still a zero width assertion. :-) That's why I chose it. It is not at the end-of-string? Because .* matches , /after .*/ would be true at every position in the string, including the beginning, and this is where foo would be substituted. I expected greediness, also because after .*? could behave non-greedy. ... But why does after .* behave non-greedy? I think you may be misreading what after .* does -- it's a lookbehind assertion. An assertion such as after pattern attempts to match pattern to the sequence immediately preceding the current match position. It does not mean skip over pattern and then match whatever comes afterwards. The greediness of the .* subpattern in after .* doesn't affect things at all -- after .* is still a zero-width assertion. Since .* can match at every position, after .* will be a successful zero-width match (i.e., a null string) at every position in the target string, including the beginning. So, s/after .*/foo/ matches the first null string it finds -- the one at the beginning of the string -- and replaces it with foo. It's the same as if you had written s/null/foo/, since after .* and null will both end up matching exactly the same (i.e., a zero-width string at any position). If this still doesn't make any sense, contact me off-list and I'll try and explain it there. Pm
Re: \x{123a 123b 123c}
On Mon, Nov 21, 2005 at 09:02:57AM -0800, Larry Wall wrote:
: There's also sp, unless someone redefines the sp subrule.
But you can't use sp in a character class. Well, that is, unless
you write it:
+[ a..z ]+sp
or some such. Maybe that's good enough.
Er, that's now +[ a..z ]+sp, unless you're now changing it back.
: And in the general case that's a slightly more expensive mechanism
: to get a space (it involves at least a subrule lookup). Perhaps
: we could also create a visible meta sequence for it, in the same
: way that we have visible metas for \e, \f, \r, \t. But I have
: no idea what letter we might use there.
Something to be said for \_ in that regard.
Yes, I thought of \_ but mentally I still have trouble
classifying _ along with the alphabetics -- '_' looks more
like punctuation to me. And in general we use backslashes
in front of metacharacters to remove their meta meaning
(or when we aren't sure if a character has a meta meaning),
so that \_ somehow seems like it ought to be a literal
underscore, guarding against the possibility that the unescaped
underscore has a meta meaning. (And yes, I can shoot
holes in this line of thinking along with everyone else.)
Whatever shortcuts we introduce, I'll be happy if we can just
rule that backslash+space (i.e., \ ) is a literal space
character -- i.e., keeping the principle that placing a backslash
in front of a metacharacter removes that character's meta
behavior.
I dunno. If «...» in ordinary code does shell quoting, maybe «...» in
rules does filename globbing or some such. I can see some issues with
anchoring semantics. Makes more sense on a string as a whole, but maybe
can anchor on element boundaries if used on a list of filenames.
I suppose one could even go as far as
rule jpeg :i « *.jp{e,}g »
or whatever the right glob syntax is.
Since we already have :perl5, I'd think that we'd want globbing
to be something like
rule jpeg :i :glob /*.jp{e,}g/
or, for something intra-rule-ish:
m :w / mv (:glob *.c)+ dir /
And perhaps we'd want a general form for specifying other
pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
:syntax('perl5') and :syntax('glob') or something like that.
Pm
Re: statement_controlfoo() (was Re: lvalue reverse and array views)
On Mon, 21 Nov 2005, Larry Wall wrote: I would like to publicly apologize for my remarks, which were far too harsh for the circumstances. I can only plead that I was trying to be far too clever, and not thinking about how it would come across. No, to be perfectly honest, it was more culpable than that. I had a niggling feeling I was being naughty, and I ignored it. Shame on me. I will try to pay better attention to my conscience in the future. Oh, I'm not the person you were responding to, and probably the less entitled one to speak in the name of everyone else here, but I feel like doing so to say that in all earnestness I'm quite sure no one took any offense out of your words. Despite the slight harshness, they're above all witty. Just as usual: and that's the style we all like! Michele -- La vita e' come una scatola di cioccolatini: un regalo banale. - scritta su un muro, V.le Sabotino - Milano.
Re: Passing a parameter to test files
On Tuesday 22 November 2005 01:10, [EMAIL PROTECTED] wrote: Hi All, I have been trying to find a way to combine the functionality of Test::Harness with testing scripts that take a parameter. Here is my situation: I am trying to test a database configuration for one specific ID. This ID is essentially part of primary key for several tables and we would like to make sure that the data in the tables follows certain rules. Of course, the rules are rather complicated, so I thought the tests could be written in perl. Basically, the setup I am considering is as follows: - There would be a directory of .t files that all test a different part of the configuration - All of the .t files would take the ID as an argument, so they could be executed as perl testfile.t SPECIFIC-ID - I could use Test::Harness to run all these test files, passing the specific ID in at runtime. Why not generate seperate test files that will system() or exec() the real test file by calling it with its ID? For example: t/test1.t -- will have : system(t/Tests/real_test.t, SPECIFIC-ID1); t/test2.t -- will have : system(t/Tests/real_test.t, SPECIFIC-ID2); Etc. Regards, Shlomi Fish - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ 95% of the programmers consider 95% of the code they did not write, in the bottom 5%.
Re: Passing a parameter to test files
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2005-11-22 10:10]:
I haven't found a way to do this with Test::Harness or
Test::TAP as they currently are.
You could take the id from either the commandline or an
environment variable. Then you could run the harness as something
like
TEST_DB_ID=42 make test
and have the scripts pick it up from $ENV{TEST_DB_ID} if they
don't find it in $ARGV[0].
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Problem with perl code - coverage during build
Selon Dharmesh Vyas [EMAIL PROTECTED]: Hello Group, I am trying to test the perl component and find the code coverage for the same.I have wrote a parser that analyses the generated perl test log files. I am using the version 5.8.7 of perl. I am trying to do the code coverage using bullseye. But while I am trying to build the component I am getting the following error. Does any one have any idea on this. It would be great if someone can suggest me something. If you're trying to calculate the code coverage of the Perl code itself (as opposed to the code coverage of a module), you can take a look at how it is done using gcov and maybe adapt it for Bullseye. The gcov way is to add the -fprofile-arcs -ftest-coverage flags to Configure ccflags and ldflags, -O0 -g to optimize, and then execute the perl.gcov target: ./Configure -Dusedevel -Doptimize='-O0 -g' \ -Accflags='-fprofile-arcs -ftest-coverage' \ -Aldflags='-fprofile-arcs -ftest-coverage' make perl.gcov Then, using Devel::Cover tools, you can generate something like this: http://www.maddingue.net/perlcover/ -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
pdd20 and :outer
Below are two cases of inner subs in Perl5 and Python. The first
(do_add3) is a plain nested subroutine, which is in the call chain. The
second (mk_add3) uses a closure. perl5 can't deal with case 1 properly
and warns.
The question is: should Parrot cover case 1 too with :outer and it's
default LexPad, or how would the code be translated to PIR?
NB: currently both are working in Parrot with :outer, second is using
the 'newclosure' opcode..
Examples in other laguages welcome too.
leo
$ cat outer.pl
#!/usr/bin/perl -w
use strict;
sub do_add3 {
my $a = $_[0];
sub add3 {
$a + 3;
}
add3;
}
print do_add3(20), \n;
print do_add3(21), \n;
sub mk_add3 {
my $a = $_[0];
return sub {
$a + 3;
}
}
my $f = mk_add3(39);
print $f, \n;
$f = mk_add3(40);
print $f, \n;
$ perl outer.pl
Variable $a will not stay shared at outer.pl line 7.
23
23
42
43
$ cat outer.py
#!/usr/bin/env python
def do_add3(arg):
a = arg
def add3():
return a + 3
return add3()
print do_add3(20)
print do_add3(21)
def mk_add3(arg):
a = arg
return lambda: a + 3
f = mk_add3(39)
print f()
f = mk_add3(40)
print f()
$ python outer.py
23
24
42
43
Re: \x{123a 123b 123c}
On Mon, Nov 21, 2005 at 11:25:20AM -0600, Patrick R. Michaud wrote:
: On Mon, Nov 21, 2005 at 09:02:57AM -0800, Larry Wall wrote:
: : There's also sp, unless someone redefines the sp subrule.
:
: But you can't use sp in a character class. Well, that is, unless
: you write it:
:
: +[ a..z ]+sp
:
: or some such. Maybe that's good enough.
:
: Er, that's now +[ a..z ]+sp, unless you're now changing it back.
No, just me going senile.
: : And in the general case that's a slightly more expensive mechanism
: : to get a space (it involves at least a subrule lookup). Perhaps
: : we could also create a visible meta sequence for it, in the same
: : way that we have visible metas for \e, \f, \r, \t. But I have
: : no idea what letter we might use there.
:
: Something to be said for \_ in that regard.
:
: Yes, I thought of \_ but mentally I still have trouble
: classifying _ along with the alphabetics -- '_' looks more
: like punctuation to me. And in general we use backslashes
: in front of metacharacters to remove their meta meaning
: (or when we aren't sure if a character has a meta meaning),
: so that \_ somehow seems like it ought to be a literal
: underscore, guarding against the possibility that the unescaped
: underscore has a meta meaning. (And yes, I can shoot
: holes in this line of thinking along with everyone else.)
I think we'll leave both _ and \_ meaning the same thing, just to avoid
that confusion path--I've seen people backwhacking anything remotely
resembling punctuation just in case it's a metacharacter, and if they
are confused about _, they might backwhack it. More to the point,
I think sp and +sp are about the right Huffman length, given that
matching a single space is usually wrong. You usually want \s or \s*.
: Whatever shortcuts we introduce, I'll be happy if we can just
: rule that backslash+space (i.e., \ ) is a literal space
: character -- i.e., keeping the principle that placing a backslash
: in front of a metacharacter removes that character's meta
: behavior.
Yes, that will be a space.
: I dunno. If «...» in ordinary code does shell quoting, maybe «...» in
: rules does filename globbing or some such. I can see some issues with
: anchoring semantics. Makes more sense on a string as a whole, but maybe
: can anchor on element boundaries if used on a list of filenames.
: I suppose one could even go as far as
:
: rule jpeg :i « *.jp{e,}g »
:
: or whatever the right glob syntax is.
:
: Since we already have :perl5, I'd think that we'd want globbing
: to be something like
:
: rule jpeg :i :glob /*.jp{e,}g/
:
: or, for something intra-rule-ish:
:
: m :w / mv (:glob *.c)+ dir /
Yep, that's what I decided in my other message that was thinking about
using ... for word boundaries and ... for capturing $.
: And perhaps we'd want a general form for specifying other
: pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
: :syntax('perl5') and :syntax('glob') or something like that.
Maybe. Or maybe it's enough that there are syntactic categories for
adding rule modifiers. Doesn't seem like you'd want to parameterize
the current language very often.
Larry
Re: \x{123a 123b 123c}
On Tue, Nov 22, 2005 at 07:52:24AM -0800, Larry Wall wrote:
I think we'll leave both _ and \_ meaning the same thing, just to avoid
that confusion path [...]
Yay!
: Whatever shortcuts we introduce, I'll be happy if we can just
: rule that backslash+space (i.e., \ ) is a literal space
: character -- i.e., keeping the principle that placing a backslash
: in front of a metacharacter removes that character's meta
: behavior.
Yes, that will be a space.
Yay!
: Since we already have :perl5, I'd think that we'd want globbing
: to be something like
: rule jpeg :i :glob /*.jp{e,}g/
: or, for something intra-rule-ish:
: m :w / mv (:glob *.c)+ dir /
Yep, that's what I decided in my other message that was thinking about
using ... for word boundaries and ... for capturing $.
Yay! (Our messages on this crossed in the mail; mine was moderated for
some reason but that's been corrected.)
: And perhaps we'd want a general form for specifying other
: pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
: :syntax('perl5') and :syntax('glob') or something like that.
Maybe. Or maybe it's enough that there are syntactic categories for
adding rule modifiers. Doesn't seem like you'd want to parameterize
the current language very often.
At least within PGE, I'm starting to come across the situation
where each application and host language wants its own slight variations
of the regular expression syntax (for compatibility reasons).
And I figured that since we (conjecturally) have C:lang('PIR'),
C:lang('Python') and C:lang('TCL') to indicate the language
to be used for the closures within a rule, it might be nice to
have a similar parameterized modifier for the pattern syntax
itself.
I was also thinking that one of the tricky parts to custom rule
modifiers such as :perl and :glob is that they actually change
the parsing for whatever follows, so it might be nice to have
a parameterized form to hook into rather than defining a custom
modifier for each syntax variant. But on thinking about it
further from an implementation perspective I guess it all comes
out the same anyway...
Pm
Re: statement_controlfoo() (was Re: lvalue reverse and array views)
On Tue, Nov 22, 2005 at 10:12:00AM +0100, Michele Dondi wrote: : Oh, I'm not the person you were responding to, and probably the less : entitled one to speak in the name of everyone else here, but I feel like : doing so to say that in all earnestness I'm quite sure no one took any : offense out of your words. Despite the slight harshness, they're above all : witty. Just as usual: and that's the style we all like! I like witty sayings as much as the next guy, but wit can hurt when misdirected. If people want me to be machine for cranking out quote file fodder, I'll do my best. But I also care about my friends. Larry
DynLexPad
dynclasses/dynlexpad.pmc provides (or should eventually provide) a more dynamic lexpad (similar to the deprecated scratchpad.pmc). It's not finished yet, it doesn't consult LexInfo for static lexicals yet. Before working more on it, I'd like to know from HLL authors, what they need. Currently it looks like this SYNOPSIS .sub _load :immediate# (1) $P0 = loadlib 'dynlexpad' .end .HLL foo, # or foo_group - load dynamic PMCs too .HLL_map .LexPad - .DynLexPad # (2) .sub main :main :lex # (3) $P0 = new .Integer store_lex 0, 'a', $P0 # (4) ... $P1 = find_lex 'a' # no pad_depth (yet) .end DESCRIPTION (1) The :immediate sub is run before the parsing proceeds, the DynLexPad is already avialable at (2) so that .constant syntax works. (2) installs for the given HLL named foo the DynLexPad as the one to be used. (3) denotes the main sub as needing a lexpad (see also pdd20) (4) stores the lexical into the DynLexPad hash as a new entry. The 'pad_depth' integer is needed for an initial store_lex, but otherwise ignored, specifically it doesn not allow (yet) a store into an outer lexpad. See also t/dynclass/dynlexpad.t and dynclasses/dynlexpad.pmc Comments welcome leo
Re: \x{123a 123b 123c}
Patrick wrote:
Since we already have :perl5, I'd think that we'd want globbing
to be something like
rule jpeg :i :glob /*.jp{e,}g/
or, for something intra-rule-ish:
m :w / mv (:glob *.c)+ dir /
Here! Here!
And perhaps we'd want a general form for specifying other
pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
:syntax('perl5') and :syntax('glob') or something like that.
Agreed.
Damian
Re: Passing a parameter to test files
thanks for the help! I think using the environment variable is a really easy way to achieve my goal. thanks again, michael
Re: \x{123a 123b 123c}
On Tue, Nov 22, 2005 at 08:19:04PM +1100, Damian Conway wrote:
: And perhaps we'd want a general form for specifying other
: pattern syntaxes; i.e., :perl5 and :glob are shortcuts for
: :syntax('perl5') and :syntax('glob') or something like that.
:
: Agreed.
But the language in the following lexical scope is a constant, so what can
:syntax($foo) possibly mean? [Wait, this is Damian I'm talking to.]
Nevermind, don't answer that...
And there aren't that many regexish languages anyway. So I think :syntax
is relatively useless except for documentation, and in practice people
will almost always omit it, which makes it even less useful, and pretty
nearly kicks it over into the category of multiplied entities for me.
Larry
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
Below are two cases of inner subs in Perl5 and Python. The first
(do_add3) is a plain nested subroutine, which is in the call chain. The
second (mk_add3) uses a closure. perl5 can't deal with case 1 properly
and warns.
The question is: should Parrot cover case 1 too with :outer and it's
default LexPad, or how would the code be translated to PIR?
sub do_add3 {
my $a = $_[0];
sub add3 {
$a + 3;
}
add3();
}
What Perl 5 does with that case is just a plain old bug, or more
precisely, a consequence of how Perl 5 implements capturing a lexical
environment. It's just bad. Don't even try supporting it.
OTOH, that same case in Perl 6 is a normal closure and is supported with
the default LexPad:
.sub do_add3
get_params (0), $P0
.lex '$a', $P0
.lex 'add3', $P1
.const .Sub add3 = add3
$P1 = newclosure add3
$P1()
.end
.sub add3 :anon :outer(do_add3)
$P0 = fetch_lex '$a'
$P1 = $P0 + 3
.return ($P1)
.end
--
Chip Salzenberg [EMAIL PROTECTED]
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote: $P0 = fetch_lex '$a' I meant find_lex, of course. PS: fetch_*, get_*, find_*, ... so many naming conventions, so little reason for them. -- Chip Salzenberg [EMAIL PROTECTED]
Re: pdd20 and :outer
your example in the previous message made me think. what will parrot do if a parrot sub declares the :outer subpragma, and the sub to which it refers doesn't have a lexical pad? something like: .sub do_add3 .const .Sub add3 = add3 $P1 = newclosure add3 $P1() .end .sub add3 :anon :outer(do_add3) .return ($P1) .end compile error? runtime error? warning only, and error on lexical access in inner sub? ~jerry
Re: \x{123a 123b 123c}
Larry Wall wrote: And there aren't that many regexish languages anyway. So I think :syntax is relatively useless except for documentation, and in practice people will almost always omit it, which makes it even less useful, and pretty nearly kicks it over into the category of multiplied entities for me. Its surprising how many are out there. Even if we ignore the various dialects of standard rexen, we can find interesting examples such as PSL, a language for specifying temporal assertions, for hardware design: http://www.project-veripage.com/psl_tutorial_5.php. Whether one would want to fold this syntax into a Crule is a different question. There are actually a number of competing languages in this space. E.g. http://www.pslsugar.org/papers/pslandsva.pdf.
Re: DynLexPad
Leopold Toetsch wrote: Before working more on it, I'd like to know from HLL authors, what they need. I don't think I need anything more than :outer and .lex for the Amber compiler. I certainly don't need to specify or manipulate pad_depth. .HLL_map .LexPad - .DynLexPad # (2) Why not use , instead of -? It would be one less special-case for the PIR programmer to remember. PDD20 says: .HLL Tcl, tcl_group ... P0 = new Integer# really TclInteger What do I write when I really want a new Integer (e.g. to pass to a routine written in something other than the current .HLL?)? I'd prefer to ask for mappings explicitly, e.g. something like this: .HLL Tcl, tcl_group ... $P0 = new Integer # really Integer $P1 = new_mapped Integer # really TclInteger Regards, Roger Browne
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 09:42:38AM -0800, jerry gay wrote:
your example in the previous message made me think. what will parrot
do if a parrot sub declares the :outer subpragma, and the sub to which
it refers doesn't have a lexical pad?
Nothing; that's entirely legal. And it's even useful, *if* the outer
sub has a :outer of its own.
sub foo ($a) {
my sub bar {
my sub baz { $a }
baz; #note - this returns a reference
}
bar();
}
While bar has no pad, it does have :outer(foo), so the find_lex in
baz will work.
.sub do_add3
.const .Sub add3 = add3
$P1 = newclosure add3
$P1()
.end
.sub add3 :anon :outer(do_add3)
.return ($P1)
.end
compile error? runtime error? warning only, and error on lexical
access in inner sub?
I'd call this correct but silly, kind of like assigning to a register
that doesn't get used afterwards.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: DynLexPad
On Tue, Nov 22, 2005 at 05:50:39PM +, Roger Browne wrote: Leopold Toetsch wrote: .HLL_map .LexPad - .DynLexPad # (2) Why not use , instead of -? Indeed. We shouldn't introduce - at this point, when we already use the perfectly serviceable comma for analogous cases. I'd prefer to ask for mappings explicitly, e.g. something like this: .HLL Tcl, tcl_group ... $P0 = new Integer # really Integer $P1 = new_mapped Integer # really TclInteger Hm. Why? -- Chip Salzenberg [EMAIL PROTECTED]
Re: \x{123a 123b 123c}
On Tue, Nov 22, 2005 at 09:46:59AM -0800, Dave Whipp wrote: : Larry Wall wrote: : : And there aren't that many regexish languages anyway. So I think :syntax : is relatively useless except for documentation, and in practice people : will almost always omit it, which makes it even less useful, and pretty : nearly kicks it over into the category of multiplied entities for me. : : Its surprising how many are out there. We can certainly add a :syntax() modifier as easily as a :foolang modifier, if we decide at some point we really need one, or if PGE could make good use of it even if Perl 6 doesn't want it. Larry
Re: \x{123a 123b 123c}
On Tue, Nov 22, 2005 at 10:30:20AM -0800, Larry Wall wrote: On Tue, Nov 22, 2005 at 09:46:59AM -0800, Dave Whipp wrote: : Larry Wall wrote: : : And there aren't that many regexish languages anyway. So I think :syntax : is relatively useless except for documentation, and in practice people : will almost always omit it, which makes it even less useful, and pretty : nearly kicks it over into the category of multiplied entities for me. : : Its surprising how many are out there. We can certainly add a :syntax() modifier as easily as a :foolang modifier, if we decide at some point we really need one, or if PGE could make good use of it even if Perl 6 doesn't want it. I'm agreeing with Larry on this one -- let's wait to decide this until we actually feel like we need it. Pm
Re: \x{123a 123b 123c}
On Mon, Nov 21, 2005 at 09:02:57AM -0800, Larry Wall wrote: On Sun, Nov 20, 2005 at 10:27:17AM -0600, Patrick R. Michaud wrote: : On Sat, Nov 19, 2005 at 06:32:17PM -0800, Larry Wall wrote: : We already have, from A5, \x[0a;0d], so you can supposedly say : \x[123a;123b;123c] : : Hmm, I hadn't caught that particular syntax in A05. AFAIK it's not : in S05, so I should probably add it, or whatever syntax we end up : adopting. Yes. Out of curiosity (and so I can update S05 and PGE), what syntax are we adopting? Is it semicolon, comma, space, any combination of the three, or ...? Pm
Re: pdd20 and :outer
On Nov 22, 2005, at 18:32, Chip Salzenberg wrote: OTOH, that same case in Perl 6 is a normal closure and is supported with the default LexPad: Ok. I'll change implementation accordingly. Below is the full code of case 1 / outer.pir leo .pragma n_operators 1 # add creates new PMC result below .sub do_add3 .param pmc arg # looks nicer than get_params .lex '$a', arg .lex 'add3', $P1 .const .Sub add3 = add3 $P1 = newclosure add3 $P2 = $P1()# tailcall eventually - b0rked .return ($P2) .end .sub add3 :anon :outer(do_add3) :lex $P0 = find_lex '$a' $P1 = $P0 + 3 # create/return new value .return ($P1) .end .sub main :main $P0 = do_add3(20) print $P0 print \n $P1 = do_add3(21) print $P1 print \n .end
Re: \x{123a 123b 123c}
On Tue, Nov 22, 2005 at 12:48:39PM -0600, Patrick R. Michaud wrote: : On Mon, Nov 21, 2005 at 09:02:57AM -0800, Larry Wall wrote: : On Sun, Nov 20, 2005 at 10:27:17AM -0600, Patrick R. Michaud wrote: : : On Sat, Nov 19, 2005 at 06:32:17PM -0800, Larry Wall wrote: : : We already have, from A5, \x[0a;0d], so you can supposedly say : : \x[123a;123b;123c] : : : : Hmm, I hadn't caught that particular syntax in A05. AFAIK it's not : : in S05, so I should probably add it, or whatever syntax we end up : : adopting. : : Yes. : : Out of curiosity (and so I can update S05 and PGE), what syntax : are we adopting? Is it semicolon, comma, space, any combination of the : three, or ...? S02.pod currently has it as comma. Larry
mapped PMC type (was: DynLexPad)
On Nov 22, 2005, at 18:50, Roger Browne wrote: Leopold Toetsch wrote: .HLL_map .LexPad - .DynLexPad # (2) Why not use , instead of -? It would be one less special-case for the PIR programmer to remember. No problem. If folks prefer a comma I'll change it. PDD20 says: .HLL Tcl, tcl_group ... P0 = new Integer# really TclInteger What do I write when I really want a new Integer (e.g. to pass to a routine written in something other than the current .HLL?)? Ah, have missed that in the pdd - that's misleading. $P0 = new .Integer always produces a .Integer and never a mapped type. If the programmer wants that she can always write: $P0 - new .TclInt Mapped types are only created inside Parrot C code and never from PASM/PIR. E.g. the builtin Complex.abs() vtable has to create a .Float result. Here the mapping of a .Float to a .PyNum is honored. The same is true, when Parrot has to create a lexpad on behalf of the HLL, then a mapping is used. Regards, Roger Browne leo
TAP as XML
Hello all, I'm in the planning stages for a project (brief planning notes http://examples.petersfamily.org/smolder.html if interested) that will be used to collect test reports for project and make them viewable on the web. I want to change as little about the way they run their tests, but still be able to collect all of the needed data. I thought about using prove with --verbose, and have the users pipe that into a file. But it's not quite TAP since it changes the plan line and outputs aggregate results at the end. My other idea was to create an XML version of TAP (probably as a micro-format (http://www.xml.com/pub/a/2005/03/23/deviant.html,http://www.microformats.org/) so that it's still viewable in a browser. TAML? While I want to avoid creating yet-another-xml-language, XML seems like a good solution for sharing and storing smoke test results. Another reason to use something wrapped around TAP would be to collect other information that TAP does not provide, like platform, date and time run, time to completely run, and if applicable developer name. Does any of this seem reasonable? Overkill? Already done? Thanks, -- Michael Peters Developer Plus Three, LP
Re: dis-junctive patterns
On Tue, Nov 22, 2005 at 09:31:27AM +0200, Gaal Yahas wrote: : In pugs, r7961: : : my @pats = /1/, /2/; : say MATCH if 1 ~~ any @pats; # MATCH : say MATCH if 0 ~~ any @pats; # no match : : So far so good. But: : : my $junc = any @pats; : say MATCH if 1 ~~ $junc; # no match : say MATCH if 0 ~~ $junc; # no match : : Bug? Feature? Feels like a bug to me. The junction should autothread the ~~ even if ~~ weren't dwimmy. And ~~ ought to be dwimmy about junctions even if they didn't autothread. Maybe they're just doing the hallway dance. Larry
Re: TAP as XML
Michael There's existing work happening in this area you may want to get involved in. We even have a draft XML schema that does exactly what you are talking about. Go read http://ali.as/pita/ Then come hang out on irc://irc.perl.org/#pita Adam K Michael Peters wrote: Hello all, I'm in the planning stages for a project (brief planning notes http://examples.petersfamily.org/smolder.html if interested) that will be used to collect test reports for project and make them viewable on the web. I want to change as little about the way they run their tests, but still be able to collect all of the needed data. I thought about using prove with --verbose, and have the users pipe that into a file. But it's not quite TAP since it changes the plan line and outputs aggregate results at the end. My other idea was to create an XML version of TAP (probably as a micro-format (http://www.xml.com/pub/a/2005/03/23/deviant.html,http://www.microformats.org/) so that it's still viewable in a browser. TAML? While I want to avoid creating yet-another-xml-language, XML seems like a good solution for sharing and storing smoke test results. Another reason to use something wrapped around TAP would be to collect other information that TAP does not provide, like platform, date and time run, time to completely run, and if applicable developer name. Does any of this seem reasonable? Overkill? Already done? Thanks,
Re: TAP as XML
Michael, You might want to look at some of the work on the Pugs test suite. http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl It uses (among other things) Test::TAP::Model and Test::TAP::HTMLMatrix, and uses YAML as an intermediate test-run format. Stevan On Nov 22, 2005, at 2:11 PM, Michael Peters wrote: Hello all, I'm in the planning stages for a project (brief planning notes http://examples.petersfamily.org/smolder.html if interested) that will be used to collect test reports for project and make them viewable on the web. I want to change as little about the way they run their tests, but still be able to collect all of the needed data. I thought about using prove with --verbose, and have the users pipe that into a file. But it's not quite TAP since it changes the plan line and outputs aggregate results at the end. My other idea was to create an XML version of TAP (probably as a micro-format (http://www.xml.com/pub/a/2005/03/23/deviant.html,http:// www.microformats.org/) so that it's still viewable in a browser. TAML? While I want to avoid creating yet-another-xml-language, XML seems like a good solution for sharing and storing smoke test results. Another reason to use something wrapped around TAP would be to collect other information that TAP does not provide, like platform, date and time run, time to completely run, and if applicable developer name. Does any of this seem reasonable? Overkill? Already done? Thanks, -- Michael Peters Developer Plus Three, LP
Re: TAP as XML
Stevan Little wrote: Michael, You might want to look at some of the work on the Pugs test suite. http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl It uses (among other things) Test::TAP::Model and Test::TAP::HTMLMatrix, and uses YAML as an intermediate test-run format. Actually, Test::TAP::HTMLMatrix is what I currently use for test reports that get emailed to developers. I definitely plan to continue using it. Also, seeing the pugs smoke server demoed as part of Atrijus's YAPC::NA presentation also gave me some ideas along these lines. I would like to take all of your good ideas (I know, I'm a thief) and create a standalone application that any project could use. Do you still think that YAML is a good intermediate format choice? Do you think an integration with other standard utilities to produce YAML would be possible (prove, etc)? Thanks for the links. It'll give me more to think about. -- Michael Peters Developer Plus Three, LP
Re: syntax for accessing multiple versions of a module
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote: I have been meaning to do some kind of p5 prototype of this, I can push it up the TODO list if it would help you. As you can probably infer from the amount of time that it has taken for me to realise that I've failed to reply to you, I think that I already have rather too much going on to be able to take advantage of anything in the near future. So thanks for the offer, but please do thinks in the order that is most logical to you. Nicholas Clark
Re: TAP as XML
Michael, On Nov 22, 2005, at 3:13 PM, Michael Peters wrote: Stevan Little wrote: Michael, You might want to look at some of the work on the Pugs test suite. http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl It uses (among other things) Test::TAP::Model and Test::TAP::HTMLMatrix, and uses YAML as an intermediate test-run format. Actually, Test::TAP::HTMLMatrix is what I currently use for test reports that get emailed to developers. I definitely plan to continue using it. Also, seeing the pugs smoke server demoed as part of Atrijus's YAPC::NA presentation also gave me some ideas along these lines. I would like to take all of your good ideas (I know, I'm a thief) and create a standalone application that any project could use. Ah, these are not my ideas, so steal away ;) Do you still think that YAML is a good intermediate format choice? Do you think an integration with other standard utilities to produce YAML would be possible (prove, etc)? Actually, you should contact Yuval Kogman (aka nothingmuch) (aka - the author of Test::TAP::*) about these questions (you could also check irc.freenode.net #perl6, people there might be able to help). But I really just gave general encouragement and occasional suggestions to this project, so I am not equipped to answer your questions. All that said, what you are talking about does sound quite interesting :) Stevan
Re: DynLexPad
I wrote: I'd prefer to ask for mappings explicitly, e.g. something like this: .HLL Tcl, tcl_group ... $P0 = new Integer # really Integer $P1 = new_mapped Integer # really TclInteger Chip wrote: Hm. Why? Because you don't always want a mapped type. You might really want an .Integer to pass to a method that can't usefully work with a TclInteger. Leo has since stated that the automatic mapped type example was in error, so there's actually no problem. Regards, Roger Browne
Re: DynLexPad
On Nov 22, 2005, at 19:52, Chip Salzenberg wrote: On Tue, Nov 22, 2005 at 05:50:39PM +, Roger Browne wrote: Why not use , instead of -? Indeed. We shouldn't introduce - at this point, when we already use the perfectly serviceable comma for analogous cases. Done, r10140. leo
type sigils redux, and new unary ^ operator
I'm changing my mind about type sigils. After playing around with ^
for a while, I find it's useful only in signatures and declarations,
and I'm generally forced to omit it when using it within inner
declarations, or it would redeclare the type. Taking that together
with the fact that it installs a local :: symbol anyway, I think we
can safely go back to the position that the :: sigil in a signature
or declaration captures a parametric type, and otherwise is a no-op.
The problem that worried me (about wanting to refer to a type that
will exist but hasn't been declared yet) does not arise often in
practice, and can be solved with a symbolic ref in any event, or
by predeclaring a stub type.
What tipped me over the edge, however, is that I want ^$x back for a
unary operator that is short for 0..^$x, that is, the range from 0
to $x - 1. I kept wanting such an operator in revising S09. It also
makes it easy to write
for ^5 { say } # 0, 1, 2, 3, 4
Now, while it's true that ^5 is an illegal type name, a unary operator
takes an expression, and that could start with an alpha: ^rand(5).
We could conceivably keep the type sigil if we forced you to say
instead ^(rand(5)) but that seems like a bad non-orthogonality.
So let's go back to ::T for a parametric type, at least until I change
my mind again. Sorry if you feel jerked around.
Larry
Re: TAP as XML
Do you still think that YAML is a good intermediate format choice? Do you think an integration with other standard utilities to produce YAML would be possible (prove, etc)? YAML has a few ... issues. :/ I've laid them out before at http://cpanratings.perl.org/dist/YAML Brian has said that the actual format is fine, but essentially the Perl class sucks ass. But eventually, you end up wanting a really nailed down file format, so that you can use the data in a variety of applications, across a variety of languages. And XML was designed for, and still remains VERY good at, doing neutral format data interchange. Adam K
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Nov 22, 2005, at 1:40, Matt Fowles wrote: Call Frame Access Chip began to pontificate about how one should access call frames. Chip suggested using a PMC, but Leo thought that would be too slow. No, not really. It'll be slower, yes. But my argument was: whenever you start introspecting a call frame, by almost whatever means, this will keep the call frame alive[1] (see Continuation or Closure). That is: timely destruction doesn't work for example and the introspection feature is adding another level of complexity that isn't needed per se, because 2 other solutions are already there (or at least implemented mostly). leo [1] a call frame PMC could be stored elsewhere and reused later, refering to then dead contents. Autrijus mentioned that this will need weak references to work properly.
Re: TAP as XML
* Adam Kennedy [EMAIL PROTECTED] [2005-11-23 01:40]:
And XML was designed for, and still remains VERY good at, doing
neutral format data interchange.
Another option if you want a lightweight format for structured
data is JSON. XML is very nice for documents, particularly with
mixed content; JSON is more human-writable for heavily structured
data, such as config files.
Regards,
--
#Aristotle
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: type sigils redux, and new unary ^ operator
On 11/22/05, Larry Wall [EMAIL PROTECTED] wrote:
What tipped me over the edge, however, is that I want ^$x back for a
unary operator that is short for 0..^$x, that is, the range from 0
to $x - 1. I kept wanting such an operator in revising S09. It also
makes it easy to write
for ^5 { say } # 0, 1, 2, 3, 4
I read this and I'm trying to figure out why P6 needs a unary operator
for something that is an additional character written the more legible
way. To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand. So, ^0 would be -1 (under 2's complement) and ^1 would
be -2. I'm not sure where this would be useful, but that's what comes
to mind when discussing a unary ^.
Thanks,
Rob
Re: Perl 6 Summary for 2005-11-14 through 2005-11-21
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote: But my argument was: whenever you start introspecting a call frame, by almost whatever means, this will keep the call frame alive[1] (see Continuation or Closure). That is: timely destruction doesn't work for example... Destruction or finalization? That is, if I have a filehandle I really want to close at the end of a scope but I don't care when GC drags it into the void, will the close happen even if there's introspection somewhere? -- c
Lexical store semantics - Q for Tcl guys
Quick question for Tcl folks. Currently, store_lex is *always* an aliasing operation. That is, after store_lex 'a', $P0 the old PMC that used to be accessible by $P1 = find_lex 'a' is now gone (unless you kept a reference somewhere else). (To modify an existing lexical, the sequence is $P1 = find_lex 'a' followed by some mutating operation on $P1.) Is this a problem for Tcl implementation? If so, how? -- Chip Salzenberg [EMAIL PROTECTED]
Re: DynLexPad
On Nov 22, 2005, at 11:06 AM, Leopold Toetsch wrote: dynclasses/dynlexpad.pmc provides (or should eventually provide) a more dynamic lexpad (similar to the deprecated scratchpad.pmc). It's not finished yet, it doesn't consult LexInfo for static lexicals yet. Before working more on it, I'd like to know from HLL authors, what they need. Currently it looks like this SYNOPSIS .sub _load :immediate# (1) $P0 = loadlib 'dynlexpad' .end .HLL foo, # or foo_group - load dynamic PMCs too .HLL_map .LexPad - .DynLexPad # (2) I'd like to provide an easy way to provide this mapping for language developers so the users of the language don't have to remember to add the second line whenever they use, e.g. Tcl. I could add another 'pmclass' keyword for this, but it would only really be needed once in the shared library, so lang authors would have to pick one PMC and add it there, so... Seems like the cleanest thing to do is add a subclass for DynLexPad (with no overrides) and map it in the PMC definition to LexPad. Does that sound reasonable? The main problem I see with doing this in the PMC is the dynamic-pmc nature of DynLexPad, which makes me wonder what the PMC code for a subclass would actually look like. .sub main :main :lex # (3) $P0 = new .Integer store_lex 0, 'a', $P0 # (4) ... $P1 = find_lex 'a' # no pad_depth (yet) .end DESCRIPTION (1) The :immediate sub is run before the parsing proceeds, the DynLexPad is already avialable at (2) so that .constant syntax works. (2) installs for the given HLL named foo the DynLexPad as the one to be used. (3) denotes the main sub as needing a lexpad (see also pdd20) (4) stores the lexical into the DynLexPad hash as a new entry. The 'pad_depth' integer is needed for an initial store_lex, but otherwise ignored, specifically it doesn not allow (yet) a store into an outer lexpad. See also t/dynclass/dynlexpad.t and dynclasses/dynlexpad.pmc Comments welcome leo
Re: TAP as XML
A. Pagaltzis wrote: * Adam Kennedy [EMAIL PROTECTED] [2005-11-23 01:40]: And XML was designed for, and still remains VERY good at, doing neutral format data interchange. Another option if you want a lightweight format for structured data is JSON. XML is very nice for documents, particularly with mixed content; JSON is more human-writable for heavily structured data, such as config files. Regards, What XML brings that JSON doesn't is that the data is validation. Life is a hell of a lot easier when you can just validate the .xml file and fire it at a very simple SAX parser without the need for a ton of error-checking logic. Also, JSON only really handles big dump structures. Strings, arrays and hashes. How well it handles dealing with the entire output of test scripts being dumped into it is unknown (by me) too. Adam K
Re: Lexical store semantics - Q for Tcl guys
Chip Salzenberg [EMAIL PROTECTED] wrote: Quick question for Tcl folks. Currently, store_lex is *always* an aliasing operation. That is, after store_lex 'a', $P0 the old PMC that used to be accessible by $P1 = find_lex 'a' is now gone (unless you kept a reference somewhere else). (To modify an existing lexical, the sequence is $P1 = find_lex 'a' followed by some mutating operation on $P1.) Is this a problem for Tcl implementation? If so, how? I don't think it is, no. ParTcl implements global/lexical storage rather naively at the moment (because I didn't understand that the lex opcodes worked this way when I implemented this over the summer). Right now we always use store_lex to assign to a lexical variable instead of using the assign opcode, which breaks things like [global]. In order for things to work properly, we may have to perform 2 find_lex and 1 store_lex/assign operations for append commands (depending on how clever we can be), but that shouldn't be an issue. When we do switch to using assign, the [global] and [upvar] commands should be pretty straightforward to implement (assuming we have access to the caller's lex pad for [upvar]). But I assume that that's why things are implemented as they are. -- matt diephouse http://matt.diephouse.com
Curses and parrot problems?
When I first installed parrot, curses worked with it, but it fails to work anymore for me, either under darwin or freebsd. On darwin, it clears the screen, and can only read assertation failed before it clears and dies, so I can't see diagnostics, but under freebsd I get this. Couldn't load 'libform': /usr/lib/libform.so: Undefined symbol stdscr current instr.: '__ncurses_init' pc 0 (library/ncurses.pasm:2) Assertion failed: ((interpreter-ctx.bp_ps.regs_p[-1L-(cur_opcode[2])])-pmc_ext), function Parrot_dlfunc_p_p_sc_sc, file ops/core.ops, line 1164. Abort Other curses programs work just fine without any problem at all. I'm testing with the ncurses_life.pir or pasm, or whatever the extension is. Has anyone else been having problems with this? Any pointers for getting it working, if it's something I can do? Joshua
