Re: [tutorial] pct tutorial language: Squaak implementation
If I may make a humble suggestion, it seems that using the English
spelling "squawk" would, besides matching the English name "parrot"
better, also avoid any confusion with Squeak, which is how I read this
subject at first. ("Smalltalk on Parrot?! Whoa!).
But maybe that's just me. :)
On 3/25/08, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Attached are the 4 most important files of my implementation of the
> PCT tutorial language, "Squaak".
>
> Ideally, these files would be accessible online through the tutorial
> (on parrotblog), but I don't know if that's possible.
>
>
> (I tried to send this earlier, having attached files separately;
> apparently that wasn't accepted maybe because it's executable code?,
> so now a zipped version)
>
> kjs
>
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: [tutorial] pct tutorial language: Squaak implementation
> "Mark" == Mark J Reed <[EMAIL PROTECTED]> writes:
Mark> ... confusion with Squeak, which is how I read this subject
Mark> at first. ("Smalltalk on Parrot?! Whoa!). But maybe
Mark> that's just me. :)
I read it that way too (and had the same reaction :-)
--
[T]he main reason Viaweb ended up being server-based was
that we didn't want to have to write Windows apps.
-- Paul Graham
Re: [tutorial] pct tutorial language: Squaak implementation
after reading this tutorial you shouldn't have too much trouble
implementing SmallTalk (SmallSquawk?) :-)
the only issue is to find a proper grammar to stick with; effectively
all statements are PAST::Op( :pasttype('call') ) or
:pasttype('callmethod') (depending on your implementation, I think the
latter is better).
I understand the confusion, and my intention was to spell it as the
proper English word... but something went wrong apparently. Maybe
Squawk is a nice enough name to save for a real language, rather than
this toy language.
kjs
On Tue, Mar 25, 2008 at 3:17 PM, Eric Hanchrow <[EMAIL PROTECTED]> wrote:
> > "Mark" == Mark J Reed <[EMAIL PROTECTED]> writes:
>
> Mark> ... confusion with Squeak, which is how I read this subject
> Mark> at first. ("Smalltalk on Parrot?! Whoa!). But maybe
> Mark> that's just me. :)
>
> I read it that way too (and had the same reaction :-)
>
> --
> [T]he main reason Viaweb ended up being server-based was
> that we didn't want to have to write Windows apps.
> -- Paul Graham
>
>
Re: Perl 6 fundraising and related topics.
> "RH" == Richard Hainsworth <[EMAIL PROTECTED]> writes: RH> No one likes bureacracy. But I feel much happier about handing over RH> money, or persuading someone else to hand over money, to a group of RH> people with established procedures and collective responsibility, than RH> to some enthusiatic individual who promises the earth and whose the RH> world-number-one genius at code writing, but might also go and blow RH> the whole lot on girls and booze cos his cat died. would you think damian has enough anti-flake genome in him to qualify for a more direct donation? :) if you do and agree that damian is worth supporting, i have an opportunity to propose. i am producing the perl college which is a set of classes taught by damian in boston, aimed at junior perl hackers. the college is sponsored by companies looking to hire intermediate level perl developers. your company or you as an individual, can be a sponsor which will support damian to come to the states for this set of classes and also for the conferences (which he missed last year because his funding came up short). if you are interested contact me off list at uri AT perlhunter.com. for more info on the perl college go to: http://perlhunter.com/college.html thanx, uri, dean of the perl college. -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Perl 6 fundraising and related topics.
Uri, Consider the position you put me, or another sponsor, in. You mention a specific person, someone who is highly respected and extremely talented. You ask if I consider this person to be as flaky as a character that was a figment of my imagination, and if I say 'no he is not so flaky', then the implication is I will provide sponsorship. And if I demur, you might say 'put up or shut up' and I feel under pressure to do something I might not really want to. But even if I say 'sure, how much?' to Damian Conway, what do I say to another request for a Klingon of altogether unknown character? And suppose I cant manage the whole amount, but I can pay a part, who makes up the rest? And suppose I pay my money, but the trip is cancelled, who pays me back? And suppose I want to sponsor the development of perl6 over parrot, leaving training to someone else? Can I respond easily to your direct request without implying some slur on Damian? The whole point about having an institutional channel for sponsorship is to remove the need for personal judgments, for sponsors to specify exactly how their money should be used, for the procedures to be in place to cover shortfalls from a central budget, for rules to be clear about what happens to money that is in excess of earmarked programmes, and for there to be clarity in all possible grey areas that happen in life. What the perl6 language needs now is a systematic development plan, with broad aims and clear goals that will lead to good quality software and to the tools to enable ordinary programmers to use perl6 for a variety of tasks. More than that it needs the excitement that comes when there is tangible progress (just look what has happened to parrot as a result of the funding arranged via The Perl Foundation). Ad hoc, piecemeal processes will yield ad hoc piecemeal results. I have absolutely no issues with the excellent series of courses you run, especially if they are taught by Damian. But where do they fit into the general scheme of things? Are they essential to the development of perl6, or do they only benefit a small group of regional companies. Do they benefit me (bear in mind that the company I run is based in Moscow, Russia)? Sorry. You asked questions I am not prepared to answer because the questions were posed in a manner that prevents me from answering. Do this through The Perl Foundation and you will get a clear answer. Richard Hainsworth Uri Guttman wrote: "RH" == Richard Hainsworth <[EMAIL PROTECTED]> writes: RH> No one likes bureacracy. But I feel much happier about handing over RH> money, or persuading someone else to hand over money, to a group of RH> people with established procedures and collective responsibility, than RH> to some enthusiatic individual who promises the earth and whose the RH> world-number-one genius at code writing, but might also go and blow RH> the whole lot on girls and booze cos his cat died. would you think damian has enough anti-flake genome in him to qualify for a more direct donation? :) if you do and agree that damian is worth supporting, i have an opportunity to propose. i am producing the perl college which is a set of classes taught by damian in boston, aimed at junior perl hackers. the college is sponsored by companies looking to hire intermediate level perl developers. your company or you as an individual, can be a sponsor which will support damian to come to the states for this set of classes and also for the conferences (which he missed last year because his funding came up short). if you are interested contact me off list at uri AT perlhunter.com. for more info on the perl college go to: http://perlhunter.com/college.html thanx, uri, dean of the perl college.
[svn:parrot-pdd] r26537 - in trunk: . docs/pdds src
Author: coke Date: Tue Mar 25 10:54:28 2008 New Revision: 26537 Modified: trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/src/vtable.tbl Log: [deprecated] Remove deprecated vtable entry "subtype". No tests fail. Resolves RT#48569 Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Mar 25 10:54:28 2008 @@ -659,17 +659,6 @@ the PMC's class is loaded. Negative numbers are considered interpreter-specific, non-public types. -=item subtype [deprecated: See RT #48569] - - UINTVAL subtype(INTERP, PMC* self, INTVAL type) - -Return the subtype of a PMC. (Note that this may be unimplemented, and may go -away). This is intended to return information about the PMC--what type of -number or string it is, whether it's a scalar, hash, array, or list, and -suchlike things. - -[This can be adequately handled by C and C.] - =item name STRING* name(INTERP, PMC* self)
[perl #48569] [DEPRECATED] vtable subtype
On Thu Dec 13 19:08:42 2007, coke wrote: > From PDD17: > > =item subtype [deprecated] > > UINTVAL subtype(INTERP, PMC* self, INTVAL type) > > Return the subtype of a PMC. (Note that this may be unimplemented, and > may go > away). This is intended to return information about the PMC--what type > of > number or string it is, whether it's a scalar, hash, array, or list, > and > suchlike things. > > [This can be adequately handled by C and C.] Removed in r26537. Closing ticket.
Re: Perl 6 fundraising and related topics.
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote: > What the perl6 language needs now is a systematic development plan, with > broad aims and clear goals that will lead to good quality software and > to the tools to enable ordinary programmers to use perl6 for a variety > of tasks. Perl 6 has had several plans over the past eight years. What Perl 6 hasn't had in quite a while is paid developer time. Plans are good and plans are fine, but I've never seen a plan do the red-green-refactor loop once, let alone the few million times it'll take to finish Perl 6.0. -- c
Re: Perl 6 fundraising and related topics.
> "RH" == Richard Hainsworth <[EMAIL PROTECTED]> writes: RH> Consider the position you put me, or another sponsor, in. You mention RH> a specific person, someone who is highly respected and extremely RH> talented. You ask if I consider this person to be as flaky as a RH> character that was a figment of my imagination, and if I say 'no he is RH> not so flaky', then the implication is I will provide sponsorship. And RH> if I demur, you might say 'put up or shut up' and I feel under RH> pressure to do something I might not really want to. i am sorry if i caused you any concern or confusion. i didn't mean to put you under any pressure in any way. my goal was to inform anyone here about another way to help with supporting perl6 (and perl5 cpan) developers, in particular damian. as for damian being flaky or not, that is a great question! :). RH> The whole point about having an institutional channel for sponsorship RH> is to remove the need for personal judgments, for sponsors to specify RH> exactly how their money should be used, for the procedures to be in RH> place to cover shortfalls from a central budget, for rules to be clear RH> about what happens to money that is in excess of earmarked programmes, RH> and for there to be clarity in all possible grey areas that happen in RH> life. i agree about needing better institutional channels for sponsorship. i am just offering a small side channel for those who would like to support damian. RH> I have absolutely no issues with the excellent series of courses RH> you run, especially if they are taught by Damian. But where do RH> they fit into the general scheme of things? Are they essential to RH> the development of perl6, or do they only benefit a small group of RH> regional companies. Do they benefit me (bear in mind that the RH> company I run is based in Moscow, Russia)? i didn't aim this at companies in moscow. you had the last best email on this thread which inspired me to respond. note that i replied to the lists as well directly to you. it was a purely informational post for the perl 6 community. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
[perl #52096] [BUG] PIOHANDLE dup-di-dup
# New Ticket Created by Ronald Blaschke
# Please include the string: [perl #52096]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52096 >
I just noticed this warning on Windows.
src\io\io.c
src\io\io.c(180) : warning C4047: 'function' : 'int' differs in levels
of indirection from 'PIOHANDLE'
src\io\io.c(180) : warning C4024: 'dup' : different types for formal and
actual parameter 1
src\io\io.c(180) : warning C4047: 'initializing' : 'const PIOHANDLE'
differs in levels of indirection from 'int'
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\io.h(308) : see declaration of 'dup'
src\io\io.c(189) : warning C4047: '==' : 'const PIOHANDLE' differs in
levels of indirection from 'int'
The offending code in F is:
ParrotIO * const io = PMC_data_typed(pmc, ParrotIO *);
const PIOHANDLE newfd = dup(io->fd);
and
if (newfd == -1) {
real_exception(interp, NULL, 1, "could not dup an fd");
}
With ParrotIO.fd declared as:
struct _ParrotIO {
PIOHANDLE fd; /* Low level OS descriptor */
...
};
The code makes sense if C is a C file descriptor, but it
might be something else.
#ifdef PIO_OS_WIN32
typedef Parrot_WIN32_HANDLE PIOHANDLE;
typedef Parrot_OFF_T PIOOFF_T;
#endif
#ifdef PIO_OS_UNIX
/* Hopefully INTVAL_SIZE is enough for PTR_SIZE so that
* the FILE* of pio_stdio_layers fit into a PIOHANDLE. */
typedef INTVAL PIOHANDLE;
typedef off_t PIOOFF_T;
#endif
#ifdef PIO_OS_STDIO
typedef FILE* PIOHANDLE;
typedef long PIOOFF_T;
#endif
C and comparison with C<-1> don't make sense if C is a
Windows C or a C.
Re: Perl 6 fundraising and related topics.
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote: > What the perl6 language needs now is a systematic development plan, with > broad aims and clear goals that will lead to good quality software and > to the tools to enable ordinary programmers to use perl6 for a variety > of tasks. Richard Dice mentioned that I should elaborate, lest it sound like I'm trying to lecture Richard Hainsworth (not my intent, and I apologize for doing so). It's important to keep in mind the degree to which one or two volunteers going on vacation can slow the progress of Rakudo (for a recent example) or to which one or volunteers putting in a few extra hours of visible work can improve the progress of Parrot (for a slightly less recent example). A plan that includes some degree of funding will help Perl 6 arrive much sooner. Previous plans glossed over this part, which is one reason they didn't work out in the long term. I just want to make sure that any discussion of a plan acknowledges that there's a fixed amount of work to go and an unknown amount of available resources to implement the plan. -- c
[perl #52028] [PATCH] Do not split macro invocations that use CONST_STRING into multiple lines
On Sun Mar 23 07:37:05 2008, kraai wrote: > Howdy, > > If a macro invocation that uses CONST_STRING is split into multiple > lines, icc uses the wrong line number for the CONST_STRING macro. The > attached patch puts such invocations on a single line and updates the > documentation. > Thanks. Applied in r26545.
Re: Musings on operator overloading
HaloO,
Larry Wall wrote:
Another minor psychological factor is comes into play is that, besides
being "too hard to type", ÷ is visually a symmetrical operator,
while division is inherently an asymmetric operation. You'll notice
that other asymmetric operators invented by mathematicians tend to
convey that asymmetry visually.
OK, with symmetric equal to commutative. But you don't have this
concern with - which is as asymmetric as /. Also x and xx are
asymmetric without visual indication. These are not even symmetric
in the types of their operants.
: > Second, a path is much more like a string than a number.
:
: Right. Which means there's no room for confusion with division,
: 'cause you can't divide strings! Ambiguity gone, problem solved, no
: worries.
Er, except for hordes of Perl 5 programmers who think you can... :)
Yeah! We could actually invent x/ for a "inverse" operation of x
in the sense that you factor a string. E.g. 'aaa' x/ 3 eq 'a' but
'abc' x/ 3 eq ''. That is a non-repetitive string is kind of primal.
Hmm, or x/ behaves more like % and 'abc' x/ 3 eq 'abc' and 'aaa' x/ 2
eq 'a' and of course 'aaa' x/ 3 eq ''. But that might better be spelled
x%, I think.
Speaking of x actually makes me wonder about two things in its
definition: (1) why is it non-associative and (2) why is it not
on the multiplicative precedence but below addition? It could be
made left associative: 'ab' x 3 x 2 eq 'abababababab' which implies
that 3 x 2 == 6. So we would get a multiplication operator that the
optimizer wouldn't touch commutatively. Hence it would be a good
candidate for the vector cross product and quaternion multiplication
and such.
Or we could use it for the scalar multiplication of vectors. That would
require it to be commutative, though. Note that this is no problem if we
define &infix::(::T,::T) to be a type error whilst &infix::(::T,
Num | Num, ::T) allows 3 x 'a' eq 'a' x 3 eq 'aaa' when ::T === Str.
Actually we could make x commutatively list associative and define that
at most one operant can be of a type different from Num or better a
type that is a Field, e.g. Complex. This automatically gives
(1,2,3) x 3 === 3 x (1,2,3) === (2,6,9). Uhh, and ~~ might check linear
dependence of vectors or so. BTW, how would the signature of x look
like if you want to enforce the presence of at most one argument of
type Field? The problem is you can't have the variadic array at the
front or the middle to get
multi *listfix: ( none(Field) ::T $v, Field [EMAIL PROTECTED] |
Field [EMAIL PROTECTED], none(Field) ::T $v|
Field [EMAIL PROTECTED], none(Field) ::T $v, Field [EMAIL
PROTECTED]
--> T)
{...}
perhaps
multi *listfix: ( [EMAIL PROTECTED] where { one(@scalars) does none(Field)
or
all(@scalars) does Field } )
{...}
but that makes capturing the non-field type impossible.
An additional idea of mine is to also introduce a generic multiplication
operator &infix: as ASCII equivalent of U+2218. An exponentiation in
terms of o would be written oo. That somewhat makes xx oddly overloaded
with list replication where one could expect it to be exponentiation in
terms of x. Then again scalar multiplication has no exponential form.
For geometric algebra one would introduce _| (U+2A3C) and |_ (U+2A3D)
for left and right contraction and /\ for the wedge. And then choose x
for the geometric product if it had multiplicative precedence. Or if we
follow the scalar multiplication approach outlined above,
&infix:<*>:(::T, T --> T) would become a generic list associative
non-commutative product operator. Note that a proper product is
homogeneous in ::T whereas multiplicative x is generally not.
Sorry if this is off-topic, but this is the outcome if I'm musing about
operator overloading. My driving idea is to abstractly define the
properties of operators that should hold when overloaded. E.g. + for
string concatenation is bad because I would expect $a + $b eqv $b + $a.
From the commutativity point of view it could be argued to overload -
which isn't commutative like ~. But I've never seen - being overloaded
with string concatenation ;)
In the last section of S03 good names for the three groups of operators
are asked for. I would call the group with guaranteed sequence points
just that: sequential operators. They come in two types: left and right
sequential. Basically this replaces the "wrong" usage of associativity
of an operator. Then associativity could retain its mathematical meaning
and allow the optimizer/parallizer to group at will. E.g + would be
associative but - left-sequential or forcing associative addition with
prior unary -. Same thing with * and / if we have e.g. &prefix:<1/>
applied before associating the factors.
Commutativity would be an even better property of an operator because it
doesn't have to assemble values returned from multiple threads in the
orde
Re: Musings on operator overloading
HaloO, Doug McNutt wrote: Don't allow it to become = f(-$x); ## wrong! Unless of course f does Linear, then you can factor out or in the multiplication with -1 at will. So linearity of operators and functions is a very interesting property for optimizers. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
[perl #47930] [RFC] Remove comma separated keys [a,b]
On Wed Nov 28 12:18:50 2007, kjs wrote: > hi, > > IMCC allows for writing > > $P0 = $P1[10, 20] > > Looking into the yacc file, it seems there's something going on with > slicing, just as the ".." syntax does (which is deprecated). > > I'm wondering what exactly is going on, what it is supposed to do. Any > enlightenment on this would be very welcome! > > Also, it would be useful to have some working examples of how this should > work. > > I expect that it's currently not working, just as the ".." syntax for > slicing, in which case I would like to propose to remove it. > > comments welcome, > > kjs +1 for adding this to the official [DEPRECATION] pile.
[perl #48549] [RFC][PIR] Let .namespace (no args) have empty brackets
On Thu Dec 13 08:04:00 2007, kjs wrote: > to specify a namespace, say, "foo", one would write: > > .namespace ["foo"] > > in order to have PIR switch (back) to the "root" namespace, you should > currently write > > .namespace > > which is ok, but more clear would be to write: > > .namespace [] > > > which just looks more consistent, IMHO. > A minor thing, but anything we can do to make PIR easier to read is a Good > Thing. > I think this change was also suggested by someone else in the last 2 months, > but I couldn't find any references. > > comments welcome, > kjs +1
[perl #37361] [BUG] Parrot 0.3.0 Tru64 core dump t/examples/japh.t #10
On Wed Oct 05 22:27:25 2005, jhi wrote: > Didn't notice this earlier because the whole japh.t is > reported as succeeding even though a core dump happens > for the subtest #10. > Since we're on 0.6.0 now and there are only 5 tests left in this test file, rejecting this ticket. If we could get a test run on Tru64 again, that'd be great. ^_^
[perl #51916] Error in tests after build
On Fri Mar 21 19:23:13 2008, [EMAIL PROTECTED] wrote: > No, and it appears not be part of Bundle::Parrot on CPAN, either. We'll > have to rectify this. > Coke asked me to pose this question for general discussion: If individual languages -- as distinct from Parrot itself -- require non-core modules from CPAN, should such modules go into Bundle::Parrot? Should we create a Bundle::Parrot::Languages? Should we create a Bundle::Parrot::SomeSpecificLanguage?
[svn:parrot-pdd] r26553 - in trunk: . docs/pdds languages/perl6/src/classes lib/Parrot/Pmc2c src src/ops src/pmc t/pmc tools/dev
Author: coke Date: Tue Mar 25 20:38:06 2008 New Revision: 26553 Modified: trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/languages/perl6/src/classes/Object.pir trunk/lib/Parrot/Pmc2c/PMCEmitter.pm trunk/src/mmd.c trunk/src/oo.c trunk/src/ops/experimental.ops trunk/src/pmc/class.pmc trunk/src/pmc/default.pmc trunk/src/pmc/deleg_pmc.pmc trunk/src/pmc/delegate.pmc trunk/src/pmc/pmcproxy.pmc trunk/src/pmc/role.pmc trunk/src/vtable.tbl trunk/t/pmc/class.t trunk/t/pmc/pmcproxy.t trunk/tools/dev/gen_class.pl trunk/tools/dev/vtablize.pl Log: [DEPRECATED] The pmc_namespace vtable was deprecated, the get_namespace vtable was its replacement: Here's a rename which resolves both tickets (now merged into RT#48144). Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Mar 25 20:38:06 2008 @@ -568,13 +568,6 @@ C object (or other high-level class object). For low-level PMCs, this returns a C object. -=item pmc_namespace [deprecated: See RT# 48144] - - PMC* pmc_namespace(INTERP, PMC* self) - -Return the namespace object for this PMC. [NOTE: replaced by -C.] - =item get_namespace PMC* get_namespace(INTERP, PMC* self)
[perl #48144] [DEPRECATED] pmc_namespace vtable
On Mon Mar 17 13:53:55 2008, bernhard wrote: > > > =item get_namespace > > > > PMC* get_namespace(INTERP, PMC* self) > > > > Return the namespace object for this PMC. > > > > > > > > The get_namespace vtable entry doesn't exist yet in vtable.tbl. > > Allison: Can this ticket be resolved ? This was the other half of the deprecated pmc_namespace ticket: merged the tickets, applied the rename in r26553. All tests pass (including perl6, which was the only language that used this vtable entry)
[svn:parrot-pdd] r26556 - in trunk: . docs/pdds docs/pdds/draft src/pmc
Author: coke Date: Tue Mar 25 20:48:51 2008 New Revision: 26556 Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod trunk/src/pmc/default.pmc Log: [DEPRECATED] Remove the deprecated vtable entry: get_bool_keyed_int (RT#48573) Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod == --- trunk/docs/pdds/draft/pdd04_datatypes.pod (original) +++ trunk/docs/pdds/draft/pdd04_datatypes.pod Tue Mar 25 20:48:51 2008 @@ -291,8 +291,6 @@ =item get_bool_keyed -=item get_bool_keyed_int - =item get_bool_keyed_str =item get_pmc Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Mar 25 20:48:51 2008 @@ -864,10 +864,6 @@ Return the boolean value for the element indexed by a PMC key. -=item get_bool_keyed_int [deprecated: See RT #48573] - -Return the boolean value for the element indexed by an integer key. - =item get_bool_keyed_str [deprecated: See RT #48575] Return the boolean value for the element indexed by a string key.
[perl #48573] [DEPRECATED] vtable get_bool_keyed_int
On Thu Dec 13 19:12:11 2007, coke wrote: > From PDD17: > > =item get_bool_keyed_int [deprecated] > > Return the boolean value for the element indexed by an integer key. > > Removed in r26556
[PATCH] Profile PIR with Devel::DProf's dprofpp
The attached patch (not for application, yet) hijacks parrot -p to emit
dprofpp-compatible output to standard error. This allows us to profile PIR
code at the PIR level (not the C level).
The caveats are:
* you'll have to edit out anything else that appears on standard error, or
dprofpp will complain
* you'll have to edit the file manually to add the magic old-style dprofpp
header, or dprofpp will complain
The header is:
#fOrTyTwO
$hz=100;
$XS_VERSION=’DProf 19970606’;
# All values are given in HZ
$rrun_utime=2; $rrun_stime=0; $rrun_rtime=7
PART2
Don't worry about that part. Just catenate it to the file, then run dprofpp
to your results.
Some of the statistics are a little bit wonky (probably because the header is
wrong-ish), but they should give you a much better idea of where your time is
going in PIR programs.
I may make this emit callgrind-compatible output in the future, but this was
the easiest proof of concept I could make work now. Enjoy.
-- c
=== src/runops_cores.c
==
--- src/runops_cores.c (revision 26556)
+++ src/runops_cores.c (local)
@@ -23,11 +23,16 @@
#include "parrot/embed.h"
#include "trace.h"
#include "interp_guts.h"
+#include
+#include
#ifdef HAVE_COMPUTED_GOTO
# include "parrot/oplib/core_ops_cg.h"
#endif
+#define Parrot_report_entry(i) Parrot_report_profile((i), "+")
+#define Parrot_report_exit(i) Parrot_report_profile((i), "-")
+
/* HEADERIZER HFILE: src/runops_cores.h */
/* HEADERIZER BEGIN: static */
@@ -38,6 +43,10 @@
__attribute__nonnull__(1)
__attribute__nonnull__(2);
+static void Parrot_report_profile(PARROT_INTERP, const char *s)
+__attribute__nonnull__(1)
+__attribute__nonnull__(2);
+
/* HEADERIZER END: static */
/*
@@ -274,8 +283,9 @@
opcode_t *
runops_profile_core(PARROT_INTERP, ARGIN(opcode_t *pc))
{
-RunProfile * const profile = interp->profile;
-const opcode_t old_op = profile->cur_op;
+RunProfile * const profile = interp->profile;
+const opcode_t old_op = profile->cur_op;
+intreport_entry = 1;
/* if reentering the runloop, remember old op and calc time 'til now */
if (old_op)
@@ -283,13 +293,24 @@
Parrot_floatval_time() - profile->starttime;
while (pc) {/* && pc >= code_start && pc < code_end) */
-opcode_t cur_op;
+opcode_t cur_op;
+op_info_t op_info = interp->op_info_table[*pc];
CONTEXT(interp)->current_pc = pc;
profile->cur_op = cur_op = *pc + PARROT_PROF_EXTRA;
profile->starttime = Parrot_floatval_time();
profile->data[cur_op].numcalls++;
+if (report_entry) {
+Parrot_report_entry(interp);
+report_entry = 0;
+}
+
+if (op_info.jump & PARROT_JUMP_ENEXT) {
+Parrot_report_exit(interp);
+report_entry = 1;
+}
+
DO_OP(pc, interp);
/* profile->cur_op may be different, if exception was thrown */
@@ -306,6 +327,22 @@
return pc;
}
+void
+Parrot_report_profile(PARROT_INTERP, NOTNULL(const char *s))
+{
+Parrot_Context *ctx = CONTEXT(interp);
+struct tms buf;
+Parrot_Context_info info;
+
+Parrot_Context_get_info(interp, ctx, &info);
+times(&buf);
+
+fprintf( stderr, "%s %02d %02d %d %s::%s\n",
+s, (int)buf.tms_utime, (int)buf.tms_stime, (int)time(NULL),
+string_to_cstring(interp, info.nsname),
+string_to_cstring(interp, info.subname) );
+}
+
/*
=back
[svn:parrot-pdd] r26557 - in trunk: . docs/pdds docs/pdds/draft
Author: coke Date: Tue Mar 25 20:52:56 2008 New Revision: 26557 Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod Log: [DEPRECATED] Remove last references to vtable entry: get_bool_keyed_str (RT#48575) Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod == --- trunk/docs/pdds/draft/pdd04_datatypes.pod (original) +++ trunk/docs/pdds/draft/pdd04_datatypes.pod Tue Mar 25 20:52:56 2008 @@ -291,8 +291,6 @@ =item get_bool_keyed -=item get_bool_keyed_str - =item get_pmc Return the PMC for this PMC. Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Mar 25 20:52:56 2008 @@ -864,10 +864,6 @@ Return the boolean value for the element indexed by a PMC key. -=item get_bool_keyed_str [deprecated: See RT #48575] - -Return the boolean value for the element indexed by a string key. - =item get_pmc_keyed PMC* get_pmc_keyed(INTERP, PMC* self, PMC* key)
[svn:parrot-pdd] r26558 - in trunk: . docs/pdds docs/pdds/draft
Author: coke Date: Tue Mar 25 20:56:29 2008 New Revision: 26558 Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod trunk/docs/pdds/pdd17_pmc.pod Changes in other areas also in this revision: Modified: trunk/DEPRECATED.pod Log: [DEPRECATED] Remove last references to vtable entry: get_bool_keyed (RT#48571) Modified: trunk/docs/pdds/draft/pdd04_datatypes.pod == --- trunk/docs/pdds/draft/pdd04_datatypes.pod (original) +++ trunk/docs/pdds/draft/pdd04_datatypes.pod Tue Mar 25 20:56:29 2008 @@ -289,8 +289,6 @@ Return the true/false value of the PMC -=item get_bool_keyed - =item get_pmc Return the PMC for this PMC. Modified: trunk/docs/pdds/pdd17_pmc.pod == --- trunk/docs/pdds/pdd17_pmc.pod (original) +++ trunk/docs/pdds/pdd17_pmc.pod Tue Mar 25 20:56:29 2008 @@ -860,10 +860,6 @@ Return the string value for the element indexed by a PMC, integer, or string key. The key is guaranteed not to be null for this function. -=item get_bool_keyed [deprecated: See RT #48571] - -Return the boolean value for the element indexed by a PMC key. - =item get_pmc_keyed PMC* get_pmc_keyed(INTERP, PMC* self, PMC* key)
[perl #48571] [DEPRECATED] vtable get_bool_keyed
On Thu Dec 13 19:11:44 2007, coke wrote: > From PDD17: > > =item get_bool_keyed [deprecated] > > Return the boolean value for the element indexed by a PMC key. > Removed last references in r26558.
[perl #48014] [DEPRECATED] PMC union struct
On Sat Dec 01 14:22:59 2007, coke wrote: > from DEPRECATED.pod > > The PMC union struct is deprecated and will be removed once all core PMCs > have > been updated. This has happened, correct? Some pointers on how to implement this would probably turn this into a decent CAGE task...
[perl #48729] [DEPRECATED] int variants of getattribute/setattribute opcodes
On Mon Feb 04 20:36:18 2008, coke wrote: > Here's a patch that removes these attributes. > > Once you apply it, update PBC_COMPAT and run 'make -f > tools/dev/ops_renum.mak' > > Not applying just yet because there are a bunch of examples which seem > to use this, but aren't > run as tests. I was suffering from wrong-thinking here. The examples must already fail, since the opcodes that are being removed throw exceptions instead of doing something useful. So removing them won't cause any more failures than already exist; Any failing examples should be fixed (or at least ticketed). Committed as r26559.
Re: [perl #48014] [DEPRECATED] PMC union struct
On Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote: > On Sat Dec 01 14:22:59 2007, coke wrote: > > from DEPRECATED.pod > > The PMC union struct is deprecated and will be removed once all core PMCs > > have been updated. > This has happened, correct? Not yet. PDD 17 made this possible, but someone (and your first two guesses don't count) has to update all of the core PMCs and the language PMCs not to use the cache structure. > Some pointers on how to implement this would probably turn this into a > decent CAGE task... 1) Figure out what kind of data the PMC stores 2) Replace all uses of PMC_int_val(), PMC_float_val(), and PMC_str_val() with attribute access within the PMC 3) Replace all uses of those macros with attribute access outside of the PMC 4) Fix any compilation errors -- c
