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
>
>
[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.
[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.
[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.
[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
