Re: Elimination of Item|Pair and Any|Junction
Larry Wall wrote:
On Wed, Jul 27, 2005 at 06:28:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.
That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking. We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to - $x {...}. Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions. (And if that's the wrong way to think about it,
please tell us why.)
Sorry, here's the patch:
: Code @Array %Hash $Item
: | // |
with: | TupleRecord |
invocant(s) : ||
:/ \__ ___|_
|: | |\|| | |
.Method : Sub Block |Value Inf Undef Junction
/|: |\ | |
/ |: | \Ref[Code]|
Rule |: | Macro|
|:_/|__/|\___
|: | | | | | |
Multi : | ~Str +Num \Ref :Pair /Match/
Now the Junction is nicely constraint with the upper bound Item (less
specific) and a lower bound Value (more specific). This also reads
nice if you want to (explicitly) allow both:
sub ( Value|Junction $val_junc )
What sub ( $any ) should default to, I don't know. My $Item indicates
Item, but could also be $Value. Or unspecific $(Item|Value).
--
$TSa.greeting := HaloO; # mind the echo!
Re: Inferring (Foo of Int).does(Foo of Any)
HaloO, Autrijus Tang wrote: [..much better explaination of the co/contra prob then mine skipped..] Hence, my proposal is that Perl 6's generics should infer its variancy, based on the signature of its methods, and derive subtyping relationships accordingly. Yes!! That would be great. But I would restrict it to the onboard methods or however we call them. Outside/free methods specialized on the generic type are firstly referential in nature, and as such bind their $.attr, @.array, %.hash and .code referential expressions through the invocant. They form a mediator layer between unrelated code and the code implementing the type's guts. The other alternative is do as Java does, which is assume invariancy by default, then force users to write variancy annotations, but I think that is considerably less attractive. There may be a case for inferring by default, but overridable by the user; if so there needs to be a syntax for that. Well, that pivots around how refs behave. I would opt for them beeing const unless explicitly allowed :rw by the instance owner. Is the syntax for that actually \$x:rw? Or even plain \$x if we assume that every sigil expression *always* means implicit const ref? And thus needs a dereferencer, e.g. $x()? Then $x = $y; # means dispatch to op = $x := $y; # same, but op := requires $x to be writeable \$x = $y; # same as := ? I prefer \$x:rw which might fail # depending on where $x refs to \$x := $y; # ??? Consider $x = [EMAIL PROTECTED]; # assume there's no slot 42, then the array could # hand-out a \.[42]:rw and allow subsequent # assignment # but $x = [EMAIL PROTECTED]; # assume .[23] is filled, then the array returns # a const ref Such an array would be typed Array of ::T^Ref:rw[Undef of ::T] and as such a hot candidate for the default array :) -- $TSa.greeting := HaloO; # mind the echo!
Re: Garbage Collector API
On 26 Jul 2005 05:18:05 -, David Formosa ) [EMAIL PROTECTED] wrote: We are should have an API to talk to the GC and give it hints about when it should run, and tweek the verious paramitors for its running. For example [...] Also my Bigobjet $big is GC::timely = Bigobect; # Request timely # destruction of $big. Usefull for filehandels and network # resources. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Compiling dynamic PMCs
hi, as my attempt to write a lua compiler is continuing (slowly but surely), and quite some stuff is working already (although rather s l o w), I decided it was time to write the PMCs representing the various Lua datatypes. I understood from my previous postings (and replies on those) that PMCs can be either implemented in PIR (although they are really created as objects, right?), or in C as .pmc files. I get the feeling writing them in C as .pmc files is the way to go, so I started with the first pmc for the lua language: LuaNil.pmc. Whenever a variable hasn't been assigned a value, its 'value' is nil. (pretty much the same as None, I think). According to the README file in the 'dynclasses' directory, adding dynamic PMCs can be done by: 1. write the PMC 2. edit parrot/config/gen/makefiles/dynclasses.in 3. make In my case this didn't work. Editing the dynclasses.in file didn't trigger the make system to make my PMC. After getting a fresh parrot, before making it, I added my pmc file, edited the dynclasses.in file, and started making parrot. This works (of course), but it's a bit cumbersome to do this everytime I'm adding a PMC. Anybody got an idea what may go wrong? thanks, klaas-jan
Re: Compiling dynamic PMCs
Klaas-Jan Stol wrote: 1. write the PMC 2. edit parrot/config/gen/makefiles/dynclasses.in 3. make In my case this didn't work. The .in files are processed by Configure.pl to create the real files. perl Configure.pl ... should do it, possibly after 'make realclean'. thanks, klaas-jan leo
[perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
# New Ticket Created by Michael G Schwern # Please include the string: [perl #36677] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36677 Parrot cannot start up if either STDOUT or STDERR are closed. In both cases it exits with 65. This problem was noticed because ponie (which uses Parrot) would not start up if STDERR was closed. $ perl -wle 'close STDERR; system(parrot --version); print $? 8' 65 $ perl -wle 'close STDOUT; system(parrot --version); print STDERR $? 8' Parrot IO: Failed init layer(unix). 65 $ perl -wle 'system(parrot --version); print $? 8' This is parrot version 0.1.2-devel built for ppc-darwin. Copyright (C) 2001-2005 The Perl Foundation. All Rights Reserved. Parrot may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Parrot source kit. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See either the GNU General Public License or the Artistic License for more details. PASM/PIR compiler version 0.1.2. 0 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in [EMAIL PROTECTED]
Re: pmc syntax
hi,
Will Coleda wrote:
On Jul 27, 2005, at 4:00 PM, Klaas-Jan Stol wrote:
hi,
Is there any documentation about the complete syntax for pmc files
when writing PMCs (this time in C)?
I think that's technically the only way to write PMCs. (things
written in PIR are Objects). And, as you've seen, pmc2c.pl is
currently where most of this documentation lives.
yep, thanks. In a previous posting (or blog entry? I can't find it at
this moment), I think Dan mentioned that the plan was to be able to
write PMCs either in PIR or in C. Depending on the server running
Parrot, one of both implementations would be used; sometimes it may not
be possible to have you own custom PMCs installed, so you would have to
use the PIR version.
But you're right, creating PMCs in PIR uses the newclass/subclass
syntax, which makes them objects. But, if I understood correctly, they
behave more or less the same, right? (in that case, effectively it
wouldn't make any difference)
I found genclass.pl and pmc2c.pl, but I couldn't find anything about
all keywords that can be used. In particular, I wrote down some
scenarios. Maybe there are some more cases than these.
Case 1:
pmclass Foo {
[ vtable methods here]
}
This one is simple. It just creates a new PMC class, as a
superclass. If I understand correctly, when writing such a class,
you would start with genclass.pl. Or, would extending default be
ok as well?
A note: genclass gives you a PMC with a *lot* of empty methods. You
should delete all the ones that you don't actually want to override.
You don't need to extend default, that's the default if you don't
override something.
You mean, this is done implicitly, right? (in Java terms: writing a
class Foo { ... } would mean Foo is extending Object)
Also note that you can put in methods that don't correspond to vtables.
These would be called as... ehm... methods :-), right?
Case 2:
pmclass Foo extends Bar {
[vtable methods here]
}
A PMC class extending from Bar. Extra vtable methods for Bar's extra
functionality (WRT Foo), or vtable methods with different behaviour
than Bar, must be written.
Yup. Note that you can specify multiple extendees.
I don't know very much about multiple inheritance, but I do know a bit
of C++ (not very fluently); what if you would inherit from 2 classes
that both offer the same method?
Which one is called? (I think C++ just won't compile, but it's been some
time I used it)
Case 3:
pmclass Foo does Bar {
[vtable methods here]
}
I don't really understand what this does. I understand the does
keyword says something about an interface (Bar) that is
implemented by this class (Foo). Why would you do this? Why does
one need this? I saw in pmc2cl.pl that there are a number of
interfaces defined already. Is there anything written about these
interfaces?
Does corresponds to the Cdoes opcode: there's no formal definition
of these interfaces, so there's no concrete list: it's only a
convention at this point. pmc2c.pl has a fairly recent list of what's
in play, and I've updated the POD to reflect these comments below
(some of which are WAGs).
array: container PMC with numerically-keyed elements
event: PMC that can be used with event queue
hash : container PMC with string-keyed elements
library : PMC that corresponds to a dynamic library
ref : PMC that references another PMC
scalar : (only used by the sample dynclasses/foo.pmc)
I'm guessing scalar might correspond directly to things Integer,
String, PerlNum, but no one is using that at the moment.
So, to sum up: when you use does in your PMC, you're not actually
contractually obligated to say that the PMC is going to act a certain
way; so, when I use does in my PASM, I'm not guaranteed anything
other than that you put that keyword in your PMC def.
This will change later, right? Otherwise your PMC could be lying, saying
it *does* something, which it doesn't.
Regards.
I came across another thing WRT PMC writing singleton.
Suppose I would want to have my own custom representation of None. I
created a class extending None, but this child class is no singleton
anymore (I created 2 instances, compared them: they proved to be 2
different objects). Looking in none.pmc:
INTVAL is_equal(PMC* other) {
MMD_None: {
return 1;
}
MMD_DEFAULT: {
return 0;
}
}
}
What should I do to have my child class be a singleton too? (just
extending singleton as well?)
thanks for your help,
klaas-jan
Re: [PATCH] recreatable shuffled tests for prove
demerphq wrote: Whose command line? Mine doesnt by default come with xargs. I expect it didn't come with perl either, yet you seem to have managed to install that yourself. -- David Cantrell
[ANNOUNCE] Test::SerialFork
The uploaded file Test-SerialFork-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/Test-SerialFork-0.01.tar.gz size: 3891 bytes md5: 087b258311b0265ad96946bfd7feb0e9 This module allows you to run the same test multiple times, with different parameters. The forking isolates the runs from each other, so that interpreter-wide changes made by one test run don't affect the others. This module is somewhat similar to Test::MultiFork, in that the test process forks a specified number of times, and runs your tests in each child process. The difference is that SerialFork only does one fork at a time, where MultiFork does them all at once. It's also much easier to give descriptive labels with SerialFork, so the output of the test program is much clearer. -- Peter Haworth [EMAIL PROTECTED] perl -Mstrict -we '$_ = goto F.print chop;\n=rekcaH lreP rehtona tsuJ;F1:eval' -- Abigail
[PATCH] Readme file dynclasses
hi, attached a patch that changes the README file in dynclasses directory. The original doesn't mention you have to do perl Configure.pl after adding a new PMC file. klaas-jan --- README 2005-07-28 13:10:51.0 +0200 +++ README.new 2005-07-28 13:10:32.0 +0200 @@ -58,8 +58,10 @@ =item 2 Edit C../config/gen/makefiles/dynclasses.in and append your PMC(s) to -the build target and: - +the build target. The dynclasses.in file is processed by Configure.pl to +create the real makefiles. So, invoke the configure script, then make: + + $ perl Configure.pl $ make =item 3
Re: Compiling dynamic PMCs
Leopold Toetsch wrote: Klaas-Jan Stol wrote: 1. write the PMC 2. edit parrot/config/gen/makefiles/dynclasses.in 3. make In my case this didn't work. The .in files are processed by Configure.pl to create the real files. perl Configure.pl ... should do it, possibly after 'make realclean'. thanks, that works. I sent a patch to update this document a minute ago (it's only a minor detail, but it may help other beginning PMC writers and prevend this question being asked again) kj
Re: Messing with the type heirarchy
On Wed, 27 Jul 2005, [ISO-8859-1] TSa (Thomas Sandla?) wrote: value to carry on a useless imaginary part. And Complex should consistently return undef when compared to other Nums or Complexes. And the Compare role My 0.02+0.01i: in mathematics it is commonly used to write e.g. z3 to mean z is real AND as a real number is less than 3. Michele -- Might I suggest you take nice strong draught of hemlock before you post again? I think we'll all be much better off... You are besmearing the memory of Sokrates. - David Kastrup in comp.text.tex, Re: Is Kastrup...
Re: Messing with the type heirarchy
HaloO Michele,
you wrote:
On Wed, 27 Jul 2005, [ISO-8859-1] TSa wrote:
value to carry on a useless imaginary part. And
Complex should consistently return undef when compared
to other Nums or Complexes. And the Compare role
My 0.02+0.01i: in mathematics it is commonly used to write e.g. z3 to
mean z is real AND as a real number is less than 3.
Which in Perl6 is written as
Complex where { .imaginary =:= 0|Undef } does Num;
somewhere in the Complex package. This would make your
intensions possible by dispatching to infix:{''}:(Num,Num)
but still preventing the general case.
--
$TSa.greeting := HaloO; # mind the echo!
Re: pmc syntax
Klaas-Jan Stol wrote: Suppose I would want to have my own custom representation of None. What should I do to have my child class be a singleton too? (just extending singleton as well?) None isn't a singleton. But have a look at the Null PMC or better env.pmc. $ grep singletion classes/*.pmc (the way to create singletons might change though) thanks for your help, klaas-jan leo
Re: pmc syntax
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
Suppose I would want to have my own custom representation of None.
What should I do to have my child class be a singleton too? (just
extending singleton as well?)
None isn't a singleton. But have a look at the Null PMC or better
env.pmc.
$ grep singletion classes/*.pmc
mmm, I looked at classes/none.pmc, this is a copy/paste:
===
#include assert.h
static PMC * Py_None;
pmclass None singleton {
===
Maybe this is wrong?
I'll have a look at the null pmc, thanks!
(the way to create singletons might change though)
thanks for your help,
klaas-jan
leo
klaas-jan
Re: [PATCH] Readme file dynclasses
Klaas-Jan Stol wrote: hi, attached a patch that changes the README file in dynclasses directory. The original doesn't mention you have to do perl Configure.pl after adding a new PMC file. Thanks, applied - r8710. leo
Re: pmc syntax
Klaas-Jan Stol wrote:
mmm, I looked at classes/none.pmc, this is a copy/paste:
===
#include assert.h
static PMC * Py_None;
pmclass None singleton {
Ah, yep - None is a singleton too - sorry for my confusion.
So it should be rather easy to subclass None, implement get/set_pointer
and use a distinct file-static PMC* storage for your singleton.
leo
Re: pmc syntax
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
mmm, I looked at classes/none.pmc, this is a copy/paste:
===
#include assert.h
static PMC * Py_None;
pmclass None singleton {
Ah, yep - None is a singleton too - sorry for my confusion.
So it should be rather easy to subclass None, implement
get/set_pointer and use a distinct file-static PMC* storage for your
singleton.
leo
ah great. it works! :-). Apparently, inheriting from a singleton class
doesn't make the child class a singleton, you have to add the
singleton keyword in the class definition header.
one more question though:
1a: when are set_pointer and get_pointer actually called?
1b: in set_pointer (I copied it from None.pmc) an assertion is done. Why
is this? (this is also part of question 1a: set_pointer is called once,
apparently?)
void set_pointer(void* ptr) {
assert(!Lua_Nil);
Lua_Nil = (PMC*) ptr;
}
Anyway:
P0 = new LuaNil
print P0
prints nil. Great! :-)
thanks.
klaas-jan
Re: pmc syntax
Klaas-Jan Stol wrote: 1a: when are set_pointer and get_pointer actually called? From pmc.c:pmc_new 1b: in set_pointer (I copied it from None.pmc) an assertion is done. Why is this? (this is also part of question 1a: set_pointer is called once, apparently?) Well, it asserts that you really just create one PMC of that kind. thanks. klaas-jan leo
Re: An idea for doing pack.
I have a fundamental disagreement with what pack used to be - it's too stringish... =) the printf and unpack syntaxes always bothered me because they are akin to 'eval'ing, more than they are to quasi quoting. I like your Pack object - that is the parsed template, but I'd also like to be able to generate these templates with a programmatic interface that isn't string concatenation... Is it just a simple data structure? Or do you have anything in mind? Will we have more powerful nesting? I think this is in order nowadays. Actually, to be really wicked, I think that packing is just applying rules in reverse (this is tricky and indeterminate, since there are no alternatives or options in unpacking/packing), and unpacking is the opposite, with two exceptions: captures are converted by looking at the binary data and interpreting it, not just stuffing it in a string the syntax is different Anywho, I like your proposal, but i'd like some even fresher ideas into pack and unpack, so i'm just trying to kick the thread around... -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me kicks %s on the nose: neeyah! pgpe8LSqamIbj.pgp Description: PGP signature
Re: Garbage Collector API
On Thu, Jul 28, 2005 at 01:08:13 -, David Formosa (aka ? the Platypus)
wrote:
On 26 Jul 2005 05:18:05 -, David Formosa )
[EMAIL PROTECTED] wrote:
We are should have an API to talk to the GC and give it hints about when it
should run, and tweek the verious paramitors for its running.
For example
[...]
Also
my Bigobjet $big is GC::timely = Bigobect; # Request timely
# destruction of $big. Usefull for filehandels and network
# resources.
I like this approach the most: it let's users specify what they
need, not how they need it done.
Every GC has slightly different semantics. If we have a generational
GC that has delays, or a reference counting scheme that does
occasional reachability tests, it doesn't really matter.
What we want is features:
some object needs to die appropriately, because i'm using
DESTROY to manage resources, or trigger an action
And we can also open the door to optimizations:
some object is cheap to store, you can collect it later than
usual
everything under this object belongs to it, and only to it (that
is, you can cleanup the whole tree when cleaning this up)
and so on and so forth.
We do need this applying to:
roles and classes:
class Moose is GC::timely { ... }
a policy for attributes of objects:
class Moose {
has $. handles method is GC::timely; # not good enough, i
# want to be able to say all children, and I want this to
# be inheritable... A class property, i guess
}
instances:
# your syntax is per container
my $big = $something but GC::timely; # do we have runtime 'does'? I
keep forgetting
contained elements within a container
my @a is Array of (Item is GC::timely);
and containers themselves without respect to their contained:
my @a is Array is GC::timely
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgp7hENFCf619.pgp
Description: PGP signature
Re: execution platform object? gestalt?
On Wed, Jul 27, 2005 at 08:59:53 -0700, Larry Wall wrote:
So in this particular case it might be better to just say
if exists get_javascript_class {...}
Eeep... That reminds me of how you check between versions of perl.
I think I want something else:
$?RUNTIME
this is a common interface to an object that does all this.
It's lexical because the same bit of code might run on a hybrid
platform if we're getting carried away.
It let's you ask mostly about roles:
if ($?RUNTIME ~~ /IsDomishBrowser/){
# the browser runtime has the window class in the dom, we
# can get it, and it doesn't matter if we're running on
# javascript or parrot embedded in mozilla
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
pgpiXbJuJ5LNx.pgp
Description: PGP signature
Re: The meaning of returns
HaloO Autrijus,
you wrote:
D) Make the return type observe both #2 and #3 at compile time,
using type variables:
sub id ( (::T) $x ) returns ::T { return($x) }
And this is a natural extension to guide the inferencer so it won't be
totally giving up on polymorphic functions such as id. C) and D) can
be taken together, resulting to a powerful soft typed language.
This is my preference. The only known issue with parametric typing is
the proliferation of params as soon as you want to stay away from
unpecificity.
However, if we take the view that type annotation are merely storage
allocation hints and runtime coercers, then A) is probably the way to go.
Please no. Or at least not exclusively. I see your storage allocation
hints as a data environment needed to implement the type.
--
$TSa.greeting := HaloO; # mind the echo!
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 00:26:27 +0800, Autrijus Tang wrote: Er, but Junctions take methods, the same way Objects do, so if there is an Object in the type hierarchy, Junction probably belongs to it. Maybe there is a role called 'Junctive'? I think junctions are orthogonal to other types, except when people try to deal with them explicitly... The all encompassing type is not really a type, but more of a shortcut. My take: Any Object Item Atom ... Pair Junction int, str, ... where any of these can also 'do' Junctive. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me tips over a cow: neeyah!! pgpKyYEaVx5jp.pgp Description: PGP signature
Re: lazy list syntax?
On Wed, Jul 27, 2005 at 20:17:41 -0300, Flavio S. Glock wrote:
I have an object representing the sequence 1..Inf.
I tried creating a Coroutine, and then assigning the Coroutine to an
Array, but it only yielded 1:
my @a = $span.lazy; # 1
The coroutine worked fine in a while loop, but it didn't work in a for
loop.
I think unary = is what you want:
my @a = $span.lazy;
for [EMAIL PROTECTED] - $item {
...
}
Ofcourse, my @a = $span.lazy will have to be fixed, but what you
tried should be working.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgp1biNHaEIxu.pgp
Description: PGP signature
Re: embedding ParTcl
On Jul 27, 2005, at 9:46 PM, Thilo Planz wrote:
Hi,
I have a few beginner's question about ParTcl.
I am trying to embed ParTcl into a PIR application, which seems to
work quite nicely, except that I have not yet figured out how to do
certain things.
This is almost certainly no fault of your own. =-)
=
1) Is there a way to reset the Tcl interpreter between invocations?
.sub _main @MAIN
load_bytecode languages/tcl/lib/tcllib.pbc
$P1 = compreg 'TCL'
$P0 = compile $P1, 'set a 1; puts $a'
$P0()
# now reset the TCL interpreter somehow
$P0 = compile $P1, 'incr a; puts $a'
$P0()
.end
Well, the interpreter is running inside parrot - all the sub and
variable definitions are stored in parrot namespaces... so for your
particular example, removing the global variable '$a' from the
namespace Tcl should be sufficient. The interpreter should have its
own state which you can reset, but a lot of that is hidden in globals
in the _Tcl namespace.
I think when we add support for [interp] and [safe], you'll be able
to do manage this process more cleanly.
2) I can access TCL variables from PIR using
find_global _Tcl, __read
Is there any way to access Parrot globals from TCL ( other than
doing inline PIR to assign them to a TCL variable) ?
At this point, no. We need the [namespace] command to be able to poke
around outside the Tcl namespace. At which point you'll be able to
do something like:
set a ::_parrot::Perl6::\$b
Interoperability between HLLs isn't finalized yet, though, so I'm not
sure if we'll each end up in our own top level namespace.
3) Is there a way to pass parameters to the subroutine produced by
the TCL compiler ?
.sub _main @MAIN
load_bytecode languages/tcl/lib/tcllib.pbc
$P1 = compreg 'TCL'
$P0 = compile $P1, 'puts $first_parameter'
$P0('hello')
# now reset the TCL interpreter somehow
.end
Nope. I would expect this to work:
.sub main @MAIN
load_bytecode languages/tcl/lib/tcllib.pbc
$P0 = compreg TCL
$P1 = compile $P0, proc _tmp {a} {puts $a}
$P1()
$P2 = find_global Tcl, _tmp
$P3 = new String
$P3 = hello
$P2($P3)
.end
That is, define a sub in Tcl that does what you want, then invoke
that sub. This fails on the last line, however, with _scratch_pad:
too deep. Adding this as a TODO item in the partcl test suite...
4) Is there a way to pass parameters from TCL to inline PIR code ?
My current work-around is to put them into variables and access
those using __Tcl::__read.
At the moment, no. However, since [inline] is a partcl creation (not
part of pure tcl), we can define whatever semantics we like: We could
pre-process the string and expand variable/backslash/command
substitution...
But, as I noted above: every variable and proc in the script is
really a parrot variable at some level: so you can use find_global,
find_lex, find_name, etc. Variables have a $ sigil, procedures have a
sigil. Variables in tcl's level 0 are parrot globals, everything
used in a proc is a lexical. {{ check out t/tcl_pir_compiler.t test #
2 for an example going in the other direction. }}
The sigils are to avoid problems with code like: set a 2; a, which
until a week or so ago, failed because it was trying to execute a
String PMC with a value of 2, instead of correctly complaining about
an invalid command.
Thanks,
Thilo
Thank you! Sorry the answer to most of your questions was no... If
there's anything I can do to help improve partcl for your use, let me
know. Since I was able to get a concrete TODO test out of #3, that'll
probably get fixed first.
Regards.
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 05:31:46AM +0800, Autrijus Tang wrote: : On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote: : Hrm. I thought the original motivation of forcing people to write : : Any|Junction : : was precisely to discourage people from accidentally write : : sub foo (Any $x) : : and have $x accept a Junction. In other words, any() should not be of : type Any. Hence it still feels natural for me that Any occurs at the : position of Mumble. : : FWIW, if Any is to be ruled to be the top type and includes Junction, : then I support Darren's proposal of Single, and maybe the Object type : can be simply eliminated to Any: There is something to be said for avoiding Object as a word with too much existing baggage from other cultures. : Any - Item - Single :- Pair : - Junction : - int, num, str : : This also means that int num str will fit to Any via autoboxing. Which makes Any mean anything that can act like an Object rather than the stricter anything that 'isa' Object. Hmm... Item could take over the 'isa' role of Object, I suppose. That does imply that Junctions (and any other syntactic lazinesses we throw into that slot) aren't really objects. Maybe we can deal with that. Or maybe Any really does mean Object and we're just viewing our hierarchy too strictly if we make every relationship isa. That's one thing that neither this formulation nor Thomas's are making very clear--which type relations are really subclassing, which are role composition, and which are subtype constraints. Certainly some of Thomas's recombining relations should be viewed as role composition rather than MI. And you can view the whole autoboxing issue as an implementation detail of constrained subtypes, where the constraint happens to be a restriction on the set of values that can fit into a particular representation. And I'm still not entirely sure I believe the not-yet-bound-ness of Pairs is all that different from the not-yet-bound-ness of Junctions to the extent that a different type level is warranted. I guess I still think there ought to be a way of marking Pairs on the call end as to whether they're intended for named args or not, without warping the whole top-level type system to that end. Larry
Re: Type::Class::Haskell does Role
HaloO Luke, you wrote: All in all, generic equality and comparison is something that Perl 5 did really poorly. Some people overloaded eq, some overloaded ==, some wrote a -equal method, and there was no way to shift between the different paradigms smoothly. This is one of the times where we have to choose for them. My ideas run more along a role that defines an ordering on a type. Such a role might require slot/infrastructure methods .EQUAL .LESSER and compose other ops from these with namespace assignment: ::.= ::= any( .==, . ) ::Str ::= Item where .value.does(Order[eq, lt]) ::Num ::= Item where .value.does(Order[==, ]) Actual syntax might be more convoluted :) The point is that the 'generic' comparator is a method junction. More like: Ahm, what did the operants say their comparator was? BTW, where can I read about PIL, other then in Parrot/Pugs svn? -- $TSa.greeting := HaloO; # mind the echo!
Re: [perl #36597] [PATCH]Dominance Frontiers
Can someone apply this? I have another patch ready that depends on this one. Thanks! -Curtis On 7/19/05, via RT Curtis Rawls [EMAIL PROTECTED] wrote: # New Ticket Created by Curtis Rawls # Please include the string: [perl #36597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 This patch adds support for dominance frontiers in imcc, including: -Array of Sets for dominance frontiers -An efficient algorithm described in A Simple, Fast Dominance Algorithm, Cooper et al. (2001) -Free and dump functions -Curtis
Re: [perl #36597] [PATCH]Dominance Frontiers
FYI, on OS X 10.4.2, I get: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/p6rules/backtrack.t1 256151 6.67% 2 t/pmc/eval.t 3 768143 21.43% 12-14 t/pmc/perlstring.t 1 256681 1.47% 61 t/pmc/string.t 1 256351 2.86% 28 I have some slight differences from svn-latest which of course shouldn't affect these tests. =-) On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote: # New Ticket Created by Curtis Rawls # Please include the string: [perl #36597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 This patch adds support for dominance frontiers in imcc, including: -Array of Sets for dominance frontiers -An efficient algorithm described in A Simple, Fast Dominance Algorithm, Cooper et al. (2001) -Free and dump functions -Curtis df.patch
Re: [perl #36597] [PATCH]Dominance Frontiers
The eval tests are failing with a pristine checkout so we can ignore those. Applying your patch to a pristine build yields only the backtrack.t failure: #2 eats 100% of the CPU until I kill it: it doesn't behave that way in svn-head. Looks like PerlString and String were red herrings. Should track down why p6rules is misbehaving with your patch, though. Regards. On Jul 28, 2005, at 1:55 PM, Will Coleda wrote: FYI, on OS X 10.4.2, I get: Failed Test Stat Wstat Total Fail Failed List of Failed -- - t/p6rules/backtrack.t1 256151 6.67% 2 t/pmc/eval.t 3 768143 21.43% 12-14 t/pmc/perlstring.t 1 256681 1.47% 61 t/pmc/string.t 1 256351 2.86% 28 I have some slight differences from svn-latest which of course shouldn't affect these tests. =-) On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote: # New Ticket Created by Curtis Rawls # Please include the string: [perl #36597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 This patch adds support for dominance frontiers in imcc, including: -Array of Sets for dominance frontiers -An efficient algorithm described in A Simple, Fast Dominance Algorithm, Cooper et al. (2001) -Free and dump functions -Curtis df.patch
Re: [perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
i've added a new test t/run/exit.t that checks parrot exit codes under different scenarios. the 8 subtests all pass on win32. hopefully this will reproduce the behavior you're seeing. ~jerry On 7/27/05, via RT Michael G Schwern [EMAIL PROTECTED] wrote: # New Ticket Created by Michael G Schwern # Please include the string: [perl #36677] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36677 Parrot cannot start up if either STDOUT or STDERR are closed. In both cases it exits with 65. This problem was noticed because ponie (which uses Parrot) would not start up if STDERR was closed. $ perl -wle 'close STDERR; system(parrot --version); print $? 8' 65 $ perl -wle 'close STDOUT; system(parrot --version); print STDERR $? 8' Parrot IO: Failed init layer(unix). 65 $ perl -wle 'system(parrot --version); print $? 8' This is parrot version 0.1.2-devel built for ppc-darwin. Copyright (C) 2001-2005 The Perl Foundation. All Rights Reserved. Parrot may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Parrot source kit. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See either the GNU General Public License or the Artistic License for more details. PASM/PIR compiler version 0.1.2. 0 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in [EMAIL PROTECTED]
Re: [perl #36597] [PATCH]Dominance Frontiers
On Thu, 28 Jul 2005, Will Coleda wrote: Applying your patch to a pristine build yields only the backtrack.t failure: #2 eats 100% of the CPU until I kill it: it doesn't behave that way in svn-head. I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say what other tests may have changed; the script I had running the comparison got stuck at backtrack.t and never finished. -- Andy Dougherty [EMAIL PROTECTED]
$value.confess()
While trying to track down a type error in a Pugs program today, I thought of what could be a handy debugging feature. I would like Perl 6 values to capture the call stack when they're created and store them into a property called confess (Autrijus's name). $value.confess would then return an array of Caller objects, which could be inspected to determine where a value came from. It might even be wise to have it capture the call stack each time the value is mutated. Since this would likely be expensive, I suspect it should be optional and turned off by default; however, this would probably be a global setting, not a lexical one. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
[svn ci] (r8717) Win32 Dynclasses
Hi, Dynclasses now work on Win32 when building Parrot with the MS Visual Studio compiler. That means that all t\dynclass\*.t passes. :-) I've also (after ci'ing a fix to config/gen/makefiles/tcl.in) managed to build Partcl on Win32 and run the tests. Here's what I'm seeing. Failed Test Status Wstat Total Fail Failed List of Failed -- t\cmd_expr.t 433 6.98% 41-43 t\cmd_linsert.t51 20.00% 2 t\cmd_proc.t 41 25.00% 4 t\cmd_source.t 21 50.00% 1 t\cmd_string.t374 10.81% 16, 33-35 t\cmd_time.t 11 100.00% 1 t\tcl_backslash.t 162 12.50% 12, 14 t\tcl_command_subst.t 101 10.00% 10 t\tcl_misc.t 121 8.33% 12 t\tcl_pir_compiler.t 31 33.33% 3 Failed 10/39 test scripts, 74.36% okay. 16/266 subtests failed, 93.98% okay. Any problems, let me know. Take care, Jonathan
Some thoughts on PIL
On Thu, Jul 28, 2005 at 06:31:34PM +0200, TSa (Thomas Sandla�) wrote: BTW, where can I read about PIL, other then in Parrot/Pugs svn? (Cc'ing in P6C.) The current type-indexed design of PIL is going away, because it is closely tied to the PIR/Parrot model, to the disadvantage of our Perl5/JavaScript backends. Also it does not capture any notion of rank-n types, and relies on the VM for a semantics for container types, which is prone to trouble. In the past few weeks I've been reading up on F:, Fw, CoC, vObj, as well as intersectional and split types for object calculi, in the hope of revamping PIL -- Pugs's new internal language -- that can alleviate backend author's pain and improve type-directed translation. Perl 6's uniqueness is that it relies on runtime-rebindable package objects for its type system, but at the same time carries the vague promise of partial static analysis for the part of the closed world via toplevel `use optimize`. The semantic of type annotations remains unresolved; I reflected this in the recent `the meaning of returns` thread. It would be far easier if we concede that Perl 6 is essentially untyped, and all type annotations are merely storage hints, that will still always require runtime coercion. This coincide with Parrot's current idea of never checking subroutine parameter's PMC types (except for MMD), and always resolve method calls as late as possible, exactly as Perl 5 did. Under that view, the only use of type annotation at compile time is speeding up property/method lookup for typed variables, so they can be looked up by number instead of names, provided new fields always go toward the end. Other than that, they can only serve as runtime assertions, leading to the curious effect that well-typed programs can run slower than the unannotated counterpart. However, my intuition is that a soft-typed system, with clearly defined dynamic parts translated to runtime coerce and dependent types, that can work exactly as Perl 5 did at first, but provide sensible inferencing and compile-time diagnostics as you gradually provide annotations, is really the way forward. Under soft typing, Parrot's role would become a fast implementation for the object space and primitives, but the soundness of large-scale programs and the standard library will be provided by the compiler, not the runtime. This plays well with Pugs's -- not neccessarily Perl 6's -- goal of keeping the language retargettable. This may not be popular view, as evidented by the relative lack of research and real-world interest to bridge the gap of static/dynamic languages, so it would take a while to come up with a suitable formal treatment. I'm currently trying to express this idea under the F: framework for the new PIL, and I'll keep p6c posted as it goes forward, and cotinue to reflect design issues to p6l. Thanks, /Autrijus/ pgpzcvHiHzmiw.pgp Description: PGP signature
Re: [ANNOUNCE] Test::Simple/More/Builder 0.60_01
Michael G Schwern wrote: * Added the long delayed BAIL_OUT to Test::More. So, the way I would go about using this would be something like this? my $obj=new SomeObj(); isa($obj, SomeObj) or BAIL_OUT(It wasn't my object :(); --Peter
Re: Elimination of Item|Pair and Any|Junction
On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote: Or maybe Any really does mean Object and we're just viewing our hierarchy too strictly if we make every relationship isa. That's one thing that neither this formulation nor Thomas's are making very clear--which type relations are really subclassing, which are role composition, and which are subtype constraints. FWIW, I've been reading up on Scala's formulation of trait/class/delegation hierarchy, and I feel a bit like flipping through a puzzle book to look at the hints, if not answers. :-) http://scala.epfl.ch/docu/files/api/index.html And I'm still not entirely sure I believe the not-yet-bound-ness of Pairs is all that different from the not-yet-bound-ness of Junctions to the extent that a different type level is warranted. Junctive autothreading are outside bindings -- they can be viewed as a two-phase exception handling from parameter type mismatches that fires away more function applications. Pairs on the other hand are bound normally; they just have a preferred zone unless overriden by the parameter signature; this resolution is strictly within the same one-step binding. I think there may be more types to come that has its preferred binding semantic, than outside-the-box devices like Junctions. I guess I still think there ought to be a way of marking Pairs on the call end as to whether they're intended for named args or not, without warping the whole top-level type system to that end. I can see marking things explicitly for named bindings: foo(:literalpair); foo(*%nameds); foo(*$pair); foo([EMAIL PROTECTED]); That will mean that foo($pair) will always be positional. Thanks, /Autrijus/ pgpwsP0LMxs4l.pgp Description: PGP signature
Re: Elimination of Item|Pair and Any|Junction
On Fri, Jul 29, 2005 at 05:59:43AM +0800, Autrijus Tang wrote:
I can see marking things explicitly for named bindings:
foo(:literalpair);
foo(*%nameds);
foo(*$pair);
foo([EMAIL PROTECTED]);
Er, sorry, the last one should be
foo(*%{ hash @list_of_pairs });
Thanks,
/Autrijus/
pgpq4Tu2ITfnw.pgp
Description: PGP signature
Re: Garbage Collector API
On Thu, 28 Jul 2005 16:22:19 +0300, Yuval Kogman [EMAIL PROTECTED] wrote:
[...]
On Thu, Jul 28, 2005 at 01:08:13 -, David Formosa (aka ? the Platypus) =
wrote:
[...]
my Bigobjet $big is GC::timely =3D Bigobect; # Request timely
# destruction of $big. Usefull for filehandels and network
# resources.
I like this approach the most: it let's users specify what they
need, not how they need it done.
I can see advantages to both approches. All GC systems have a hit
when they run, in some situations it would be nice to shift the hit to
times when it doesn't mattor that much. For example a GUI app may
delay the GC till when the user has been idle for a while.
Every GC has slightly different semantics. If we have a generational
GC that has delays, or a reference counting scheme that does
occasional reachability tests, it doesn't really matter.
Yes thats why I was saying hints. Not all hints are going to be
that meaningfull.
What we want is features:
some object needs to die appropriately, because i'm using
DESTROY to manage resources, or trigger an action
Which I'm calling the timely trait.
And we can also open the door to optimizations:
some object is cheap to store, you can collect it later than
usual
Sort of an anty timely? GC::tardy
everything under this object belongs to it, and only to it (that
is, you can cleanup the whole tree when cleaning this up)
GC::tombstone;
[...]
We do need this applying to:
roles and classes:
class Moose is GC::timely { ... }
Yep (and yes to all your other suggestions).
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
[perl #31649] [TODO] Win32 - Automatically Export Symbols
This is the Better Way to do part of what my recent dynclasses ci did. But, I think that some input is needed into what should be in the Parrot API for extensions and what should not. Also, it'd be changes that touch a lot of files and I'm not sure that's wise while we've got leo's branch - someone may know better than I here. If someone could provide input into what should be in the Parrot API then I'll happily deal with this task and fix up dynclass building to do things this way at the appropriate time. Thanks, Jonathan
Re: [ANNOUNCE] Test::Simple/More/Builder 0.60_01
On Thu, Jul 28, 2005 at 05:48:58PM -0500, Peter wrote: So, the way I would go about using this would be something like this? my $obj=new SomeObj(); isa($obj, SomeObj) or BAIL_OUT(It wasn't my object :(); isa_ok() but you get the idea. You call it when you think the code is so busted that its not worth continuing any testing, that means halting the current test and not running any further test files. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: lazy list syntax?
2005/7/28, Yuval Kogman [EMAIL PROTECTED]:
I think unary = is what you want:
my @a = $span.lazy;
for [EMAIL PROTECTED] - $item {
...
}
Ofcourse, my @a = $span.lazy will have to be fixed, but what you
tried should be working.
Is for = only for filehandles? I tried:
pugs say for =1
*** cannot cast from VInt 1 to Handle (VHandle)
- Flavio S. Glock
Re: lazy list syntax?
On Thu, Jul 28, 2005 at 19:58:16 -0300, Flavio S. Glock wrote:
2005/7/28, Yuval Kogman [EMAIL PROTECTED]:
I think unary = is what you want:
my @a = $span.lazy;
for [EMAIL PROTECTED] - $item {
...
}
Ofcourse, my @a = $span.lazy will have to be fixed, but what you
tried should be working.
Is for = only for filehandles? I tried:
pugs say for =1
*** cannot cast from VInt 1 to Handle (VHandle)
Hmmm... That's odd. I may be out of date, but I thought that unary =
is the complement of unary **.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah
pgpHrUYgvCrPS.pgp
Description: PGP signature
Test::Builder::STDOUT ?
I've been pondering custom test runners recently and have hit the
familiar problem of Test::Harness::Straps not capturing STDERR, so
missing the diagnostics that Test::Builder outputs.
A moderately evil solution occurred, and I now have a
Test::Builder::STDOUT on my box that just does:
use Test::Builder;
*Test::Builder::failure_output = \Test::Builder::output;
redirecting all T::B diagnostic messages to STDOUT. Now I can add:
$ENV{ HARNESS_PERL_SWITCHES } = '-MTest::Builder::STDOUT';
to my test runner and all my diagnostics end up in the results hash
that Test::Harness::Straps::analyze_file returns.
Obviously won't work if your test scripts aren't written using T::B,
but that's not a problem I hit very often.
Greasy hack? Obviously - but it seems to do the job. I'm tempted to
throw it at CPAN :-)
Is there a better way I'm missing?
Cheers,
Adrian
Re: Test::Builder::STDOUT ?
On Fri, 2005-07-29 at 02:49 +0100, Adrian Howard wrote: I've been pondering custom test runners recently and have hit the familiar problem of Test::Harness::Straps not capturing STDERR, so missing the diagnostics that Test::Builder outputs. Is there a better way I'm missing? If you can use your own test harness, use Test::Harness::Straps::analyze() or Test::Harness::Straps::analyze_fh() to collect STDERR and STDOUT from the tested process. -- c
Re: Test::Builder::STDOUT ?
On Fri, Jul 29, 2005 at 02:49:48AM +0100, Adrian Howard wrote:
Obviously won't work if your test scripts aren't written using T::B,
but that's not a problem I hit very often.
Greasy hack? Obviously - but it seems to do the job. I'm tempted to
throw it at CPAN :-)
Is there a better way I'm missing?
BEGIN { *STDERR = *STDOUT }
That'll handle anything, Test::Builder or not.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
