Re: Multimethod dispatch?
Adam Turoff writes:
> On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> > It will still have a lot of power in text processing, and still be a
> > powerful "quicky" language, but that's no longer its primary focus --
> > not to say that highly structured programming is. Some applications
> > want strong typing, some don't. That's why typing is optional (which
> > is still driving me nuts as to how that's going to work).
>
> You seem to have Perl5 confused with bash, sed or awk.
>
> The main principles behind Perl are:
> 0: Get the job done (before the boss fires you)
> 1: TMTOWTDI
> 2: Use what works for you (i.e., Perl has no ideological bias)
Those are the general principles, yes, and the ones that make Perl so
enjoyable to use. But if you take a closer look, say at the builtins
and the features of Perl, you'll see that it's quite clearly a text
processing language. And that's fine -- it doesn't keep you from
doing non-text related stuff; it seems to find a way to make
anything text-related.
It's easy to get all those other non-text related things done with
CPAN. That's when text becomes less important, because there are
extensions written for everything.
> I don't see what typing has to do with any of that. And I don't see why
> optional typing or moving towards 'highly structured programming' is the
> solution to fixing all of Perl5's warts.
I don't think it's trying to fix all of Perl5's warts. And I don't
see what typing doesn't have to do with any of that. TMTOWTDI.
There are people who don't consider typing a programmer's aid at all,
and think that it's just there to help the compiler generate code
without working as hard. On the other hand, some people consider
typing a good error-checker and an idiom-enabling mechanism. Again,
that's why it's optional.
[snip]
> > What the A6 MMD's accomplish are the common case. There's one "most
> > common" kind of dispatch that it implements. But Perl's not going to
> > stop you from redefining the "multi" declarator, registering the
> > routines, and using your own dispatcher. Perl 5 sure didn't :-)
>
> That's a cop-out.
>
> Of course I can write my own dispatcher or warp the syntax to make my
> pet idiom work. If the solution to every hard or unforseen problem is
> "warp the syntax", then Perl6 is doomed to failure[*]. Don't forget that
> Perl has many masters, and if the work-a-day Perl5 programmer is left in
> the dust, then Perl6 will not have fufilled its mission.
I didn't say "warp the syntax" (though that is a useful one :-).
> The whole point behind Perl6 is to remove the warts and make easy things
> easier. To me, this is a wart:
>
> my %dispatch = (
> param1 => sub {...},
> param2 => sub {...},
> );
>
> sub foo {
> my $param = shift;
>
> if (my $sub = $dispatch{$param}) {
> $sub->(@_);
> } else {
> warn "No such parameter: $param\n";
> }
> }
>
> It's structurally similar to MMD, yet it is unsupported by MMD. And a
> very easy technique for cleaning up Perl programs.
And I don't see what's stopping someone from writing Dispatch::Value.
use Dispatch::Value;
sub foo($param is value('param1')) {...}
sub foo($param is value('param2')) {...}
What it seems you're wanting is it to be in the core. And I'm saying
that's irrelavent. There are thousands of great ideas out there, and
they can't all fit into Perl's core. That's why there's thousands of
modules on CPAN.
And I'm not saying it won't be in the core, either. It'll probably be
in the core module set.
Oh, sorry if I've turned this into too much philosophy. I'll happily
talk about more concrete things like ways it might be possible to
extend the standard dispatcher. Give me some more code to work with
-- more hypothetical examples -- and I'll talk about that.
> Z.
>
>
> *: JBoss 4.0 is coming out, and if the pre-press reports are even remotely
> correct, it was implemented using a high degree of AOP. The JBoss team
> didn't need to warp Java syntax to accomplish it; instead, they rewrote
> the class loader to support :before and :after subs dynamically appearing
> and disappearing. I predict that this kind of extension, along with
> macros, are going to be *MUCH* more useful than hacking the grammar.
>
> The 'warping the syntax' escape hatch should only be used for hacking in
> things like v-strings or lexical filehandles, *not* every pet extension
> hook that someone could possibly want to see in the language.
Again, I never said "warp the syntax".
Luke
Re: Multimethod dispatch?
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote: > What it seems you're wanting is it to be in the core. And I'm saying > that's irrelavent. There are thousands of great ideas out there, and > they can't all fit into Perl's core. That's why there's thousands of > modules on CPAN. Have you looked at the perl5 distribution lately :-) Graham.
Re: Cothreads
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote: >> So, in summary, its good to have a clean abstraction for all the >> HCCCT things. But I think it is a mistake to push them too >> close. Each of the HCCCT things might be implemented as facades over >> the underlying othogonal concepts of data management and execution >> management (hmm, we mustn't forget IO and other resource managers). > > Yeah, that. > > What I STRONGLY SUGGEST WE AVOID is a situation where _some_ of > those interfaces are object-based, using or similar, > and others of those are trait or keyword based, such as > or , and others are implicit and invisible > (closures).[*] I would be very, very surprised to see a situation where you don't have an object interface to the various things which are more usually made with the various bits of syntactic sugar. A nice, consistent OO API for these things will make the life of macro/refactoring brower/SmalltalkLikeIDE/whatever author so much easier. -- Piers
Re: Multimethod dispatch?
On Mon, Jun 02, 2003 at 10:34:14AM -0600, Luke Palmer wrote:
> And I don't see what's stopping someone from writing Dispatch::Value.
>
> use Dispatch::Value;
> sub foo($param is value('param1')) {...}
> sub foo($param is value('param2')) {...}
>
> What it seems you're wanting is it to be in the core.
Actually, no.
I expected that there'd be a way to extend runtime behavior through modules
like this hypothetical Dispatch::Value, Dispatch::Multimethods, or
Dispatch::Agent::Smith, but I'm seeing precious little evidence of that,
just allusions to MMD with the 'multi' keyword and all that.
As I said earlier, MMD is starting to give me a big case of The Fear
because it's predicated on offering behavior that heretofore hasn't been
widely used in Perl, and it's based around limitations that don't
necessarily exist in Perl. It's nice that Perl6 will extend its dynamic
range, but the whole reason for Perl6 in the first place is to fix
some of the warts in the current problem domain.
With some recent focus on MMD (mostly thanks to Dan's WTHI post, and my
discovery of TAMOP), I started to feel like MMD was good for a certain
style of programming, but necessarily ignores a "native" Perl5 idiom that's
equally powerful and perhaps preferable for a large set of problems.
I'm not trying to throw out the type system or cast MMD as pure evil.
Rather, I'm just poking around to make sure the dispatch machinery isn't
wired in for single dispatch/MMD without opening it up for extensions
via simple dispatch classes. *That* feature seems much more important
to me than wiring in MMD, since MMD could be implemented through
Dispatch::Multimethods or something. It's been done before with
Class::Multimethods, and I'll buy that there's a benefit to adding a
'multi' keyword to the language, but not if that's the last word for
variant dispatching...
If some dispatch class can use some syntax vaguely approximating the straw
man above, then this is just a tempest in a teapot and I'll move along.
But I haven't heard or seen anything concrete that dispatch behavior in
Perl6 can be user-defined without resorting to serious magic. Instead,
it's starting to sound suspiciously like "you can have any dispatching
behavior you want, so long as it's either single dispatch (modulo
sub/method semantics) or MMD". And that would be a net loss for Perl6.
Z.
Re: Multimethod dispatch?
> A better fitting solution wouldn't focus on classic > MMD, but simply "Dispatch", where type- and value-based > dispatching are two of many kinds of dispatching supported. I've always liked the sound of Linda's tuple spaces and view that as a nice generalized dispatch approach. Procedure calls are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
Re: Multimethod dispatch?
> A better fitting solution wouldn't focus on classic > MMD, but simply "Dispatch", where type- and value-based > dispatching are two of many kinds of dispatching supported. I've always liked the sound of Linda's tuple spaces and view that as a nice generalized dispatch approach. Procedure calls are thrown into a tuple space, then other (mop) code grabs one or more tuples and dispatches them. Grep like code is used for the grabbing. -- ralph mellor
Timely object destruction
Piers Cawley wrote: > > The Perl 6 Summary for the week ending 20030601 > Another Monday, another Perl 6 Summary. Does this man never take a > holiday? (Yes, but only to go to Perl conferences this year, how did > that happen?) > > We start with the internals list as usual. > > More on timely destruction > The discussion of how to get timely destruction with Parrot's Garbage > Collection system continued. Last week Dan announced that, for languages > that make commitments to call destructors as soon as a thing goes out of > scope, there would be a set of helpful ops to allow languages to trigger > conditional DOD (Dead Object Detection) runs at appropriate times. > People weren't desperately keen on the performance hit that this entails > (though the performance hit involved with reference counting is pretty > substantial...) but we didn't manage to come up with a better solution > to the issue. > > http://xrl.us/iu5 I'd like to reiterate (and clarify) my idea, of a hybrid scheme combining refcounting and DoD. All values needing timely destruction would inherit from a class RefCounted. They should (in the normal scheme of things) be stored in variables with an "is refcounted" trait (or a trait which inherits or includes that trait, if that's possible). Hopefully, only a *small* number of objects in a system need timely destruction, and (for best performance) all variables which will hold those objects will have the "is refcounted" trait set on them. (If most or all objects needed timely destruction, then we wouldn't be moving away from perl5's pure-refcount GC, would we?) All operations on a variable or variables having the "is refcounted" trait result in opcodes to call the refcount(inc|dec) method(s) of the values in those variables. Under normal circumstances, when a refcounted value's refcount goes to zero, it self destructs^W^W cleans itself up. This is quite perl5-esque, and of course slower than simply letting the DoD-GC handle everything, BUT, in the absence of circular reference loops, it does produce timely cleanup of those objects which need it, which pure-DoD wouldn't, and DOESN'T result in numerous, and thus expensive, requests for full DoD runs. For all of the other schemes, full DoD runs would be run on every scope exit, even if there's only one single variable in scope which needs timely destruction. Here's where the non-normal circumstances are described, and how they're handled: It's legal for a refcounted value to end up referenced by a non- refcounted variable. This has to be so, since adding the "is refcounted" trait everywhere would get cumbersome; also we may sometimes *need*, for one reason or another, to store refcounted values in the same containers which also hold non-refcounted values. Thus, if a refcounted value gets stored in a non-refcounted variable, then that value could quite easily still be reachable when it's refcount goes to zero. Obviously, when this is the case, we need to avoid a premature cleanup. To avoid premature cleanup, any time that the contents of a refcounted variable is assigned to a non-refcounted variable, an opcode to set a "reachable by non-refcounted variable" flag on the value precedes the assignment. If a refcounted values's refcount goes to zero, and it has this flag set, it does NOT self-destruct[*]. A global counter keeps track of how many values have a refcount of zero and have this flag set. >From here, we are in a similar situation as other proposals -- for the timeliest possible destruction, then on every single scope exit, we check if this global counter is nonzero, and if so, do a DoD run. For potentially less timely destruction, we do this check whenever we leave a scope where a refcounted variable was declared, but not when we leave other scopes. Which of these two is done is a choice of the language designer, but might possibly be controlled by a pragma. Note that in the absence of marking any variables with the "is refcounted" trait, and with the use of the first option here (at every scope exit, check the counter and maybe do DoD), this scheme behaves *identically* with one of the other schemes proposed. It would be *no* slower at run time, since the refcount(inc|dec) methods are only called when doing operations dealing with variables with the "is refcounted" trait, and if noone uses that trait, there's no extra work. DoD would be a tiny bit slower with my scheme than the other, due to the extra flag checking, but (assuming that *most* code with objects needing timely destruction properly marks it's variables with the necessary "is refcounted" trait) that's a small price to pay for doing fewer DoD runs. [*] How does this flag get cleared, you might ask? Simplest would be to not clear it at all. This would be mostly harmless in terms of when objects get destructed, but would probably result in more DoD runs than we really need -- blech. [**] A mor
Re: Timely object destruction
On Mon, 2 Jun 2003, Benjamin Goldberg wrote: > All values needing timely destruction would inherit from a class > RefCounted. I like this concept a lot, but maybe we can take it a little further and make it transparent to the programmer. Suppose that the internals only tracked objects that have a DESTROY method (or whatever it will be called in Perl6)? You get the same benefit without the additional brain-overhead of manually indicating that the class needs to be tracked. -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: interthread signaling
Luke Palmer wrote: I think it would fall trivially out of the events mechanism, which is planned for Parrot. I have heard rumours of such a thing, but no details of how it will be exposed in the language... Dave.
calling convention and continuation ramblings
I have a working implementation that that switches parrot to a continuation passing style. While working on cleaning up a few things up, I got the following idea ... The current parrot context struct has a set of register stacks struct IRegChunk *int_reg_top; struct NRegChunk *num_reg_top; etc ... These are used when saving and restoring the registers. Are they used other than when following the (old) calling convention? I would like to get rid of these register stacks. In their place I would like to introduce a context object (call it a continuation?) that saves and restores the stacks (user_stack, pad_stack, control_stack, and intstack) and the last half of the registers: P16-P31, I16-I31, etc. (These registers are not involved in the calling or returning convention.) This would make it unnecessary to put a saveall and a restoreall around each call/callcc. Of course it would still be possible to save and restore individual registers on the user stack. Calling a subroutine would look like (note: no saveall/restoreall needed) set P0, ... # put Sub PMC in place callcc # creates a context object # invokes the sub in P0 or for tail calls and other fancy stuff set P0, ... # put Sub PMC in place set P1, ... # put some context in P1 (unless it # is already in place as it would # be for most tail calls) call # invokes the sub in P0, the current # context is not saved returning looks like sub: # put return values in registers ... return # invokes context in P1, which # restores context etc or even just sub: # put return values in registers ... call P1 # same as return Just to be clear my current implementation does most of this, except that none of the registers are saved as part of the context, just the stacks (including the register stacks). So my proposal is to get rid of the register stacks and have the context object save (and restore) *half* of the registers in addition to the user, pad, control and int stacks. This seems like a nice approach to me as it simplifies the Parrot_Context struct and the calling and returning from subs and methods. Comments? -- Jonathan Sillito
flushing STDOUT before reading STDIN
A small annoyance, I can't seem to write a good line-input routine as of very recent changes (synced yesterday, noon). All I'm trying to do is variations on: print "? " readline S0, 0 And no prompt shows before the readline starts its business. Any suggestions as to how I can flush stdout before beginning input and whatnot? I'm not above resorting to PASM hackery at this point, since the I/O is in flux.
interthread signaling
"Piers Cawley" <[EMAIL PROTECTED]> wrote
> Threads and Progress Monitors
> Dave Whipp had some more thread questions, and wondered what would be
a
> good Perl 6ish way of implementing a threaded progress monitor. Whilst
> the discussion of all this was interesting, I'm not sure that it's
> really much to do with the language, more something that one would
> implement according to taste and the particular requirements of a
given
> project.
A quick summary of what came out of it:
On the basis that perl makes simple things simple, we drilled down on the
example of a simple progress monitor. This morphed into the question of how
to implement a timeout:
sub slow
{
TIMEOUT(60) { throw TimeoutException }
# TIMEOUT(60) { return undef but reason("timeout") }
... # slow stuff, maybe calls out to 3rd-party code
return ...;
}
The implementation of the TIMEOUT macro proposed a Timer object. It was
_assumed_ that Perl6 would provide a signaling mechanism to allow such timer
objects to be implemented. $SIG{ALRM} probably isn't sufficient -- perhaps
timers will actually be parrot-level concepts. Precisely how such a
mechanism would work is unresolved.
Second, it requires the timeout block to be able to kill off the mainline of
execution, but in a way that cleans up nicely and allows execution to resume
at the caller of the timed-out block. The more general case is that one
thread may wish to inject an exception into another -- again, this assumes
some form of inter-thread signaling machanism.
Dave.
Re: interthread signaling
> "Piers Cawley" <[EMAIL PROTECTED]> wrote
> > Threads and Progress Monitors
> > Dave Whipp had some more thread questions, and wondered what would be
> a
> > good Perl 6ish way of implementing a threaded progress monitor. Whilst
> > the discussion of all this was interesting, I'm not sure that it's
> > really much to do with the language, more something that one would
> > implement according to taste and the particular requirements of a
> given
> > project.
>
> A quick summary of what came out of it:
>
> On the basis that perl makes simple things simple, we drilled down on the
> example of a simple progress monitor. This morphed into the question of how
> to implement a timeout:
>
> sub slow
> {
> TIMEOUT(60) { throw TimeoutException }
> # TIMEOUT(60) { return undef but reason("timeout") }
> ... # slow stuff, maybe calls out to 3rd-party code
> return ...;
> }
>
> The implementation of the TIMEOUT macro proposed a Timer object. It was
> _assumed_ that Perl6 would provide a signaling mechanism to allow such timer
> objects to be implemented. $SIG{ALRM} probably isn't sufficient -- perhaps
> timers will actually be parrot-level concepts. Precisely how such a
> mechanism would work is unresolved.
I think it would fall trivially out of the events mechanism, which is
planned for Parrot.
Luke
> Second, it requires the timeout block to be able to kill off the mainline of
> execution, but in a way that cleans up nicely and allows execution to resume
> at the caller of the timed-out block. The more general case is that one
> thread may wish to inject an exception into another -- again, this assumes
> some form of inter-thread signaling machanism.
>
>
> Dave.
Re: [perl #22353] JIT!
Luke Palmer <[EMAIL PROTECTED]> wrote: > It appears JIT is entirely broken. It broke recently, as it was > working well for me just a couple days ago. > I'm running i686 (P3) Linux, gcc-3.2.2 Have it. I did install gcc 3.3.1 (and a newer gdb). The segfaults are due to new ways how gcc 3 does subroutine calling, or better how gcc does pass subroutine params on the stack (and destroy JITs returns address as it goes). Anyway: please try this procedure (or equivalent): $ make -s # make (silently) parrot $ touch core_ops_cgp.c # touch the relevant file $ make # make again ^C # stop it $ gcc-3.3 -c core_ops_cgp.c -mno-accumulate-outgoing-args ^ # copy and past above command line for making core_ops_cgp.o and # append the marked option $ make -s && make -sC languages/imcc $ IMCC=imcc perl t/harness -j t/*/*.t [ gcc-3.3 is the compiler executable on my system ] So we need (and already did since some time) per file compile settings: - tsq.c does not compile with any optimization - core_ops_cg.c might need no optimization on systems with ~< 100 MB RAM - core_ops_cgp.c needs above flag (except when -Os is given as optimize option) > Luke leo
Re: flushing STDOUT before reading STDIN
Clinton A. Pierce <[EMAIL PROTECTED]> wrote: > A small annoyance, I can't seem to write a good line-input routine as of > very recent changes (synced yesterday, noon). All I'm trying to do is > variations on: > print "? " > readline S0, 0 > And no prompt shows before the readline starts its business. flush 1 HTH leo
[perl #22521] IMCC causes seegfault with many perlarrays and perlhashes
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [perl #22521]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22521 >
I'm not sure what triggers this bug, but I can reliably reproduce it. The
code is *far* too large to list here, but this perl script will generate
the appropriate code in larger and larger samples until it starts
crashing. Adjust as appropriate:
for($s=10; $s<1; $s+=100) {
print "Number: $s\n";
open(IMCC, ">foo.imc") || die;
print IMCC <
Re: Timely object destruction
Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > I'd like to reiterate (and clarify) my idea, of a hybrid scheme > combining refcounting and DoD. I'll try to translate this to parrot speak. I hope that I fully understand your scheme, but lets see. > All values needing timely destruction would inherit from a class > RefCounted. All such variables?! ... have a special vtable and additionally a refcount, where the ... > All operations on a variable or variables having the "is refcounted" > trait result in opcodes to call the refcount(inc|dec) method(s) of the > values in those variables. ... get_val and the set_val part of the value access does inc|dec the refcount: if (--PTimer->refcount == 0) if (PObj_is_referenced(PTimer)) interpreter->need_lazy_dod = 1 else VTABLE_destroy( .. PTimer); > Under normal circumstances, when a refcounted value's refcount goes > to zero, it self destructs^W^W cleans itself up. > To avoid premature cleanup, any time that the contents of a > refcounted variable is assigned to a non-refcounted variable, an opcode > to set a "reachable by non-refcounted variable" flag on the value > precedes the assignment. If a refcounted values's refcount goes to > zero, and it has this flag set, it does NOT self-destruct[*]. set_is_referenced PTimer := PObj_is_referenced_SET(PTimer) set PAgggregate[key], PTimer > A global counter keeps track of how many values have a refcount of zero > and have this flag set. IMHO no counter just a flag, but doesn't matter now. > From here, we are in a similar situation as other proposals -- for the > timeliest possible destruction, then on every single scope exit, we > check if this global counter is nonzero, and if so, do a DoD run. lazysweep # as currently > During the course of a DoD run, when we look for what PMCs are reachable, > we keep track of what each thing was reachable *from*. > If a PMC was found to be reachable through a non-refcounted variable, > then we set a flag saying so. At the end of DoD, every reachable refcounted > value which has the first flag set, but this other flag not set, gets it's > first flag cleared. I think I don't understand the "first & other flag". If a PTimer is e.g. inside an aggregate (i.e. reachable through non-refcounted) the live_FLAG of the PTimer gets set and it will not get destroyed. If during the DOD run the PTimer is not referenced it will have the live_FLAG cleared and will be destroyed. If there are any objects with a refcount live after a DOD run, we set again the interpreter->need_lazy_dod flag. leo
Re: [perl #22521] IMCC causes seegfault with many perlarrays and perlhashes
Clinton A. Pierce <[EMAIL PROTECTED]> wrote: > # New Ticket Created by "Clinton A. Pierce" > # Please include the string: [perl #22521] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=22521 > > I'm not sure what triggers this bug, ... but gdb knows it ;-) Thanks for the bug report, fixed. leo
[perl #22535] [PATCH] use PIO_eprintf instead of PIO_fprintf(PIO_STDERR)
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #22535]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22535 >
Hi,
In many places in the code we use the idiom
PIO_fprintf(interpreter, PIO_STDERR(interpreter), ...);
But there is a function for doing exactly this
PIO_eprintf(interpreter, ...);
This may be slightly more optimal, but the main reason for this change
is to make changes in the io-code more maintainable.
bye
boe
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/58661/43655/54bbb2/eprintf.diff
Index: debug.c
===
RCS file: /cvs/public/parrot/debug.c,v
retrieving revision 1.77
diff -u -r1.77 debug.c
--- debug.c 27 May 2003 18:06:48 - 1.77
+++ debug.c 2 Jun 2003 22:12:34 -
@@ -639,7 +639,7 @@
/* Don't do anything if there is already a breakpoint at this line */
if (sbreak && sbreak->skip > -1) {
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),
+PIO_eprintf(interpreter,
"Breakpoint %li already at line %li\n",i,line->number);
return;
}
@@ -708,7 +708,7 @@
pdb->breakpoint = newbreak;
}
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Breakpoint %li at line %li\n",i,line->number);
+PIO_eprintf(interpreter, "Breakpoint %li at line %li\n",i,line->number);
}
/* PDB_init
@@ -754,7 +754,7 @@
/* Restart if we are already running */
if (pdb->state & PDB_RUNNING)
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Restarting\n");
+PIO_eprintf(interpreter, "Restarting\n");
/* Get the bytecode start */
pdb->cur_opcode = interpreter->code->byte_code;
@@ -775,7 +775,7 @@
/* Skip any breakpoint? */
if (command && *command) {
if (!pdb->breakpoint) {
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"No breakpoints to skip\n");
+PIO_eprintf(interpreter, "No breakpoints to skip\n");
return;
}
ln = atol(command);
@@ -873,7 +873,7 @@
/* Remove the RUNNING state */
pdb->state &= ~PDB_RUNNING;
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Program exited.\n");
+PIO_eprintf(interpreter, "Program exited.\n");
return 1;
}
@@ -1385,7 +1385,7 @@
pline = pline->next;
if (!(pline)) {
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Label number %li out of bounds.\n",label->number);
+PIO_eprintf(interpreter, "Label number %li out of bounds.\n",label->number);
return;
}
@@ -1492,7 +1492,7 @@
/* abort if fopen failed */
if (!file) {
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Unable to load %s\n", f);
+PIO_eprintf(interpreter, "Unable to load %s\n", f);
return;
}
@@ -1609,14 +1609,14 @@
i = 1;
while (line->next) {
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"%li ",pdb->file->list_line + i);
+PIO_eprintf(interpreter, "%li ",pdb->file->list_line + i);
/* If it has a label print it */
if (line->label)
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"L%li:\t",line->label->number);
+PIO_eprintf(interpreter, "L%li:\t",line->label->number);
c = pdb->file->source + line->source_offset;
while (*c != '\n')
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"%c",*(c++));
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"\n");
+PIO_eprintf(interpreter, "%c",*(c++));
+PIO_eprintf(interpreter, "\n");
line = line->next;
if (i++ == n)
break;
@@ -1798,7 +1798,7 @@
PDB_print_stack_pmc(interpreter, command);
break;
default:
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Unknown argument \"%s\" to 'stack'\n", command);
+PIO_eprintf(interpreter, "Unknown argument \"%s\" to 'stack'\n", command);
break;
}
}
@@ -1817,11 +1817,12 @@
if (!chunk) {
i = depth / FRAMES_PER_INT_REG_CHUNK;
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"There are only %li frames\n",i);
+PIO_eprintf(interpreter, "There are only %li frames\n",i);
return;
}
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"Integer stack, frame %li, depth %li\n", i, depth);
+PIO_eprintf(interpreter, "Integer stack, frame %li, depth %li\n",
+i, depth);
na(command);
PDB_print_int(interpreter, &chunk->IReg[depth], atoi(command));
@@ -1840,11 +1841,11 @@
if (!chunk) {
i = depth / FRAMES_PER_NUM_REG_CHUNK;
-PIO_fprintf(interpreter, PIO_STDERR(interpreter),"There are only %li frames\n",i);
+PIO_eprintf(interpreter, "There
win32 and test_mail.c
Hello.
MSVC stumble over
static struct longopt_opt_decl options[] = {
.
{'\0', 128, 0, { "--gc-debug" } },
{'\0', 0, 0, { } }
}
Рlease, replace it by
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.66
diff -r1.66 test_main.c
36c36
< {'\0', 0, 0, { } }
---
> {'\0', 0, 0, { "" } }
or as you find convenient.
Nick.
P.S.
I didn't find Ticket about it.
Sorry to trouble you if it present.
Re: win32 and test_mail.c
> Hello.
>
> MSVC stumble over
>
> static struct longopt_opt_decl options[] = {
> .
> {'\0', 128, 0, { "--gc-debug" } },
> {'\0', 0, 0, { } }
> }
>
> Рlease, replace it by
>
> RCS file: /cvs/public/parrot/test_main.c,v
> retrieving revision 1.66
> diff -r1.66 test_main.c
> 36c36
> < {'\0', 0, 0, { } }
> ---
> > {'\0', 0, 0, { "" } }
>
> or as you find convenient.
It doesn't really matter for this last entry, but make it NULL
instead. In imcc's main.c, there's two entries with a { } that should
be replaced with { NULL }, too.
So now we have:
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.66
diff -u -r1.66 test_main.c
--- test_main.c 2 Jun 2003 08:52:41 - 1.66
+++ test_main.c 3 Jun 2003 12:23:07 -
@@ -33,7 +33,7 @@
{ 'v', 'v', 0, { "--version" } },
{ '.', '.', 0, { "--wait" } },
{'\0', 128, 0, { "--gc-debug" } },
-{'\0', 0, 0, { } }
+{'\0', 0, 0, { NULL } }
};
static void usage(void);
Index: languages/imcc/main.c
===
RCS file: /cvs/public/parrot/languages/imcc/main.c,v
retrieving revision 1.25
diff -u -r1.25 main.c
--- languages/imcc/main.c 2 Jun 2003 08:52:27 - 1.25
+++ languages/imcc/main.c 3 Jun 2003 12:23:07 -
@@ -85,7 +85,7 @@
{ 'd', 'd', OPTION_required_FLAG, { "--debug" } },
{ 'w', 'w', 0, { "--warnings" } },
{ 'G', 'G', 0, { "--no-gc" } },
-{ '.', '.', 0, { } },
+{ '.', '.', 0, { NULL } },
{ 'a', 'a', 0, { "--pasm" } },
{ 'h', 'h', 0, { "--help" } },
{ 'V', 'V', 0, { "--version" } },
@@ -96,7 +96,7 @@
{ 'o', 'o', OPTION_required_FLAG, { "--output" } },
{ 'O', 'O', OPTION_required_FLAG, { "--optimize" } },
{ OPT_GC_DEBUG, '\0', 0, { "--gc-debug" } },
-{ 0, 0, 0, { } }
+{ 0, 0, 0, { NULL } }
};
/* most stolen from test_main.c */
Re: Make mine SuperSized....
On Tue, 2003-06-03 at 03:54, Henrik Tougaard wrote: > On Sat, May 31, 2003 at 09:54:45AM -0400, Bryan C. Warnock wrote: > [snip] Part of what was snipped was this line: (For the sake of using real numbers, I'll assume 32/64.) > > Currently, the flow is, in variable sizes: > > > > Opcodes: 32 (constants are limited by the spec) > > PMCs : 64 > > Regs : 64 > > Guts : 64/32 mix > > System : 32 > > > [snip] > > The flow *really* is, in value sizes: > > > > Opcodes: 32 (constants are limited by the spec) > > PMCs : 64 > > Regs : 32 > > Guts : 32 > > System : 32 > [snip] > You seem to forget that there *are* systems out there that have a native 64-bit > integer size (and a heavy penalty > for handling 32-bit ints). Even the pointer size *has* to be 64 bits - the system I > write this on has 6 GB of > memory installed, so a 32 bit pointer is just useless. I have forgotten nothing.[1] I simply got tired of talking in the abstract. The above also holds true for 64/128. (Well, except that opcode values are still limited to 32-bits, but padded in a 64-bit construct. I believe this was reiterated in the thread that followed with Gopal V, but I'll try to clarify here. (I don't always convey my messages clearly.) This is *not* a proposal that Parrot should be 32 bit. This *is* a suggestion that the Parrot core should *not* be built around types wider than the underlying physical hardware is. > So even the 'System' size must be 64-bits, as > size_t is an unsigned long (and therefor 8 bits. And that's right in line with what I was saying. Don't get wrapped up in the numbers. They were just an example. [1] Actually, I'm sure I've forgotten a lot, which it why I'm posted this for comments and criticism. But I haven't forgotten about 64 bit platforms, which is my platform of predominant use. That would be rather short-sighted, even for me. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Register allocation bug in IMCC? Or misunderstanding on my part?
At 11:10 PM 6/1/2003 -0400, Uri Guttman wrote: why don't you manage your own basic call stack in an array or PerlArray or something? trying to map that mess of call/return poo onto a proper compiler with register allocation is going to lose us the services of leo while he recuperates at the hospital for homicidal BASIC coders. Naw. I'm not homocidal. Suicidal with a masochistic bent, that's all. And I don't think I've ever asked for anything from the Parrot team other than opinions on honest-to-goodness bugs or understanding of some area of how to target this platform. Hope no-one's going to need a pshrink after this. I only ask odd questions because sometimes I'm dealing with odd things. Like programs that are essentially one big compilation unit -- almost, and doing odd things with bsr/ret... you will just have to bite the bullet and emulate your own virtual engine over parrot and not try to map BASIC directly to it. so code a VM with BASIC flow control. you can probably do something odd like make each BASIC statement into a parrot sub. then just compile your basic into a simple flow control IL that just calls parrot subs. the subs all have access to your need globals (with the obvious find_global/set_global :) a primary global now is the BASIC VM PC. As far as I know, BASIC only gets weird with flow control in two places. One is 'RETURN X', another is computed goto 'goto X'. The former I'm handling be wrapping bsr/ret with a little bit of code (after each bsr, the code asks "was the ret destined for me or not?"). The latter is handled by a table inserted into the code mapping the compile-time labels over to runtime destinations. So that: branch USERLABEL_100# Normal goto USERLABEL_100: # Expression, etc... result in $S0 branch COMPUTED_GOTO COMPUTED_GOTO: eq $S0, "USERLABEL_10", USERLABEL_10 eq $S0, "USERLABEL_20", USERLABEL_20 etc... print "Label " print $S0 print " does not exist at line " print BASICLINE end And the COMPUTED_GOTO jumptable gets inserted in the code only if the program does something stupid like a computed goto. BASIC compilers/interpreters have always felt free to punish the programmer with space/speed tradeoffs for programmer laziness. feel free to tell me this is total cocky-pop. :) In the first incarnation (04/2002) the Parrot VM (pre-PerlHashes mind you) was an inconvenience and BASIC essentially was inside it's own little VM on top of this odd processor. I'd like to exercise as many the facilities available to me now for speed and whatnot. This re-targeting from PASM to PIR is much easier than the original PASM port to begin with.
Re: Register access
"Sean O'Rourke" <[EMAIL PROTECTED]> writes: > On 30 May 2003, Bryan C. Warnock wrote: >> Ha ha, just kidding, of course. I'm all for it, but given my record >> today, that might be an imminent sign of its rejection. > > Or, given your historical record, you may have just killed the thread ;). Threads die when one of two things happen: 1. Someone compares someone/thing/group unfavourably to Hitler. At this point the signal/noise ratio of the thread approaches 0. This is known as Godwin's Law. 2. Bryan C. Warnock says something, at which point everyone else in the thread declines to comment, helping to increase Bryan's level of paranoia whilst leaving him forever stuck on the horns of his own Dilemma. Personally, whilst 2. is potentially funny, I don't think it's necessarily a good idea. It's a bit like the whole "I know, when John Glenn lands on the shuttle, everyone should be wearing monkey masks..." thing. -- Piers
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030601 Another Monday, another Perl 6 Summary. Does this man never take a holiday? (Yes, but only to go to Perl conferences this year, how did that happen?) We start with the internals list as usual. More on timely destruction The discussion of how to get timely destruction with Parrot's Garbage Collection system continued. Last week Dan announced that, for languages that make commitments to call destructors as soon as a thing goes out of scope, there would be a set of helpful ops to allow languages to trigger conditional DOD (Dead Object Detection) runs at appropriate times. People weren't desperately keen on the performance hit that this entails (though the performance hit involved with reference counting is pretty substantial...) but we didn't manage to come up with a better solution to the issue. http://xrl.us/iu5 Bryan C. Warnock, patchmonster of the week Bryan C. Warnock seems to be attempting to outdo Leo Tötsch in the patchmonster stakes this week. He put in a miscellany of patches dealing with the Perl based assembler, opcode sizes, debugging flags and probably others. Most of them were applied with alacrity. The Perl 6 Essentials book Dan Sugalski gave a rundown of how the Perl 6 Essentials book came about, what's in it and all that jazz. He started by apologizing for not mentioning it before, but he thought he had. This led Clint Pierce to wonder if there was something up with Dan's Garbage Collection system. The existence of the book probably goes some way to explaining Leo Tötsch's relative silence over the last few weeks. Nicholas Clark wondered if it explains why Parrot doesn't have objects yet. Brent Dax wondered when it would be available (by OSCON this year apparently). http://xrl.us/iu6 IMCC, PASM and constants/macros Clint Pierce had some big headaches with moving his BASIC interpreter over to IMCC owing to problems with ".constant" which is legal for the assembler, but not for IMCC. Leo Tötsch pointed Clint at IMCC's ".const" operator. Bryan Warnock wondered if IMCC and the assembler's syntax couldn't be unified. Leo noted that it wasn't quite that straightforward because ".constant" declares an untyped constant, but ".const" requires a type as well. It turns out that ".const" wasn't quite what Clint needed, so Leo pointed him at ".sym" and ".local" which do seem to do what he needs. http://xrl.us/iu7 3-arg opens Bryan Warnock wondered if open I3, "temp.file", "r" was valid code. Answer, no, the right way to do it is the Perlish "open I3, "temp.file", "<"". Jürgen Bömmels promised more and better documentation for the Parrot IO system. Eventually. http://xrl.us/iu8 Smaller PMCs Leo Tötsch's work on the new PMC layout continues apace. I'm afraid I don't quite understand what's going on in this area, which does make it rather tricky to summarize things. It seems to have a good deal to do with memory allocation and garbage collection... Leo thinks that it's the right thing, but there seem to be issues involved with good ways of allocating zeroed memory. http://xrl.us/ijt An experimental Wiki for parrot development Mitchell N Charity has put up an experimental Wiki for Parrot and primed it with a few things. Stéphane Payrard pointed out that it's rather hard to make a WikiWord from, for example, PMC. (10 points to the first person to email [EMAIL PROTECTED] with the expansion of PMC). http://xrl.us/iu9 IMCC packfile bug While toying with pbc2c.pl, Luke Palmer discovered that it doesn't want to play with IMCC generated .pbc files. Apparently this is because we currently have two bytecode file formats. Leo Tötsch thought the problem lay with assemble.pl which is old and slow and doesn't produce 'proper' parrot bytecode. Leo also thought that the way pbc2c.pl worked wasn't actually any use. Dan reckoned the time had come to ditch assemble.pl too, and reckoned there was a case for renaming IMCC as parrot since it can run either .pbc or assembly files. Leo liked the idea, but is concerned about the state of the Tinderbox. http://xrl.us/iva Method Calling Dan tantalized all those waiting eagerly for objects in Parrot by discussing how to make method calls. This, of course, means a few new ops, called "findmeth", "callmeth" and "callccmeth" for the time being. Jonathan Sillito had a few naming consistency issues with the ops. Dan agreed there were issues and asked for suggestions for an opcode naming convention. http://xrl.us/ivb Simple Constant Propagation in IMCC Matt Fowles posted a patch to add simple constant propagation to IMCC. Essentially this means that, say set I0, 5 set I1, 2 set I2, I1
