[perl #40410] Segfault in packfile code
Hi, I've tracked the bug down some and ci'd a workaround for this tonight, with a comment that some more digging maybe is wanted in the future. But it solves the problem just fine at the moment. Jonathan
Re: socket related constants
On Fri, Sep 08, 2006 at 12:38:39PM +0200, Leopold Toetsch wrote: Hi, typical socket ocde currently looks a bit unfriendly due to magic constants, e.g. socket sock, 2, 1, 6 # PF_INET, SOCK_STREAM, tcp I'd like to have symbolic constants for all that stuff: socket sock .PF_INET, .SOCK_STREAM, .PROTO_tcp Appended is a C snippet, which produces such constants[1]. It's incomplete and not integegrated in Configure/make at all, but maybe it is a starting point. Q: is there a better option to generate these constants? I can't give an exact answer, but... Perl 5 has gone through several generations of how to do constants There are two problems to be solved 1: Parsing C header files and identifying what are actually constants (might be #ifdefs, might be enums, the value of an #ifdef may be an expression that happens to evaluate to a constant) (For shipped libraries the alternative seems to end up being listing all the constants you expect to see, the union of constants in all the variants of that header across operating systems/compiler runtimes) 2: Injecting identified constants into Perl (here Parrot) appropriately With Perl 5.10 we should be at the point of actually having constants that are both memory efficient and inline into code at compile time. However, step 2 is easier for Perl because we're not trying to do portable bytecode. Some constants, (such as *most* of the socket constants, but I think not all) are defined in RFCs, so can be baked into bytecode at compile time. But other constants (such as POSIX limits) are per system, so a complete solution needs a way of knowing how to defer baking those constants until load time. Or maybe it doesn't call them constant as far as bytecode interpretation goes, but any JIT or AOT can see that they are, and treat them accordingly. Nicholas Clark
[svn:parrot-pdd] r14781 - trunk/docs/pdds/clip
Author: leo Date: Thu Sep 28 01:39:18 2006 New Revision: 14781 Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod Log: pddXX_cstruct - clarify a few items Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod == --- trunk/docs/pdds/clip/pddXX_cstruct.pod (original) +++ trunk/docs/pdds/clip/pddXX_cstruct.pod Thu Sep 28 01:39:18 2006 @@ -97,7 +97,7 @@ char b; DEF -The generalization of arbitrary attribute names would of course be +The generalization of quoted attribute names would of course be possible too, but isn't likely needed. =head2 Syntax variant @@ -139,13 +139,13 @@ bar_cs = subclass 'CStruct', 'bar' addattribute(s) bar_cs, 'DEF' double x; -foo foo;# the foo class is already defined -foo *fptr; +foo cfoo; # contained foo structure +foo *fptr; # a pointer to a foo struct DEF o = new 'bar' - setattribute o, 'x', 3.14 - setattribute o, ['foo'; 'a'], 4711 # o.foo.a = 4711 - setattribute o, ['fptr'; 'b'], 255 + setattribute o, 'x', 3.14 # C-ish equivalent: + setattribute o, ['cfoo'; 'a'], 4711 # o.foo.a = 4711 + setattribute o, ['fptr'; 'b'], 255 # o.fptr-b = 255 Attribute access is similar to current *ManagedStruct's hash syntax but with a syntax matching ParrotObjects. @@ -158,6 +158,8 @@ char b[100]; DEF +Access to array elements automatically does bounds checking. + =head2 Possible future extemsios cs = subclass 'CStruct', 'todo'
Re: [svn:parrot-pdd] r14774 - in trunk: . docs/pdds/clip
Am Donnerstag, 28. September 2006 01:30 schrieb Jonathan Worthington:
Hi,
Some first thoughts that come to mind after reading leo's two proposals.
+with new variants of the Caddattribute opcode:
+
+ addattribute cs, 'a', .DATATYPE_INT
+ addattribute cs, 'b', .DATATYPE_CHAR
Certainly preferable to syntax 1.
+Probably desired and with not much effort TBD 3):
+
+ addattribute(s) cs, 'DEF'
+int a;
+char b;
+ DEF
But more importantly, all syntax checking is done at PIR compile time,
whereas the string describing the struct elements and types would not be
parsed until runtime so typo's in type names or general syntax errors
aren't detected until then.
That's true. Well, the idea is of course to be able to paste arbitrary C
structures into the PIR and be done with it. (I can imagine that in the
long-run class parsing and construction will be done at BEGIN or IMMEDIATE
time. This might also be done with some external parser and not in C code.)
+The generalization of arbitrary attribute names would of course be
+possible too, but isn't likely needed.
pdd updated - I ment quoted attr names.
+ addattribute(s) bar_cs, 'DEF'
+double x;
+foo foo;# the foo class is already defined
May I suggest change second foo there to something else?
Done.
... But please don't rely too much on knowledge of
C semantics when describing Parrot ones.
Yep. OTOH are we dealing with C structures here. Pointers to structs vs.
contained structs are very common construct in C code.
+=head2 Array Structures Elements
With bounds checking on accesses to b, right?
Yep. pdd updated.
I think for safety reasons we will later want to have some way of only
letting approved code that uses unmanagedstructs run, as with them
anyone can segfault the VM in no time at all...but that's for a security
PDD or something.
Indeed.
Maybe a side issue, but how do you propose dealing with languages that
allow:
class A {
private int x;
...
}
class B is A {
private int x; /* Parent's x not visible, but name is the same. */
...
}
Where methods in A will access the x defined in A and methods in B will
access the x defined in B?
Parrot allows that already. See also t/pmc/objects_17.pir
+consequently that the attribute offsets are calculated differently
+depending on type, alignment, and padding. These calculations are
+already done in Funmanagedstruct.pmc.
I am curious how this hurts our portability. Alignment and padding can
differ somewhat between platforms.
Sure. Pointer size also differs. But as the offsets are always calculated on
the very same platform this doesn't really matter.
And don't optimizing compilers
sometimes re-order struct elements for better packing?
Not as far as I know. This would also cause troubles for C code accessing any
C library.
(Put another way: how portable is the UnmanagedStruct PMC?)
E.g. the SDL code (using {Un,}ManagedStruct a lot runs on 32 64 bit
machines, LE or BE.
A Good Thing. Also we will want an interface to get hold of the
attribute names and types...
Yep.
Another side-thought - if we know the types of the things in the
attributes of the PMC, can we not auto-generate the mark code for any we
know are PMC* or STRING*?
Yes. We do that already for ParrotObjects/Classes.
+=head2 Locking or opmc-pmc_ext-_synchronize
Why put it before the location that is pointed to? That seems confusing
to me, and inconsistent with the next_for_gc entry that is placed after
the flags rather than before the PMC starts.
Well, the idea is to have the very same struct layout, whether the PMC is
shared or not.
Plus I imagine it
complicates de-allocation - you have to check the flag and subtract
sizeof(struct _Sync) if it's set...
Sure. OTOH it's simplifying attribute access.
That's all that comes to me right now. ;-)
Thanks for all your comments and suggestions.
Thanks,
Jonathan
leo
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Aaron Sherman wrote:
I certainly hope not, as I agree with you! That's not the goal at all,
and in fact if that were a side effect, I would not want this to be
implemented. The idea of having types AT ALL for protos was something
that I threw in because it seemed to make sense at the end. The really
interesting thing is to match signature shapes, not types. That is, max
doesn't take two positional arguments, and a max that does is probably
doing something that users of max will be shocked by. To this end, a
programmer of a library *can* issue an assertion: all implementations of
max will take one (no type specified) positional parameter and any
number of adverbial named parameters (again, no type specified).
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
Of course, I hadn't quite thought this through - as packages aren't
classes, there would probably have to be heavy constraints on what
FooMultiPrototypes may declare.
This would also allow you to reuse multi prototype sets.
Also, I don't think you answered Trey's concern, that your mechanism
allows you to declare what classes may export but not what they *have*
to export, which I would also view as more important - your mechanism
seems to only serve to ban extensions and convenience methods, but
doesn't give any extra promises on the class behaviour. To extend your
example, if a library developer provides a three-argument max, it won't
get in the way and won't break any existing contracts. But if the same
developer doesn't also provide 2-argument max on that same class, it may
very well break any code that works with that class.
Re: RFC: multi assertions/prototypes: a step toward programming by contract
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe that
declarative requirements should go on roles. And then packages could do
them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information. I think there has to be a way for a role to define
constraints onto the thing it is going to be composed into---see my
unreplied mail 'class interface of roles'. The type requirements
of a role could be mostly inferred from the role definition, especially
if we have something like a super keyword that in a role generically
refers to the thing it's composed into before the role is composed.
Note that self refers to the object *after* composition and instance
creation.
Of course, I hadn't quite thought this through - as packages aren't
classes, there would probably have to be heavy constraints on what
FooMultiPrototypes may declare.
Basically instance data declarations and methods require a class
for composition. Everything else can also go into packages and modules.
IIRC, additional methods can come as package qualified as in
role Foo
{
method Array::blahh (...) {...} # goes into Array class
}
and as such require the package to make an Array class available.
Regards,
--
[HOWTO] call a method on a PMC in PIR
I suppose that again it is a trivial question, but I did not manage to find the answer by myself in the documentation. So I want for example to call diretly the elements method on a FixedBooleanArray I tried pmc.elements() pmc.elements() pmc._elements() pmc.__elements() But it did not work... In fact, what I really want to do, for debugging purposes, is to add a custom method in the FixedBooleanArray.pmc (e.g get_allocated_size() ) and be able to call it from PIR test code. Thanks Karl Forner
Re: [HOWTO] call a method on a PMC in PIR
Am Donnerstag, 28. September 2006 12:47 schrieb Karl Forner:
I suppose that again it is a trivial question, but I did not manage to find
the answer by myself in the documentation.
So I want for example to call diretly the elements method on a
FixedBooleanArray
I tried
pmc.elements()
pmc.elements()
pmc._elements()
pmc.__elements()
But it did not work...
Exactly. Due to asymmetry of methods and vtables, the latter are not
accessible as methods. You have to use the equivalent opcode:
$I0 = elements ar_pmc
But you can code a PIR wrapper for it:
.namespace ['FixedBooleanArray']
.sub 'elements' :method
$I0 = elements self
.return ($I0)
.end
usable as:
$I0 = ar_pmc.'elements'()
In fact, what I really want to do, for debugging purposes, is to add a
custom method in the FixedBooleanArray.pmc (e.g get_allocated_size() ) and
be able to call it
from PIR test code.
As you need PMC internals for this, you'd have to add it to the .pmc itself
(temporarely):
METHOD INTVAL get_allocated_size() {
return PMC_int_val2(SELF); /* or whatever */
}
Thanks
Karl Forner
HTH,
leo
Re: socket related constants
On Thu, Sep 28, 2006 at 09:36:13AM +0100, Nicholas Clark wrote: However, step 2 is easier for Perl because we're not trying to do portable bytecode. Some constants, (such as *most* of the socket constants, but I think not all) are defined in RFCs, so can be baked into bytecode at compile time. But other constants (such as POSIX limits) are per system, so a complete solution needs a way of knowing how to defer baking those constants until load time. Or maybe it doesn't call them constant as far as bytecode interpretation goes, but any JIT or AOT can see that they are, and treat them accordingly. Mentioning sockets got me thinking about APR... Has anyone seriously looked at using it for doing portable I/O? -J -- pgpYE95rRAqhn.pgp Description: PGP signature
Re: RFC: multi assertions/prototypes: a step toward programming by contract
HaloO, Trey Harris wrote: I would hate for Perl 6 to start using CAny or CWhatever in the sort of ways that many languages abuse Object to get around the restrictions of their type systems. I think that, as a rule, any prototype encompassing all variants of a multi should not only specify types big enough to include all possible arguments, but also specify types small enough to exclude impossible arguments. As Miroslav proposed to handle the specification of the interface with role composition we get another thing as well: implicit type parameter expansion. That is, a role can be defined in terms of the self type and e.g. use that as parameter type, return type and type constraints. All of which nicely expand to the module or package type the role is composed into! Regards, TSa. --
xx operator
Hi,
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit(---,10);
Interestingly, it says:
pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---
What am I misunderstanding here? Or is this a Pugs bug?
I am using pugs 6.2.12
- Fagzal
Re: xx operator
Fagyal Csongor skribis 2006-09-28 15:11 (+0200): say $string xx $repeat; List context. my $add = $string xx $repeat; Item context, for a list repetition operator. Doesn't really make sense, and I think a warning or error message would be more appropriate. I think you meant either: my @add = $string xx $repeat; or: my $add = $string x $repeat; Or perhaps: my $add = [ $string xx $repeat ]; # This is what your current code does, but I think it's best if Perl # enforced that you be explicit about the []. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: xx operator
A. Pagaltzis wrote:
I have the following code:
class MyStupidString {
method repeatit(Str $string, Int $repeat) {
say $string xx $repeat;
my $add = $string xx $repeat;
say $add;
}
};
my $obj = MyStupidString.new;
$obj.repeatit(---,10);
Interestingly, it says:
pugs test2.p6
--
--- --- --- --- --- --- --- --- --- ---
What am I misunderstanding here?
The `xx` operator. That's list-repeat, not string-repeat.
In Perl 5 terms, the code you wrote is:
sub repeatit {
my ( $string, $repeat ) = @_;
my @res = ( $string ) x $repeat;
print @res;
my $add = @res;
print $add;
}
which should make it obvious what is going on.
Thank you and Juerd.
It was indeed a misunderstanding, I though x changed to xx in Perl6
for some reasons...
Now is the first time I write some Perl6 code that I actually run, too
:) It is *really* enjoyable. Feels like this is how Perl should really
look like, and it is so DWIM I can hardly believe it. Kudos to all who
helped to make it happen!
- Fagzal
Re: RFC: multi assertions/prototypes: a step toward programming by contract
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example, above) is a promise made by a class to meet its own
specification.
In the RFC, I was trying to develop a method by which a module could
assert a stricture (consider this part of use strict in Perl 6 if you
will) that would constrain the CALLER of that module (as well as the
module itself, of course) to a particular signature template for a
multi. This allows us to centrally document a multi that might be
defined in many places, and have that documentation actively constrain
the multi to match. In this way, the user doesn't have to figure out
that max is a method on Array in order to find its documentation, and a
module that uses Array gets
Constraining a class to use the multis that it declares isn't really a
constraint. It's more of a second definition, and there isn't much need
for that in Perl 6.
I'm starting to think that proto was the wrong word, as it immediately
makes people think about C/C++ prototypes, which are not at all the
same beast.
Of course, if you want to have a role that uses prototypes to constrain
a class, that's certainly doable:
role StrictMax { our proto max(Array @array) { ... } }
class MyClass does StrictMax { ... }
Sure, that works, but an unexported, type-specific proto is rather a
weak version of what I was suggesting.
Again, here's the example that I gave at the end:
=item max
=inline our proto max(@array, *%adverbs) is export {...}
Cmax takes an input sequence or array (C@array) and
returns the maximum value from the sequence.
Specific implementations of max may be defined which
allow comparators or other adverbs (C%adverbs) to
be defined.
=cut
Re: FYI compiling PIR function calls
Jonathan Scott Duff wrote:
To be on the safe side, method (and function) names *should* be quoted. I
don't think that this is inconsistent.
Is there a reason that you would want to conflate method names and
variables used as a method name? If not, why not change the syntax
slightly so that method names in a variable are uniquely identified?
Here's a suggestion:
obj.foo() # a methodname constant
.local string bar
bar = get_some_meth()
obj.$bar() # a method variable
Exactly, change the most common case (of a method call by bare name) to
be the unmarked case, and use some additional marking on the less common
case of calling a method by a string name or method object. I wouldn't
use '$' to mark the string lookup because it's too confusing with the
temporary register variables ($S0, etc). But some other syntactic sugar
would work. This is clumsy, but then, it's also rare.
obj.{bar}() # a string method name
obj.{$S1}()
Allison
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Aaron Sherman wrote:
TSa wrote:
Miroslav Silovic wrote:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example, above) is a promise made by a class to meet its own
specification.
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD). Specifically, the role states which subroutines the package
must define, including the signatures that they have to be able to
support. IOW, it defines what the package is required to do, as
opposed to what the package is forbidden from doing (as your proposal
does). If I'm understanding the idea correctly, you write the package
role as a file, hand it to the programmer, and tell him to produce a
package that does the role.
--
Jonathan Dataweaver Lang
Re: FYI compiling PIR function calls
On Thursday 28 September 2006 11:25, Allison Randal wrote:
Exactly, change the most common case (of a method call by bare name) to
be the unmarked case, and use some additional marking on the less common
case of calling a method by a string name or method object. I wouldn't
use '$' to mark the string lookup because it's too confusing with the
temporary register variables ($S0, etc). But some other syntactic sugar
would work. This is clumsy, but then, it's also rare.
obj.{bar}() # a string method name
obj.{$S1}()
That's not bad; it reminds me a bit of Perl and Tcl.
To push a little more the other direction, is it possible for the compiler to
detect symbol and method name conflicts? It's only the collision that makes
a case ambiguous, right?
-- c
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Jonathan Lang wrote:
Aaron Sherman wrote:
TSa wrote:
Miroslav Silovic wrote:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles the central bearer of type
information.
Type information is secondary to the proposal, but I'll run with what
you said.
This (the example, above) is a promise made by a class to meet its own
specification.
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine thing to want to do. Not something that I was thinking of
initially, and only tangentially related, but a good idea. I think you
get this for free by embedding a proto (or perhaps a sigform) inside
of a role:
role Foo { sigform bar($baz) { ... } }
Notice the lack of export which forces this to only apply to the class
or module to which the role is applied via composition, not to a module
which imports that class or module.
Whereas:
package CORE;
use Array;
use List;
...
=item max
=inline sigform max(@items, *%adverbs) is export {...}
...docs...
would not only impose those constraints on this use of Array and List,
but on the caller of CORE (in this case any typical Perl invocation).
Both work equally well, which is sort of nice, given that I didn't think
about the first form before-hand. I think that goes a long way to
demonstrate the flexibility of Perl 6's package/module/class/role system.
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Aaron Sherman wrote:
Jonathan Lang wrote:
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine thing to want to do. Not something that I was thinking of
initially, and only tangentially related, but a good idea. I think you
get this for free by embedding a proto (or perhaps a sigform) inside
of a role:
role Foo { sigform bar($baz) { ... } }
What would be the difference between this and
role Foo { sub bar($baz) { ... } }
? IOW, what's the difference between a 'sigform' declaration and a
to be defined later subroutine declaration?
Notice the lack of export which forces this to only apply to the class
or module to which the role is applied via composition, not to a module
which imports that class or module.
True enough. That said, it wouldn't be hard to change this. Consider
the possibility of an exported trait, which causes whatever it's
applied to to be exported whenever a module imports its package.
Thus, you could say something like:
start of file
role Foo;
sub bar($baz) is exported { ... }
At which point anything that imports a module that composes Foo will
import bar as well.
And I'm making the (probably erroneous) assumption that Perl 6 doesn't
have a robust, intuitive means of marking package components for
export already. I'm sure that a few moments with the appropriate
Synopsis would correct said error.
--
Jonathan Dataweaver Lang
Re: FYI compiling PIR function calls
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
On Thursday 28 September 2006 11:25, Allison Randal wrote:
obj.{bar}() # a string method name
obj.{$S1}()
I'm not sure what's meant by a string method name above, but
I'd look at it as:
.local string abc
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
obj.{S0}() # call method indicated by S0
obj.$S0()# call method indicated by $S0
Having obj.abc() always mean obj.'abc'() seems to me like it's
most in line with what PIR-authors expect.
As noted in the last instance, I don't know that we need a
separate obj.{$S0}() case since the dollar sign is sufficient
to distinguish exactly what was meant. But there's also an
argument in favor of the consistency of {...} always meaning
evaluate this as opposed to treat this as literal given
by the bareword and 'abc' forms.
To push a little more the other direction, is it possible for the
compiler to detect symbol and method name conflicts?
It's only the collision that makes a case ambiguous, right?
I don't think that the compiler always knows at compile time
what method names are available for any given object, so detecting
collisions could be problematic.
However, it could certainly detect when a bareword symbol has
been used as a method name and warn about it, requiring the use of an
explicit obj.{symbol}() or obj.'symbol'() form to disambiguate it.
Pm
Re: FYI compiling PIR function calls
On Thursday 28 September 2006 12:42, Patrick R. Michaud wrote:
To push a little more the other direction, is it possible for the
compiler to detect symbol and method name conflicts?
It's only the collision that makes a case ambiguous, right?
I don't think that the compiler always knows at compile time
what method names are available for any given object, so detecting
collisions could be problematic.
Oh no, of course not.
However, it could certainly detect when a bareword symbol has
been used as a method name and warn about it, requiring the use of an
explicit obj.{symbol}() or obj.'symbol'() form to disambiguate it.
Yes, that is what I meant. If there's a symbol in the current compilation
unit with the same name as a bareword method call, require disambiguation.
Otherwise, assume it's a bareword method call.
-- c
Re: FYI compiling PIR function calls
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
I'm just quoting the relevant pieces here and add some comments below:
obj.'abc'() # call 'abc' method of obj
obj.abc() # always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of sense, and there are simple rules for the syntax:
* use {symbol}, if the thing isa symbol
* use 'name', if the 'name' contains non-identifier characters
(of if unsure, of if you are a compiler ;-)
* else you also might use bare word syntax
That should be it to deal with all that:
obj.S0() # emit warning but call 'S0' method
Rational: if bare abc isa identifier here, then CS0 too.
obj.$S0()# illegal
leo
Re: FYI compiling PIR function calls
Patrick R. Michaud wrote:
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
On Thursday 28 September 2006 11:25, Allison Randal wrote:
obj.{bar}() # a string method name
obj.{$S1}()
I'm not sure what's meant by a string method name above, but
I'd look at it as:
You got it, I meant a method name stored in a string variable/register.
.local string abc
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
obj.{S0}() # call method indicated by S0
obj.$S0()# call method indicated by $S0
Having obj.abc() always mean obj.'abc'() seems to me like it's
most in line with what PIR-authors expect.
Yup.
Allison
Re: FYI compiling PIR function calls
Leopold Toetsch wrote:
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of sense, and there are simple rules for the syntax:
* use {symbol}, if the thing isa symbol
* use 'name', if the 'name' contains non-identifier characters
(of if unsure, of if you are a compiler ;-)
* else you also might use bare word syntax
The latter two are the same rules as the rules for declaring
methods/subs, which makes for nice consistency.
That should be it to deal with all that:
obj.S0() # emit warning but call 'S0' method
Rational: if bare abc isa identifier here, then CS0 too.
I can see the value of this warning for the transition, but long-term we
really don't want the code to be littered with warnings for deprecated
features. It'd be pretty simple to write a script that combs the .pir
files in the repository for any instance of a method name that looks
like a register name.
obj.$S0()# illegal
Is '$' a valid identifier character? If so, then it's legal, but just
treated as part of the string name of the method. If not (which seems
more likely), then it's illegal anyway, so no special case is needed.
Allison
Draft of Bytecode PDD
I just got off the phone with Jonathan Worthington. At YAPC::EU he agreed to draft a PDD for Parrot's bytecode file format. He has done a fantastic job. He's checking it in now, so everyone will have a chance to comment. The PDD incorporates a handful of important changes that have been discussed over the past year. After he checks it in, he'll integrate a few updates based on things we worked out as we talked through the PDD in the call. We also still have a few open questions, which he'll briefly summarize in a separate message. Thanks to Jonathan for the wonderful work! Allison
requirements gathering on mini transformation language
I need a volunteer write up the requirements for a mini transformation language to use in the compiler tools. You wouldn't have to write up the specification for the language, just what features we need. This will help us plan what it's going to take to get from here to there, and give us a way to measure when the spec/implementation can be called done. It's essentially a matter of spending some time with me and Patrick on the phone and solidifying the ideas on paper, together with any perspectives or experience you add to the mix. Allison
Re: FYI compiling PIR function calls
Am Donnerstag, 28. September 2006 22:53 schrieb Allison Randal:
Leopold Toetsch wrote:
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of sense, and there are simple rules for the syntax:
* use {symbol}, if the thing isa symbol
* use 'name', if the 'name' contains non-identifier characters
(of if unsure, of if you are a compiler ;-)
* else you also might use bare word syntax
The latter two are the same rules as the rules for declaring
methods/subs, which makes for nice consistency.
Yep.
That should be it to deal with all that:
obj.S0() # emit warning but call 'S0' method
Rational: if bare abc isa identifier here, then CS0 too.
I can see the value of this warning for the transition, but long-term we
really don't want the code to be littered with warnings for deprecated
features. It'd be pretty simple to write a script that combs the .pir
files in the repository for any instance of a method name that looks
like a register name.
Indeed. I'm pretty sure that there isn't one test nor other .pir in the tree
using this syntax. The rules are clear enough: CS0 is parsed as IDentifier
in that case, which means:
obj.S0() := obj.'S0'()
That is: no warning needed at all.
obj.$S0()# illegal
Is '$' a valid identifier character?
No. Just a PIR temp variable signature, which makes the thingy a variable or
synmbol.
If so, then it's legal, but just
treated as part of the string name of the method. If not (which seems
more likely), then it's illegal anyway, so no special case is needed.
I wanted just to stress the illegality of it as it was differently used in a
previous mail.
Allison
leo
Re: requirements gathering on mini transformation language
Allison Randal writes: mini transformation language to use in the compiler tools. For what purpose, roughly? I've some experience with rule-based peep-hole optimisations. If it's in that area, I volunteer. Best wishes, Markus Triska
Re: [HOWTO] call a method on a PMC in PIR
METHOD INTVAL get_allocated_size() {
return PMC_int_val2(SELF); /* or whatever */
}
great, exactly what I needed
thanks
karl
Re: requirements gathering on mini transformation language
On Thursday 28 September 2006 14:51, Markus Triska wrote: Allison Randal writes: mini transformation language to use in the compiler tools. For what purpose, roughly? I've some experience with rule-based peep-hole optimisations. If it's in that area, I volunteer. That's part of it, but mostly it's for transforming one tree-based representation of a program into another. See for example Pheme's lib/*.tg files. -- c
Bytecode PDD
Hi, I've checked in the proposed bytecode PDD and also most of the changes that I discussed with Allison earlier today. Feedback on it would be greatly appreciated. One of the areas that it would good to have some input on, even if it's just a yes, that's sane, is versioning. The current implementation versions the packfile based up the current version of Parrot and the opcode fingerprint. However, between versions of Parrot it is feasible that there will be no packfile format changes, and we'd like an easy way for a particular Parrot version to assess whether it can read and run a certain packfile (as well as being able to write packfiles that are readable by previous Parrots). These things matter once Parrot is deployed in production use - new versions must be able to read older bytecode files. Therefore, a bytecode file version number has been introduced, with a major and a minor part. This is independent of the Parrot version number, and replaces the opcode fingerprint. See the proposed PDD for details. A couple of open questions on this are: 1) Is keeping the Parrot version number around sensible and if so, is having it as the version of Parrot that wrote the packfile useful? I guess it's helpful if we need workarounds for bugs in previous versions of Parrot in later versions to know this. Other thoughts? 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? Again, comments and/or suggestions on anything else in the proposal are very welcome! :-) Thanks, Jonathan
Re: Re: FYI compiling PIR function calls
Allison Randal [EMAIL PROTECTED] wrote:
.local string abc
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
obj.{S0}() # call method indicated by S0
obj.$S0()# call method indicated by $S0
Having obj.abc() always mean obj.'abc'() seems to me like it's
most in line with what PIR-authors expect.
Yup.
Why not handle this like we handle subroutines? That is, why don't we
have a find_method opcode that returns a bound method? That simplifies
parsing for IMCC and makes PIR a little simpler.
obj.'abc'() # call 'abc' method of obj
obj.abc() # same as above
$P0 = find_method obj, abc # get bound method indicated by abc symbol
$P0() # actually call it
--
Matt Diephouse
http://matt.diephouse.com
Re: FYI compiling PIR function calls
On Thursday 28 September 2006 17:57, Matt Diephouse wrote: Why not handle this like we handle subroutines? That is, why don't we have a find_method opcode that returns a bound method? That simplifies parsing for IMCC and makes PIR a little simpler. obj.'abc'() # call 'abc' method of obj obj.abc() # same as above $P0 = find_method obj, abc # get bound method indicated by abc symbol $P0() # actually call it Does that make emitting PASM a lot more difficult? All of a sudden, invoking $P0 means that $P0 has to know that it stores something in the appropriate invocant PMC register. I suppose that means creating a CurriedInvocantMethodCall PMC that does all of this magic in invoke(). That's not awful, but -- c
[svn:parrot-pdd] r14785 - trunk/docs/pdds/clip
Author: jonathan Date: Thu Sep 28 15:55:52 2006 New Revision: 14785 Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod Log: Add most of the changes resulting from discussion with Allison. Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod == --- trunk/docs/pdds/clip/pdd13_bytecode.pod (original) +++ trunk/docs/pdds/clip/pdd13_bytecode.pod Thu Sep 28 15:55:52 2006 @@ -145,58 +145,43 @@ |||0x00 - IEEE 754 8 byte double | |||0x01 - i386 little endian 12 byte long double | ++++ - | 11 | 1 | Major version number of the earliest version of Parrot | - ||| that should be able to run this file. For example, if | - ||| Parrot 0.9.5 was the first Parrot that was able to | - ||| run this bytecode file properly, this byte would | - ||| have the value 0. | - ++++ - | 12 | 1 | Minor version number of the earliest version of Parrot | - ||| that should be able to run this file. For example, if | - ||| Parrot 0.9.5 was the first Parrot that was able to | - ||| run this bytecode file properly, this byte would | - ||| have the value 9. | - ++++ - | 13 | 1 | Patch version number of the earliest version of Parrot | - ||| that should be able to run this file. For example, if | - ||| Parrot 0.9.5 was the first Parrot that was able to | - ||| run this bytecode file properly, this byte would | - ||| have the value 5. | - ++++ - | 14 | 10 | Opcode fingerprint. This stores the fingerprint of the | - ||| opcodes that the Parrot this packfile was written by | - ||| was built with. This enables detection of packfiles| - ||| that can not be run by the version of Parrot reading | - ||| the file. | - |||| - ||| The fingerprint is computed by taking the MD5 hash of | - ||| the file PBC_COMPAT, a file in the Parrot repository | - ||| that is only updated when an incompatible change is| - ||| made to the Packfile format, for example renumbering | - ||| operation codes. | - |||| - ||| This need only be checked when running a development | - ||| version of Parrot. Release versions should choose to | - ||| accept or decline a PBC file based only on the major, | - ||| minor and patch version numbers. | + | 11 | 1 | Major version number of the version of Parrot that | + ||| wrote this bytecode file. For example, if Parrot 0.9.5 | + ||| wrote it,this byte would have the value 0. | + ++++ + | 12 | 1 | Minor version number of the version of Parrot that | + ||| wrote this bytecode file. For example, if Parrot 0.9.5 | + ||| wrote it,this byte would have the value 9. | + ++++ + | 13 | 1 | Patch version number of the version of Parrot that | + ||| wrote this bytecode file. For example, if Parrot 0.9.5 | + ||| wrote it,this byte would have the value 5. | + ++++ + | 14 | 1 | Major version number of the bytecode file format. See | + ||| the section below on bytecode file format version | + ||| numbers. | + ++++ + | 15 | 1 | Minor version number of the bytecode file format. See | + ||| the section below on bytecode file format version | + ||| numbers. |
[svn:parrot-pdd] r14784 - trunk/docs/pdds/clip
Author: jonathan Date: Thu Sep 28 14:23:15 2006 New Revision: 14784 Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod Log: Add draft of the bytecode PDD. This is still missing some changes that need to be made following discussion with Allison, but gives the big picture of what is proposed. Modified: trunk/docs/pdds/clip/pdd13_bytecode.pod == --- trunk/docs/pdds/clip/pdd13_bytecode.pod (original) +++ trunk/docs/pdds/clip/pdd13_bytecode.pod Thu Sep 28 14:23:15 2006 @@ -1,5 +1,945 @@ -=pod +# Copyright (C) 2001-2005, The Perl Foundation. +# $Id$ + +=head1 NAME + +docs/pdds/pdd13_bytecode.pod - Parrot Bytecode + +=head1 ABSTRACT + +This PDD describes the file format for Parrot Bytecode (PBC) files and the +interface through which they may be manipulated programatically. + +=head1 VERSION + +$Revision$ + +=head1 DESCRIPTION + +=over 4 + +=item - The sequence of instructions making up a Parrot program, a constants +table and debug data are all stored in a binary format called a packfile or +PBC (Parrot Bytecode File). + +=item - A PBC file can be read by Parrot on any platform, but may be encoded +more optimally for a particular platform. + +=item - It is possible to add arbitrary annotations to the instruction +sequence, for example line numbers in the high level language and other debug +data. + +=item - PMCs will be used to represent packfiles and packfile segments to +provide a programming interface to them, both from Parrot programs and the +Parrot internals. + +=back + + +=head1 DEFINITIONS + +None. + + +=head1 IMPLEMENTATION + +=head2 Changes From The Current Implementation + +A number of things in this proposed PDD differ from what is currently +implemented. This section details these changes and some of the reasoning +behind them. + + +=head3 Packfile Header + +The format of the packfile header has changed completely, based upon a +proposal at +Lhttp://groups.google.com/group/perl.perl6.internals/browse_thread/thread/1f1af615edec7449/ebfdbb5180a9d813?lnk=gst +and the requirement to have a UUID. I also observed that the INT field in the +previous header format is used nowhere in Parrot and appears redundant, and +that we were missing storing a patch version number along with the major and +minor, which made the version number less useful. The opcode type is also gone +due to non-use. + +The version number now reflects the earliest version of Parrot that is capable +of running the bytecode file, to enable cross-version compatibility that will +be needed in the future. + + +=head3 Segment Header + +Having the type associated with the segment inside the VM is fine, but since +it is in the directory segment anyway it seems odd to duplicate it here. Also +removed the id (did not seem to be used anywhere) and the second size (always +computable by knowing the size of this header, so it appears redundant). + + +=head3 Fixup Segment + +We need to support unicode sub names, so fixup labels should be an index into +the constants table to the relevant string instead of just a C string as they +are now. + + +=head3 Annotations Segment + +This is new and replaces and builds upon the debug segment. See here for some +on-list discussion: + +Lhttp://groups.google.com/group/perl.perl6.internals/browse_thread/thread/b0d36dafb42d96c4/4d6ad2ad2243e677?lnk=gstrnum=2#4d6ad2ad2243e677 + + +=head3 Packfile PMCs + +This idea will see packfiles and segments within them being represented by +PMCs, easing memory management and providing an interface to packfiles for +Parrot programs. + +This part of the proposal is based upon a few previous discussions, mostly on +IRC or in realspace. Here is a mailing list comments that provide one of the +motivations or hints of the proposa. + +Lhttp://groups.google.com/group/perl.perl6.internals/browse_thread/thread/778ea0ac4c8676f7/b249306b543b040a?lnk=gstq=packfile+PMCsrnum=2#b249306b543b040a + + + +=head2 Packfiles + +This section of the documentation describes the format of Parrot packfiles. +These contain the bytecode (sequence of instructions), constants table, fixup +table, debug data, annotations and possibly more. + +Note that, unless otherwise stated, all offsets and lengths are given in terms +of Parrot opcodes, not bytes. An opcode corresponds to a word size in length. +The word size is specified in the packfile header. + + +=head3 Packfile Header + +PBC files start with a variable length header. All data in this header is +stored as strings or in a single byte so endianness and word size need not be +considered when reading it. + +Note that in this section only, offsets and lengths are in bytes. + + ++++ + | Offset | Length | Description| + ++++ + | 0 | 8 | 0xFE 0x50 0x42 0x43 0x0D 0x0A 0x1A
[svn:perl6-synopsis] r12485 - doc/trunk/design/syn
Author: larry Date: Thu Sep 28 18:53:32 2006 New Revision: 12485 Modified: doc/trunk/design/syn/S03.pod Log: Extirpated machine-dependent definition of bit complement, noticed by audreyt++. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 28 18:53:32 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 25 Sept 2006 + Last Modified: 28 Sept 2006 Number: 3 - Version: 68 + Version: 69 =head1 Changes to Perl 5 operators @@ -923,7 +923,7 @@ [%]() # fail (reduce is nonsensical) [x]() # fail (reduce is nonsensical) [xx]() # fail (reduce is nonsensical) -[+]() # +^0 (-1 on 2's complement machine) +[+]() # -1(from +^0, the 2's complement in arbitrary precision) [+]() # fail (reduce is nonsensical) [+]() # fail (reduce is nonsensical) [~]() # fail (sensical but 1's length indeterminate)
Re: RFC: multi assertions/prototypes: a step toward programming by contract
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine thing to want to do. Not something that I was thinking of
initially, and only tangentially related, but a good idea. I think you
get this for free by embedding a proto (or perhaps a sigform) inside
of a role:
role Foo { sigform bar($baz) { ... } }
What would be the difference between this and
role Foo { sub bar($baz) { ... } }
This would define a non-multi subroutine with a yadda body. Later
declarations of a multi sub by the same name would be resolved as per
the rules in, I think, A12, but don't quote me on that, as I'm probably
wrong about the location. Multi and single dispatch have rules of
engagement, but essentially don't interact much until something gets
invoked.
Still, that has little or nothing to do with constraining the definition
of multi subs by signature, which is what I was proposing.
Notice the lack of export which forces this to only apply to the class
or module to which the role is applied via composition, not to a module
which imports that class or module.
True enough. That said, it wouldn't be hard to change this. Consider
the possibility of an exported trait, which causes whatever it's
applied to to be exported whenever a module imports its package.
The original example was an exported version, so there's no change to
make. I only gave the non-exported version as an example in this recent
mail to demonstrate that the rather unrelated concept that you brought
up (defining a role that restricts multi method definitions WITHIN a
class/module/package) just happened to be easy to do given the RFC as I
proposed it, even though I had not thought about that use before.
Please, feel free to re-read the RFC. I'm getting the impression that it
wasn't as clear, as perhaps I had intended, and you might be able to
propose some clarification
