Re: [perl #53542] [PATCH] dynpmc.pl ignores compilation failures
On Tuesday 29 April 2008 20:28:25 Andy Dougherty wrote:
When compilation of a file in src/dynpmc/ fails, the build continues
anyway -- there was an existing die command, but it could never actually
be triggered. This patch actually looks at the return value and dies if
the compilation fails. (Otherwise, the error gets buried and is easy to
miss.)
--- parrot-svn/config/gen/makefiles/dynpmc_pl.in Mon Apr 28 12:31:26 2008
+++ parrot-andy/config/gen/makefiles/dynpmc_pl.in Tue Apr 29 11:28:15 2008
@@ -270,12 +270,10 @@
$dest_stem ||= $src_stem;
if (needs_build($dest_stem$O, $src_stem.c)) {
-return run(compile_cmd($dest_stem$O, $src_stem.c))
+run(compile_cmd($dest_stem$O, $src_stem.c))
or die compile $src_stem.c failed ($?)\n;
}
-else {
-return 1;
-}
+return 1;
}
sub partial_link {
Thanks, applied as r27247.
-- c
Re: [perl #53472] [PATCH] jit/(ppc|arm)/exec_dep.*
On Monday 28 April 2008 14:51:29 [EMAIL PROTECTED] wrote: The attached patch fixes a breakage in the build on linux-ppc with jit. Without it, make aborts while trying to link libparrot.so with cc -o miniparrot src/main.o \ -Wl,-rpath=/home/victor/src/perl6/parrot/blib/lib -L/home/victor/src/perl6/parrot/blib/lib -lparrot -ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline -lglut -lGLU -lGL -lcrypto -L/usr/local/lib -Wl,-E src/null_config.o /home/victor/src/perl6/parrot/blib/lib/libparrot.so: undefined reference to `offset_fixup' A change in the declaration of offset_fixup from void to static void appears to have caused this. It's been a long time since I've done any C programming (decades in fact) so go easy. I can include the myconfig if requested. This fixes the build for me, but ymmv. I've included a mysimilar change for ARM on the theory that the declarations are the same there and may well be similarly broken. I'm not subscribed to the list, so replies should go to my email rather than the list. This looks correct to me (and I think I'm the one who broke it). Thanks, applied as r27248. -- c
Re: [perl #53496] Re: [bug] Build failure with G++
On Monday 28 April 2008 23:52:44 Senaka Fernando wrote: Attaching patch No. 2 for C++ Build Issue. I still need to resolve this bigint.c issue. This is something caused by the GMP includes I suspect. This patch didn't apply cleanly as of r27247; is it still an issue for you? -- c
[perl #53548] [PATCH] fix for auto-generation of runtime/parrot/include/interpflags.pasm
# New Ticket Created by Chris Dolan # Please include the string: [perl #53548] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53548 The file runtime/parrot/include/interpflags.pasm is auto-generated by config/gen/parrot_include.pm from include/parrot/interpreter.h. The .h parser didn't know how to handle or'd values like this: PARROT_THR_TYPE_2 = PARROT_IS_THREAD | PARROT_THR_COPY_INTERP, Thus, the generated file looked like: .macro_const PARROT_THR_TYPE_1 4096 .macro_const PARROT_THR_TYPE_2 4096 .macro_const PARROT_THR_TYPE_3 4096 With the attached patch, the generated file now (correctly) looks like this: .macro_const PARROT_THR_TYPE_1 4096 .macro_const PARROT_THR_TYPE_2 12288 .macro_const PARROT_THR_TYPE_3 28672 I did not check whether the parser change broke affected any other generated files. It would be a good idea to run the generator before and after applying this patch to see exactly what changes. There's a bit of code duplication in this patch, for example with the octal parsing. This could easily be factored out if desirable (by me or someone else). Chris P.S. I tested via the following command: perl -Ilib -Iconfig -MParrot::Configure -Mgen::parrot_include \ -e'gen::parrot_include-new-runstep(Parrot::Configure-new)' parrot_include.pm | 42 -- 1 files changed, 40 insertions(+), 2 deletions(-) parrot_include.pm.patch Description: Binary data
Re: [perl #52870] [PATCH] README_cygwin.pod update
On Sunday 13 April 2008 22:21:17 Reini Urban wrote: Attached patch removes fixed issues from the TODO. Thanks, applied as r27250. -- c
Re: treatment of isa and inheritance
HaloO, just to deepen your understanding of co- and contravariance you should digest http://www.pps.jussieu.fr/~gc/papers/toplas95.pdf The important point to get from it is that dispatch-relevant parameters are also covariant. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: treatment of isa and inheritance
HaloO John, interesting to note that you are now nailing down things that I'm advocating for quite a while. Are you sure that Perlkind is following? E.g. $Larry hasn't written 'isa' into S12 yet. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #53552] [Patch] for file config/gen/makefiles/root.in
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #53552] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53552 Hello, the command rpm -ba parrot.spec doesn't work under linux (Fedora, SuSE). So this patch is responsible that a generated Makefile rather holds the command rpmbuild -ba parrot.spec. Gerd Pokorra --- config/gen/makefiles/root.in 2008-04-15 19:19:39.0 +0200 +++ config/gen/makefiles/root.in.new 2008-04-30 10:32:54.0 +0200 @@ -2129,7 +2129,7 @@ rpms : release sudo cp parrot-$(VERSION).tar.gz /usr/src/*/SOURCES sudo cp parrot.spec /usr/src/*/SPECS - cd /usr/src/*/SPECS @make_and@ sudo rpm -ba parrot.spec + cd /usr/src/*/SPECS @make_and@ sudo rpmbuild -ba parrot.spec win32-inno-installer : world installable $(PERL) tools/dev/mk_inno.pl --version=$(VERSION) --prefix=$(PREFIX) [EMAIL PROTECTED]@
Re: treatment of isa and inheritance
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: HaloO, just to deepen your understanding of co- and contravariance you should digest http://www.pps.jussieu.fr/~gc/papers/toplas95.pdf The important point to get from it is that dispatch-relevant parameters are also covariant. Regards, TSa. Thanks for the link. I did mention that the invocant was an exception, since it is already known to be the correct type.
Re: treatment of isa and inheritance
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: HaloO John, interesting to note that you are now nailing down things that I'm advocating for quite a while. Are you sure that Perlkind is following? E.g. $Larry hasn't written 'isa' into S12 yet. Regards, TSa. I am listening. I'm synthesizing and documenting. I'm also disappointed with the lack of feedback from Larry, considering the amount of effort and time I'm putting into it. But I'm sure he'll squawk if I say something really off, rather than flesh out the existing skeleton. isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. Nobody's objected to it. In this group, I'm preaching to the choir anyway. Everyone knows higher-order typing is the idea, and I'm just trying to work out the ramifications and details that are in-tune with the orthodox documentation and discussions here. --John
Re: treatment of isa and inheritance
HaloO, John M. Dlugosz wrote: isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. Nobody's objected to it. In this group, I'm preaching to the choir anyway. Everyone knows higher-order typing is the idea, and I'm just trying to work out the ramifications and details that are in-tune with the orthodox documentation and discussions here. Hmm, I always had the impression of strong headwind. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Pragma for type matching alternative implementations
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
Very interesting reading... :)
It actually made me think that it would be possible to implement it as a
pragma.
class A { has $.a };
class B { has $.b };
sub foo { A $a } { ... } [sic, should be () around parameters]
{
foo(B.new()); # FAIL
use typematch 'like';
foo(B.new()); # OK
use typematch 'does';
foo(B.new()); # FAIL
}
The problem with doing F-bounds instead of subtype as a normal match is
that it does behave differently. It is =not= substitutable for the
original type. Unless you are also going to type the variable using a
generic type parameter, the code just won't work with it properly.
It is up to foo in your example to be written to support higher-order
polymorphism on $a. It is not up to the caller to say take this
anyway, unless it is more like the int/float/double case in which case
you generate a wrapper to pass. I think there should be syntax to do
that explicitly: I've been using the keyword 'shoehorn' for a
not-quite-isa cast that adds error checking. My current expositions are
to show how casting is never needed, and I carefully avoided even
showing one in the example code.
--John
Re: [perl #53496] Re: [bug] Build failure with G++
On Tue, 29 Apr 2008 23:05:04 -0700 chromatic [EMAIL PROTECTED] wrote: On Monday 28 April 2008 23:52:44 Senaka Fernando wrote: Attaching patch No. 2 for C++ Build Issue. I still need to resolve this bigint.c issue. This is something caused by the GMP includes I suspect. This patch didn't apply cleanly as of r27247; is it still an issue for you? This is the issue we fixed in #53112. It's weird - the timestamp on Senaka's email (according to RT) is April 14, Senaka and I are wondering if the email got stuck in a queue somewhere for 2 weeks. I've verified with him that the issue is fixed, and merged the ticket with #53112. Mark
Re: weird perl6/plumhead problem
On Tue, 29 Apr 2008, Patrick R. Michaud wrote: On Tue, Apr 29, 2008 at 12:34:47PM -0400, Jeff Horwitz wrote: mod_parrot can load multiple HLL compilers in the same interpreter, and on my server i'm using both perl6 and plumhead. this works fine if i load perl6 before plumhead. however, if i load perl6 *after* plumhead, i get a nasty error: push_pmc() not implemented in class 'Sub' ... My complete off-the-wall guess is that perl6.pbc has a :multi sub that happens to have the same name as a non-multi sub in plumhead. Or something like that. So, when perl6 is loaded first, the :multi sub in perl6 gets replaced by the non-multi sub in plumhead. When plumhead is loaded first, Parrot tries to push the :multi sub in perl6 onto the (non-:multi) sub in plumhead and throws the exception. i think you're right -- i dove into the backtrace and found that the sub in question was 'infix:+', which is multi in perl6 and non-multi in plumhead. assuming this is the problem, it seems to me that the .HLL sandbox that coke mentioned would solve this. correct? -jeff
Re: [perl #53496] Re: [bug] Build failure with G++
-- Will Coke Coleda On Apr 30, 2008, at 8:53 AM, Mark Glines [EMAIL PROTECTED] wrote: On Tue, 29 Apr 2008 23:05:04 -0700 chromatic [EMAIL PROTECTED] wrote: On Monday 28 April 2008 23:52:44 Senaka Fernando wrote: Attaching patch No. 2 for C++ Build Issue. I still need to resolve this bigint.c issue. This is something caused by the GMP includes I suspect. This patch didn't apply cleanly as of r27247; is it still an issue for you? This is the issue we fixed in #53112. It's weird - the timestamp on Senaka's email (according to RT) is April 14, Senaka and I are wondering if the email got stuck in a queue somewhere for 2 weeks. Happened to some of my tickets as well. The latest log.perl.org entry coincided with the arrival 2 weeks later. I've verified with him that the issue is fixed, and merged the ticket with #53112. Mark
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO, Daniel Ruoso wrote: [ I'm using this message to reply, because I didn't receive your reply... I'm taking it from the list history... There really seems to be something wrong with this list... ] I see all your messages arrive twice. This is not specced apparently to leave room for decision in the implementation. But there's an important question to be answered before that... what is the type returned by WHICH? Isn't that up to the implementation as well? E.g. on a 32bit platform use an unsigned 32bit integer. The only things that should not happen is that you let it leak onto the value level or that WHICHes of differently typed objects are compared. With leaking to the value level I mean allowing $x.WHICH == 42 even if it is known that WHICH is implemented with a number. But it's important to keep in mind that eqv behaviour might also be overriden by the object, that might give a canonical representation that matches the other object. Ups, no object can override eqv or any other binary method. These live outside of HOW space. You can insert your dispatch targets but that's about it. On the other hand, a 'realises' trait could change the object in order that it would still match with both 'eqv' and '===', while still '~~' to an additional type. This would be done simply by creating an anonymous class that isa the original class while overriding .^does, WHICH and eqv to shadow to the original class, and then re-blessing the object to this anonymous class. I don't understand your motivation, but I think it is the obsession with object identity. You say that the object changes class, i.e. its HOW or WHAT changes while perhaps keeping its WHICH. But eqv, === and ~~ are defined outside of the class or object system. There is an inheritance order on HOW space and a subtyping order on WHAT space. Class based dispatch goes along the former, type based dispatch along the latter. The object that changes class should not be eqv or === to itself before the transition or nominal typing becomes absurd. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: treatment of isa and inheritance
--- John M. Dlugosz [EMAIL PROTECTED] wrote: isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. Nobody's objected to it. In this group, I'm preaching to the choir anyway. So, isn't isa and the £ merely things which can be added by programmers by changing the grammar? That was one of the design goals of the language. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: treatment of isa and inheritance
HaloO, Ovid wrote: So, isn't isa and the £ merely things which can be added by programmers by changing the grammar? That was one of the design goals of the language. With a changeable grammar this applies to everything except the changeability itself. But the type system is part of the language core. As such 'isa' and 'like' or assignment and binding semantics need a definition. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Polymorphism and Representations (Was: Re: First look: Advanced Polymorphism whitepaper)
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:= (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
I guess I also forgot the is rw to get a binding to the caller's
container not the local one of the sub. Otherwise you could write
into the caller's container without rw in the sig.
The issue I want to address is how easy it is to implement
immutable semantics. The ref copying is sort of an annoyance
there.
class A
{
has $.a = 0;
submethod BUILD ($.a) {}
method inc ($self is rw:) # get at the container of
{ # of the caller
$self = self.^new(self.a + 1);
# return self.^new(self.a + 1) without the rw
# sadly doesn't work for $x.inc syntax
}
}
my A $a .= new(7);
my A $b = $a;
$a === $b; # true
$a eqv $b; # true
$a.inc; # shall behave like ++ for Int
$a === $b; # false
$a eqv $b; # false
The spec also says that one has to use .=method to call an in-place
mutator. That is $x.inc in Daniel's example should actually mean
$x = $x.inc along the lines that $x++ also means $x = $x + 1.
Finally combine that with the wish to allow literals of class A. Let's
assume the grammar is patched to parse integer literals as As. Then
with the above 7.inc gives an error because 7 is not mutable. So as
I outlined before I want to care for the callers constraint. Perl 6
lacks a syntax for that.
My readings have been that = just copies the ref. Unless it's a value
type or immutable which just means that it doesn't matter. I'll have
to read up on that some more soon.
Keep us informed, please.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Pragma for type matching alternative implementations (Was: Re: treatment of isa and inheritance)
Ter, 2008-04-29 às 21:03 -0500, John M. Dlugosz escreveu:
In response to questions on my whitepaper, I made this companion
to bring people up to speed on the issue.
http://www.dlugosz.com/Perl6/web/isa-inheritance.html
Very interesting reading... :)
It actually made me think that it would be possible to implement it as a
pragma.
class A { has $.a };
class B { has $.b };
sub foo { A $a } { ... }
{
foo(B.new()); # FAIL
use typematch 'like';
foo(B.new()); # OK
use typematch 'does';
foo(B.new()); # FAIL
}
This could be achieved simply by scope-redefining
infix:~~(Object,Object) to use another implementation.
(Note that I'm trying at all costs to avoid adding that as a signature
trait, because that would complicate the dispatching ;)
daniel
Re: treatment of isa and inheritance
Qua, 2008-04-30 às 15:55 +0200, TSa escreveu: But the type system is part of the language core. As such 'isa' and 'like' or assignment and binding semantics need a definition. Actually, this is one of the hardest parts of implementing Perl 6, because even 'isa', 'like', assignment and binding are dependent on the representation of the given objects, so even such basic operations are polymorphic. This makes the bootstrap of the type system harder, but not impossible. What happens is that, as it is polymorphic, I can provide known low-level implementation of higher-level types that will interoperate transparently with them. By doing that I can bootstrap by special-casing the low-level implementations and getting out of the water that way. This also allows some other interesting features, like the fact that I may have a constant identifier that interoperates with Str while I still can compare to of them simply by comparing their pointer addresses, or by providing a shadow object that points to the inner data structure of other object in order to expose the expected API. In fact, that is the exact point that makes it possible for Perl 6 to have a *fully* boostrapped type system. What defines native types in Perl 6 is not that they have a incompatible lowlevel structure (because they don't, unless optimized), but that they are the only types that the interpreter may expect to know how they look like. Everything else should be opaque to the interpreter (but eventually the optimizer may have a catalog to inspect the internals directly). Take a look at http://www.perlfoundation.org/perl6/index.cgi?smop_p6opaque_implementation and at http://www.perlfoundation.org/perl6/index.cgi?smop_oo_api To see how that's being implemented in SMOP. daniel
Re: First look: Advanced Polymorphism whitepaper
--- chromatic [EMAIL PROTECTED] wrote: $p1 must be like a Point, but it needn't actually be a Point. Both $p2 and the return value must be the same type of thing that $p1 is. That was always my goal for roles in the first place. I'll be a little sad if Perl 6 requires an explicit notation to behave correctly here -- that is, if the default check is for subtyping, not polymorphic equivalence. I had initially thought this, but think about the case where someone wants to rewrite something to be compliant to another interface. If I pass a CGI::Simple object to a method expecting a CGI object, there's an excellent chance that it will *just work*, even though there's no relation between the two. In this case, a role really doesn't work. Of course, the '£' might not work either since we're not specifying that we only need a subset of the behavior to work properly. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: treatment of isa and inheritance
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: HaloO, John M. Dlugosz wrote: isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. 'doesa'? I suppose, but I had not thought about it. The issues are the same: The final type made with composed roles does not have to follow subtyping rules with respect to treating the role as an interface abstract type. Nobody's objected to it. In this group, I'm preaching to the choir anyway. Everyone knows higher-order typing is the idea, and I'm just trying to work out the ramifications and details that are in-tune with the orthodox documentation and discussions here. Hmm, I always had the impression of strong headwind. How so?
Re: treatment of isa and inheritance
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote: So, isn't isa and the £ merely things which can be added by programmers by changing the grammar? That was one of the design goals of the language. The capability needs to exist as part of the overall type system, with primitive hooks provided in the metaobjects. The understanding of subtype and F-bounds both need to be built into the is this type OK? binding logic and the very implementation of binding. The syntax to access these features -- to mark which type uses which matching rules -- is far more arbitrary and cosmetic. The isa as a synonym for is would be a no-brainer macro. But marking the metaobject with the intention and updating all the calls to the metaobject that build the class based on the items in the class's main block, to do the subtype covariance/contravariance checking, is more than just updating the grammar. I also have one other trick planned -- perhaps using isa can suppress virtual type redefinitions, if used with suitable modifiers. That way you can turn off the feature that is making your parameters covariant without you explicitly overriding them. --John
Re: Polymorphism and Representations
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Finally combine that with the wish to allow literals of class A. Let's assume the grammar is patched to parse integer literals as As. Then with the above 7.inc gives an error because 7 is not mutable. So as I outlined before I want to care for the callers constraint. Perl 6 lacks a syntax for that. I'll digest that more later. For these issues, I have my thoughts stacked a few plates down and don't want to lose my productivity right now. But, I'm thinking along the lines of Pascal and C++. You can't pass a non-lvalue by reference, period. (5)++ is just plain wrong. The matching rules for MMD should be at least as good as C++ overloading, to have a version of the function that is for non-lvalues and one that is for lvalues. Also, Perl 6 synopses mentions both 'rw' and 'ref' separately. I think there will be a choice of copy/return or ref binding for 'rw', which allows for differing types; and bind directly with 'ref' which allows for custom container ties to work live rather than just get an update at the end. We need a clear summary of expectations; that is, what do we want to be able to accomplish. Then refactor that into a set of real features that span the target feature set. --John
Re: treatment of isa and inheritance
On Apr 30, 2008, at 8:43 AM, TSa wrote: John M. Dlugosz wrote: isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''.
Re: treatment of isa and inheritance
On Wed, Apr 30, 2008 at 07:29:58AM -0500, John M. Dlugosz wrote: I am listening. I'm synthesizing and documenting. I'm also disappointed with the lack of feedback from Larry, considering the amount of effort and time I'm putting into it. But I'm sure he'll squawk if I say something really off, rather than flesh out the existing skeleton. Well, I mentioned before that I have very little bandwidth at the moment, due to health and employment issues, plus needing to prepare for a number of upcoming talks. (Not to mention stealing time to hack on the STD grammar and longest-token matcher.) My only choice is to operate in the bear-of-very-little-brain mode to see if any of this will be remotely understandable to normal people. I can tell you my uncomfy spots, but I haven't the energy to defend them at the moment. First some nitpicky things. I don't like using ::?CLASS for something that is not a compile-time constant. The ? twigil is supposed to mean that, and that's why we don't use ::?SELF anymore, but self, because that can vary in meaning dynamically. So I'd rather have a keyword or a pseudo-package, if it's needed. Or a different twigil for generically instantiated items, if it comes into common use, and gets applied to a variety of names, neither of which is certain. But ::CLASS would be an improvement over ::?CLASS, if we reserve that pseudo-package. Are there other things that fall into the same twigilish category? Or can they all be found via ::CLASS? I don't like the indentation style that makes the closing quote look like part of the contents of a block. You can do whatever you like in your own papers, of course, but we've spent many years teaching people in the Perl community to outdent their final curly so that it means something, rather than hiding it on the end like it's an embarrassing non-pythonism. So you'll get better acceptance of any standards document if you follow that community standard. The £ seems rather gratuitous from a language design point of view. Every such symbol in a paper increases the number of people whose eyes glaze over when they try to read it. I understand it's a placeholder, but the current syntax can already express such a like constraint via: $dog where .like(Goat) We could also have syntactic relief for such a concept by making like work like where syntactically: $dog like Goat On a more fundamental level, I wonder what the social ramifications are. First, to what extent is this something that will interfere with people who don't want to learn higher-order typing in order to get their job done, but will be forced to because one of their cohorts is using it, or the boss mandates it? And will Perl get a Haskellian only-a-genius-can-use-it reputation because of that? Second, is anybody actually going to implement it? We're pretty short of volunteers as it is, and I don't think I'm smart enough to do it, and I'm very, very slow to put anything into Perl that I don't know how to implement. Basically, I'm not a types person, historically speaking, so I'm naturally a bit skeptical. But over the last few years I've seen some of both the power and peril of strictly-typed FP. I'm interested in making sure Perl 6 is close enough to supporting any paradigm that it can be warped into full support of that paradigm in any lexical scope, but I'm leary of any paradigm that starts sucking in all the other lexical scopes into its sphere of influence whether they like it or not. Compile-time typing tends to have that effect, and I'm wondering how we avoid that problem. isa as a synonym for is that turns on warnings is documented at the end of my paper under Concepts discussed in this paper that are not on the Synopses. From a language design point of view, having both is and isa is a dreadfully powerful stink. Either something need to be unified, or something needs to be better distinguished. Nobody's objected to it. In this group, I'm preaching to the choir anyway. Everyone knows higher-order typing is the idea, and I'm just trying to work out the ramifications and details that are in-tune with the orthodox documentation and discussions here. That's fine, but please don't mistake the general silence for anything other than people's eyes glazing over. If a fancy concept can't be made easily understandable to the general public (or can't at least be hidden from the general public beneath some cargo-cultable syntax), it's not going into baseline Perl 6. I can be pretty clever at times, but right now I'm standing up for Joe Blow, who doesn't give a rip about orthodoxy. What's in it for him? All that being said, I do like the fact that this whole effort is exploring semantic niches that need to be fleshed out. I wish I had time to think through the Perlish answers to some of these good questions. I hope other people will continue to participate in thrashing some of these things out. Larry
Re: [perl #46629] [TODO] [C] [PATCH] Implement multiplication of integers with complex numbers
On Mon, Oct 22, 2007 at 2:24 PM, via RT Paul Cochrane
[EMAIL PROTECTED] wrote:
TODO mulInteger, Complex
The attached patch is a simple implementation using
mulComplex,Integer and adds the operation in the multiply test in
complex.t (don't know if it's the correct place).
--
Salu2
Index: src/pmc/integer.pmc
===
--- src/pmc/integer.pmc (revisión: 27253)
+++ src/pmc/integer.pmc (copia de trabajo)
@@ -20,6 +20,7 @@
*/
#include parrot/parrot.h
+#include pmc_complex.h
/* RT#46619 create MMD headers to in Pmc2c.pm */
extern INTVAL Parrot_BigInt_is_equal_BigInt(PARROT_INTERP, PMC*, PMC*);
@@ -596,8 +597,8 @@
return overflow(INTERP, SELF, b, dest, MMD_MULTIPLY);
}
MMD_Complex: {
-real_exception(INTERP, NULL, E_NotImplementedError,
-RT#46629 mulInteger, Complex);
+ return Parrot_Complex_multiply_int(INTERP, value,
+SELF.get_integer(), dest);
}
MMD_BigInt: {
return Parrot_BigInt_multiply_int(INTERP, value,
Index: t/pmc/complex.t
===
--- t/pmc/complex.t (revisión: 27253)
+++ t/pmc/complex.t (copia de trabajo)
@@ -320,6 +320,11 @@
mul P1, P0, P3
print P1
print \n
+
+mul P1, P3, P0
+print P1
+print \n
+
end
CODE
-5+12i
@@ -331,6 +336,7 @@
2-2i
1-1i
10+10i
+10+10i
OUTPUT
pasm_output_is( 'CODE', 'OUTPUT', divide );
Re: First look: Advanced Polymorphism whitepaper
Qua, 2008-04-30 às 08:56 -0700, Ovid escreveu: I had initially thought this, but think about the case where someone wants to rewrite something to be compliant to another interface. If I pass a CGI::Simple object to a method expecting a CGI object, there's an excellent chance that it will *just work*, even though there's no relation between the two. In this case, a role really doesn't work. This makes me think that 'realises' has a considerably more common usage than I thought... Every time you implement something like CGI::Simple, you would like to say 'CGI::Simple realises CGI'. Of course that, in an ideal OO world, CGI would be an abstract role that both the default CGI implementation and CGI::Simple would 'do'. But that seems to javaish to me (read that as something I hate;), and having how to 'lie' about who you are seems more like a Perl thing to do... daniel
Re: treatment of isa and inheritance
Brandon S. Allbery KF8NH wrote: TSa wrote: I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''. Agreed. I'm definitely in the category of people who find the difference between is and isa to be, as Larry put it, eye-glazing. I can follow it, but that's only because I've been getting a crash course in type theory. Brandon's alternative has the potential to be less confusing given the right choice of adverb, and has the added bonus that the same adverb could apply equally well to both 'is' and 'does'. On a side note, I'd like to make a request of the Perl 6 community with regard to coding style: could we please have adverbal names that are, well, adverbs? is :strict Dog brings to my mind the English Fido is a strict dog, rather than Fido is strictly a dog. Not only is is :strictly Dog more legible, but it leaves room for the possible future inclusion of adjective-based syntax such as big Dog (which might mean the same thing as Dog but is big or Dog where .size Average). To misquote Einstein, things should be as simple as is reasonable, but not simpler. -- Jonathan Dataweaver Lang
Re: treatment of isa and inheritance
On Wed, Apr 30, 2008 at 9:14 PM, Jon Lang [EMAIL PROTECTED] wrote: Brandon S. Allbery KF8NH wrote: TSa wrote: I totally agree! Using 'isa' pulls in the type checker. Do we have the same option for 'does' e.g. 'doesa'? Or is type checking always implied in role composition? Note that the class can override a role's methods at will. It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''. Agreed. I'm definitely in the category of people who find the difference between is and isa to be, as Larry put it, eye-glazing. I can follow it, but that's only because I've been getting a crash course in type theory. +1 Brandon's alternative has the potential to be less confusing given the right choice of adverb, and has the added bonus that the same adverb could apply equally well to both 'is' and 'does'. On a side note, I'd like to make a request of the Perl 6 community with regard to coding style: could we please have adverbal names that are, well, adverbs? is :strict Dog brings to my mind the English Fido is a strict dog, rather than Fido is strictly a dog. Not only is is :strictly Dog more legible, but it leaves room for the +1 possible future inclusion of adjective-based syntax such as big Dog (which might mean the same thing as Dog but is big or Dog where .size Average). To misquote Einstein, things should be as simple as is reasonable, but not simpler. and can I add another quote, from someone who's last name is appropriate ;) 'Simplicity does not precede complexity, but follows it.' (Alan Perlis) cheers, Jim Fuller
Re: treatment of isa and inheritance
On Apr 30, 2008, at 15:14 , Jon Lang wrote: Brandon S. Allbery KF8NH wrote: It occurs to me that this shouldn't be new keywords, but adverbs, i.e. ``is :strict Dog''. On a side note, I'd like to make a request of the Perl 6 community with regard to coding style: could we please have adverbal names that are, well, adverbs? is :strict Dog brings to my mind the English -ly suffixes everywhere conflicts with Huffman coding, which per @Larry is a primary design concern. Consider the leading colon to be the Perl6 equivalent. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: treatment of isa and inheritance
On Apr 30, 2008, at 15:14 , Jon Lang wrote: only is is :strictly Dog more legible, but it leaves room for the possible future inclusion of adjective-based syntax such as big Dog It occurs to me that we already have this: we call them types. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: treatment of isa and inheritance
Larry Wall larry-at-wall.org |Perl 6| wrote: On a more fundamental level, I wonder what the social ramifications are. First, to what extent is this something that will interfere with people who don't want to learn higher-order typing in order to get their job done, but will be forced to because one of their cohorts is using it, or the boss mandates it? And will Perl get a Haskellian only-a-genius-can-use-it reputation because of that? Second, is anybody actually going to implement it? We're pretty short of volunteers as it is, and I don't think I'm smart enough to do it, and I'm very, very slow to put anything into Perl that I don't know how to implement. I've posted on PerlMonks to get a broader opinion from those besides who directly told me what was needed/semiplanned already. My own interest is in incrementally adding types to maintain existing code that grows, so I'm keeping that clearly in mind. That's also why I proposed isa, to let people stay in their comfort zone and know they are checked against accidentally needing the fancy stuff to proceed. Maybe it will be as exotic as those who write the DB ties. But it's under the hood and there for others to use the benefits from. In other discussions (with Prof Simmons) I've looked at how run-time checking blends into optional strong typing, as part of this design. I also want to document the algorithm in some detail, to make sure that different implementations conform. So implementors will be told exactly how to do it. It's really no worse than generics already planned in the synopses, really! I can get very close to F-bounds constraints just by using existing features and syntactic sugar. --John
Re: First look: Advanced Polymorphism whitepaper
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: Qua, 2008-04-30 às 08:56 -0700, Ovid escreveu: I had initially thought this, but think about the case where someone wants to rewrite something to be compliant to another interface. If I pass a CGI::Simple object to a method expecting a CGI object, there's an excellent chance that it will *just work*, even though there's no relation between the two. In this case, a role really doesn't work. This makes me think that 'realises' has a considerably more common usage than I thought... Every time you implement something like CGI::Simple, you would like to say 'CGI::Simple realises CGI'. Of course that, in an ideal OO world, CGI would be an abstract role that both the default CGI implementation and CGI::Simple would 'do'. But that seems to javaish to me (read that as something I hate;), and having how to 'lie' about who you are seems more like a Perl thing to do... daniel Especially when the fit does not have to be perfect. Part of my (unfinished overall) design is to have a way to say close enough. It will line up the stuff that fits, and put runtime checks around the stuff that doesn't. I use the keyword 'shoehorn' for this forced semi-casting g. So you can shoehorn a CGI::Simple into a CGI to call code that was written to expect strict subtyping. It will work just like non-typed message dispatch, only let you use optimized dispatch tables and document the intent and have it tell you (if you care) where the problem areas will be. --John
[perl #53592] [PATCH]: config/auto/pcre.pm: touch-ups and tests
# New Ticket Created by James Keenan
# Please include the string: [perl #53592]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53592
Hmm, yet another config step class that appeared without an RT ...
In any case, here are some touch-ups to the code and some tests which
closely follow those for other recently added configuration step
classes.
kid51
Index: MANIFEST
===
--- MANIFEST(revision 27261)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Wed Apr 30 20:45:06 2008 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Thu May 1 02:02:56 2008 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -3494,6 +3494,9 @@
t/steps/auto_opengl-03.t[]
t/steps/auto_ops-01.t []
t/steps/auto_pack-01.t []
+t/steps/auto_pcre-01.t []
+t/steps/auto_pcre-02.t []
+t/steps/auto_pcre-03.t []
t/steps/auto_perldoc-01.t []
t/steps/auto_perldoc-02.t []
t/steps/auto_pmc-01.t []
Index: t/steps/auto_pcre-02.t
===
--- t/steps/auto_pcre-02.t (revision 27261)
+++ t/steps/auto_pcre-02.t (working copy)
@@ -1,11 +1,11 @@
#! perl
# Copyright (C) 2007-2008, The Perl Foundation.
# $Id$
-# auto_pcre-01.t
+# auto_pcre-02.t
use strict;
use warnings;
-use Test::More tests = 13;
+use Test::More tests = 21;
use Carp;
use lib qw( lib );
use_ok('config::init::defaults');
@@ -16,7 +16,7 @@
my $args = process_options(
{
-argv = [ q{--without-pcre} ],
+argv = [ ],
mode = q{configure},
}
);
@@ -36,35 +36,108 @@
$step = $step_name-new();
ok( defined $step, $step_name constructor returned defined value );
isa_ok( $step, $step_name );
-ok( $step-description(), $step_name has description );
-ok( $step-runstep($conf), runstep() returned true value);
-is( $step-result(), 'no', Got expected result );
-is( $conf-data-get( 'has_pcre' ), 0,
-Got expected value for 'has_pre');
+# Mock values for OS and C-compiler
+my ($osname, $cc, $initial_value);
+$osname = 'mswin32';
+$cc = 'gcc';
+$initial_value = $conf-data-get( 'libs' );
+ok($step-_add_to_libs( {
+conf= $conf,
+osname = $osname,
+cc = $cc,
+win32_nongcc= 'pcre.lib',
+default = '-lpcre',
+} ),
+_add_to_libs() returned true value);
+like($conf-data-get( 'libs' ), qr/-lpcre/,
+'libs' modified as expected);
+# Restore value for next test.
+$conf-data-set( 'libs' = $initial_value );
+
+$osname = 'mswin32';
+$cc = 'cc';
+$initial_value = $conf-data-get( 'libs' );
+ok($step-_add_to_libs( {
+conf= $conf,
+osname = $osname,
+cc = $cc,
+win32_nongcc= 'pcre.lib',
+default = '-lpcre',
+} ),
+_add_to_libs() returned true value);
+like($conf-data-get( 'libs' ), qr/pcre\.lib/,
+'libs' modified as expected);
+# Restore value for next test.
+$conf-data-set( 'libs' = $initial_value );
+
+$osname = 'foobar';
+$cc = 'gcc';
+$initial_value = $conf-data-get( 'libs' );
+ok($step-_add_to_libs( {
+conf= $conf,
+osname = $osname,
+cc = $cc,
+win32_nongcc= 'pcre.lib',
+default = '-lpcre',
+} ),
+_add_to_libs() returned true value);
+like($conf-data-get( 'libs' ), qr/-lpcre/,
+'libs' modified as expected);
+# Restore value for next test.
+$conf-data-set( 'libs' = $initial_value );
+
+# Mock different outcomes of _evaluate_cc_run
+my ($test, $has_pcre);
+my $verbose = $conf-options-get('verbose');
+
+$test = q{pcre foobar};
+ok(! $step-_evaluate_cc_run($test, $verbose),
+Got expected setting for has_pcre);
+
+$test = q{pcre 4.1};
+ok($step-_evaluate_cc_run($test, $verbose),
+_evaluate_cc_run returned true value as expected);
+is($step-result(), q{yes, v4.1}, Got expected PCRE version);
+
+# Mock different outcomes of _recheck_settings()
+my ($libs, $ccflags, $linkflags);
+
+$libs = q{-lalpha};
+$ccflags = q{-Ibeta};
+$linkflags = q{-Lgamma};
+$verbose = undef;
+$step-_recheck_settings($conf, $libs, $ccflags, $linkflags, $verbose);
+like($conf-data-get('libs'), qr/$libs/,
+Got expected value for 'libs');
+like($conf-data-get('ccflags'), qr/$ccflags/,
+Got expected value for 'ccflags');
+like($conf-data-get('linkflags'), qr/$linkflags/,
+Got expected value for 'linkflags');
+
pass(Completed all tests in $0);
### DOCUMENTATION ###
=head1
Exceptions and Concurrency Questions
From the wiki at http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks : * Deprecate rethrow. The replacement seems to be that an exception handler declines to handle an exception. This is the default behavior; an exception handler explicitly notifies the scheduler that it has handled (or will handle) the exception by using the handled opcode. PDD 25 suggests that there are Task PMCs which represent or encapsulate these exceptions. Presumably the handled opcode will remove the exception Task from the scheduler and resume execution at the appropriate point. Presumably also the declining to handle an exception (the replacement for rethrow) will cause the scheduler to move to the next exception handler in its list? If so, how do we model this control flow? * Change 'real_exception' to use concurrency scheduler. Does this mean to change the opcode and its backing functions to create a Task PMC, an Exception PMC, or both? If so, where does control flow go with the scheduler works asynchronously? Or does the scheduler handle exceptions as they occur in real-time? A later task: * 'throw_exception' and 'rethrow_exception' change to something more like 'Parrot_cx_handle_tasks'. ... suggests that these functions may schedule the exception (if necessary) and then immediately run the scheduler in the current interpreter. * 'push_exception' changes to 'Parrot_cx_add_handler'. The latter function already exists. Merge or rename? Note that exception handling has to stop looking in interp-dynamic_env for this to work. * 'count_exception_handlers' changes to access the concurrency scheduler (a simple method call or keyed access). There's currently no way of filtering handlers in the scheduler by parentmost type; should there be one? More later, -- c
OK, ::?CLASS not virtual
Larry Wall larry-at-wall.org |Perl 6| wrote: I don't like using ::?CLASS for something that is not a compile-time constant. ... we don't use ::?SELF anymore, but self, because that can vary in meaning dynamically OK, for some meaning of constant. After all ::?LINE is different every time you call it. I see it as the compiler automatically defining it properly for each use, not so much what its return value had to be, that made it special. But to try and put your meaning more precisely (my specialty), I think it expands at compile time into a literal. That is, you don't want it to expand into another symbol that itself changes or is an accessor. Now you have the same problem with using ::?CLASS inside a role. Rather than saying well, we'll defer that, this time don't use it in a role. I propose the symbol CLASS as follows. It is inherited like BUILD and other all-cap things from Object. It is defined as a type alias. It is overridden in every class to refer to the current ::?CLASS at that time. The implementation can treat it as just another virtual type name that is inherited. It fits with other all-cap things -- stuff from Object that is sometimes customized for each class. It follows the general idea that non-global non-qualified type names are virtual. It is only reserved in context, so it won't get in the way of non-class code that dares to use an all-cap name. And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). --John
Re: OK, ::?CLASS not virtual
John M. Dlugosz wrote: And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). Can a role inherit from a class? If so, to which class does CLASS refer: the inherited one, or the one into which the role is composed? -- Jonathan Dataweaver Lang
Re: First look: Advanced Polymorphism whitepaper
On Wednesday 30 April 2008 08:56:24 Ovid wrote: That was always my goal for roles in the first place. I'll be a little sad if Perl 6 requires an explicit notation to behave correctly here -- that is, if the default check is for subtyping, not polymorphic equivalence. I had initially thought this, but think about the case where someone wants to rewrite something to be compliant to another interface. If I pass a CGI::Simple object to a method expecting a CGI object, there's an excellent chance that it will *just work*, even though there's no relation between the two. Sure; ad hoc polymorphism allows for cognates. Not all cognates are false cognates. (If no cognates were false, duck typing would work in a correctness sense. Sadly, both trees and dogs bark.) In this case, a role really doesn't work. I think that's a non sequitur. There's no allomorphism in your example. This is why roles-as-types is so important: type inferencers can't infer allomorphism because allomorphism relies on explicitly-marked semantic meanings. -- c
Re: First look: Advanced Polymorphism whitepaper
On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: First look: Advanced Polymorphism whitepaper
On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. In defense of chromatic's point, both people and syrup run. -- Jonathan Dataweaver Lang
Re: First look: Advanced Polymorphism whitepaper
On May 1, 2008, at 1:30 , Jon Lang wrote: On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. In defense of chromatic's point, both people and syrup run. But there *is* some commonality there, to the extent that both are motion. This is the kind of thing that spawned this discussion, in fact: if what matters is motion, there is no reason *not* to substitute one for the other. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: First look: Advanced Polymorphism whitepaper
On Thu, May 01, 2008 at 01:34:45AM -0400, Brandon S. Allbery KF8NH wrote: On May 1, 2008, at 1:30 , Jon Lang wrote: In defense of chromatic's point, both people and syrup run. But there *is* some commonality there, to the extent that both are motion. This is the kind of thing that spawned this discussion, in fact: if what matters is motion, there is no reason *not* to substitute one for the other. Er, ask Nasa their opinion of duck typing newtons and pounds. Hey, they're both units of thrust, so they both cause motion... Me, my nose runs and my feet smell. Quack. Larry
Re: First look: Advanced Polymorphism whitepaper
On May 1, 2008, at 1:46 , Larry Wall wrote: On Thu, May 01, 2008 at 01:34:45AM -0400, Brandon S. Allbery KF8NH wrote: On May 1, 2008, at 1:30 , Jon Lang wrote: In defense of chromatic's point, both people and syrup run. But there *is* some commonality there, to the extent that both are motion. This is the kind of thing that spawned this discussion, in fact: if what matters is motion, there is no reason *not* to substitute one for the other. Er, ask Nasa their opinion of duck typing newtons and pounds. Hey, they're both units of thrust, so they both cause motion... Well, yes; but what spawned this side discussion was the whole notion of mixing things that normally wouldn't. It *is* Perlish to let you do such things, after all. (Note that strong typing would disallow this, so NASA could still have their units check.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
