Re: Parrot interfaces
At 8:54 PM -0700 8/16/04, chromatic wrote: On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote: I've noticed there are ops for interfaces, but no implementation or ppd yet. Perl 6 has roles which are much more useful than interfaces -- in fact, interfaces are degenerate roles. See Apocalypse 12 for more. http://www.perl.com/pub/a/2004/04/16/a12.html Parrot does/should have the 'does' op, which ought to check and identify roleishness. I don't know its current status. does checks whether a class somewhere in the hierarchy of the object you're querying says it implements the interface you're asking after. Whether it has anything much to do with perl 6 roles is up in the air--there's some disagreement over that. Discussion as to the differences between roles and interfaces should probably happen on p6l ([EMAIL PROTECTED]) Not for this stuff, no. I'm not on perl6-language, if nothing else, so discussion there won't make any difference to what we do with parrot. :) Looks like this isn't yet implemented. We need some interface add/remove/query ops akin to the add_parent op and its ilk, and some code in the core to walk the tree looking for interfaces. And documentation. That'd be good. I should see if I can get a clear path through the network here today, as it ought to be pretty straightforward to do. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
ninja
[EMAIL PROTECTED] (Thomas Klausner) wrote in message
news:[EMAIL PROTECTED]...
Hi!
On Fri, Jul 23, 2004 at 08:41:58AM +0200, James
Mastros wrote:
BTW, what's $report-{files}{ninja}?
see here:
http://use.perl.org/comments.pl?
Okay, I looked at that link, and the link to one of
acme's pages therein, and I still gotta wonder ...
How do I boost my (modules') ninja?
If I get my mojo working, will my ninja go up?
jimk
=
Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Fine-tuning output from Devel::Cover
Two days ago I uploaded the most recent version of my module List::Compare to CPAN. This was the first version in whose development I used Paul Johnson's Devel::Cover to analyze the test suite's coverage of the module's code and, as a result, over 3300 tests were added, both to test new code and to test older code more thoroughly. The first thing I noticed after using Devel::Cover was how much output it generates. The HTML files depicting the line-by-line status of the coverage are enormous. As an alternative, I generated a plain-text file like so: cover cover_db -report=text LC_coverage_20040814.txt Even that file was large. Since my coverage was fairly good to begin with, what I *really* wanted was a smaller file which reported on the uncovered elements. I took two approaches: (1) hacking up a Perl script which parsed the plain-text report; (2) manually cutting-and-pasting the uncovered elements into a new, much smaller plain-text file. For example, I edited the file so that only subroutines with uncovered branches were printed out. But I wondered: Wouldn't be easier to pass options to 'cover' so that a report focusing on uncovered items would be generated? Is this possible now? The documentation for cover's options is, to say the least, very terse, and I can't tell whether it can DWIW. So: Can Devel::Cover's 'cover' program be used to generate reports of uncovered statements/branches/conditions/only? Thank you very much. Jim Keenan = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: Updates to modules-related pod
On Tue, Aug 17, 2004 at 09:50:11AM +0200, Rafael Garcia-Suarez ([EMAIL PROTECTED]) wrote: BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ? Yeah, now we just post to use.perl.org. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #31209] nci_test.o needs compiling with position independant code
Nicholas Clark (via RT) wrote: # New Ticket Created by Nicholas Clark # Please include the string: [perl #31209] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31209 --- osname= linux osvers= 2.6.6 arch= x86_64-linux-thread-multi cc= cc --- Flags: category=core severity=high ack=no --- Attempting to build the nci test dynamic library on an Opteron fails: cc -shared -L/usr/local/lib -fPIC -L/usr/local/lib -g \ -o runtime/parrot/dynext/libnci.so src/nci_test.o /usr/bin/ld: src/nci_test.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC src/nci_test.o: could not read symbols: Bad value collect2: ld returned 1 exit status I infer that the code for nci_test.o needs to be compiled with the appropriate position independent code flag, but I don't know how to this portably. Hi, currently I'm looking into 'libtool' for turning 'libsyck.a' into a shared library. This brings me to the idea, wether it would it be an option to use 'libtool' for library building stuff within parrot. 'libtool' from the commandline seems to have unexpectedly little cruftiness. However I don't know about Win32 support. CU, Bernhard -- ** Dipl. Phys. Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Interfaces, briefly
This needs some docs, but I figured I'd throw out the short description to the list since they've come up, and we ought to finish them. For parrot, interfaces are *very* simple things. An interface is a string tag which can be attached to a class. Each class can have multiple interface tags attached to it. The does op walks an object's hierarchy looking to see if any class in the hierarchy has the queried interface tag. That's it. Very simple. There's no checking of class names or anything -- if a class implements an interface of the same name then it should tag itself as implementing an interface with the class name. The whole point of the interface design here is so code that checks to see if an object can do something can check to see if an object implements the interface: object.does(Storable); rather than seeing if the object implements a particular method: object.can(freeze); or is in a particular class: object.isa(Storable); since presumably interfaces are a bit more uniquely named than methods, and an object may be able to do something some class does while not actually being in that class. Interfaces aren't inheritable, have no metadata, aren't orange, can't be instantiated, and have no methods/attributes/slots/properties. Now, that's not to say that a language can't have something it calls an interface which has slots or methods or can be inherited from. That's fine. (Granted, it'd be a parrot class with an interface attached, rather than a pure parrot interface, but there's nothing saying what *you* call something has to match what *we* call something :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Interfaces, briefly
since presumably interfaces are a bit more uniquely named than methods, and an object may be able to do something some class does while not actually being in that class. should interface names be registered somewhere? how are collisions handled? i can imagine a scenario where multiple 'print' interfaces have been created. how will parrot handle this? or am i missing something basic? ~jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
RE: Interfaces, briefly
At 10:55 AM -0400 8/17/04, Gay, Jerry wrote: since presumably interfaces are a bit more uniquely named than methods, and an object may be able to do something some class does while not actually being in that class. should interface names be registered somewhere? Nope. how are collisions handled? They aren't. i can imagine a scenario where multiple 'print' interfaces have been created. how will parrot handle this? or am i missing something basic? Basically if you have two or more interfaces with the same name parrot can't distinguish them, and doesn't know they're not the same thing. In this case there's no difference than if you have two or more methods named, say, 'run', which do very different things. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Fine-tuning output from Devel::Cover
On Tue, Aug 17, 2004 at 06:22:13AM -0700, Jim Keenan wrote: Two days ago I uploaded the most recent version of my module List::Compare to CPAN. This was the first version in whose development I used Paul Johnson's Devel::Cover to analyze the test suite's coverage of the module's code and, as a result, over 3300 tests were added, both to test new code and to test older code more thoroughly. Wow! The first thing I noticed after using Devel::Cover was how much output it generates. The HTML files depicting the line-by-line status of the coverage are enormous. You think they are large now ... :-) As an alternative, I generated a plain-text file like so: cover cover_db -report=text LC_coverage_20040814.txt Even that file was large. Since my coverage was fairly good to begin with, what I *really* wanted was a smaller file which reported on the uncovered elements. I took two approaches: (1) hacking up a Perl script which parsed the plain-text report; (2) manually cutting-and-pasting the uncovered elements into a new, much smaller plain-text file. For example, I edited the file so that only subroutines with uncovered branches were printed out. But I wondered: Wouldn't be easier to pass options to 'cover' so that a report focusing on uncovered items would be generated? Is this possible now? The documentation for cover's options is, to say the least, very terse, and I can't tell whether it can DWIW. At the moment, no, there is no option to do what you want. So: Can Devel::Cover's 'cover' program be used to generate reports of uncovered statements/branches/conditions/only? What you want to do (no really, you do) is to write a new report which only reports on the uncovered constructs. Or maybe an option to the existing report(s) is a better solution. Or maybe an interactive backend is the real solution, using Tk, or Gtk, or Wx, or CGI or whatever. I have deliberately made it as easy as possible to write new backends in the hope that people would do so when the need arose. The trouble is that Michael made the current default report so nice that most people don't even consider the need for something different. But writing a new backend is fairly simple. It's probably easiest to copy from one of the existing ones - Text is the shortest and clearest. There is an API to access the coverage data, you can pass in options from cover, and with the backend in the Report subdirectory it can be called from cover. If anyone wants to write a new backend, I'd be happy to include it in the distribution, or for you to release it separately. Just be aware that the main reason I still call the code alpha is because there may still need to be API changes. Hopefully only minor ones or backwards compatible ones now though. So I'm afraid that at the moment there is nothing to do what you want, and your options range from cover -report text | grep '\*\*\*' through to writing a full blown gui backend. By the way, how big is enormous? I had never expected the size of the HTML output to be a problem, but it obviously is to some people. The current output is much smaller than that from the report that I originally wrote. I don't think there's much scope for reducing its size without also reducing the content. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Interfaces, briefly
Dan Sugalski [EMAIL PROTECTED] wrote: This needs some docs, but I figured I'd throw out the short description to the list since they've come up, and we ought to finish them. $ cat does.pasm new P0, .Array does I0, P0, array print I0 does I0, P0, scalar print I0 print \n end $ parrot does.pasm 10 TODO is AFAIK walk the parent chain and define some standard names for known interfaces we provide. And the dynamic variants of interface changes. The class compiler understands: pmclass Class ... does foo does bar leo
Re: Fine-tuning output from Devel::Cover
The first thing I noticed after using Devel::Cover was how much output
it generates. The HTML files depicting the line-by-line status of the
coverage are enormous.
I assume you're talking about the large amount of data reported and not
the actual file sizes? The HTML files are massive problem was fixed
quite a while ago.
As an alternative, I generated a plain-text file like so:
cover cover_db -report=text LC_coverage_20040814.txt
Even that file was large.
You're generating basically the same report in a different format. You
should expect the same volume of data.
Since my coverage was fairly good to begin with, what I *really*
wanted was a smaller file which reported on the uncovered elements.
[...]
Can Devel::Cover's 'cover' program be used to generate reports of
uncovered statements/branches/conditions/only?
No. There's (currently) no option for doing so. The HTML is well formed,
though, which should make building a filter easy if you know how the
formatting works. ;) e.g.:
#!/usr/bin/perl
use strict;
use warnings;
while () {
# remove source lines with no coverage data
next if (/class=s/ ! /class=c./);
# remove source lines without at least some missing coverage
next if (/class=c./ ! /class=c[012]/);
print;
}
__END__
Add a little nice packaging and that should do the trick.
-mjc
Re: Revision of A12's lookahead notions
On Tue, Aug 10, 2004 at 11:07:59AM -0700, Larry Wall wrote:
2) In the absence of evidence to the contrary, methods always
assume they have *no* arguments. For methods:
2a) A method not followed by a left paren or colon has no
arguments.
Just checking--whitespace doesn't count, right?
foo(1,2,3);# Func with 3 args
foo (1,2,3); # Same exact thing
When you say *no* arguments, does that mean that they do not get
passed the implicit $self ref? (Or is that even relevant anymore?)
2b) As with multies, method declarations can have no effect on the
parsing of methods. Unlike multis, the default is no arguments.
So, this doesn't work:
method foo($$$);
.foo 1,2,3; # WRONG!
2d) Given 2c, additional arguments may occur as adverbs
whether or not there is an argument pill:
pill == parenthesized arg list?
3) A bare {...} where an operator is expected always terminates the
current list operator, and takes the precedence level back to statement
level. That is, it pops all the implicit left parentheses of list
operators with implicit right parentheses.
Is that a metasyntactic {...} or a literal y3 (yadda-yadda-yadda)
operator?
(Side note: This is my biggest problem with this operator--it makes
discussions about pseudo- and/or skeleton code highly ambiguous.)
3a) Note that an operator {...} cannot occur in the arguments of either
a function or a method. Operator {...} is reserved for statement level
control flow blocks.
if blurk {...} {...}# 1st closure is arg, 2nd ifblock
if blurk(1) {...} # closure is ifblock
if blurk 1 {...} # closure is ifblock
if .blurk {...} # closure is ifblock
if .blurk {...} {...} # 1st is ifblock, 2nd is bare block?
Does that final question mark indicate uncertainty on your part about
how the language should be defined, or uncertainty on the parser's
part about what the code means?
if .blurk 1 {...} # ILLEGAL
Just checking...this is illegal because 2c says that [t]he only way
to pass arguments to a method is by an explicitly parenthesized list
or by adverb. Or by both. Correct? If the '1' wasn't there, then
you'd have a legal statement (as per example above).
3b) Term {...} cannot assume a comma after it if the next thing is
a closure. Otherwise the first line under 3a breaks. The fifth
line with a bare block is a bit problematic as a silent failure mode
if the user expects the first block to be an argument to .blurk, which
it isn't.
3c) Actually, despite the fact that I stated 3 in terms of
precedence, as far as the parser is concerned 3 probably
means that statement control things are parsed top down,
and the bottom up expression parser simply stops when it hits
an operator {...}.
4) Adverbs apply to the previous unparenthesized prefix, infix,
or postfix operator, bypassing simple terms and other pill
operators such as circumfix or postcircumfix.
$a + $b :foo# applies to +
$a + @b[2] :foo # applies to +
$a + int($b) :foo # applies to int
$a + (int($b)) :foo # applies to +
@a.=sort:{ +$_ }# applies to .sort
@a.sort(:quick):{ +$_ } # applies to .sort
@a.sort:quick:{ +$_ } # both adverbs apply to .sort
Yoiks. This gives me the screaming willies. Couldn't we make it nice
and simple and say that adverbs must immediately follow (or
immediately precede, whichever you prefer, but pick one) their
operator?
$a +:foo $b # applies to +
$a +:foo @b[2] # applies to +
$a + int:foo($b)# applies to int
$a + (int($b)) :foo # WRONG!
@a.=sort:{ +$_ }# applies to .sort
@a.sort(:quick):{ +$_ } # applies to .sort
@a.sort:quick:{ +$_ } # both adverbs apply to .sort
Barring pathological cases where you pile up five or ten adverbs, this
seems like it reads clearer.
And while we're on the subject of making this simpler...there seem to
be a lot of cycles and contortions being devoted to making it possible
to leave the parens off of functions (and maybe method) calls. Is
this necessary? Is it really that big an advantage? Couldn't we just
make a nice, simple, easy-to-explain-and-remember rule that says When
you call a func/meth, you always use (). Put whatever args you want
inside the (). ??
Totally unambiguous to the human and the parser, easy to comprehend,
comfortable for people coming from basically any other language. And
it's only two characters.
--Dks
Re: [need input] interpreter permissioning
At 12:11 PM -0400 8/17/04, Felix Gallo wrote: The summary: request for architectural analysis. The motivation: there are certain languages, possibly including perl 6, that will benefit from the ability to flow from one parrot interpreter to another. We could add a few keywords and call the language variant Perlang, too! Anyway, there *is* a threefold plan, involving quotas, privileges/capabilities, and restricted embedding environments. clock time (ulimit style) This'd be a per-interpreter, per-user quota. disk (ulimit style) This'd be done probably by the embedding environment. (Though actual IO operations would be subject to quotas) memory (ulimit style) Quotas. namespace access Privileges PMC (user-level functions, variables (e.g., %ENV, etc.) Also privileges. individual builtins (looping, 'my', assignment, etc.) Privs, possibly quotas and the embedding environment for IO and event type things. Is anyone aware of any reason why the straightforward approach -- implementing a per-thread 'running restricted' flag, an extra if branch in the bytecode interpreter code paths, a bytecode to flip into restricted mode*, and a per-PMC permission 3-bit (rwx) permission bitmask -- would not be the best solution? Mainly because it's a bit too restrictive. What I'm planning on is a VMS-style quota, privilege, and identifier system. (Or, rather, an extendable privilege system where extra privs can be defined and set/reset) Nothing too fancy, but expressive enough to allow for reasonable control over restricted interpreters. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: [perl #31128] Infinite loop in key_string
I don't know what's eating my mail, but evidently the attachment never made it out. I tracked down this particular problem and fixed it for the actual case I was using, which was not a PerlHash at all but rather my own custom Match PMC for use in regexes. The attached patch resolves the exact symptom I was seeing, but actually doesn't fix the problem in either the PerlHash nor the Match cases, for different reasons. For PerlHash, P0[foo;3] seems to be interpreted as an iterator access? I hope there's some other way of indicating that. For my Match PMC, I needed to avoid the whole conversion to string anyway. Still, I won't commit this patch directly, because I have only recently delved into the latest incarnation of the keyed code, and it scares me. Oh boy. What are the odds of this message actually making it out? Index: t/pmc/perlhash.t === RCS file: /cvs/public/parrot/t/pmc/perlhash.t,v retrieving revision 1.44 diff -r1.44 perlhash.t 22c22 use Parrot::Test tests = 34; --- use Parrot::Test tests = 35; 693a694,709 output_is( 'CODE', 'OUTPUT', Getting PMCs from string;int compound keys); new P0, .PerlHash new P1, .PerlHash new P2, .PerlInt set P2, 4 set P1[0], P2 set P0[a], P1 set I0, P0[a;0] print Four is print I0 print \n end CODE Four is 4 OUTPUT
Re: [perl #31128] Infinite loop in key_string
Oh, and while I have my fingers crossed, I may as well throw in the original test patch as well. I'll let these messages go to hell together. Urk! Except I used stupid filenames, and swapped the attachments. So this attachment is actually the patch. Need more sleep. ? src/py_func.str Index: src/key.c === RCS file: /cvs/public/parrot/src/key.c,v retrieving revision 1.51 diff -u -r1.51 key.c --- src/key.c 8 Jul 2004 10:19:11 - 1.51 +++ src/key.c 17 Aug 2004 17:00:08 - @@ -357,6 +357,10 @@ case KEY_pmc_FLAG | KEY_register_FLAG: reg = interpreter-pmc_reg.registers[PMC_int_val(key)]; return VTABLE_get_string(interpreter, reg); +case KEY_integer_FLAG: +return string_from_int(interpreter, PMC_int_val(key)); +case KEY_integer_FLAG | KEY_register_FLAG: +return string_from_int(interpreter, interpreter-int_reg.registers[PMC_int_val(key)]); default: case KEY_pmc_FLAG: return VTABLE_get_string(interpreter, key);
[PATCH] Match PMC
I needed to create a Match PMC object for holding the match groups
(parenthesized expressions and capturing rules) from a regex match.
Unfortunately, it works by using another new PMC type, the MatchRange
PMC, to signal that an element of its hashtable should be interpreted
specially (as a substring of the input string). One PMC knowing about
another currently means they need to be static PMCs, not dynamic.
(AFAIK) So this is the patch of what I am currently using. I cannot
guarantee it will actually be useful for any other regex implementors,
so I feel uncomfortable committing it myself. (OTOH, if someone needs
something different, they can just add it as a different name.) The
point is, this is something I need for my stuff and the future of
languages/regex is with some version of it, so I can't commit those
changes without this. Although I fully expect the Match PMC will need
to be substantially beefed up to become a full grammar object (or
something...), this is base functionality that it needs to start with.
With these two PMCs, I can construct a match object containing the
hypotheticals $1, $2, etc., as well as a full parse tree comprised of
nested match objects. This does *not* handle saving and restoring
previous hypothetical values, as is needed in the case of
(a)+b
In my compiler, that is handled by the compiled engine code.
Index: classes/match.pmc
===
RCS file: classes/match.pmc
diff -N classes/match.pmc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ classes/match.pmc 17 Aug 2004 17:02:01 -
@@ -0,0 +1,205 @@
+/*
+Copyright: 2004 The Perl Foundation. All Rights Reserved.
+$Id$
+
+=head1 NAME
+
+classes/match.pmc - Match object for rules
+
+=head1 DESCRIPTION
+
+This is a match object for holding hypothetical variables, the input string,
+etc.
+
+For now, it is really just proof-of-concept code, and I fully expect
+anyone who reads this to hurl. Violently.
+
+=head2 Functions
+
+=over 4
+
+=cut
+
+*/
+
+#include assert.h
+#include parrot/parrot.h
+
+STRING * hash_get_idx(Interp *interpreter, Hash *hash, PMC *key);
+
+static STRING* make_hash_key(Interp* interpreter, PMC * key)
+{
+if (key == NULL) {
+internal_exception(OUT_OF_BOUNDS,
+Cannot use NULL key for Match!\n);
+return NULL;
+}
+return key_string(interpreter, key);
+}
+
+static STRING* match_range(Interp* interp, PMC* self, PMC* range)
+{
+STRING* input_key = const_string(interp, !INPUT);
+Hash* hash = (Hash*) PMC_struct_val(self);
+HashBucket *b;
+STRING* input;
+int start, end;
+
+b = hash_get_bucket(interp, hash, input_key);
+if (!b) {
+internal_exception(1, Match: input string not set);
+return NULL;
+}
+
+input = VTABLE_get_string(interp, (PMC*) b-value);
+/* These could both be converted to grab UVal_int directly, but
+ * I'll leave it like this for now because it'll test the vtable
+ * members. */
+start = VTABLE_get_integer_keyed_int(interp, range, 0);
+end = VTABLE_get_integer_keyed_int(interp, range, 1);
+
+if (start == -2 || end == -2 || end start - 1)
+return NULL;
+else
+return string_substr(interp, input, start, end - start + 1, NULL, 0);
+}
+
+static STRING* fetch_string(Interp* interp, PMC* matchobj, PMC* val)
+{
+if (val-vtable-base_type == enum_class_MatchRange) {
+return match_range(interp, matchobj, val);
+} else {
+return VTABLE_get_string(interp, val);
+}
+}
+
+static INTVAL fetch_integer(Interp* interp, PMC* matchobj, PMC* val)
+{
+if (val-vtable-base_type == enum_class_MatchRange) {
+STRING* valstr = match_range(interp, matchobj, val);
+return string_to_int(interp, valstr);
+} else {
+return VTABLE_get_integer(interp, val);
+}
+}
+
+pmclass Match extends PerlHash {
+
+/*
+
+=item CSTRING *get_string_keyed_str(STRING *key)
+
+=cut
+
+*/
+
+STRING* get_string_keyed_str (STRING* key) {
+PMC* value;
+Hash* hash = (Hash*) PMC_struct_val(SELF);
+HashBucket *b = hash_get_bucket(INTERP, hash, key);
+if (b == NULL) {
+/* XXX Warning: use of uninitialized value */
+/* return VTABLE_get_string(INTERP, undef); */
+return NULL;
+}
+return fetch_string(INTERP, SELF, (PMC*) b-value);
+}
+
+/*
+
+=item CSTRING *get_string_keyed(PMC *key)
+
+Returns the string value for the element at C*key.
+
+=cut
+
+*/
+
+STRING* get_string_keyed (PMC* key) {
+PMC* valpmc;
+STRING* keystr;
+HashBucket *b;
+Hash *hash = PMC_struct_val(SELF);
+PMC* nextkey;
+
+switch (PObj_get_FLAGS(key) KEY_type_FLAGS) {
+case KEY_integer_FLAG:
+/* called from iterator with an integer idx in key */
+/* BUG! This will iterate through the input string as
+ * well as all of the real values. */
+
Re: [PATCH] Match PMC
Oh, and here's my test code for the Match PMC. This is really just a
copy of t/pmc/perlhash.t (since the Match PMC is supposed to behave
like a hash for the most part), but with one added test case at the
end showing how this would be used to store and retrieve
hypotheticals.
Index: t/pmc/match.t
===
RCS file: t/pmc/match.t
diff -N t/pmc/match.t
--- /dev/null 1 Jan 1970 00:00:00 -
+++ t/pmc/match.t 17 Aug 2004 17:28:17 -
@@ -0,0 +1,1256 @@
+#! perl
+
+# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
+# $Id: match.t,v 1.44 2004/04/19 12:15:22 leo Exp $
+
+=head1 NAME
+
+t/pmc/match.t - Match Objects
+
+=head1 SYNOPSIS
+
+ % perl t/pmc/match.t
+
+=head1 DESCRIPTION
+
+Tests the CMatch PMC. Does standard hashtable testing. Then tests
+various aspects of retrieving ranges of the input string.
+
+Probably ought to do nested match objects too.
+
+=cut
+
+use Parrot::Test tests = 34;
+use Test::More;
+
+output_is(CODE, OUTPUT, Initial Match tests);
+ new P0, .Match
+
+ set P0[foo], -7
+ set P0[bar], 3.5
+ set P0[baz], value
+
+ set I0, P0[foo]
+ set N0, P0[bar]
+ set S0, P0[baz]
+
+ eq I0,-7,OK_1
+ print not
+OK_1: print ok 1\\n
+ eq N0,3.50,OK_2
+ print N0
+OK_2: print ok 2\\n
+ eq S0,value,OK_3
+ print S0
+OK_3: print ok 3\\n
+
+set S1, oof
+set S2, rab
+set S3, zab
+
+ set P0[S1], 7
+ set P0[S2], -3.5
+ set P0[S3], VALUE
+
+ set I0, P0[S1]
+ set N0, P0[S2]
+ set S0, P0[S3]
+
+ eq I0,7,OK_4
+ print not
+OK_4: print ok 4\\n
+ eq N0,-3.50,OK_5
+ print N0
+OK_5: print ok 5\\n
+ eq S0,VALUE,OK_6
+ print S0
+OK_6: print ok 6\\n
+
+ end
+CODE
+ok 1
+ok 2
+ok 3
+ok 4
+ok 5
+ok 6
+OUTPUT
+
+output_is('CODE', OUTPUT, more than one Match);
+ new P0, .Match
+ set S0, key
+ set P0[S0], 1
+
+new P1, .Match
+set S1, another_key
+set P1[S1], 2
+
+ set I0, P0[S0]
+ set I1, P1[S1]
+
+ print I0
+ print \n
+ print I1
+ print \n
+end
+CODE
+1
+2
+OUTPUT
+
+output_is('CODE', OUTPUT, hash keys with nulls in them);
+ new P0, .Match
+ set S0, parp\0me
+ set S1, parp\0you
+
+ set P0[S0], 1 # $P0{parp\0me} = 1
+ set P0[S1], 2 # $P0{parp\0you} = 2
+
+ set I0, P0[S0]
+ set I1, P0[S1]
+
+ print I0
+ print \n
+ print I1
+ print \n
+ end
+CODE
+1
+2
+OUTPUT
+
+output_is('CODE', OUTPUT, nearly the same hash keys);
+ new P0, .Match
+ set S0, a\0
+ set S1, \0a
+
+ set P0[S0], 1
+ set P0[S1], 2
+
+ set I0, P0[S0]
+ set I1, P0[S1]
+
+ print I0
+ print \n
+ print I1
+ print \n
+
+ end
+CODE
+1
+2
+OUTPUT
+
+output_is('CODE', OUTPUT, The same hash keys);
+ new P0, .Match
+ set S0, Happy
+ set S1, Happy
+
+ set P0[S0], 1
+ set I0, P0[S0]
+ print I0
+ print \n
+
+ set P0[S1], 2
+ set I1, P0[S1]
+
+ print I1
+ print \n
+
+ end
+CODE
+1
+2
+OUTPUT
+
+# NB Next test depends on key2 hashing to zero, which it does with
+# the current algorithm; if the algorithm changes, change the test!
+
+output_is('CODE', OUTPUT, key that hashes to zero);
+new P0, .Match
+set S0, key2
+set P0[S0], 1
+set I0, P0[S0]
+ print I0
+ print \n
+ end
+CODE
+1
+OUTPUT
+
+output_is('CODE', OUTPUT, size of the hash);
+ new P0, .Match
+
+ set P0[0], 1
+ set I0, P0
+ print I0
+ print \n
+
+ set P0[1], 1
+ set I0, P0
+ print I0
+ print \n
+
+ set P0[0], 1
+ set I0, P0
+ print I0
+ print \n
+
+ end
+CODE
+1
+2
+2
+OUTPUT
+
+output_is(CODE, OUTPUT, stress test: loop(set, check));
+ new P0, .Match
+
+set I0, 200
+set S0, mikey
+set P0[S0], base
+concat S1, S0, s
+set P0[S1], bases
+set S2, I0
+concat S1, S0, S2
+set P0[S1], start
+set S3, P0[mikey]
+print S3
+print \\n
+set S3, P0[mikeys]
+print S3
+print \\n
+set S3, P0[mikey200]
+print S3
+print \\n
+LOOP:
+eq I0, 0, DONE
+sub I0, I0, 1
+set S2, I0
+concat S1, S0, S2
+concat S4, S0, S2
+eq S1, S4, L1
+print concat mismatch:
+print S1
+print vs
+print S4
+print \\n
+L1:
+set P0[S1], I0
+set I1, P0[S1]
+eq I0, I1, L2
+print lookup mismatch:
+print I0
+print vs
+print I1
+print \\n
Re: [need input] interpreter permissioning
Dan writes: Anyway, there *is* a threefold plan, involving quotas, privileges/capabilities, and restricted embedding environments. If there's a link out there, I must've missed it. Is there one? clock time (ulimit style) This'd be a per-interpreter, per-user quota. Depending on how 'interpreter' is to be, ah, interpreted, that may be too large a grain -- a language may want to have a set-up period during which the rules don't apply, and also a thread (for monitoring purposes, or other) to which the rules apply or don't. e.g., #!//googlestorage/programs/concurrent_basic.08012005 10 ? HELLO WORLD! NOW DOING SETUP 20 USE MODULE IRC::SERVER 30 USE REMOTE ALLOW PUBLIC :LOW-QUOTA TO GOSUB 60 IN PARALLEL 40 GOSUB IRC::SERVER::SETUP counts against perms/quota in this interp? 50 GOTO DO_INTERESTING_STUFF does not return; counts against perms/quota? 60 ARGUMENT X 70 PRINT X TO REMOTES 80 RETURN If by interpreter you mean thread then I'm with you, though. Or if each thread has-a new interpreter, that also is the good stuff. [...] Quotas. [...] Privileges [...] Also privileges. [...] Privs, possibly quotas and the embedding environment for IO and event type things. You've got it covered. So where's the spec? Is anyone aware of any reason why the straightforward approach -- [...] would not be the best solution? Mainly because it's a bit too restrictive. Man, I thought I had a bad case of second systems effect...but you're working on, like, ninth. I genuflect. What I'm planning on is a VMS-style quota, privilege, and identifier system. Pagan heretic -- you shall burn in the purifying flames of RSTS/E! (Or, rather, an extendable privilege system where extra privs can be defined and set/reset) Nothing too fancy, but expressive enough to allow for reasonable control over restricted interpreters. Can you provide a short example of what 'extra privs can be defined and set/reset' means? I haven't touched VMS in about two decades. Felix
Re: Popping an empty stack
On Tue, Aug 17, 2004 at 03:15:01AM -0600, Luke Palmer wrote: : Michel Pelletier writes: : We have to through an IndexError exception for Python. But that's not : done yet. : : Okay, I'll keep depth checking. I thought about attempting a patch, but : Larry says return an undef containing an unthrown exception, Dan wonders : if it should be an empty undef, and you say throw an exception, so I'm : unsure what patch y'all want. ;) : : If it's a PerlArray, return an undef of some kind. It needn't contain : an unthrown exception yet (but if you can figure out how to do that, : great). A bare undef should be fine. Bare undef is fine for now as long as it's not being tested directly against a particular address of undef (as happens in Perl 5). As long as definedness and truth are interrogated through a vtable somewhere, it should work out. What it'll probably eventually come down to in Perl 6 is that the typical undef is an exception object that happens to have the undef role mixed in, which causes the object to appear undefined and false, but otherwise behaves exactly like an exception object, and can easily be turned into a real thrown exception, or have its information incorporated into another exception. The point of unthrown exceptions is to let people program in an undef style without throwing away information about why the value is undefined. Larry
Re: Fine-tuning output from Devel::Cover
On Tue, Aug 17, 2004 at 04:21:09PM +, [EMAIL PROTECTED] wrote: No. There's (currently) no option for doing so. The HTML is well formed, though, which should make building a filter easy if you know how the formatting works. ;) e.g.: Or applying an XSLT file to it? Tony
Re: Updates to modules-related pod
-BEGIN PGP SIGNED MESSAGE- Moin, On Monday 16 August 2004 22:00, Kirrily Skud Robert wrote: In looking through perlnewmod, perlmodlib, perlmodstyle, and other related POD today, I found that most of them are out of date and not in keeping with recent trends in module writing, testing/QA, etc. So, with a due sense of foreboding, I have dived in once again. Errr, hi, long time no p5p. Hello again :) Some comment: +it connected to the rest of the CPAN, you'll need to go to Register +Namespace on PAUSE. Once registered, your module will appear in the +by-module and by-category listings on CPAN. Only a very few of my modules are registered in that namespace. For instance, Math::BigInt::Pari is, while Math::BigInt::GMP is not. The reason is simple: It never worked. I think I sent at least GMP at least two times to the register namespace black hole, and it never happened. AFAIR there was only one guy (Hi Andreas :) working on the registrations, and only every two weeks on Sunday or something like that. So, two (honest) questions: * does it work better now, e.g. should I resub mit my module(s)? * What exactly is the registration good for? I mean, all my dozend or so modules work, and are connected to the rest of CPAN or whatever this means. I cannot remember when I used the by-module or by-category listings on CPAN - - I always just use search.cpan.org for whatever I need installing, and even if I look for a module that I don't want to reinvent, I just hit keywords into search.cpan.org until there is no tomorrow and I found something I can (ab)use. So, if the register namespace isn't too usefull and/or doesn't work fine, why burden new authors with it? Best wishes, Tels - -- Signed on Tue Aug 17 19:16:51 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Now, admittedly, it's critical software. This is the 'let's go kill people' software. -- Mark A. Welsh III -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBQSI9jHcLPEOTuEwVAQEFmwf/R431B4s9O8C+VoWVrxiWlEFHNOSghy1P b9/vogT4N0RD+2dbi67MWfsC9/iV0mLVGphiRjOufRiDdZHX7+E0qqFXI8tmoqdW wvchULy6n+yOofQC8NTaOkG7oNlhXGSaWRnVsjzTL21BaIs8pZVtt8yIMGfbyejA +GZtL18MhPAzNmsLFAlQDxyHL0C8e11Z0bHQky2F1ftpWTC5z38J3pzWxMGGG8PW kei+eIjOgmJcPbZteroO86XQSAwVD3BVE5ng86Maxk4DGNrFJN4NBeeco56XB2pT 22y3AfYQ5aHZyWAUWvmmZViPqZBZ4Tr3MbI7GkAB3o5n0NZRI+XTtQ== =bK7Q -END PGP SIGNATURE-
Re: [need input] interpreter permissioning
At 1:30 PM -0400 8/17/04, Felix Gallo wrote: Dan writes: Anyway, there *is* a threefold plan, involving quotas, privileges/capabilities, and restricted embedding environments. If there's a link out there, I must've missed it. Is there one? There isn't. I'll go fix that with PDD 18, Security and Quotas. Might be a day or two until it hits the repository. clock time (ulimit style) This'd be a per-interpreter, per-user quota. Depending on how 'interpreter' is to be, ah, interpreted, that may be too large a grain -- a language may want to have a set-up period during which the rules don't apply, and also a thread (for monitoring purposes, or other) to which the rules apply or don't. e.g., [...] If by interpreter you mean thread then I'm with you, though. Or if each thread has-a new interpreter, that also is the good stuff. Yep, per-interpreter means per-thread. Each thread gets an interpreter. (Logically, at least. There'll only ever be one OS thread in an interpreter at any one time, though I suppose it's possible an interpreter could move from one thread to another. I'd rather not, though) Also quota and priv checking can be enabled and (if you have sufficient privs) disabled on the fly, so you can do setup and then enable checking, or disable checking when you're running privileged code. [...] Quotas. [...] Privileges [...] Also privileges. [...] Privs, possibly quotas and the embedding environment for IO and event type things. You've got it covered. So where's the spec? In my brain. I'm fixing that, though, as there's not that much room. :) Is anyone aware of any reason why the straightforward approach -- [...] would not be the best solution? Mainly because it's a bit too restrictive. Man, I thought I had a bad case of second systems effect...but you're working on, like, ninth. I genuflect. I figure if we're going to steal the system, we might as well steal a mature one. :-P What I'm planning on is a VMS-style quota, privilege, and identifier system. Pagan heretic -- you shall burn in the purifying flames of RSTS/E! Mmmm, RSTS/E. And BASIC/PLUS 2.6. Now *those* were the days. Now, where did I put my overlaying linker... (Or, rather, an extendable privilege system where extra privs can be defined and set/reset) Nothing too fancy, but expressive enough to allow for reasonable control over restricted interpreters. Can you provide a short example of what 'extra privs can be defined and set/reset' means? I haven't touched VMS in about two decades. VMS's (and yes, for the grammar wonks, that apostrophe is actually correct) privilege system has 32 separate privs, each conveniently fitting in a bit. They govern things like being able to exceed quotas, ignoring protection codes on things in your group or on everything, do physical IO, or ignore privileges. 32 of the things since they conveniently fit in a word. It also has a named capability thing, where you can tag things (executables, shared libraries, files, system objects) with an identifier, then give those identifiers to users--basically a filesystem ACL scheme extended to non-file objects. (It's used for the filesystem ACL setup, FWIW, though generally you don't use the same identifier for file control that you do for non-file objects) Having the two schemes split's one of those historical things -- what I'd like to do is just be able to have an unbounded number of privilege bits and add to them at runtime as need be. That way instead of faking privs with identifiers you just extended the list of available privs. The VMS priv system also has two (well, three, but the third's a default used when processes are created) sets of privs per process -- the current and the allowed privs. Current privs are what you can do right now, while the allowed are the privs you can enable. You'll often find VMS accounts with a hefty set of allowed privs but a small set of current privs (so you *can* kill the world, but won't by default), and sometimes you'll have accounts that have current privs that aren't in the allowed set (so the priv is enabled until it is dropped, and once dropped will never come back) which is useful for initialization that needs extra privs temporarily. There are also privileged subs, and automatic priv checking for subs, but that's all extra. I really ought to start writing the spec so I can pass it on to people who actually know what they're doing to rip to shreds... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revision of A12's lookahead notions
David Storrs writes:
On Tue, Aug 10, 2004 at 11:07:59AM -0700, Larry Wall wrote:
2) In the absence of evidence to the contrary, methods always
assume they have *no* arguments. For methods:
2a) A method not followed by a left paren or colon has no
arguments.
Just checking--whitespace doesn't count, right?
foo(1,2,3);# Func with 3 args
foo (1,2,3); # Same exact thing
You quote Larry's text about methods, then give an example using
functions! Your example is wrong: in the general case there must not be
whitespace between a function call and a left paren that is delimiting
its args. This is so that things like this behave themselves:
print (2 + 3) * 4;
That will be treated as:
print((2 + 3) * 4);
rather than the (pointless):
(print 2 + 3) * 4;
But in your example above they may actually evaluate to the same thing:
I think the parens in the second line are redundant (because the
precedence rules would cause things to be evaluated in that order
anyway) but benign (however I'm still shakey on exactly when lists need
to be splatted in Perl 6, so it's possible that I'm wrong and the parens
are actually treated like square brackets, passing in an array as a
single argument).
Regarding the question you actually asked, as to whether spaces are
permitted in method calls, there is no ambiguity: since method args have
to be surrounded by parens, there's no chance that in something like
this:
$obj.meth (2 + 3) * 4;
the arg could be anything other than 5. So perhaps spaces could be
allowed there, but for consistency with functions I'd prefer them to be
prohibited, and hence for the above line to be a syntax error.
When you say *no* arguments, does that mean that they do not get
passed the implicit $self ref? (Or is that even relevant anymore?)
Things in the current object can now be accessed as C$.thing instead
of C$self-{thing}; this has nothing to do with the param list any
more.
2b) As with multies, method declarations can have no effect on the
parsing of methods. Unlike multis, the default is no arguments.
So, this doesn't work:
method foo($$$);
That isn't how parameter types are specified in Perl 6, anyway.
.foo 1,2,3; # WRONG!
Yup -- by rule 2a you quoted above, a method call with arguments always
has to use parens.
2d) Given 2c, additional arguments may occur as adverbs
whether or not there is an argument pill:
pill == parenthesized arg list?
That's my guess too.
3) A bare {...} where an operator is expected always terminates the
current list operator, and takes the precedence level back to statement
level. That is, it pops all the implicit left parentheses of list
operators with implicit right parentheses.
Is that a metasyntactic {...} or a literal y3 (yadda-yadda-yadda)
operator?
It must be the former -- there can't be special rules just for the
latter! And if you look at the Cif example Larry gives just after the
above para, it makes sense to mean any block.
(Side note: This is my biggest problem with this operator--it makes
discussions about pseudo- and/or skeleton code highly ambiguous.)
I agree!
3a) Note that an operator {...} cannot occur in the arguments of either
a function or a method. Operator {...} is reserved for statement level
control flow blocks.
if blurk {...} {...}# 1st closure is arg, 2nd ifblock
if blurk(1) {...} # closure is ifblock
if blurk 1 {...} # closure is ifblock
if .blurk {...} # closure is ifblock
if .blurk {...} {...} # 1st is ifblock, 2nd is bare block?
Does that final question mark indicate uncertainty on your part about
how the language should be defined, or uncertainty on the parser's
part about what the code means?
I read the question mark as well it must be a bare block cos it isn't
anything else, but I'm not entirely sure why anybody would put a bare
block there.
if .blurk 1 {...} # ILLEGAL
Just checking...this is illegal because 2c says that [t]he only way
to pass arguments to a method is by an explicitly parenthesized list
or by adverb. Or by both. Correct?
Yup.
If the '1' wasn't there, then you'd have a legal statement (as per
example above).
Yes; if the 1 wasn't there then the statement would exactly be one of
the preceding example, and therefore behave exactly as annotated in that
example! (How could it be anything else?)
And while we're on the subject of making this simpler...there seem to
be a lot of cycles and contortions being devoted to making it possible
to leave the parens off of functions
Yes (as per Perl 5).
(and maybe method)
Only methods without args (as per Perl 5).
calls.Is this necessary?
Yes.
Is it really that big an advantage?
Yes.
Couldn't we just make a nice, simple, easy-to-explain-and-remember
rule that says When
Re: Updates to modules-related pod
On Tue, Aug 17, 2004 at 07:16:52PM +0200, Tels wrote: +it connected to the rest of the CPAN, you'll need to go to Register +Namespace on PAUSE. Once registered, your module will appear in the +by-module and by-category listings on CPAN. Only a very few of my modules are registered in that namespace. For instance, Math::BigInt::Pari is, while Math::BigInt::GMP is not. The reason is simple: It never worked. I think I sent at least GMP at least two times to the register namespace black hole, and it never happened. AFAIR there was only one guy (Hi Andreas :) working on the registrations, and only every two weeks on Sunday or something like that. There are multiple people who have the ability to administer CPAN in that fashion - I'm one of them, for what it's worth, though I'll admit I haven't touched it in years while I've been on hiatus. I forget who else. So, two (honest) questions: * does it work better now, e.g. should I resub mit my module(s)? * What exactly is the registration good for? I mean, all my dozend or so modules work, and are connected to the rest of CPAN or whatever this means. Having your module registered means it will show up in the category listing as seen on the front page of search.cpan.org and in the by-module and by-category listings (which, yeah, nobody uses anymore AFAIK). However, the by recentness list at http://cpan.org/modules/01modules.mtime.html indicates that something at least is being updated very frequently, at least daily, and I suspect automatically. So the question is, which bits are updated automatically by the mere fact of a module author doing the register namespace thing, and which bits require manual intervention? So, if the register namespace isn't too usefull and/or doesn't work fine, why burden new authors with it? I raised this on [EMAIL PROTECTED] the other day in fact. Register namespace is useful in some ways and not in others, it seems. The most useless part of it is the published modules list, and IMO we should get rid of the thing. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ I've decided to rename [Connect's Melbourne border router] 'Madi's Pants' because it keeps dropping. -- Madi (from the Netizen quotes file)
Re: [need input] interpreter permissioning
On Tue, Aug 17, 2004 at 02:01:31PM -0400, Dan Sugalski wrote: Yep, per-interpreter means per-thread. Each thread gets an interpreter. (Logically, at least. There'll only ever be one OS thread in an interpreter at any one time, though I suppose it's possible an interpreter could move from one thread to another. I'd rather not, though) As I understand it modperl2 does this dynamic rebinding of perl interpreters to threads, so I expect that they'd like to be able to do in parrot, for whatever reasons they found it useful with perl5. Nicholas Clark
Re: [PATCH] Re: [perl #31128] Infinite loop in key_string
On Tue, Aug 17, 2004 at 10:10:14AM -0700, Steve Fink wrote: I don't know what's eating my mail, but evidently the attachment never made it out. I tracked down this particular problem and fixed it for perl.org's list server software eats attachments named /\.t$/ It appears sufficiently ingrained that it's not been possible to dissuade it from consuming these fine delicacies. I guess it was written by the anti-Schwern. :-) Nicholas Clark
Re: Fine-tuning output from Devel::Cover
Tony Bowden [EMAIL PROTECTED] wrote: On Tue, Aug 17, 2004 at 04:21:09PM +, [EMAIL PROTECTED] wrote: The HTML is well formed, though, which should make building a filter easy if you know how the formatting works. ;) e.g.: Or applying an XSLT file to it? The HTML reports are really XHTML, so that should be possible. I've never used XSLT myself, but I don't think it would be very hard. Hmm... with a little XLST + JavaScript it should be possible to create a report with a button that could toggle between showing everything and just showing the parts with missing coverage. That'd be slick. :) This thread has made me wonder about something: Would it be useful to have a raw XML report format? Done properly it could allow Devel::Cover to use it as the *only* report format, assuming that the distribution included tools for common transformations like text and HTML. Despite what Paul said about it being fairly simple to write a new backend, it's definitely not trivial. While I'm sure it's clear to him, I've found the underlying data structure and classes to be somewhat challenging to understand and keep straight in my head. I think that it would be a lot easier for Joe User to build something to transform XML than to write a new backend. -mjc
RE: [need input] interpreter permissioning
Dan Sugalksi wrote: VMS's (and yes, for the grammar wonks, that apostrophe is actually correct) I'd lay even odds that VMS would qualify for the ancient proper names exception... William Strunk, Jr. (1869-1946). The Elements of Style. 1918. II. ELEMENTARY RULES OF USAGE Form the possessive singular of nouns with 's. Follow this rule whatever the final consonant. Thus write, Charles's friend Burns's poems the witch's malice This is the usage of the United States Government Printing Office and of the Oxford University Press. Exceptions are the possessives of ancient proper names in -es and -is, the possessive Jesus', and such forms as for conscience' sake, for righteousness' sake. But such forms as Achilles' heel, Moses' laws, Isis' temple are commonly replaced by the heel of Achilles the laws of Moses the temple of Isis The pronominal possessives hers, its, theirs, yours, and oneself have no apostrophe. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: [need input] interpreter permissioning
At 7:30 PM +0100 8/17/04, Nicholas Clark wrote: On Tue, Aug 17, 2004 at 02:01:31PM -0400, Dan Sugalski wrote: Yep, per-interpreter means per-thread. Each thread gets an interpreter. (Logically, at least. There'll only ever be one OS thread in an interpreter at any one time, though I suppose it's possible an interpreter could move from one thread to another. I'd rather not, though) As I understand it modperl2 does this dynamic rebinding of perl interpreters to threads, so I expect that they'd like to be able to do in parrot, for whatever reasons they found it useful with perl5. That works. The only reason I can think to not do this is for external libraries that have thread-dependencies, since migrating the interpreter wouldn't migrate the TLS. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Revision of A12's lookahead notions
On Tue, Aug 17, 2004 at 06:02:13PM +, Smylers wrote:
: David Storrs writes:
: Just checking--whitespace doesn't count, right?
:
: foo(1,2,3);# Func with 3 args
: foo (1,2,3); # Same exact thing
:
: You quote Larry's text about methods, then give an example using
: functions! Your example is wrong: in the general case there must not be
: whitespace between a function call and a left paren that is delimiting
: its args. This is so that things like this behave themselves:
:
: print (2 + 3) * 4;
:
: That will be treated as:
:
: print((2 + 3) * 4);
:
: rather than the (pointless):
:
: (print 2 + 3) * 4;
:
: But in your example above they may actually evaluate to the same thing:
: I think the parens in the second line are redundant (because the
: precedence rules would cause things to be evaluated in that order
: anyway) but benign (however I'm still shakey on exactly when lists need
: to be splatted in Perl 6, so it's possible that I'm wrong and the parens
: are actually treated like square brackets, passing in an array as a
: single argument).
It would depend on whether you declared
sub foo ($a, $b, $c)
or
sub foo ([EMAIL PROTECTED])
With the first declaration, for the second example $a would end
up with [1,2,3], because parens in a scalar context work like [].
With the second declaration, you'd end up with 1,2,3 in the array,
because parens in a list context flatten as they do in Perl 5.
(On the principle that parens are really only for grouping, to
tell the compiler when to ignore operator precedence. The fact that
scalar parens can work like [] is not really a fact about parens but
a fact about the comma operator within the parens.)
: Regarding the question you actually asked, as to whether spaces are
: permitted in method calls, there is no ambiguity: since method args have
: to be surrounded by parens, there's no chance that in something like
: this:
:
: $obj.meth (2 + 3) * 4;
:
: the arg could be anything other than 5. So perhaps spaces could be
: allowed there, but for consistency with functions I'd prefer them to be
: prohibited, and hence for the above line to be a syntax error.
Yes, though certainly someone will come up with a pragma to say something
like:
use mandatory_parens;
in which case, since the parens are mandatory on arguments, it wouldn't
be ambiguous to allow whitespace. But then you'd have to write all
your attributes as
$obj.attr()
: 2d) Given 2c, additional arguments may occur as adverbs
: whether or not there is an argument pill:
:
: pill == parenthesized arg list?
:
: That's my guess too.
Mine too. :-)
: 3) A bare {...} where an operator is expected always terminates the
: current list operator, and takes the precedence level back to statement
: level. That is, it pops all the implicit left parentheses of list
: operators with implicit right parentheses.
:
: Is that a metasyntactic {...} or a literal y3 (yadda-yadda-yadda)
: operator?
:
: It must be the former -- there can't be special rules just for the
: latter! And if you look at the Cif example Larry gives just after the
: above para, it makes sense to mean any block.
:
: (Side note: This is my biggest problem with this operator--it makes
: discussions about pseudo- and/or skeleton code highly ambiguous.)
:
: I agree!
In general, if I mean a literal yada-yada-yada, I'll say that. But it's
not a big problem if you assume that C... always indicates pseudo code.
It's just that Perl 6 allows you to compile certain forms of pseudo-code.
: I read the question mark as well it must be a bare block cos it isn't
: anything else, but I'm not entirely sure why anybody would put a bare
: block there.
Yes, with an additional undertone of: and maybe there should be a
warning for something so obviously screwy.
Or maybe we just require that a bare closure must start on its own line,
which would turn the above into a syntax error.
: Couldn't we just make a nice, simple, easy-to-explain-and-remember
: rule that says When you call a func/meth, you always use (). Totally
: unambiguous to the human and the parser, easy to comprehend,
: comfortable for people coming from basically any other language.
:
: But there's no point in making Perl as awkward as some other language;
: otherwise we could just use those other languages and not bother with
: Perl.
Especially since it'll be trivially easy to turn Perl into an awkward
language by saying:
use parens :mandatory;
or some such to re-institute C lexer semantics. That's not to be
confused with:
use parens :stickinthemud;
which presumably re-institutes the Perl 5 lexer mess.
But we'll just have to shoot anyone who makes a wisecrack like:
use parens :lisp;
Larry
Re: Revision of A12's lookahead notions
On Tue, 2004-08-17 at 12:54, Larry Wall wrote: But we'll just have to shoot anyone who makes a wisecrack like: use parens :lisp; Surely that should have its own pragma: use parenths; -- c
Something to ponder
1) We're going to have MMD for functions soon 2) Function invocation and return continuation invocation's essentially identical 3) Therefore returning from a sub/method can do MMD return based on the return values Someone probably ought to think about what sort of syntax you might add to a language to take advantage of this... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NCI and callback functions
On Tue, Aug 17, 2004 at 09:01:39AM +0200, Leopold Toetsch wrote: It returns a PerlUndef. 60 dlfunc P2, P1, g_signal_connect, lptpP - \ P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), , 65 store_global Gtk::g_signal_connec, P2 - , \ P2=PerlUndef=PMC(0x8363fb8 Num:0 Int:0) ^ The symbol g_signal_connect isn't found in that lib. ow.. ok, this one is actaully a macro.. the actual function is gulong g_signal_connect_object (gpointer instance, const gchar *detailed_signal, GCallback c_handler, gpointer gobject, GConnectFlags connect_flags); so I've changed this and now it does find it. And it does seem to callback as well, but there must something else wrong (or I'm missing something) as it dies anyway. Attached are again the test files, plus two dumps of my tries to run it. In one of them (run.null) I simply null the user data to be passed through. In that case it displays the button but dies as soon as it is clicked on (in this case it dies because the user data is null actually, but at least it let me now it does actually callback :) Parrot_callback_D then verify_CD). On other one (run), there is an actual (not null) user data. Know it goes somewhere into the g_signal function and (guess) also someway back.. but I'm really blind as to what is really happening there..? leo Thanks Stephane 8 saveall 9 loadlib P1, libgtk-x11-2.0 - P1=NULL, 12 dlfunc P2, P1, gtk_init, vii - P2=NULL, P1=ParrotLibrary=PMC(0x8364108), , 17 store_global Gtk::gtk_init, P2 - , P2=NCI=PMC(0x8364048) 20 dlfunc P2, P1, gtk_main, vv - P2=NCI=PMC(0x8364048), P1=ParrotLibrary=PMC(0x8364108), , GC 25 store_global Gtk::gtk_main, P2 - , P2=NCI=PMC(0x8364030) 28 dlfunc P2, P1, gtk_widget_show, vp - P2=NCI=PMC(0x8364030), P1=ParrotLibrary=PMC(0x8364108), , 33 store_global Gtk::gtk_widget_show, P2 - , P2=NCI=PMC(0x8364018) 36 dlfunc P2, P1, gtk_container_add, vpp- P2=NCI=PMC(0x8364018), P1=ParrotLibrary=PMC(0x8364108), , 41 store_global Gtk::gtk_container_a, P2 - , P2=NCI=PMC(0x8364000) GC 44 dlfunc P2, P1, gtk_button_new_with_, pt - P2=NCI=PMC(0x8364000), P1=ParrotLibrary=PMC(0x8364108), , 49 store_global Gtk::gtk_button_new_, P2 - , P2=NCI=PMC(0x8363fe8) 52 dlfunc P2, P1, gtk_window_new, pi- P2=NCI=PMC(0x8363fe8), P1=ParrotLibrary=PMC(0x8364108), , 57 store_global Gtk::gtk_window_new, P2 - , P2=NCI=PMC(0x8363fd0) GC 60 dlfunc P2, P1, g_signal_connect_obj, lptpPi - P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), , 65 store_global Gtk::g_signal_connec, P2 - , P2=NCI=PMC(0x8363fb8) 68 restoreall 69 find_global P0, Gtk::gtk_init - P0=NULL, 72 set I5, 0- I5=0, 75 invoke 76 find_global P0, Gtk::gtk_window_new- P0=NCI=PMC(0x8364048), GC 79 null I5 - I5=0 81 invoke 82 set P15, P5 - P15=NULL, P5=UnManagedStruct=PMC(0x8363fa0) 85 find_global P0, Gtk::gtk_button_new_ - P0=NCI=PMC(0x8363fd0), 88 set S5, Parrot - , 91 invoke 92 set P6, P5 - P6=NULL, P5=UnManagedStruct=PMC(0x8363f88) GC 95 set P11, P5 - P11=NULL, P5=UnManagedStruct=PMC(0x8363f88) 98 newsub P6, 22, -98 - P6=UnManagedStruct=PMC(0x8363f88), , 102 new P7, 31 - P7=NULL, 105 set P7, 42 - P7=Integer=PMC(0x8363f58), 108 new_callback P5, P6, P7, Ut- P5=UnManagedStruct=PMC(0x8363f88), P6=Sub=PMC(0x8363f70 Adr:0x84e6628), P7=Integer=PMC(0x8363f58), GC 113 find_global P0, Gtk::g_signal_connec - P0=NCI=PMC(0x8363fe8), 116 set S5, clicked- S5=Parrot, 119 set I5, 0- I5=0, 122 set P6, P5 - P6=Sub=PMC(0x8363f70 Adr:0x84e6628), P5=UnManagedStruct=PMC(0x8363ef8) 125 set P5, P11 - P5=UnManagedStruct=PMC(0x8363ef8), P11=UnManagedStruct=PMC(0x8363f88) GC 128 invoke Segmentation fault 8 saveall 9 loadlib P1, libgtk-x11-2.0 - P1=NULL, 12 dlfunc P2, P1, gtk_init, vii - P2=NULL, P1=ParrotLibrary=PMC(0x8364108), , 17 store_global Gtk::gtk_init, P2 - , P2=NCI=PMC(0x8364048) 20 dlfunc P2, P1, gtk_main, vv - P2=NCI=PMC(0x8364048), P1=ParrotLibrary=PMC(0x8364108), , GC 25 store_global Gtk::gtk_main, P2 - , P2=NCI=PMC(0x8364030) 28 dlfunc P2, P1, gtk_widget_show, vp - P2=NCI=PMC(0x8364030), P1=ParrotLibrary=PMC(0x8364108), , 33 store_global Gtk::gtk_widget_show, P2 - , P2=NCI=PMC(0x8364018) 36 dlfunc P2, P1, gtk_container_add, vpp- P2=NCI=PMC(0x8364018), P1=ParrotLibrary=PMC(0x8364108), , 41 store_global Gtk::gtk_container_a, P2 - ,
Re: Something to ponder
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote: 1) We're going to have MMD for functions soon 2) Function invocation and return continuation invocation's essentially identical 3) Therefore returning from a sub/method can do MMD return based on the return values Someone probably ought to think about what sort of syntax you might add to a language to take advantage of this... the two-dimensional '+' results-distribution operator, naturally. #!/usr/bin/perl9 $x -\ \ @mylist -+--- $obj.mymmdsub; / %hash --/ F.
Re: Something to ponder
Dan~ This is the coolest things I have heard all day. I am not sure that my brain is entirely around what situations it would be useful in yet. But it is really cool. It seems to me that it would probably be most useful in the tail call setting where you are just passing the result from one function into another... Matt On Tue, 17 Aug 2004 16:22:58 -0400, Felix Gallo [EMAIL PROTECTED] wrote: On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote: 1) We're going to have MMD for functions soon 2) Function invocation and return continuation invocation's essentially identical 3) Therefore returning from a sub/method can do MMD return based on the return values Someone probably ought to think about what sort of syntax you might add to a language to take advantage of this... the two-dimensional '+' results-distribution operator, naturally. #!/usr/bin/perl9 $x -\ \ @mylist -+--- $obj.mymmdsub; / %hash --/ F. -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Something to ponder
On Tue, 2004-08-17 at 16:22, Felix Gallo wrote:
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote:
1) We're going to have MMD for functions soon
2) Function invocation and return continuation invocation's
essentially identical
3) Therefore returning from a sub/method can do MMD return based on
the return values
$x -\
\
@mylist -+--- $obj.mymmdsub;
/
%hash --/
How very fungible of you ;-)
Still, I think that's a nice APPLICATION, but the concept is more
flexible, if I understand it correctly. It would be something that would
look more like a cross between exception handling and a switch
statement.
I would think it would look more like (again, Perlish example):
$sock.peername()
does returntype(
Net::Address::IP - $ip {
die Remote host unresolvable: '$ip';
}, Net::Address - $addr {
die Non IP unresolvable address: '$addr';
}, Str - $_ {
print Seemingly valid hostname: '$_'\n;
});
Of course, that's just Perl. Perhaps Python would add something that
would look like:
returnswitch: sock.peername()
returncase os.net.addr.ip:
lambda ip: raise OSError, Unresolvable %s % str(ip)
returncase os.net.addr:
lambda addr: raise OSError, Unresolvable non-IP %s % str(ip)
returncase str:
lambda name: print Seemingly valid hostname: '%s' % name
My python skills are still developing, so pardon me if I've gotten it
wrong, and I'm just inventing os.net.addr.ip for purposes of
pseudo-code
Is that the kind of thing you had in mind, Dan, or am I misunderstanding
how return continuations work?
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: Fine-tuning output from Devel::Cover
--- Paul Johnson [EMAIL PROTECTED] wrote: By the way, how big is enormous? I had never expected the size of the HTML output to be a problem, but it obviously is to some people. 'Enormous' is obviously a subjective judgment, so let me describe the coverage files I've got and how I worked with them. List::Compare currently consists of 4 .pm files. The 'File Coverage' HTML files for them total 328KB. If I printed them out in a normal size, I would get 57 pages. Depending on the zoom ratio in my browser, that would be equivalent to somewhere between 85 and 114 screens deep. When I utilize Devel::Cover's 'cover report=text' option, I get all the information contained in the 'File Coverage' HTML files plus the Branch, Condition and Subroutine Coverage files as well -- and that comes out to 312KB. Depending on whether I print that out in portrait or landscape mode from a text editor such as Apple TextEdit, that comes to 96 or 168 pages. When working on a project like this, I like to do two things: (1) print out my reference data so I can mark it up with the advanced technology known as ink, and (2) display it on my screen in a GUI text-editor while I revise the Perl code in a visually distinct program (in this case, vi). I don't to have to be constantly scrolling up and down in the GUI program to spot the uncovered code, nor do I want to have to leaf through 96 pages of hard copy. Hence, I want to get that text file edited down to display just what needs correction. Doing this manually or by a Perl script which parses the plain-text coverage report, I got it down to 7 pages of hard copy. That's much more workable. But it would obviously be much more efficient to extract this information from the cover_db database itself than from a report generated from that database. Should I find the time, I'll venture into Devel::Cover's internals and see what I can do. Thank you very much. jimk = Affiliations: Perl Seminar NY / New York Perlmongers / Toronto Perlmongers __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Re: [need input] interpreter permissioning
DS == Dan Sugalski [EMAIL PROTECTED] writes: What I'm planning on is a VMS-style quota, privilege, and identifier system. Pagan heretic -- you shall burn in the purifying flames of RSTS/E! DS Mmmm, RSTS/E. And BASIC/PLUS 2.6. Now *those* were the days. Now, DS where did I put my overlaying linker... RT-11 had a neat feature with overlays. since you could have more physical ram (22 bits of address) than virtual ram (16 bits) you could use the extra ram for overlays instead of disk. this was much faster as you would imagine. all the overlay runtime code had to do was mung a few memory management registers. i did that myself to load audio data into the high ram (where the dma hardware could directly access it as it had 22 physical address bits in it). you kiddies are SO SPOILED today. :) what is amazing is how you can actually have more physical ram today (4GB) than virtual again (on 32 bit boxes of course)! my how history repeats! :) 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
Re: Popping an empty stack
On Tue, 17 Aug 2004 03:15:01 -0600 Luke Palmer [EMAIL PROTECTED] wrote: Michel Pelletier writes: We have to through an IndexError exception for Python. But that's not done yet. Okay, I'll keep depth checking. I thought about attempting a patch, but Larry says return an undef containing an unthrown exception, Dan wonders if it should be an empty undef, and you say throw an exception, so I'm unsure what patch y'all want. ;) If it's a PerlArray, return an undef of some kind. It needn't contain an unthrown exception yet (but if you can figure out how to do that, great). A bare undef should be fine. Well this is easy enough, but after trying it out I'm wondering its usefulness. if an out of bounds get on an array returns an undef, then bounds checking code must go through the same overhead to check for the undef as it would need to initially just check the validity of the bounds in the first place. Compare: $I0 = .STACK if $I0 0 goto .$NoError new $P0, .Exception $P0[_message] = Stack is Empty! throw $P0 .local $NoError: pop $P0, .STACK to pop $P0, .STACK isa $I0, $P0, PerlUndef unless $I0 goto .$NoError new $P0, .Exception $P0[_message] = Stack is Empty! throw $P0 .local $NoError: versus just throwing a catchable error if the array is empty on pop: pop $P0, .STACK # throws exception if Perl or other languages want an undef returned, it would seem to make more sense that they assume to cost of catching the exception and turning it into an undef, than everyone else turning the undef into an exception. Popping an empty stack to feels much more exceptional to me than an operation that results in an undef. -Michel
Re: Popping an empty stack
Michel Pelletier [EMAIL PROTECTED] wrote: $P0 = new .PerlArray pop $P1, $P0 kills the process with a 'Array index out of bounds!'. Is there a way to get an exception I can catch out of this? We have to through an IndexError exception for Python. But that's not done yet. -Michel leo
Re: Updates to modules-related pod
Kirrily Skud Robert wrote: Here's an initial patch to perlnewmod, the main points of which are: * recommend module-starter over h2xs * modernise recommended h2xs invocation * modernise list of recommended modules to learn from * refer to Test::Simple and Test::More instead of Test * modernise PAUSE-related instructions Thanks, applied as change #23220 to bleadperl. I know module-starter (part of the Module::Starter package) isn't part of the core, but I figure that there are two answers to that: 1) propose M::S for inclusion in the core, or 2) since this doc is aimed at CPAN authors anyway, let's assume that it won't kill them to get the module from there. 2) is surely better :) BTW, isn't the habit to post to c.l.p.announce a bit deprecated now ?
Re: Parrot interfaces
On Mon, 16 Aug 2004 20:54:34 -0700 chromatic [EMAIL PROTECTED] wrote: On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote: I've noticed there are ops for interfaces, but no implementation or ppd yet. Perl 6 has roles which are much more useful than interfaces -- in fact, interfaces are degenerate roles. See Apocalypse 12 for more. http://www.perl.com/pub/a/2004/04/16/a12.html Mmm. Some light reading. Now at least I know where BUILD comes from. I think I get it, but correct me if I'm wrong: Roles are an orthogonal structure to classes, like classes but they describe not an inheritance relationship, but a functional relationship between an object an the behavior other object expect from it, irregardless of its pedigree, and to a degree, its implementation langauge. Parrot does/should have the 'does' op, which ought to check and identify roleishness. I don't know its current status. To my novice eyes, unimplemented. But what implements a Role? A modified class? Discussion as to the differences between roles and interfaces should probably happen on p6l ([EMAIL PROTECTED]), though there are some implementation details for Perl 6's signature checking system that Parrot doesn't currently handle as it could. From a cross language standpoint I'm wondering less about Perl 6 roles specificly or how they are implemented, and more about how roles are going to work between components and languages, particularly from the perspective of adaptation, ala PEP 246 or PyProtocols: http://www.python.org/peps/pep-0246.html (Object Adaptation) http://peak.telecommunity.com/PyProtocols.html Both interesting reads from a cross-language standpoint, especially the latter: PyProtocols also doesn't force you to use a particular interface coding style or even a specific interface type. You can use its built-in interface types, or define your own. If there's another Python package out there with interface types that you'd like to use (CORBA? COM?), you can even create your own adapters to make them work with the PyProtocols API. not just another Python Package out there with interfaces but now Parrot lets use use another *language* with interfaces. Will roles (interfaces) with adaptation improves the ability for components written in different langauges to cross language barriers? -Michel
Re: Popping an empty stack
On Tue, 17 Aug 2004 08:54:32 +0200 Leopold Toetsch [EMAIL PROTECTED] wrote: Michel Pelletier [EMAIL PROTECTED] wrote: $P0 = new .PerlArray pop $P1, $P0 kills the process with a 'Array index out of bounds!'. Is there a way to get an exception I can catch out of this? We have to through an IndexError exception for Python. But that's not done yet. Okay, I'll keep depth checking. I thought about attempting a patch, but Larry says return an undef containing an unthrown exception, Dan wonders if it should be an empty undef, and you say throw an exception, so I'm unsure what patch y'all want. ;) -Michel
Re: Popping an empty stack
Michel Pelletier writes: We have to through an IndexError exception for Python. But that's not done yet. Okay, I'll keep depth checking. I thought about attempting a patch, but Larry says return an undef containing an unthrown exception, Dan wonders if it should be an empty undef, and you say throw an exception, so I'm unsure what patch y'all want. ;) If it's a PerlArray, return an undef of some kind. It needn't contain an unthrown exception yet (but if you can figure out how to do that, great). A bare undef should be fine. Luke
Re: [perl #31126] [PATCH[ More dynpmc fixes (with patch, really)
Mattia Barbon [EMAIL PROTECTED] wrote: Hello, this patch: 1) removes the necessity of having #define enum_class_Foo -1 in the dynpmc file 2) makes DYNSUPER fail at compile time instead of at runtime 3) makes MDD declarations work, as long as there isn't a circular dependencies and PMCs are loaded in the correct order All tests pass (Linux, x86), but this patch does not affect output for core PMCs anyway. s/not/almost not/ :) The constness of the MMD_init temp table got dropped. We should keep these tables const. (Same holds BTW for the temp vtable templates). So what about: make these tables const (again) and patch in the necessary dynamic changes during MMD registering or after during vtable copying respectively. Anyway, applied as well as #31124. Regards Mattia leo
Re: [perl #31186] [PATCH] Various pod nits
Will Coleda [EMAIL PROTECTED] wrote: Nothing serious, just trying to clean up a few nits in assorted POD. Thanks, applied. leo
Re: [perl #31126] [PATCH[ More dynpmc fixes (with patch, really)
Mattia Barbon [EMAIL PROTECTED] wrote: Hel= lo, this patch: 1) removes the necessity of having #define enu= m_class_Foo -1 in the dynpmc file 2) makes DYNSUPER fail at= compile time instead of at runtime 3) makes MDD declarations work, = as long as there isn't a circular dependencies and PMCs are loade= d in the correct order All tests pass (Linux, x86), but this pat= ch does not affect output for core PMCs anyway. s/not/almost = not/ :) Oops. Correct. The constness of the MMD_init temp tabl= e got dropped. We should keep these tables const. (Same holds BTW for = the temp vtable templates). Why? In the current code they are create= d on stack. Does it really matter if they are const or not, in this case= ? They are copied anyway. So what about: make these tables const (ag= ain) and patch in the necessary dynamic changes during MMD registering= or after during vtable copying respectively. I can do that by pa= ssing an array of integers to the registration function (for example). I= just can't see what is gained by this approach. Regards Mattia
[perl #31208] dynclasses/README's instructions fail on OS X
# New Ticket Created by Nicholas Clark # Please include the string: [perl #31208] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31208 --- osname= darwin osvers= 7.3.0 arch= darwin-64int-2level cc= ccache gcc --- Flags: category=core severity=high ack=no --- On OS X, if I attempt to follow the instructions in dynclasses/README, it fails during make -C dynclasses First failure is: $ make -C dynclasses /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --dump foo.pmc /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --c foo.pmc can't find file 'foo.dump' in path '/Users/nick/Parrot/parrot24/classes/..', '/Users/nick/Parrot/parrot24/classes' at ../classes/pmc2c2.pl line 242. make: *** [foo.c] Error 2 I hack round this with $ cp dynclasses/foo.dump . And try again: $ make -C dynclasses /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --dump foo.pmc Use of uninitialized value in numeric gt () at ../classes/pmc2c2.pl line 488. /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --c foo.pmc env MACOSX_DEPLOYMENT_TARGET=10.3 cc -pipe -fno-common -no-cpp-precomp -pipe -fno-common -Wno-long-double -g -Dan_Sugalski -Larry -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -bundle -undefined dynamic_lookup \ -o foo.dylib \ -I../include -I../classes \ -L../blib/lib -lparrot foo.c ld: warning -L: directory name (arry) does not exist ld: ../blib/lib/libparrot.dylib is input for the dynamic link editor, is not relocatable by the static link editor again make: *** [foo.dylib] Error 1 I'm not sure what the problem is, as ../blib/lib/libparrot.dylib does exist, and is being found, but we seem to be making some .so specific assumptions here, or maybe some x86 specific assumptions. I'm not sure how to do this portably. Note also that make -C is *not* portable. It's a gnu make-ism. And that LD_LIBRARY_PATH instruction isn't portable either. Nicholas Clark --- Summary of my parrot 0.1.0 configuration: configdate='Tue Aug 17 12:12:23 2004' Platform: osname=darwin, archname=darwin-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=/Users/nick/Sandpit/maint/bin/perl5.8.3 Compiler: cc='ccache gcc', ccflags='-pipe -fno-common -no-cpp-precomp -pipe -fno-common -Wno-long-double ', Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags=' -flat_namespace ', cc_ldflags='', libs='-lm' Dynamic Linking: so='.dylib', ld_shared=' -bundle -undefined dynamic_lookup', ld_shared_flags='' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: DYLD_LIBRARY_PATHHOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH PERL5LIBSHELL
[perl #31209] nci_test.o needs compiling with position independant code
# New Ticket Created by Nicholas Clark # Please include the string: [perl #31209] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31209 --- osname= linux osvers= 2.6.6 arch= x86_64-linux-thread-multi cc= cc --- Flags: category=core severity=high ack=no --- Attempting to build the nci test dynamic library on an Opteron fails: cc -shared -L/usr/local/lib -fPIC -L/usr/local/lib -g \ -o runtime/parrot/dynext/libnci.so src/nci_test.o /usr/bin/ld: src/nci_test.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC src/nci_test.o: could not read symbols: Bad value collect2: ld returned 1 exit status I infer that the code for nci_test.o needs to be compiled with the appropriate position independent code flag, but I don't know how to this portably. Nicholas Clark --- Summary of my parrot 0.1.0 configuration: configdate='Tue Aug 17 13:45:23 2004' Platform: osname=linux, archname=x86_64-linux-thread-multi jitcapable=0, jitarchname=nojit, jitosname=nojit, jitcpuarch=i386 execcapable=0 perl=/usr/bin/perl Compiler: cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lpthread -lcrypt -lrt' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib -fPIC', ld_shared_flags='' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=1 byteorder=12345678, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATHSHELL
Re: Updates to modules-related pod
Kirrily Skud Robert [EMAIL PROTECTED] wrote: :Here's an initial patch to perlnewmod Thank you. : =item Get a CPAN user ID : :-Every developer publishing modules on CPAN needs a CPAN ID. See the :-instructions at Chttp://www.cpan.org/modules/04pause.html (or :-equivalent on your nearest mirror) to find out how to do this. :+Every developer publishing modules on CPAN needs a CPAN ID. Visit :+Chttp://pause.perl.org/, select Request PAUSE Account, and wait for :+your request to be approved by the PAUSE administrators. 04pause.html has some useful and important information people should probably read before requesting an account. : =item Cperl Makefile.PL; make test; make dist : :-Once again, Ch2xs has done all the work for you. It produces the :-standard CMakefile.PL you'll have seen when you downloaded and :-installs modules, and this produces a Makefile with a Cdist target. :+Once again, Cmodule-starter or Ch2xs has done all the work for you. :+They produce the standard CMakefile.PL you'll have seen when you :+downloaded and installs modules, and this produces a Makefile with a :+Cdist target. ... you see when you download and install modules. Hugo
Re: Updates to modules-related pod
[EMAIL PROTECTED] wrote: 04pause.html has some useful and important information people should probably read before requesting an account. It's also linked from http://pause.perl.org/ (about PAUSE); this latest URL is probably easier to remember.
Re:[perl #31208] dynclasses/README
$ make -C dynclasses /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --dump foo.pmc /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --c foo.pmc can't find file 'foo.dump' in path '/Users/nick/Parrot/parrot24/classes/..', '/Users/nick/Parrot/parrot24/classes' at ../classes/pmc2c2.pl line 242. make: *** [foo.c] Error 2 I hack round this with $ cp dynclasses/foo.dump . Alternativley, change line 609 of pmc2c2.pl to read unshift @include, ., $FindBin::Bin/.., $FindBin::Bin; adding . to search path Regards Mattia
