Re: Yadda yadda yadda some more
Larry Wall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
: does that mean that this use of yada yada yada is already decided on and
allowed?
Yes, with the proviso that it only works that way where a term is
expected. (As a postfix operator it's short for C..Inf.)
So, C... is a syntactically valid term which dies when evaluated at
run-time (or throws an exception, if they're not the same thing). It seems
to me then that the Yada operator has to have 2 special properties beyond,
say, a macro which returns the closure C{ die }. And it raises two
questions for me. Also, we should get used to calling it the Yada Yada Yada
term, or perhaps even the Yada literal, since it is not operating on
anything (outside its postfix unary form).
[Special Property #1]
If the Yada operator is valid anywhere a term is expected, it must
syntactically valid in all these cases:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues. This will have to be true at least in those
contexts that ask for strict type-checking, even if other scopes don't care.
This reminds me of Java's Cnull literal reference value which can be
validly assigned to any reference type. (Technically, it's not a keyword,
but try giving that answer on an interview at your own peril.)
I don't see any functional problem with this special property as long as it
can be implemented in the core language. Seems like it would have to be a
special rule of type checking. So we'd have generic Scalar as the universal
recipient, and now the Yada literal as the universal donor. (Any association
of strong type-checking with the extraction of blood is purely imaginary.
;-)
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an exception
(mod throwing syntax)
so that the first case can be redefined without a warning, while the second
case would warn on redefinition.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
fit (or exception)? I'm unsure of the meaning of this idiom, because the
only time the C... line gets evaluated is at class compilation time, which
is when we don't want any complaints in this case.
[Question #2]
Does C... know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN { our IO $server = ...; };
The rhs value is evaluated here at compile-time. Is C... smart enough to
know that and keep quiet?
Regards,
-Dov
Re: Yadda yadda yadda some more
--- Matthew Walton [EMAIL PROTECTED] wrote:
Dov Wasserman wrote:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be
assignment-compatible with any and all lvalues. This will have to
be true at least in those contexts that ask for strict type-
checking, even if other scopes don't care.
This reminds me of Java's Cnull literal reference value which can
be validly assigned to any reference type. (Technically, it's not a
keyword, but try giving that answer on an interview at your own
peril.)
I don't see any functional problem with this special property as
long as it can be implemented in the core language. Seems like it
would have to be a special rule of type checking. So we'd have
generic Scalar as the universal recipient, and now the Yada
literal as the universal donor. (Any association of strong type-
checking with the extraction of blood is purely imaginary.
As far as the compiler's concerned at that point, it might behave
something like Cundef. For the purposes of the type checker that
would probably be sufficient. Worrying about the actual value
wouldn't be a problem until runtime, at which time it's quite safe
for C... to do what it's supposed to do and complain.
I think of this as very much like the typed-undef we discussed last
month or so: ... should return an unthrown exception wrapped in
undef-ness.
The type returned by ... should just have a multitude of type-casting
tricks associated:
my int $i = ...; # Fails at compile time -- no good conversion.
my Int $i = ...; # Warns at compile time, fails at runtime.
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method,
etc.) which has only been declared with the Yada Yada Yada closure
does not generate a warning. It seems like Perl 6 will have to
take some special note, then, when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an
exception (mod throwing syntax)
so that the first case can be redefined without a warning, while
the second case would warn on redefinition.
I would guess again that the body of the sub not being actually
executed until the sub is called means that C... passes through
the compile phase without a problem. The compiler would have to
special-case it though, to allow the redefinition.
Perhaps not. If {...} evaluates to C(Code)(undef but something), the
transition from Cdefined(foo) == FALSE to Cdefined(foo) == TRUE
might not be grounds for a redef warning.
I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C I really hope it
would anyway, because if you really want to do something like that
we've already got Cundef.
This is wrong. The purpose of Cundef is I declare that I've thought
about the issue and at this point in the code $number should have no
value. The purpose of C... is I declare that there should be
something here, but I haven't thought about it yet.
IOW, C... is a form of literate programming that's relatively
self-explanatory and highly compatible with Agile development:
class foo {
has $.x = ...;
method bar() {...}
method baz($a)
{
if ($a)
{
.bar();
}
say Hello;
}
}
class foo_test
{
is UnitTestCase;
has $.foo;
method test_empty_baz()
{
$.foo = new foo;
$.foo.baz(undef);
}
}
This code should work okay -- no Yadda ever gets executed.
Then when I add:
method test_valid_baz()
{
$.foo = new foo;
$.foo.baz(1);
}
there should be a failure, because $.foo.baz calls $.foo.bar, which is
defined C{...}, which evaluates to an unspecified value exception.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would
work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it
pitch a fit (or exception)? I'm unsure of the meaning of this
idiom,
because the only time the C... line gets evaluated is at class
compilation time, which is when we don't want any complaints in
this case.
I thought class closures 'ran' at object creation time. I'm probably
wrong about that. Object creation time would be a good time for that
particular yada yada yada to start complaining though. I suspect
C... is going to be considerably more sophisticated than a macro
that replaces it with C{ die }.
I think the metaclass class assembler function will behave like this:
If only a Yadda is provided, just return a typed Yadda object.
If anything other than a Yadda:
If you provide a definition of any name, it goes in.
If you provide a Yadda, it gets recorded.
When wrapping up, if any methods are provided,
Re: Yadda yadda yadda some more
Austin Hastings wrote:
I think of this as very much like the typed-undef we discussed last
month or so: ... should return an unthrown exception wrapped in
undef-ness.
The type returned by ... should just have a multitude of type-casting
tricks associated:
my int $i = ...; # Fails at compile time -- no good conversion.
my Int $i = ...; # Warns at compile time, fails at runtime.
I don't get the reasoning here. If Yada Yada Yada is to indicate code
that you haven't written yet, it should never fail at compile time
unless it's impossible to compile the program without knowing what that
code is, so
my int $i = ...;
should compile. The problem would arise when you actually tried to run
that particular bit of code, which may well look to Parrot like 'die
horribly'.
If Yada Yada Yada is not to indicate code that you haven't written yet,
then what is it really for?
I would guess again that the body of the sub not being actually
executed until the sub is called means that C... passes through
the compile phase without a problem. The compiler would have to
special-case it though, to allow the redefinition.
Perhaps not. If {...} evaluates to C(Code)(undef but something), the
transition from Cdefined(foo) == FALSE to Cdefined(foo) == TRUE
might not be grounds for a redef warning.
That would make sense... if ... gave you an indefined code block (rather
than code which returns an undefined value, which we all know and love,
or at least I love it), it would actually make a LOT of sense.
I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C I really hope it
would anyway, because if you really want to do something like that
we've already got Cundef.
This is wrong. The purpose of Cundef is I declare that I've thought
about the issue and at this point in the code $number should have no
value. The purpose of C... is I declare that there should be
something here, but I haven't thought about it yet.
IOW, C... is a form of literate programming that's relatively
self-explanatory and highly compatible with Agile development:
class foo {
has $.x = ...;
method bar() {...}
method baz($a)
{
if ($a)
{
.bar();
}
say Hello;
}
}
class foo_test
{
is UnitTestCase;
has $.foo;
method test_empty_baz()
{
$.foo = new foo;
$.foo.baz(undef);
}
}
This code should work okay -- no Yadda ever gets executed.
Then when I add:
method test_valid_baz()
{
$.foo = new foo;
$.foo.baz(1);
}
there should be a failure, because $.foo.baz calls $.foo.bar, which is
defined C{...}, which evaluates to an unspecified value exception.
Yes, that's more or less as I would expect it to work.
I thought class closures 'ran' at object creation time. I'm probably
wrong about that. Object creation time would be a good time for that
particular yada yada yada to start complaining though. I suspect
C... is going to be considerably more sophisticated than a macro
that replaces it with C{ die }.
I think the metaclass class assembler function will behave like this:
If only a Yadda is provided, just return a typed Yadda object.
If anything other than a Yadda:
If you provide a definition of any name, it goes in.
If you provide a Yadda, it gets recorded.
When wrapping up, if any methods are provided, then a special
yadda-on-not-found dispatcher is provided. If no methods are
provided, a special yadda-on-not-inherited dispatcher is provided.
A similar data member access is provided.
So that:
class Foo {
has $.a;
has $.b;
...
}
Becomes:
class Foo {
AUTOMETH {
if inherited($method_name), run it.
else return sub {...};
}
has $.a;
has $.b;
AUTOMEMBER {
if inherited($member_name), return it.
else return \...;
}
}
So you can have objects made from class Foo, but if you try and get at a
method which doesn't exist you get Yada instead of 'that method doesn't
exist'... that makes sense, I think, because you can use any method
names you like in your code, and the effect is basically 'this method
hasn't been written yet'.
I would expect that to run and complain at compile time. That might
be irritating, but I'm not sure how else it could be done, because
BEGIN blocks are run then, and when they're run you need to know what
values you're going to assign to the variables.
Unless you gather it up inside some sort of lazy evaluation construct
that keeps delaying the evaluation of it until you hit run phase, at
which point you've probably got the entire BEGIN block ready to go,
with everything that comes after it also hanging around, and... no,
doesn't sound good does it?
Again, I like it. A partially defined object isn't fatal unless you
actually need that part.
If Yada is actually a value with a special type as you've said here,
then it falls out quite well. You can put it into anything you like, you
just get a problem the moment you
Re: Yadda yadda yadda some more
--- Matthew Walton [EMAIL PROTECTED] wrote: I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; Right. This goes back to the notion that lowercase basic types (int, str, bool) are storage efficient and therefore cannot contain values outside the domain, like Cundef. I've argued in the past that it should be possible to put undef into lctypes, to no avail. So, since no special values can go into lctypes, I presume this applies to Yadda as well -- trying to stuff a Yadda object into an lctype will result in a compile time (BEGIN time, more probably) failure. =Austin
Re: Yadda yadda yadda some more
[EMAIL PROTECTED] wrote: Austin Hastings wrote: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. Or. not so horribly. If I'm in the perl debugger, I'd want that to be a breakpoint and give me the option to type in a evaluable string to replace it. So it should throw a properly marked exception that an outer context can do something with. Good point.
Re: Yadda yadda yadda some more
On Fri, May 14, 2004 at 07:48:52AM -0700, Austin Hastings wrote: : : --- Matthew Walton [EMAIL PROTECTED] wrote: : I don't get the reasoning here. If Yada Yada Yada is to indicate : code that you haven't written yet, it should never fail at compile : time unless it's impossible to compile the program without knowing : what that code is, so : : my int $i = ...; : : Right. This goes back to the notion that lowercase basic types (int, : str, bool) are storage efficient and therefore cannot contain values : outside the domain, like Cundef. : : I've argued in the past that it should be possible to put undef into : lctypes, to no avail. So, since no special values can go into : lctypes, I presume this applies to Yadda as well -- trying to stuff a : Yadda object into an lctype will result in a compile time (BEGIN time, : more probably) failure. But the stuffing is not happening at compile time. Assignment happens at run time. Larry
Re: Yadda yadda yadda some more
Austin Hastings wrote: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. Or. not so horribly. If I'm in the perl debugger, I'd want that to be a breakpoint and give me the option to type in a evaluable string to replace it. So it should throw a properly marked exception that an outer context can do something with. -- Mark Biggar [EMAIL PROTECTED]
Re: Yadda yadda yadda some more (2)
Austin Hastings wrote:
Maybe this is how they'll teach perl at religious schools:
#! /usr/bin/perl6 -w
#
# TEMPLATE.P6 -- standard template for programs at Abstemious U.
#
use no ...;
sub usage() {...}
sub main() {...}
Aha, this is where the DWIM::AI module I suggested on 01-Apr comes in.
Create a template like the above and then DWIM::AI::Yadda will
join the dots and create the program for you !
R.
--
Richard Nuttall
Nuttall Consulting
01353 649878
www.nuttall.uk.net
Re: Yadda yadda yadda some more
--- Larry Wall [EMAIL PROTECTED] wrote: On Fri, May 14, 2004 at 07:48:52AM -0700, Austin Hastings wrote: : I've argued in the past that it should be possible to put undef : into lctypes, to no avail. So, since no special values can go : into lctypes, I presume this applies to Yadda as well -- trying : to stuff a Yadda object into an lctype will result in a compile : time (BEGIN time, more probably) failure. But the stuffing is not happening at compile time. Assignment happens at run time. Larry I don't know what I was thinking. Probably something about static vars. It's still invalid to try to fill an lctype with Yadda because of the domain issue, right? =Austin
Re: Yadda yadda yadda some more
On Fri, May 14, 2004 at 10:56:52AM -0700, Austin Hastings wrote: : It's still invalid to try to fill an lctype with Yadda because of the : domain issue, right? That's correct. It would in theory be possible to store a defined bit off to the side somewhere, but that pretty much defeats the purpose of having the lctypes in the first place. Larry
Re: Yadda yadda yadda some more
On Thu, 2004-05-13 at 15:35, Dov Wasserman wrote:
[Special Property #1]
If the Yada operator is valid anywhere a term is expected, it must
syntactically valid in all these cases:
my $id = ...;
Since I presume C... is going to be of type Object or whatever the
universal base class was (I think it was Object), this should compile
fine, and issue a run-time exception.
my Int age = ...;
Same deal. There WOULD be a small difference with:
my int $age = ...;
which is actually:
my int $age = (...).prefix:+();
which is still valid, and produces a run-time exception.
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues.
Easy enough.
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
Yes, that would have to be a special-case, and that means that ... is
smarter that just a macro (or perhaps that subroutine definition is
smarter than I'm giving it credit for. No biggie.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
No we don't know that, but I think it's fair to say that class should
probably catch the Yadda exception, and define the metaclass with some
kind of property like $thenewclass.meta does Exception::Yadda or
something like that.
[Question #2]
Does C... know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN { our IO $server = ...; };
No, I don't think it should know or care. BEGIN should probably
propagate the exception (or just ignore it), since there's no graceful
way to recover here.
The rhs value is evaluated here at compile-time. Is C... smart enough to
know that and keep quiet?
I don't see the value in keeping it quiet. You've already executed the
code the one and only time you're going to, there's no sense in not
throwing the exception.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
On Fri, 2004-05-14 at 10:48, Austin Hastings wrote:
my int $i = ...;
Right. This goes back to the notion that lowercase basic types (int,
str, bool) are storage efficient and therefore cannot contain values
outside the domain, like Cundef.
Nope, not at all.
You can say:
my int $i = $complex_high_level_cool_object;
any time you like, and that should compile clean (unless the object does
something special at compile-time to exclude such a conversion from even
being attempted).
The question I have is: how do classes control their conversion? In C++
you can overload the casting operator for any time and/or define a
constructor for the receiving type.
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
Aaron Sherman wrote:
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
From A12:
**
New Grammatical Categories
The current set of grammatical categories for operator names is:
CategoryExample of use
--
coerce:as 123 as BigInt, BigInt(123)
self:sort @array.=sort
term:...$x = {...}
prefix:++$x
infix:+ $x + $y
postfix:++ $x++
...
**
It's not exactly clear how that's used, considering that you can't do
multi-dispatch on the return type (right?)...perhaps like
multi sub coerce:as(Int $dest is rw, MyObj $src) {...}
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Yadda yadda yadda some more
Aaron Sherman writes:
The question I have is: how do classes control their conversion? In C++
you can overload the casting operator for any time and/or define a
constructor for the receiving type.
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
Yep, that's what happened. See Apocalypse 12 under Overloading.
Specifically, it's defined by the operator coerce:as. So:
class Foo {...}
multi sub *coerce:as (Foo $foo, ::Bar $class) {
say Converting to $class.name()
}
my Bar $bar = Foo.new; # Converting to Bar
You can do it explicitly, too:
my $bar = Foo.new as Bar;
Luke
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote: IMHO, we are currently talking C only, so that shouldn't be a problem. I hope anybody tells me if I'm wrong. Still, I am curious. Why would the linker need to know about C or C++? I thought ICU contained some C++ files. As to why we care, you might need different libraries for c versus c++. For example, the Solaris c++ man page has this note: By default, the CC driver passes the following -l options to ld: -lC -lC_mtstubs -lm -lw -lcx -lc There are likely other issues too, but that's the first one that comes to mind. Of course, to build ICU the flags would be necessary, but we're not building it directly - we are asking it to build itself, and then we just link to the resulting library, which shouldn't need anything special. Am I getting things wrong here? Ron
CALL__BUILD
Hi,
whats the plan WRT to CALL__BUILD?
I've written a patch that makes it the default, but does a fallback to
__init if no BUILD property is set. If the __init method does not exists,
no exception is thrown (like before), whereas now an exception is thrown if
you specify a BUILD property and the specified method does not exists.
A special case is if you set BUILD to an empty string, then no constructor is
called for the class, not even __init if it exists.
All tests are passing, plus two new tests for the new functionality (exception
if constructor not found and constructor disabling)
Should I apply it?
jens
Index: src/objects.c
===
RCS file: /cvs/public/parrot/src/objects.c,v
retrieving revision 1.90
diff -u -w -r1.90 objects.c
--- src/objects.c 27 Apr 2004 12:00:43 - 1.90
+++ src/objects.c 14 May 2004 15:09:34 -
@@ -482,6 +482,7 @@
void * __ptr;
} __ptr_u;
STRING *meth;
+*meth_str = NULL;
#if 0
prop = VTABLE_getprop(interpreter, class, prop_str);
if (!VTABLE_defined(interpreter, prop))
@@ -509,6 +510,7 @@
PMC *classsearch_array = get_attrib_num(class_data, PCD_ALL_PARENTS);
PMC *parent_class;
INTVAL i, nparents;
+#if 0
int free_it;
static void *what = (void*)-1;
/*
@@ -527,6 +529,7 @@
Parrot_base_vtables[enum_class_delegate]-init(interpreter, object);
}
else {
+#endif
/*
* 1) if class has a CONSTRUCT property run it on the object
*no redispatch
@@ -538,6 +541,7 @@
STRING *meth_str;
PMC *meth = get_init_meth(interpreter, class,
CONST_STRING(interpreter, CONSTRUCT), meth_str);
+ int default_meth;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -556,6 +560,16 @@
classsearch_array, i);
meth = get_init_meth(interpreter, parent_class,
CONST_STRING(interpreter, BUILD), meth_str);
+ /* no method found and no BUILD property set? */
+ if (!meth meth_str == NULL) {
+ /* use __init as fallback constructor method, if it exists */
+ meth_str = string_from_cstring(interpreter, __init, 6);
+ meth = Parrot_find_method_with_cache(interpreter,
+ parent_class, meth_str);
+ default_meth = 1;
+ }
+ else
+ default_meth = 0;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -564,9 +578,23 @@
Parrot_run_meth_fromc_save(interpreter, meth,
object, meth_str);
}
+ else if (meth_str != NULL
+ string_length(interpreter, meth_str) != 0 !default_meth) {
+ real_exception(interpreter, NULL, METH_NOT_FOUND,
+ Method '%Ss' not found, meth_str);
+ }
}
meth = get_init_meth(interpreter, class,
CONST_STRING(interpreter, BUILD), meth_str);
+ /* no method found and no BUILD property set? */
+ if (!meth meth_str == NULL) {
+ /* use __init as fallback constructor method, if it exists */
+ meth_str = string_from_cstring(interpreter, __init, 6);
+ meth = Parrot_find_method_with_cache(interpreter, class, meth_str);
+ default_meth = 1;
+ }
+ else
+ default_meth = 0;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -575,7 +603,14 @@
Parrot_run_meth_fromc_save(interpreter, meth,
object, meth_str);
}
+ else if (meth_str != NULL string_length(interpreter, meth_str) != 0
+ !default_meth) {
+ real_exception(interpreter, NULL, METH_NOT_FOUND,
+ Method '%Ss' not found, meth_str);
}
+#if 0
+}
+#endif
}
/*
Index: t/pmc/object-meths.t
===
RCS file: /cvs/public/parrot/t/pmc/object-meths.t,v
retrieving revision 1.17
diff -u -w -r1.17 object-meths.t
--- t/pmc/object-meths.t 10 Apr 2004 12:50:23 - 1.17
+++ t/pmc/object-meths.t 14 May 2004 15:09:35 -
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 19;
+use Parrot::Test tests = 21;
use Test::More;
output_like('CODE', 'OUTPUT', callmethod - unknown method);
@@ -136,6 +136,52 @@
ok 2
OUTPUT
+output_is('CODE', 'OUTPUT', disabling the constructor);
+newclass P1, Foo
+new P0, .PerlString
+setprop P1, BUILD, P0
+find_type I1, Foo
+new P3, I1
+print ok 1\n
+end
+.namespace [Foo]
+.pcc_sub __init:
+print nok ok!\n
+invoke P1
+CODE
+ok 1
+OUTPUT
+
+output_is('CODE', 'OUTPUT', specified constructor method does not exist);
+newclass P1, Foo
+new P0, .PerlString
+set P0, bar
+setprop P1, BUILD, P0
+
+newsub P20, .Exception_Handler, _handler
+set_eh P20
+
+find_type I1, Foo
+new P3, I1
+print not ok 1\n
+end
+
+_handler:
MMD stuff
Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, well, there you go. It does break some of the object tests, since they don't yet participate in MMD the way they ought, but that should happen later on. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Dan Sugalski wrote: At 5:23 PM -0700 5/13/04, Jeff Clites wrote: [Most commentary snipped, as it's dead-on] - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? Hi, I have little expertise in building libraries on many platforms. But aren't these issues all addressed by GNU's 'libtool'. Is there a licensing reason for not using that? CU, Bernhard -- ** Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Addition to compiler_faq.pod
patch attached. gist: how do i manage a simple case of lexical pads? cfaq.diff Description: Binary data -sterling
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Wed, 12 May 2004, Ron Blaschke wrote: I have finally sorted out the details of the flags stuff, which I will present below. Any comments are highly appreciated. Be warned: I am going to implements this if there are no objections. ;-) You might want to review the patch I submitted about a year and a half ago -- it's # 18319, and it included some (but certainly not all) of your good ideas. In particular, I was careful to distinguish among three separate functions: Compiler: Used to turn .c files into .o files. Linker:Used to combine .o files (and libraries) into an executable. Shared Library Builder: Tool to turn .o files into a shared library. I called it by the Configure variable 'ld', but better names are certainly welcome. Each one of these tools needs its own set of flags. I gather parrot's now trying to include stuff compiled with C++, so you'll also need a macro for that. Furhter, if parrot's going to include stuff compiled with C++, the Linker will have to be a command that correctly handles C and C++. On Unix systems, that's probably just the C++ compiler. I don't know what it is on Windows or VMS. Regarding C++ flags, I'd hope that the C++ compiler would accept the same flags as the C compiler, but you ought to allow for the possibility of setting extra c++ -specific flags, so you'll need a macro for that too. - The following macros will be provided in the Makefile CFLAGS_COMMON common compiler flags LDFLAGS_COMMON common linker flags xxx_STATIC_BUILDcflags and ldflags to build static parrot xxx_STATIC_USE cflags and ldflags to use static parrot PARROT_STATIC_NAME full, platform dependent name of static parrot lib xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot xxx_DYNAMIC_USE cflags and ldflags to use shared parrot PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib The name of the parrot library should blend into the current system (and might even be different for debug builds, eg libparrot_g.so (is that correct?) or parrotd.lib). For perl5, the direction we went with this issue was to embed the different build information into the directory, rather than into the library name. That way, you don't have to change all the command lines that might link to parrot from -lparrot to -lparrot_g or -lparrot_64 or -lparrot_mt or -lparrot_longdouble or -lparrot_whatever. Keeping multiple versions of a parrot shared library on a system at the same time is tricky, and needs to be very carefully thought out. -- Andy Dougherty [EMAIL PROTECTED]
Re: Events (I think we need a new name)
On Wed, May 12, 2004 at 06:15:54PM +0200, K Stol wrote: | It does, though, sound like we might want an alternate name for this | stuff. While event is the right thing in some places it isn't in | others (like the whole attribute/property mess) we may be well-served | choosing another name. I'm open to suggestions here... | | The system sends a 'message' to the user program, telling it has | finished (for example) Disk I/O. The aged Windows API does things as 'message queues'. Windows keeps a message queue for every running application. An application calls GetMessage to retrieve each message. As I recall, each message is a triple: a message-code, a word-parameter, and a long-parameter which is often a pointer when the simple word-parameter is not sufficient. An application then can choose to pass-up on the message, leading to a default implementation by calling DispatchMessage. It can also PostMessage to add a message to a particular application/thread's event queue. SendMessage is the blocking version of PostMessage. Anyway, if this is close to what you mean by 'event', then I'd consider calling it a 'message' and lifting as must of the Windows message-queue design pattern as seems appropriate. Clark
Re: Event design sketch
On Tue, May 11, 2004 at 02:06:51PM -0400, Dan Sugalski wrote: At 1:10 PM -0400 5/11/04, Uri Guttman wrote: i don't think there is a need for all those variants. why would alarm need any special opcode when it is just a timer with a delay of abs_time - NOW? let the coder handle that and lose the extra op codes. I didn't see any reason to not do absolute times as well as deltas. It's no big deal either way. You may need the distinction later. POE's mailing list has a thread with a periodicity of about six months: What happens when daylight-saving time comes or goes? The answer: All your short-term timers fire at once if the clock moves ahead, or everything stalls for an hour (or so) when it moves back. So far the best solution requires a distinction between absolute and relative timers: Adjust the relative timers to compensate for the shift, but leave the absolute ones alone. Relative timers tend to be used for things like timeouts and periodic polling. You don't want all your TCP connections to suddenly time out when the clock jumps ahead, and you don't want your log tailers to pause an hour when it skips back. However, you usually do want your absolute-timed jobs to run when the wall clock says they should be. Something to keep in mind. -- Rocco Caputo - http://poe.perl.org/
RE: Events (I think we need a new name)
How about: tocsin toc.sin( P ) Pronunciation Key (tksn) n. An alarm sounded on a bell. A bell used to sound an alarm. A warning; an omen. -Original Message- From: Gordon Henriksen [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 2:52 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Events (I think we need a new name) Matt Fowles wrote: I think Page already has a different meaning in computers, namely a page of memory. Not to mention a web page. For what it is worth, I support event as the name. Being as I think I'm largely responsible for the sense that the name needs to be changed, I should point out that I do actually support calling these events--so long as they're modified to play nice with OS event loops. Upon reflection, that just requires a means to synchronously dispatch an event to a handler chain from a C callback. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED] The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Events (I think we need a new name)
It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot event'? One advantage... it'd be easy searchable. I recall a pain whenever I searched for 'thread', or 'Icon'. Regards, Waldemar -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 6:08 PM To: [EMAIL PROTECTED] Subject: Events (I think we need a new name) Okay, so I'm working on redoing the events document based on the critiques from folks so far. (Which have been quite helpful) I should have a second draft of the thing soon. It does, though, sound like we might want an alternate name for this stuff. While event is the right thing in some places it isn't in others (like the whole attribute/property mess) we may be well-served choosing another name. I'm open to suggestions here... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Events (I think we need a new name) - Parcel?
I LOVE IT: PARrot Container for Event Lobbing!!! -Original Message- From: Andy Wardley [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 7:36 AM To: Butler, Gerald Cc: 'Gordon Henriksen'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: Events (I think we need a new name) - Parcel? Butler, Gerald wrote: How about: tocsin [...thinking out loud...] I'm not sure it's a good idea to use an obscure word, even if it is appropriate to the usage. It should be a word that the average user would recognise, and hopefully be able to intuit some sense of what it does. How about Parcel? Like Packet and Message it provides a sense of what it is doing. The metaphor extends to sending and receiving parcels, wrapping and unwrapping them, and so on. On a more trivial note, the first three letters make it a prime candidate for a corny acronym: PARrot Communication Event Layer PARrot Container for Event Lobbing PARrot Commissioner for Event Liaison A The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Events (I think we need a new name) - Parcel?
Butler, Gerald wrote: How about: tocsin [...thinking out loud...] I'm not sure it's a good idea to use an obscure word, even if it is appropriate to the usage. It should be a word that the average user would recognise, and hopefully be able to intuit some sense of what it does. How about Parcel? Like Packet and Message it provides a sense of what it is doing. The metaphor extends to sending and receiving parcels, wrapping and unwrapping them, and so on. On a more trivial note, the first three letters make it a prime candidate for a corny acronym: PARrot Communication Event Layer PARrot Container for Event Lobbing PARrot Commissioner for Event Liaison A
RE: Events (I think we need a new name)
On Fri, 2004-05-14 at 06:27, Rachwal Waldemar-AWR001 wrote: It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot event'? One advantage... it'd be easy searchable. I recall a pain whenever I searched for 'thread', or 'Icon'. If you're talking about search engines, then of course parrot event works just fine. If you're talking about searching your code, then that's another matter. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Addition to compiler_faq.pod
At 8:58 AM -0400 5/13/04, Sterling Hughes wrote: patch attached. gist: how do i manage a simple case of lexical pads? Applied. Now to get the darned things answered... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: MMD stuff
On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, well, there you go. It does break some of the object tests, since they don't yet participate in MMD the way they ought, but that should happen later on. It would be great to have a quick paragraph-or-two about the design/API/goals. I know what MMD is in general, but I got lost in figuring out whether this MMD is supposed to be the back-end for Perl6's multi's (I think it isn't), how it relates to PMCs and their VTABLE's, the high-level view of how it's implemented, why it's faster (than what?), what types we are dispatching on (I v. N v. S v. P, or PMC types, or Object types), how type fallbacking is done, what you have to put in a .pmc file (?) to create an MMD entry, etc. Maybe that would be more than a paragraph, but a quick paragraph would let me ask better questions. (And I saw docs/mmd.pod, but I'm looking for a higher-level overview.) Thanks, JEff
Re: MMD stuff
At 10:48 AM -0700 5/14/04, Jeff Clites wrote: On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, well, there you go. It does break some of the object tests, since they don't yet participate in MMD the way they ought, but that should happen later on. It would be great to have a quick paragraph-or-two about the design/API/goals. I know what MMD is in general, but I got lost in figuring out whether this MMD is supposed to be the back-end for Perl6's multi's (I think it isn't), how it relates to PMCs and their VTABLE's, the high-level view of how it's implemented, why it's faster (than what?), what types we are dispatching on (I v. N v. S v. P, or PMC types, or Object types), how type fallbacking is done, what you have to put in a .pmc file (?) to create an MMD entry, etc. Good point. I should write up something more formal, but for the moment... This MMD stuff is only for the functions in the PMC vtable that take a PMC and a second parameter (right now only a PMC, but when we're done it'll work for any right-hand type). The goal here is to ultimately rip out all these functions from the vtable and leave them in the MMD subsystem where they really belong. Ultimately it'll be faster since nearly all the PMC classes parrot will run with will have their vtable methods call the MMD system *anyway*, so we cut out that level of indirection. PMC writing shouldn't change--the pmc preprocessor will pull out the code from it and treat any defined vtable methods that are now MMD as the default for that PMC class. At the moment there's no hierarchy and distance searching for filling in the MMD table--either there's a dead-on correct entry or there isn't. That needs fixing, though there's still the issue of deciding what the class hierarchy is, but we'll get there in a bit. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
MMD changes in
Some tests are failing, and there are still issues with parrotobject-derived thigns, but the changes are all in and should be a matter of getting the busted stuff un-busted. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Thu, 13 May 2004 17:23:18 -0700, Jeff Clites wrote: xxx_STATIC_BUILDcflags and ldflags to build static parrot We should make it clear that we are talking about building a static lib (to distinguish from what the next macro is intended for)--so how about: xxx_STATIC_LIB_BUILD or xxx_LIB_STATIC_BUILD (I'm worried that xxx_STATIC_BUILD by itself isn't clear.) xxx_LIB_STATIC_BUILD is fine with me. xxx_STATIC_USE cflags and ldflags to use static parrot How about: xxx_STATIC_LINK I was more thinking along the line of building the library (..._BUILD) and using the library (..._USE). PARROT_STATIC_NAME full, platform dependent name of static parrot lib How about: LIBPARROT_STATIC Agreed. - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? Dan has already read my thoughts on that, and posted them. - When building parrot the compiler macro PARROT_LIB_EXPORTS will be defined, when using parrot PARROT_LIB_IMPORTS Again, for what use? I'm not against these last 2 sets of macros--just wondering what the intended use is. It's used to let the compiler know that the mentioned symbols are exported/imported. The two macros will probably only be used to get the PARROT_API macro, for those platforms that use it, right. Eg, Microsoft uses __declspec(dllimport) void someFunction() to let the compiler know that someFunction should be imported from a DLL. Maybe other compilers have a similar kludge. So, here's the new complete list of things. Hope you like it. Makefile CFLAGS_COMMON common compiler flags LDFLAGS_COMMONcommon linker flags CFLAGS_LIB_STATIC_BUILD cflags to build static parrot LDFLAGS_LIB_STATIC_BUILD lflags to build static parrot CFLAGS_LIB_STATIC_USE cflags to use static parrot LDFLAGS_LIB_STATIC_USElflags to use static parrot LIBPARROT_STATIC full, platform dependent name of static parrot lib CFLAGS_LIB_DYNAMIC_BUILD cflags to build dynamic parrot LDFLAGS_LIB_DYNAMIC_BUILD lflags to build dynamic parrot CFLAGS_LIB_DYNAMIC_USEcflags to use dynamic parrot LDFLAGS_LIB_DYNAMIC_USE lflags to use dynamic parrot LIBPARROT_DYNAMIC full, platform dependent name of dynamic parrot lib C PARROT_LIB_STATIC compiling for static parrot PARROT_LIB_DYNAMICcompiling for dynamic parrot PARROT_LIB_EXPORTSexport parrot symbols (compiling parrot lib) PARROT_LIB_IMPORT import parrot symbols (using parrot lib) PARROT_APIdeclare as API Ron
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Fri, 14 May 2004 09:11:32 +0200, Bernhard Schmalhofer wrote: I have little expertise in building libraries on many platforms. But aren't these issues all addressed by GNU's 'libtool'. Is there a licensing reason for not using that? autoconf, automake and libtool address the issues we are facing, but focus on UNIXisch operating systems. IIRC, these tools create a bunch of shell scripts, glued together by m4. I'd rather stick to something that scares me a little less. Ron
Re: more B::Concise stuff (PATCH - updated)
Jim Cromie wrote: Jim Cromie wrote: folks, attached patch has following adjustments to B::Concise and its tests. heres 2nd rev of that patch, now against 22802 Thanks, applied as change 22820. Time to play with it...
