Re: Embedded perl5 modules
Richard Hainsworth [EMAIL PROTECTED] writes: Steffen said: Maybe an additional use perl5:Wx::SimpleApp; Tried it. Doesnt work. In the meantime I tried my guess and also had to learn that. See also my experiments in my other answer. *However, surely a perl6 program using a perl5 module should not require a more complex calling structure/approach than the equivalent perl5 module. Hence if use Wx; is sufficient for a perl5 program to find Wx::SimpleApp and Wx::Frame packages (namespaces), then use perl5:Wx; should be sufficient for a perl6 program. No?? Of course you are right ... in a finished perfect world. But currently we have not yet arrived. Therefore I deduced my guess from the known issues with using Perl5-from-Perl6 regarding export/import. And when you write use Wx; and get all other packages en passant, then Wx does some of that Exporter stuff. So Wx is a maybe a rather hard test for Perl5 integration. Did you have success using other Perl5 modules? I'm not sure about your target. If you want to learn Perl5 integration, maybe try something easier first. If you explicitly just need it with Wx, then maybe you still have to wait some time or find someone from the Pugs coders who might help. Maybe we should write a little test in the Pugs repository for that behaviour. Without Wx but with that indirect package export/import that Wx does. I'm just not sure where it belongs. Maybe near t/perl5/import.t -- go for it, if you dare. :-) Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Programming languages and copyright?
Hello, Does anyone know if programming languages are protected by copyright or not? When creating a new program, you are not allowed to pick-and-choose what you want from other programs sources as that would be a copyright violation. But when creating a new programming language, it seems that everyone is picking-and-choosing what they want from other programming languages. So I'd like to ask whether this is legal or not and why? -- Markus Laire
Re: Programming languages and copyright?
Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. When creating a new program, you are not allowed to pick-and-choose what you want from other programs sources as that would be a copyright violation. Sources is the key word there. You are allowed to take inspiration from what other programs _do_ -- indeed most programs out there seem to be imitations of or rivals to others. But when creating a new programming language, it seems that everyone is picking-and-choosing what they want from other programming languages. Yes, but not from the source of their implementation. (At least, not from the source of any which don't have a licence explicitly permitting doing so.) Smylers
Re: set operations for roles
HaloO, Larry Wall wrote: I now think it's a bad idea to overload | or to do type construction, Is it then a god idea to overload the set operations? At least the type constructions are set theoretic on the intension set of the roles. especially since the tendency is to define them backwards from the operational viewpoint that most Perl programmers will take. Can you give an example how these directions collide? Is it the fact that A(|)B produces a subtype of A and B, and that A()B produces a supertype? I can imagine that 'does AB' could be read as doing both interfaces. BTW, what is set complement? Is it (!)? Regards, TSa. --
Re: set operations for roles
HaloO, Jonathan Lang wrote: OK. My main dog in this race is the idea of defining new roles through the concepts of the intersection or difference between existing roles (even the union was thrown in there mainly for the sake of completion), with the consequent extension of the type system in the opposite direction from the usual one (toward the more general); I strongly agree. Having a language that allows supertying has novelty. But I think that union is not there for completion but as integral part when it comes to defining a type lattice which I still believe is the most practical approach to typing. This includes computed types, that is artificial nodes in the lattice. These intermediate types are usually produced during type checking and automatic program reasoning. Think e.g. of the type of an Array: my @array = (0,1,2); # Array of Int @array[3] = three; # Array of Int()Str This Int()Str type might actually be Item. The flattened |@array has type Seq[Int,Int,Int,Str] but the unflattend array should say something that is applicable to all its contents. The array might actually maintain this content type at runtime. And yes, this roles as sets paradigm would presumably mean that you could examine roles using '⊂', '⊃', '∈', and so on. BTW, are the ASCII equivalents spelled (), () and (in)? Regards, --
Re: Programming languages and copyright?
On 10/23/06, Smylers [EMAIL PROTECTED] wrote: Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. Yes, but the syntax of the programming language is more than just an idea. Copyright-article[1] at Wikipedia says that Copyright is a set of exclusive rights regulating the use of a particular expression of an idea or information. So, for example, the idea of look-behind assertions can't be copyrighted as it's an idea. But what about a particular form chosen to express that idea (e.g. to use before pattern to denote look-behind)? Can this be copyrighted as it's more than just an idea? [1] http://en.wikipedia.org/wiki/Copyright ps. I'm asking this because I'm thinking of creating a (simple) programming language by myself, but I'm unsure about how much syntax I could copy from any existing programming languages. -- Markus Laire
Re: set operations for roles
HaloO, Jonathan Lang wrote: OK. My main dog in this race is the idea of defining new roles through the concepts of the intersection or difference between existing roles Note that you should not call these 'intersection type' because this term is used for the union of role interfaces. That is the typist intersects the extension sets of objects doing the roles that are combined. IOW, set operations for roles could also be defined the other way around. If that solves the perceptive dissonance of a typical Perl programmer that Larry mentioned, I don't know. And yes, this roles as sets paradigm would presumably mean that you could examine roles using '⊂', '⊃', '∈', and so on. Given the semantic aspect of roles, I don't think that I'd go along with saying that 'A ⊃ B' is equivalent to 'A.does(B)' - although I _would_ agree that if 'A.does(B)' then 'A ⊃ B'. Rather, I'd think of 'A ⊃ B' as being the means that one would use for duck-typing, if one really wanted to (presuming that one can mess with how perl 6 does type-checking). I guess up to now it is undefined how structural and how nominal the Perl 6 type system is. But I agree that when a role A says that it does B that the type system should check if A ⊃ B. I believe that it should be possible to fill a node in the type lattice with a named role precisely to catch dispatches to this intersection, union or another combination interface. Or you instanciate parametric roles for the same purpose. Note that union interfaces might need some merging of signatures as I tried to argue elsewhere. Also, we might allow the subrole to change signatures in accordance with the intended subtype relation. Regards, TSa. --
Re: set operations for roles
TSa schreef: A(|)B produces a subtype of A and B, and that A()B produces a supertype Are you sure? I see as limiting; sub and | as enlarging; super. To me, is connected to multiplication (and inproduct, statistics, fuzzy logic), and | to addition (and outproduct). $ perl -we 'printf 0x%02X\n, 0x0E 0x33' 0x02 $ perl5 -we 'printf 0x%02X\n, 0x0E | 0x33' 0x3F -- Groet, Ruud Oops, I think I found a bug in sprintf: $ perl5 -we 'printf %#04X\n, 15' 0X0F which AFAIK should print 0x0F, so with a lowercase x.
Re: classnames and HLL namespaces -- help!
On Sun, Oct 22, 2006 at 11:38:10PM +0200, Leopold Toetsch wrote: Am Sonntag, 22. Oktober 2006 20:56 schrieb Patrick R. Michaud: I strongly disagree. I don't think that a subclass should have to be named as a sub-namespace of its parent class. Namespace and classes are currently totally orthogonal. You are declaring a subclass (not a sub-namespace) with all the implications for naming it. Okay, I'll rephrase to avoid the classname/namespace confusion(*): I don't think that a subclass' name should have to include the names of its parent classes. From your earlier message: On Sat, Oct 21, 2006 at 07:10:21PM +0200, Leopold Toetsch wrote: IMHO this should look like this: .HLL 'pge', '' ... cl = newclass 'Exp' # ['pge'; 'Exp'] ... .namespace ['Exp'] # ['pge'; 'Exp'] ... scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure'] ... It's the ['Exp'; 'Closure'] that bothers me here -- I don't think that a subclass should have to include the name of its parent in the class name. It should be: scl = subclass 'Exp', 'Closure'# ['pge'; 'Closure'] However, writing either this or scl = subclass 'Exp', ['Closure'] # ['pge'; 'Closure'] gives me the class Closure already registered error that started this thread. - (*): AFAICT, it's also not true that classnames and namespaces are currently totally orthogonal, since the class' methods have to be placed in a namespace that matches the classname. So, a class named [ 'Exp'; 'Closure' ] must place its methods in a [ 'Exp'; 'Closure' ] namespace. Pm
Parrot Bug Summary
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.
Re: set operations for roles
HaloO,
Ruud H.G. van Tol wrote:
TSa schreef:
A(|)B produces a subtype of A and B, and that A()B
produces a supertype
Are you sure?
Very sure ;)
In record subtyping a record is a mapping of labels to types.
In Perl 6 speak this is what a package does. One record type
is a subytpe if it has a superset of the label set and the
types of the common labels are subtypes. This record is the
intension set of types. When it grows the number of objects
in the extension set decreases. The limiting cases are the
universal set Any that has the empty intension set and Undef
or Whatever with the universal intension set but no defined
instances.
I see as limiting; sub and | as enlarging;
super.
To me, is connected to multiplication (and inproduct, statistics,
fuzzy logic), and | to addition (and outproduct).
As I just wrote elsewhere this is the extensional view of the
sets underlying types. The extension of Bool e.g. is {0,1} and
that of Int is {...,-2,-1,0,1,2,...} from which one argues that
Bool is a subtype of Int and that Bool()Int (=) Bool. On the
interface side of things Bool has to support all methods that
Int has, e.g. +, -, *, and /. Note that both types are not closed
under these operations: 1 + 1 == 2, 5/4 == 1.25. Bool adds logical
operators like and || to the intension set.
Regards, TSa.
--
Re: [svn:perl6-synopsis] r13252 - doc/trunk/design/syn
HaloO,
[EMAIL PROTECTED] wrote:
Log:
does operator is non-associative according to S03. Leave it that way for now.
[..]
-$fido does Sentry | Tricks | TailChasing | Scratch;
+$fido does (Sentry, Tricks, TailChasing, Scratch);
Does that apply to the trait verbs used in class definitions as well?
I find it a sane thing to write
class C is (A,B,C) does (X,Y,Z) {...}
Regards, TSa.
--
Re: Programming languages and copyright?
On 10/23/06, Markus Laire [EMAIL PROTECTED] wrote: On 10/23/06, Smylers [EMAIL PROTECTED] wrote: Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. Yes, but the syntax of the programming language is more than just an idea. Copyright-article[1] at Wikipedia says that Copyright is a set of exclusive rights regulating the use of a particular expression of an idea or information. So, for example, the idea of look-behind assertions can't be copyrighted as it's an idea. But what about a particular form chosen to express that idea (e.g. to use before pattern to denote look-behind)? Can this be copyrighted as it's more than just an idea? Here's another example (which I can work through to completion, unlike the look-behind example: It is an idea (and an old one) to place a symbol between two parts of a mathematical expression to indicate the two parts should be added together. That idea is uncopyrightable. Going further, it is also an idea that should multiple parts be present separated by the addition symbol without anything to group them into pairs, they should be added from left to right. It is an idea that that symbol should be +, and is likewise uncopyrightable. It is an idea that, when parsing such an expression, the rule to handle the first idea should be that an expression can be a term, or a combination of an expression, a '+' symbol, and a term. This is also uncopyrightable. The parsing rule (in BNF): expression :== term | expression '+' term; is a particular expression of the idea we've been talking about, and as such, is theoretically copyrightable. However, it is also about the only way to express that particular idea in BNF, so it may fail copyrightability (in the US) on those lines anyway. I wouldn't worry about stealing syntax from other languages, as long as you don't steal their source code without permission. Disclaimer: I am not a lawyer, IP or otherwise, and the above should not be construed as legal advice. Look-behind assertions are an idea. The use of before pattern as syntax to denote look-behind assertions is also an idea. The abstract grammar that [1] http://en.wikipedia.org/wiki/Copyright ps. I'm asking this because I'm thinking of creating a (simple) programming language by myself, but I'm unsure about how much syntax I could copy from any existing programming languages. -- Markus Laire
Re: set operations for roles
TSa writes: Ruud H.G. van Tol wrote: TSa schreef: A(|)B produces a subtype of A and B, and that A()B produces a supertype Are you sure? Very sure ;) In which case that provides a handy example supporting Larry's suggestion that this is confusing, with some people expecting it to work exactly opposite to how it does. It doesn't really matter which way is right -- merely having some people on each side, all naturally deriving what makes sense to them -- shows that implementing this would cause much confusion. Smylers
Re: set operations for roles
HaloO, Smylers wrote: In which case that provides a handy example supporting Larry's suggestion that this is confusing, with some people expecting it to work exactly opposite to how it does. So the mere fact that there are two sets involved rules out the set operators as well? It doesn't really matter which way is right -- merely having some people on each side, all naturally deriving what makes sense to them -- shows that implementing this would cause much confusion. Better suggestions? Other than just writing one or the other in the spec, I mean. I would opt for A()B producing the subtype on the footing that this is usually called an intersection type, even though the interfaces are merged. Regards, TSa. --
Re: [HOWTO] add a C file to get archived in libparrot.a
Karl Forner wrote: I've added one C src file, say src/foo.c, and include/parrot/foo.h, and a test in t/src/foo.t. I've changed the MANIFEST file accordingly, but I can not manage to have my foo.o file to be added in libparrot.a (after a make clean;perl Configure.pl ;make) What did I miss ? Not sure if you've solved this yet, but just a guess: did you try a make realclean? Jonathan
Re: set operations for roles
Smylers wrote: TSa writes: Ruud H.G. van Tol wrote: TSa schreef: A(|)B produces a subtype of A and B, and that A()B produces a supertype Are you sure? Very sure ;) In which case that provides a handy example supporting Larry's suggestion that this is confusing, with some people expecting it to work exactly opposite to how it does. It's a terminology issue. The OO terms subclass and superclass are counterintuitive, in that a superclass is more limited than the subclass that is derived from it - that is, the subclass provides a superset of the elements of the superclass. I have studiously avoided using that terminology for this very reason. Well, that and the fact that we're talking about roles here, not classes; and conceptually, roles are supposed to be more egalitarian than classes - super-role and sub-role would carry too much of a hierarchal connotation for what roles are supposed to be. () and (|) would actually reflect your intuition regarding the capabilities of the result, in that a role arrived at by means of () would provide fewer options than the individual roles used to create it, while a role arrived at by means of (|) would provide more options. It doesn't really matter which way is right -- merely having some people on each side, all naturally deriving what makes sense to them -- shows that implementing this would cause much confusion. I'll have to differ from you here. We (the language designers) get to choose how the concepts get presented, and presentation is everything (or pretty darn close). If we make a point of highlighting the set operations perspective and avoiding traditional type theory terminology (which, as Larry pointed out and TSa demonstrated, is very much inside out from how most people think), we can avoid most of the confusion you're concerned about. -- Jonathan Dataweaver Lang
Re: signature subtyping and role merging
HaloO, Jonathan Lang wrote: Please, no attempts to merge signatures. Instead, use multiple dispatch That avoids the problem before it occurs. But do you expect every role to provide its methods as multi just in case? Also, sub is an odd choice to use while illustrating role composition; while subs _are_ allowed in roles AFAIK, they're generally not put there. Methods and submethods are by far more common. The problem remains the same. After method lookup the arrow type of the non-invocant parameters has to be a contra-variant supertype of the two merged signatures. This signature is then a requirement to the composed class that indirectly does both roles. Regards, TSa. --
Current State of ParrotClass and ParrotObject?
Just wanted to collect information about ParrotClass and ParrotObject. I can't seem to instantiate a ParrotObject from a ParrotClass using the new opcode. I've seen references to the instantiate_object opcode but it seems unimplemented. I know the object pdd is coming up on Allison's stack, but how was the previous design of ParrotClass and ParrotObject suppose to work. Kevin
Re: set operations for roles
TSa [EMAIL PROTECTED] wrote: I strongly agree. Having a language that allows supertying has novelty. But I think that union is not there for completion but as integral part when it comes to defining a type lattice which I still believe is the most practical approach to typing. This includes computed types, that is artificial nodes in the lattice. These intermediate types are usually produced during type checking and automatic program reasoning. Think e.g. of the type of an Array: my @array = (0,1,2); # Array of Int @array[3] = three; # Array of Int()Str Actually, these would be something along the lines of Array of Int and Array of (Int, Int, Int, Str), respectively. That is, each of @array[0..2] would be of type Int, while @array[3] would be of type Str. @array itself would be of type Array (which, without any further qualifiers, is equivalent to Array of Any). If you must force a more restrictive type on @array, go with Array of (Int | Str) (yes, I do mean |, not (|); it's a type-matching issue, not a container-construction issue.) And yes, this roles as sets paradigm would presumably mean that you could examine roles using '⊂', '⊃', '∈', and so on. BTW, are the ASCII equivalents spelled (), () and (in)? I'd hope that they'd be something like '()', '()', and 'in'; only use parentheses when neccessary. Likewise, I'd want the relative complement operator to be '-', not '(-)'. -- Jonathan Dataweaver Lang
[svn:parrot-pdd] r15000 - trunk/docs/pdds/clip
Author: jonathan Date: Mon Oct 23 08:19:59 2006 New Revision: 15000 Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod Log: Add annotation groups to the bytecode specification. Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod == --- trunk/docs/pdds/clip/pdd13_bytecode.pod (original) +++ trunk/docs/pdds/clip/pdd13_bytecode.pod Mon Oct 23 08:19:59 2006 @@ -179,7 +179,7 @@ ||| that UUIDs are stored and read as strings. The UUID is | ||| computed by applying the hash function specified in| ||| the UUID type field over the entire packfile not | - ||| including this header and the trailing zero padding. | + ||| including this header and its trailing zero padding. | ++++ | 18 + u | n | Zero-padding to make the total header length a | ||| multiple of 16 bytes in length.| @@ -496,9 +496,21 @@ level languages can use annotations to store file names, line numbers, column numbers and any other data, for debug purposes or otherwise, that they need. -The segment comes in two parts: a list of annotation keys (such as line and -file), followed by a list of indexes into the bytecode stream and key/value -pairings (from instruction 235, the annotation line has value 42). +The segment comes in three parts: + +=over 4 + +=item A list of annotation keys (for example, line and file). + +=item An annotation groups table, used to group together annotations for a +particular HLL source file (an annotation group starting clears all active +annotations, so they will not spill over between source files; it also +allows for faster lookup of annotations). + +=item A list of indexes into the bytecode stream and key/value pairings (for +example, starting at instruction 235, the annotation line has value 42). + +=back The first word in the segment supplies the number of keys. @@ -526,6 +538,33 @@ |||0x03 - PMC Constant | ++++ +The annotation groups table comes next. This starts with a single integer to +specify the numbe of entries in the table. + + ++++ + | Offset | Length | Description| + ++++ + | 1 | 1 | Number of annotation group entries that follow.| + |||n | + ++++ + +A group entry maps an offset in the bytecode segment to an offset in the list +of annotations (that is, offset 0 refers to the first word following this +table). The list of offsets into the bytecode segment (and by the definition +of this segment, the offsets into the annotations list) must be in ascending +order. + + ++++ + | Offset | Length | Description| + ++++ + | 0 | 1 | Offset into the bytecode segment where the | + ||| instructions for a particular high level source file | + ||| start. | + ++++ + | 1 | 1 | Offset into the annotations list specifying where the | + ||| annotations for the given instruction start. | + ++++ + The rest of the segment is made up of a sequence of instructions to key and value mappings, taking the following format. @@ -552,7 +591,8 @@ to all following instructions up to the point of a new value being specified for that key with another annotation. This means that if 20 instructions make up the compiled form of a single line of code, only one line annotation is -required. +required. Note that this also implies that annotations must be placed in +the same order as the instructions.
Re: set operations for roles
HaloO, Jonathan Lang wrote: If we make a point of highlighting the set operations perspective You know that there are two sets involved. So which one do you mean? and avoiding traditional type theory terminology (which, as Larry pointed out and TSa demonstrated, is very much inside out from how most people think), we can avoid most of the confusion you're concerned about. Well, the type theory terminology has it all. You just have to be careful what you pick and how you combine the terms. Sub and super be it in class, role or type connotate an order that in fact is there as a partial order or preferably as a lattice. The rest is about choosing a syntax. I for my part can live happily with whatever flipping of () and (|) we settle on as long as I know to which set they apply. That being said I would think that prior art dictates () as meaning subtype creation. Which puts it in line with for the all junction and as logical connective. Note that the counterintuitive notation for pre-composed roles using | is gone. It still exists in the signatures, though. Regards, TSa. --
Re: set operations for roles
TSa wrote: Jonathan Lang wrote: OK. My main dog in this race is the idea of defining new roles through the concepts of the intersection or difference between existing roles Note that you should not call these 'intersection type' because this term is used for the union of role interfaces. It is? Where? I can't find it in any of the Synopses. That is the typist intersects the extension sets of objects doing the roles that are combined. IOW, set operations for roles could also be defined the other way around. If that solves the perceptive dissonance of a typical Perl programmer that Larry mentioned, I don't know. I think that defining the union of role interfaces as an intersection would only lead to confusion. Keep things clear: A()B is the intersection of A and B, and includes in its interface only those elements that are common to both A's and B's interfaces; A(|)B is the union of A and B, and includes in its interface everything in A's interface and everything in B's interface. A-B is the difference of A and B, and includes in its interface everything in A's interface that isn't in B's interface. And yes, this roles as sets paradigm would presumably mean that you could examine roles using '⊂', '⊃', '∈', and so on. Given the semantic aspect of roles, I don't think that I'd go along with saying that 'A ⊃ B' is equivalent to 'A.does(B)' - although I _would_ agree that if 'A.does(B)' then 'A ⊃ B'. Rather, I'd think of 'A ⊃ B' as being the means that one would use for duck-typing, if one really wanted to (presuming that one can mess with how perl 6 does type-checking). I guess up to now it is undefined how structural and how nominal the Perl 6 type system is. It's not explicitly stated, as far as I can see; but it does seem to be implied that type-checking makes use of .does(), and that .does() is essentially nominal (for a sufficiently broad definition of name). But I agree that when a role A says that it does B that the type system should check if A ⊃ B. I disagree. It's implicit that if A.does(B), then A ⊃ B; so checking the latter as well as the former would be redundant. Meanwhile, the converse is _not_ true: it is quite possible for A ⊃ B to be true while A.does(B) is false. Using something closer to a nominal approach allows the role's name to convey the semantics, something that a strictly interface comparison would be unable to do. Note that union interfaces might need some merging of signatures as I tried to argue elsewhere. The only merging of signatures that I'd want to see would be to drop them entirely in the case of a collision of non-multi methods. Also, we might allow the subrole to change signatures in accordance with the intended subtype relation. Note that perl 6 doesn't speak of subroles; and while it _does_ speak of subtypes, it means something entirely different by the term than what type theory means by it: in perl 6, a subtype is a way of placing restrictions on the acceptable values that an object can have. In the sense that it limits what a type can do, it's more akin to what you'd call a supertype. -- Jonathan Dataweaver Lang
Re: set operations for roles
HaloO, Jonathan Lang wrote: BTW, are the ASCII equivalents spelled (), () and (in)? I'd hope that they'd be something like '()', '()', and 'in'; only use parentheses when neccessary. Likewise, I'd want the relative complement operator to be '-', not '(-)'. Funny. I would have hoped that the parens unequivocally indicate set operations. The set difference should be (-) on the basis that numeric minus should subtract their cardinalities much like it does for arrays and hashes. Regards, TSa. --
Re: set operations for roles
Jonathan Lang schreef: () and (|) would actually reflect your intuition regarding the capabilities of the result, in that a role arrived at by means of () would provide fewer options than the individual roles used to create it, while a role arrived at by means of (|) would provide more options. OK, I am glad I asked about sure and that it is out of the way (for) now. -- Groet, Ruud
Re: signature subtyping and role merging
TSa wrote:
Jonathan Lang wrote:
Please, no attempts to merge signatures. Instead, use multiple
dispatch
That avoids the problem before it occurs. But do you expect
every role to provide its methods as multi just in case?
Conceded.
Bear in mind, though, that signatures include not only type
information, but also parameter names; and method calls are permitted
to pass an argument into a given parameter by means of its name
instead of its position, so the names cannot be disregarded. For
instance, consider the following pair of methods, supplied by
different roles:
method connect ( Terminal $from, Terminal $to ) { doit($from, $to) }
method connect ( Terminal $dest, Terminal $src ) { doit($src, $dest) }
There's no automated means that would allow you to reliably merge
those two signatures in a semantically appropriate way - not until
perl is smart enough to know that from and src have similar
connotations. When you have a conflict like this, you're better off
dropping the signatures altogether and leaving it up to the guy
writing the new implementation to figure out what to do with the
arguments that he gets.
--
Jonathan Dataweaver Lang
[svn:parrot-pdd] r15001 - trunk/docs/pdds/clip
Author: jonathan
Date: Mon Oct 23 09:30:39 2006
New Revision: 15001
Modified:
trunk/docs/pdds/clip/pdd13_bytecode.pod
Log:
Add dependencies segment to the specification and fix string constants storage.
Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod
==
--- trunk/docs/pdds/clip/pdd13_bytecode.pod (original)
+++ trunk/docs/pdds/clip/pdd13_bytecode.pod Mon Oct 23 09:30:39 2006
@@ -203,10 +203,20 @@
The minor version number should be incremented in all other cases when a
change is made that means a previous version of Parrot would not be able to
-run the program encoded in the packfile. This is mostly opcode re-numbering or
-the addition of new opcodes.
+run the program encoded in the packfile. This includes:
-{{ QUESTION: Should this also include changes to the core PMC types? }}
+=over 4
+
+=item Opcode renumbering
+
+=item Addition of new opcodes and removal of existing ones
+
+=item Addition of new core PMCs and removal of existing ones
+
+=item Changes to the interface (externally visible behaviour) of an opcode or
+PMC
+
+=back
A single version of Parrot can support reading and writing of more than one
bytecode file format. In fact, once Parrot is in production use it will be
@@ -294,6 +304,7 @@
|||0x04 - Bytecode Segment |
|||0x05 - Annotations Segment |
|||0x06 - PIC Data Segment |
+ |||0x07 - Dependencies Segment |
++++
| 1 | n | The name of the segment, as a (NULL terminated) ASCII |
||| C string. This must be padded with trailing NULL |
@@ -407,11 +418,17 @@
++++
| 1 | 1 | Flags, copied from the string structure. |
++++
- | 2 | 1 | Character set, copied from the string structure. |
+ | 2 | 1 | Character set; either the index of a built-in one or a |
+ ||| dynamically loaded one whose index is in a range given |
+ ||| in the dependencies table. |
++++
- | 3 | 1 | Length of the string data in bytes.|
+ | 3 | 1 | Encoding, either the index of a built-in one or a |
+ ||| dynamically loaded one whose index is in a range given |
+ ||| in the dependencies table. |
++++
- | 4 | n | String data with trailing zero padding as required.|
+ | 4 | 1 | Length of the string data in bytes.|
+ ++++
+ | 5 | n | String data with trailing zero padding as required.|
++++
=head4 PMC Constants
@@ -595,6 +612,60 @@
the same order as the instructions.
+=head3 Dependencies Segment
+
+This segment holds a table of external and possibly dynamically loaded items
+that are needed for this packfile to run. This includes:
+
+=over 4
+
+=item Dynamic PMC libraries (.loadlib)
+
+=item Dynamic opcode libraries (.loadlib)
+
+=item Dynamically loaded string encoding
+
+=item Dynamically loaded character set
+
+=back
+
+The segment starts with the number of entries in the table.
+
+ ++++
+ | Offset | Length | Description|
+ ++++
+ | 1 | 1 | Number of entries in the dependencies table. |
+ |||n |
+ ++++
+
+Following this are n entries of variable length, taking the following format.
+
+ ++++
+ | Offset | Length | Description|
+ ++++
+ | 0 | 1 | Number of entries in the dependencies table. |
+ |||0x00 - Dynamic PMC Library |
+ |||0x01 - Dynamic Opcode Library |
+ |||0x02 - Dynamically Loaded String Encoding |
+ |||
Re: Bytecode PDD
Hi,
Sorry for delay in getting to this - been working on-site with $JOB for
a while. Comments and questions below, but please see r15001.
Leopold Toetsch wrote:
2) How should we handle changes to the core Parrot library (mostly PMCs,
but also consider anything we promise is available)? Should this bump
the packfile version number too? Or do we want some other mechanism to
handle this?
This is still a can of worms. Not so much changes to PMC type numberings per se (which should invalidate PBCs)
Yup, after further mulling I think changes to these and
non-backward-compatible interface changes to the built-in PMCs should
cause an entry in PBC_COMPAT and invalidate said resources. Now in the spec.
but the dynamic nature of these resources.
I'll try to dump my thoughts.
A PBC refers - via its contents - to several possibly dynamically extendable
resources. A probably incomplete list is:
1) PMCs [*1]
2) charsets
3) encodings
4) HLLs
5) opcodes
(see also src/pmc/parrotinterpreter.pmc:547 ff) [*2]
Whenever such items are refered to by a numeric index and that index is part of
the PBC, we have a possible problem.
Let's look at opcodes. These are present in the PBC as index (the opcode
number). We got a packfile with some dynamic opcode inside:
opcodes
[ 10, 20, 30, 1300, 1301, 0 ]
Let's say, opcode #1300 and #1301 are from some dynamic opcode lib. Now this PF
gets loaded into an interpreter, which already has dynamic opcode librar{y,ies}
loaded. In the best case, it was the same opcode library and the opcode numbers
just happen to match. But that's pure luck.
The same argument holds for all other above resources.
I have added a dependencies segment that can be used to list all of the
dynamically loaded resources that a bytecode file uses. These can then
be located and loaded and any collisions detected (and once implemented,
resolved) at load-time.
BTW encodings seem to be missing in the pdd - and we can't do:
Character set, copied from the string structure.
because this is a pointer. We need an index into the available
charsets/encodings.
Fixed this bit, thanks.
So what I think, we have to do, is:
- store a metatable of such resources, this is basically for:
2-4) a list of names / library PMCs, which describes how to load
the resource
(or NULL, if this resource is a core resource)
1,5) same + range of indices
Will a dynamic character set or encoding library that we load not
possibly contain more than one character set or encoding and therefore
need a range of indices too? I have gone with this for now.
Please can you also expand a little on what a HLL resource is? I thought
this was just a dynamic PMC library but where some of those PMCs get
used in place of some built-ins, such as Integer using Perl6Integer
instead or something like this?
- when now a PBC is loaded, we'd have to merge this information with already in-memory structures of the interpreter. We can at least detect, if there's a collision.
We're not doing this at the moment?!
Still better would of course be to relocate the index and use this
mapping during unpacking. Unfortunately we can't do the relocation of opcodes for mmap-ed bytecde in memory.
Sure; we'll probably be able to teach pbc_merge to resolve such
collisions though, so people can merge stuff together and have them
resolved once rather than having to make an unmapped copy each runtime.
Maybe we can find some scheme to make collisions less likely too (we've
got 32 bits to play with, after all).
[*1] theoretically PMCs shouldn't be a problem, as these are usually looked up
dynamically, but it depends of course on the usage of dynamic oplibs :-(
.loadlib mypmc
...
new P0, .MyPMC # new_p_ic .MyPMC is refered to by index
new P0, 'MyPMC' # referenced by name
For the index case, we'd again have the described problem.
(The .Type syntax is always fine for core PMCs, which don't change for the
validity range of the packfile).
Yup - unless we only allow .Type for built-ins of course.
Thanks,
Jonathan
Re: signature subtyping and role merging
HaloO,
Jonathan Lang wrote:
Bear in mind, though, that signatures include not only type
information, but also parameter names; and method calls are permitted
to pass an argument into a given parameter by means of its name
instead of its position, so the names cannot be disregarded. For
instance, consider the following pair of methods, supplied by
different roles:
method connect ( Terminal $from, Terminal $to ) { doit($from, $to) }
method connect ( Terminal $dest, Terminal $src ) { doit($src, $dest) }
Well, the type system would see these as a method that besides the
invocant has got two positional parameters of type Terminal and the
classes these things are composed into have to provide a method that
accepts these two. That's easy so far. But I see your point of the
argument names. So you can construct a role conflict and leave an
undefined method for the class. As long as users abide by the positional
interface they get what either role guarantees. When names have to be
available as well, then we get an undefined method that has to have two
positionals and two named parameters such that all four names appear
to satisfy all conceivable call sites for the two roles.
There's no automated means that would allow you to reliably merge
those two signatures in a semantically appropriate way - not until
perl is smart enough to know that from and src have similar
connotations. When you have a conflict like this, you're better off
dropping the signatures altogether and leaving it up to the guy
writing the new implementation to figure out what to do with the
arguments that he gets.
I don't know how close leaving an undefined method as described above
to the class designer comes to automated merge. Note that at no point
I'm arguing that the body be merged. I'm seeing guarantees that the type
system tries to hold up in favour of the users of roles.
Regards, TSa.
--
Re: set operations for roles
HaloO, Jonathan Lang wrote: my @array = (0,1,2); # Array of Int @array[3] = three; # Array of Int()Str Actually, these would be something along the lines of Array of Int and Array of (Int, Int, Int, Str), respectively. That is, each of @array[0..2] would be of type Int, while @array[3] would be of type Str. Oh, no. Array of (Int,Int,Int,Str) would prescribe every single entry to be of the type (Int,Int,Int,Str) and I believe you need to write Seq[Int,Int,Int,Str]. @array itself would be of type Array (which, without any further qualifiers, is equivalent to Array of Any). If you must force a more restrictive type on @array, go with Array of (Int | Str) (yes, I do mean |, not (|); it's a type-matching issue, not a container-construction issue.) Which is another argument for choosing '(|)' to mean supertype in role combination. Regards, TSa. --
OO Requirements [was Re: classnames and HLL namespaces -- help!]
Allison Randal wrote: I think the object model needs a thorough going over in general Yup. It's on the list right after I/O, threads, and events. -- for the reasons above and because it's an unproven system. I'm not convinced that it will handle all of Perl 6's needs as is. No serious OO language has been implemented yet on Parrot; everything up to this point has been either procedural or functional. Ruby is a serious OO language, but it's not finished yet. For that matter, Perl 6 is partially implemented. But, I entirely agree on the core point that pushing these languages forward will help push Parrot forward. And pushing Parrot's OO support forward will enable these languages to be pushed forwards some more. :-) Would it be a good idea to start collecting requirements together from different language implementors so that when the time comes to work on the OO PDD, there is already a good description of what it needs to do? If so, I'm happy to make a start on a first cut and maintain it (e.g. accept patches to it from anyone who wants to contribute but doesn't have a commit bit). Jonathan
Re: Parrot::Coroutine
In languages/lua/lib/thread.pir, I create a Lua thread type by extension of Parrot::Coroutine. So I add a lot of methods for Lua type, but I think that 2 of these methods could be integrated in Parrot::Coroutine : - __clone - __get_pointer (equivalent of get_pointer() in src/pmc/sub.pmc) François.
Re: OO Requirements [was Re: classnames and HLL namespaces -- help!]
On Monday 23 October 2006 09:49, Jonathan Worthington wrote: Would it be a good idea to start collecting requirements together from different language implementors so that when the time comes to work on the OO PDD, there is already a good description of what it needs to do? If so, I'm happy to make a start on a first cut and maintain it (e.g. accept patches to it from anyone who wants to contribute but doesn't have a commit bit). Please do. The docs/pdds/clip/ directory exists for this. -- c
Re: OO Requirements [was Re: classnames and HLL namespaces -- help!]
On Mon, Oct 23, 2006 at 05:49:08PM +0100, Jonathan Worthington wrote: Allison Randal wrote: I think the object model needs a thorough going over in general Yup. It's on the list right after I/O, threads, and events. ... Ruby is a serious OO language, but it's not finished yet. For that matter, Perl 6 is partially implemented. But, I entirely agree on the core point that pushing these languages forward will help push Parrot forward. And pushing Parrot's OO support forward will enable these languages to be pushed forwards some more. :-) Would it be a good idea to start collecting requirements together from different language implementors so that when the time comes to work on the OO PDD, there is already a good description of what it needs to do? If so, I'm happy to make a start on a first cut and maintain it (e.g. accept patches to it from anyone who wants to contribute but doesn't have a commit bit). I'll be very happy to see this and contribute where I can. For my immediate/near-term future needs, I'm reasonably happy with Parrot's existing implementation, with the exception that classnames in HLLs seem to conflict with Parrot's pre-existing classnames (and perhaps those of other HLLs). Pm
Re: signature subtyping and role merging
TSa wrote: I don't know how close leaving an undefined method as described above to the class designer comes to automated merge. Note that at no point I'm arguing that the body be merged. I'm seeing guarantees that the type system tries to hold up in favour of the users of roles. If you're not using multi, then the signature is superfluous for type-checking purposes. That is the purpose of not using multi, after all: to avoid the overhead involved in using the signature in method identification. So either you use multi, in which case the signatures exist in parallel; or you don't, in which case the signature isn't important. -- Jonathan Dataweaver Lang
Re: classnames and HLL namespaces -- help!
Am Montag, 23. Oktober 2006 15:14 schrieb Patrick R. Michaud: .HLL 'pge', '' ... cl = newclass 'Exp' # ['pge'; 'Exp'] ... .namespace ['Exp'] # ['pge'; 'Exp'] ... scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure'] ... It's the ['Exp'; 'Closure'] that bothers me here -- I don't think that a subclass should have to include the name of its parent in the class name. It should be: scl = subclass 'Exp', 'Closure' # ['pge'; 'Closure'] I'm of course seeing your point, but the implementation differs. I'll try to summarize all the guts with more details: 1) a class hasa namespace This means that namespace names and class names are fully independent. 2) Above newclass/subclass actually are doing this: (with names abbreviated for line-length's sake) opcode / directive # Namespace Class --- .HLL 'p', '' # 'p' (or ['p'])--- (1) cl = newclass 'E' # ['p'; 'E'] 'E' scl = subclass 'E', ['E'; 'C'] # ['p'; 'E'; 'C']['E' 'C'] 3) when a class is created, the code in (2) tries to find a matching namespace in the current namespace then in the HLL namespace else a new namespace is created. 4) Summary - if you don't qualify the 'Closure' it just collides with the existing class of that name - that's it. (1) no effect (2) src/objects.c:577 ff leo
Re: Current State of ParrotClass and ParrotObject?
Am Montag, 23. Oktober 2006 16:58 schrieb Kevin Tew: I can't seem to instantiate a ParrotObject from a ParrotClass using the new opcode. You have a code snippet? Did you have a look at t/pmc/obj*.t or all the tons of OO usage all over libs? leo
Re: Bytecode PDD
Am Montag, 23. Oktober 2006 18:31 schrieb Jonathan Worthington:
1,5) same + range of indices
Will a dynamic character set or encoding library that we load not
possibly contain more than one character set or encoding and therefore
need a range of indices too? I have gone with this for now.
Indeed. We should just use the generalization i.e. a range of indices for all
resources.
Please can you also expand a little on what a HLL resource is? I thought
this was just a dynamic PMC library but where some of those PMCs get
used in place of some built-ins, such as Integer using Perl6Integer
instead or something like this?
It's a HLL name, the shared lib, and an array of type mappings. See also
src/hll.c:
interpreter-HLL_info
@HLL_info = [
[ hll_name, hll_lib, { core_type = HLL_type, ... }, namespace ],
...
]
The namespace is added at runtime.
leo
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
This patch adds a test for DOS line endings in text files in the
Parrot distribution.
Comments welcome,
Hi Paul,
could you add a check for SVN::Client and skip the test when there is no
SVN::Client?
Bernhard,
No worries :-) Please see attached patch.
I noticed something odd when I was testing this patch. When I used
the following code (adapted directly from perlcritic.t)
BEGIN {
eval { use SVN::Client; };
if ($@) {
plan skip_all = 'SVN::Client not installed';
}
}
and tested that the test couldn't find SVN::Client and hence would
skip the tests, I got a compile-time error that the module wasn't in
@INC, yet when I change the eval statement to:
eval use SVN::Client;
it works (by printing just the message: SVN::Client not installed),
and yet Programming Perl says that the latter Ceval is just a less
efficient form of the former. Any ideas what's going on here? I then
tested perlcritic.t and found that it gives an @INC compile time error
too when it can't find Test::Perl::Critic, and I can supply a patch
for that if you want. The reason I ask is that even though I have a
solution, I don't know *why* it works, and I'd like to, but can't seem
to find any reason for the difference between the Ceval forms.
Many thanks in advance!
Paul
files affected:
MANIFEST
t/codingstd/line_endings.t
Index: MANIFEST
===
--- MANIFEST (revision 14998)
+++ MANIFEST (working copy)
@@ -2450,6 +2450,7 @@
t/codingstd/cppcomments.t []
t/codingstd/cuddled_else.t []
t/codingstd/fixme.t []
+t/codingstd/line_endings.t []
t/codingstd/linelength.t[]
t/codingstd/perlcritic.t[]
t/codingstd/tabs.t []
Index: t/codingstd/line_endings.t
===
--- t/codingstd/line_endings.t (revision 0)
+++ t/codingstd/line_endings.t (revision 0)
@@ -0,0 +1,102 @@
+#! perl
+# Copyright (C) 2006, The Perl Foundation.
+# $Id$
+
+use strict;
+use warnings;
+
+use lib qw( . lib ../lib ../../lib );
+use Test::More;
+use ExtUtils::Manifest qw(maniread);
+
+# skip the tests if SVN::Client isn't installed
+BEGIN {
+eval use SVN::Client;
+if ($@) {
+plan skip_all = 'SVN::Client not installed';
+}
+}
+
+# set up how many tests to run
+plan tests = 1;
+
+=head1 NAME
+
+t/codingstd/line_endings.t - checks for DOS line endings in text files
+
+=head1 SYNOPSIS
+
+# test all files
+% prove t/codingstd/line_endings.t
+
+# test specific files
+% perl t/codingstd/line_endings.t src/foo.c include/parrot/bar.h
+
+=head1 DESCRIPTION
+
+Checks that text files do not have DOS (CRLF) line endings. Instead, they
+should have Unix (CR) line endings.
+
+=head1 SEE ALSO
+
+Ldocs/pdds/pdd07_codingstd.pod
+
+=cut
+
+my @files = @ARGV ? @ARGV : source_files();
+my @dos_files;
+
+foreach my $file (@files) {
+my $buf;
+
+# slurp in the file
+open( my $fh, '', $file )
+or die Cannot open '$file' for reading: $!\n;
+{
+local $/;
+$buf = $fh;
+}
+
+# append to the dos_files array if the code matches
+push @dos_files = $file\n
+if $buf =~ m{\r$}m;
+}
+
+ok( !scalar(@dos_files), 'Line endings correct' )
+or diag( DOS line ending found in . scalar @dos_files . files:[EMAIL PROTECTED] );
+
+sub source_files
+{
+my $client = SVN::Client-new();
+my $manifest = maniread('MANIFEST');
+my @test_files;
+# grab names of files to test (except binary files)
+foreach my $filename ( sort keys %$manifest ) {
+# try to read the svn:mime-type property of the file
+my $prop_ref = $client-propget(svn:mime-type, $filename, WORKING, 0);
+
+# if we have no mime-type property set or the mime-type is text/*
+# then the file is text (this is the assumption used by subversion)
+my $prop = $prop_ref-{$filename};
+# of the mime-type property is undefined, append to the file list
+if (!defined $prop) {
+push @test_files, $filename;
+}
+else {
+# if we know we have a text file, append it
+push @test_files, $filename
+if ($prop =~ m{text});
+}
+}
+
+return @test_files;
+}
+
+exit;
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Tue Oct 24 04:08:49 2006 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 83 new + 277 open = 360
Created this week: 5
Closed this week: 10
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
40524 [TODO] PGE - need tests for greedy backtracking
40523 [TODO] adjust string_append function and usage
40511 [PATCH] Removal of deprecated fetchmethod opcode
2 - 3 weeks old
40490 Flat/Slurpy Named Parameter Passing Errors
40472 APL test failures
3 - 4 weeks old
40443 Separate vtable functions from methods (using :vtable)
4 - 5 weeks old
5 - 6 weeks old
6 - 7 weeks old
40313 [TODO] Tcl - full namespace support
40312 [TODO] Tcl - support namespaces in [info commands]
7 - 8 weeks old
8 - 9 weeks old
40217 Parrot_autoload_class() knows about Python and Tcl
9 - 10 weeks old
40191 [PATCH] PGE simple grammar test file revisited
40182 [TODO] Convert PGE::CodeString to .pmc
40156 [TODO] - Can't use an Iterator with a DynLexPad PMC
40153 [CAGE] TEST_PROG
10 - 11 weeks old
40138 [TODO] Tcl - add tcl's tests into our repository
40132 [TODO] Remove set_pmc vtable method
40124 [TODO] Document HLL mappings
40123 [TODO] push_eh + .param for argument mismatch errors
11 - 12 weeks old
40090 [TODO] Tcl - make 'tcl.pbc --pir' work.
40072 [CAGE] tools/dev/mk_manifest_and_skip.pl requires svn
40060 [CAGE] Fix non-symbol-table namespace pollution in public headers
40059 [CAGE] Fix symbol table namespace pollution
12 - 13 weeks old
40010 [TODO] Add a mutex to eval_nr in compilers/imcc/parser_util.c
39992 [TODO] t/op/01-parse_ops.t: figure out how to test parsing of pmc
constant parameters
39939 [TODO] exhaustively test new {set,get}*global and get*namespace opcodes
13 - 14 weeks old
39932 [TODO] enable bulk operations in rt
39927 [TODO] named/slurpy parameters for PMC methods
39908 [BUG] IMCC treats $S as a non-register instead of throwing an error
14 - 15 weeks old
39855 [CAGE] configuration: define MIN/MAX macros for all integral typedefs
39852 [TODO] Tcl - Create the ::tcl namespace properly
39851 [BUG] .HLL doesn't reset the .namespace
39845 [TODO] Better IMCC Errors: unexpected IDENTIFIER
39844 [BUG] Parrot doesn't do args checking for a sub without params
39833 [TODO] Tcl - Make [rename] handle namespaces
39827 [TODO] [CAGE] implement is_abs_path()
39802 [PATCH] [CAGE] turning up the warnings levels in gcc as much as we can
15 - 16 weeks old
39784 Make Parrot's default namespace be untyped
39738 bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
16 - 17 weeks old
39648 PGE - bad variable name
17 - 18 weeks old
18 - 19 weeks old
19 - 20 weeks old
39430 Method cache not always invalidated
39329 Check to make sure PMC_str_val, etc. are used appropriately
20 - 21 weeks old
---
Overview of Open Issues
Platform Severity Tag Lang
aix 0abandoned 05005threads 0 Amber0
All 2fatal 3bounce0 BASIC0
bsdos 0High 0Bug 29 bc 0
cygwin0low 1compiler 0 befunge 0
cygwin_nt 0medium0configure 0 bf 0
darwin0none 0core 0 cola 0
dec_osf 0Normal1dailybuild0 forth0
dgux 0unknown 0docs 0 jako 0
dos 0Wishlist 3duplicate 0 Lisp 0
dynixptx 0 install 1 m4 0
freebsd 0 library 0 ook 0
generic 0 notabug 0 perl60
gnu 0 notok 0 plot 0
HPUX 0 ok0 punie1
irix 0 Patch24 python 0
irix640 regex 0 ruby 0
Linux 1 sendToCPAN0 scheme 0
lynxos0 Todo196 tcl 30
mac 0 unknown 0 urm 0
machten 0 utilities 0 Zcode0
macos 0 wontfix 0
MacOS X 0
mswin32 0
netbsd0
next 0
openbsd 1
os2 0
os390 0
other 0
powerux 0
qnx 0
riscos0
sco
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
On Oct 23, 2006, at 7:39 AM, Paul Cochrane wrote:
BEGIN {
eval { use SVN::Client; };
if ($@) {
plan skip_all = 'SVN::Client not installed';
}
}
Paul,
This should be
eval {require SVN::Client; };
use() is a compile-time directive, not runtime.
Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Clotho Advanced Media, Inc. - Creators of MediaLandscape Software
(http://www.media-landscape.com/) and partners in the revolutionary
Croquet project (http://www.opencroquet.org/)
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
I suppose the reason it's more efficient is that it compiles it at actual
compile time. The only use I know of eval{} is catching dies...
On 10/23/06, Paul Cochrane [EMAIL PROTECTED] wrote:
This patch adds a test for DOS line endings in text files in the
Parrot distribution.
Comments welcome,
Hi Paul,
could you add a check for SVN::Client and skip the test when there is no
SVN::Client?
Bernhard,
No worries :-) Please see attached patch.
I noticed something odd when I was testing this patch. When I used
the following code (adapted directly from perlcritic.t )
BEGIN {
eval { use SVN::Client; };
if ($@) {
plan skip_all = 'SVN::Client not installed';
}
}
and tested that the test couldn't find SVN::Client and hence would
skip the tests, I got a compile-time error that the module wasn't in
@INC, yet when I change the eval statement to:
eval use SVN::Client;
it works (by printing just the message: SVN::Client not installed),
and yet Programming Perl says that the latter Ceval is just a less
efficient form of the former. Any ideas what's going on here? I then
tested perlcritic.t and found that it gives an @INC compile time error
too when it can't find Test::Perl::Critic, and I can supply a patch
for that if you want. The reason I ask is that even though I have a
solution, I don't know *why* it works, and I'd like to, but can't seem
to find any reason for the difference between the Ceval forms.
Many thanks in advance!
Paul
files affected:
MANIFEST
t/codingstd/line_endings.t
Re: Synposis 26 - Documentation [alpha draft]
On October 16th Damian Conway wrote: If the contents are not a number, they are interpreted as an upper-case Unicode character name, or as a lower-case XHTML entity. For example: One more problem: not all XHTML entities are lower-case. For example: ETH; THORN; Eacute; Theta; For a complete list, see: http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_xhtml_character_entities I was thinking that we could distinguish them because Unicode character names are always multiple words, but a quick search turned up ANGLE (U+2220), so that won't work. We could special-case ETH and THORN (the only all-uppercase entities) and require translators to recognize them as entities. We could allow an ampersand to indicate that it's an entity reference: EETH and ETHORN. The ampersand would be optional if the entity name contains lowercase: either EEacute or EEacute would be ok. We could disallow EETH ETHORN and require the Unicode names: ELATIN CAPITAL LETTER ETH ELATIN CAPITAL LETTER THORN. -- Chris Madsen[EMAIL PROTECTED] -- http://www.pobox.com/~cjm --
