Re: Printing literal "\0" in parrot
At 6:47 PM +0200 5/15/02, Joe Yates wrote: >Dear all, > >I'm trying to print the following string: > > \0 > >I.e. the output of the perl instruction > > print "\\0"; > >See attached test. > >It's getting treated as a string terminator. > >Am I escaping incorrectly, or is it incorrect treatment of "\0" at some point? Incorrect treatment of nulls. We're using printf at the moment to print. That'll change when the I/O system's fully in place. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: gcc vs ICC comparison
At 8:41 PM +0300 5/15/02, [EMAIL PROTECTED] wrote: >Does Parrot compile on ICC , if yes is it faster ? I don't know that anyone's tried. Care to download it and take a shot? (I don't have the free disk space on my Linux box at the moment) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: From the Too Much Time on My Hands Department...
At 2:49 PM -0700 5/15/02, Tony Payne wrote: >Towers of Hanoi in parrot assembler. Feel free to use it as an example, >or just as a test-case for PerlArrays. Added to the repository. Thanks! -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [netlabs #590] Can't Print the Sequence slash + zero
At 1:38 PM + 5/16/02, Joe Yates (via RT) wrote: ># New Ticket Created by Joe Yates ># Please include the string: [netlabs #590] ># in the subject line of all future correspondence about this issue. ># http://bugs6.perl.org/rt2/Ticket/Display.html?id=590 > > > >Dear all, > >In parrot code, I'm trying to print the following string: > > \0 > >I.e. the output of the perl instruction > > print "\\0"; > >It's getting treated as a string terminator. > >See attached test. > >Am I escaping incorrectly, or is it incorrect treatment of "\0" at some point? We're using printf to print, so it's taking the null as a string terminator. This'll be fixed when we've got the Parrot IO support rolled out. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [COMMIT] Embedding overhaul
At 1:14 PM -0700 5/15/02, Brent Dax wrote: >Dan Sugalski: ># At 12:51 AM -0700 5/15/02, Brent Dax wrote: ># >-Parrot becomes Parrot_Interp ># >-Parrot_String is gone and the string_funcs.h functions are ># no longer ># >externally visible. -A few structures have been renamed. ># >-config.h has been rearranged so that INTVAL, etc. are now ># aliases for ># >Parrot_Int, etc. ># >-A few things that were accidentally made external no longer are. ># ># This isn't a problem with config.h. config.h should *never* be used ># by anyone embedding Parrot, either directly or indirectly. > >Why not? Some parts of Parrot's embedding system have to be set up by >Configure. And those parts should go in embed.h. The bare minimum amount of stuff should go in there--the definitions of INTVAL, NUMVAL, Buffer, STRING (maybe), and the exported functions. A later phase of the build could probably set this up as well, as it'd have access to more information. Stuff like PMC definitions shouldn't go in it. PMC * should be typedef'd to void * in the embedding header. ># >I first noticed the problems with computed-goto when I found the ># >following line in test_main.c: ># > ># >#ifdef HAVE_COMPUTED_GOTO ># > ># >See the problem? ># ># Yes. test_main.c should never have to know about computed goto cores ># or whatnot. The define's likely something generally passed on the ># command line to all the parrot core bits, > >True. Still, the idea of a define like this not being fixed somewhere >scares me a bit. If someone tries to send us a copy of their config.h >so we can debug a problem, we can't tell if they have cgoto enabled. That's definitely a problem. That #define should be in config.h, and *is* a problem. >Actually, it should know that Parrot may support a computed-goto core >and the flag to enable it is X. It shouldn't have to know if this >particular copy of Parrot is built with that capability. (It probably >should be able to detect it, however, so that it can handle cases like >the one in test_main's -h handler.) Flag handling, or at least feature enabling, should probably be done by core code. We should provide a set_feature() function ># test_main.c should only use "parrot/embed.h", which shouldn't include ># any Parrot .h files > >I'm including three: > >-parrot/interpreter.h, which provides a forward definition of struct >Parrot_Interp and a full definition of enum Parrot_Interp_flag. We should have a typedef for Parrot_Interp to void * for embedders. >-parrot/warnings.h, which provides warning classes. Hrm, good point. >-parrot/config.h, which provides data like what a Parrot_Int (INTVAL) is >and what version of Parrot this is. > >All three are specifically crafted to expose as little as possible. >(Well, maybe not config.h, but it doesn't expose anything that isn't >prefixed. I should probably move most of the JIT stuff out of the >interface. In fact, I'll do that right now.) Cool. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Test op/stacks:29 dying.
At 4:19 PM -0400 5/15/02, Kevin Falcone wrote: > > "BD" == Brent Dax <[EMAIL PROTECTED]> writes: > >BD> Chris Ball: >BD> # (Note: My first attempt at this message bounced from >BD> # onion.perl.org, which is why it's going to p6i. Reported to >BD> # [EMAIL PROTECTED], who's looking into it.) >BD> # == >BD> # Seems to be cross-x86, if not global. >BD> # >BD> # t/op/stacks.ok 28/29#Failed test (t/op/stacks.t >BD> # at line 592) >BD> # # got: '' >BD> # # expected: '43210-1 >BD> # # ' >BD> # # Looks like you failed 1 tests of 29. t/op/stacks.dubious >BD> #Test returned status 1 (wstat 256, 0x100) >BD> # DIED. FAILED test 29 >BD> #Failed 1/29 tests, 96.55% okay (-1 skipped test: 27 >BD> # okay, 93.10%) > >BD> Argh, it works fine on Windows, but even Cygwin breaks. I wrote the >BD> code and the test, but I can't debug a problem that only appears on >BD> Unix. > >Don't blame Unix. It actually works without the end on NetBSD on a >sparc :) It's a memory allocator issue, and it'll randomly segfault places. Depends, more than anything else, on whether the word immediately past the end of the memory allocated for the code is 0 or not. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More memory management changes
At 9:53 PM +0200 5/15/02, Peter Gibbs wrote: >The attached patch is the next set of proposed changes to the memory >management routines, with the copy-on-write logic removed. Peter, did these go in? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Where to put #ifs
At 2:27 PM -0400 5/16/02, Melvin Smith wrote: >If we are not to put non-embed visible in config.h, we must >pre-process parrot.h, because I need to put symbls such as >EXP_NETWORKING somewhere. Put anything that alters how Parrot works in config.h. It won't ultimately be included by embedders. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: CVS Access
At 12:45 PM -0500 5/16/02, David M. Lloyd wrote: >Is CVS access for Parrot still invitation-only? If not, I would like to >request CVS access. I have posted mildly useful patches (mostly warning >fixes really) in the past; I don't think any have ever been rejected. > >The CVS page at dev.perl.org/cvs implies that a maintainer (probably Dan I >guess) would have to grant this access one way or another. Generally either I or the current pumpkin holder, in this case Jeff Goff, throw a request at the CVS maintainers for access. >With an actual CVS account maybe I'll feel obligated to contribute more >often. ;-) Promise? :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Perl6 currying
Hi,
I was reading Damian's new excellent diary entry in which he explains the
new currying syntax for Perl6.
(For the lazy ones it's reachable at
http://www.yetanother.org/damian/diary_latest.html)
This new feature allows to partially fill place-holder functions, such as:
my &div = {$^x / $^y};
my &half= &div(y=>2};
print half(6); # 3
This is a very neat feature, and very useful, as it's explained very well on
Damian's page.
But I am not sure I like the syntax. The problems I see are:
- You only can curry placeholder-generated functions. So if you intend to
make a function curryiable, you are forced to use place-holders, even if
that's not the cleanest way of programming it.
- This means that the creator of a function needs to impose a policy on
whether he expects the function users to use currying or not. A module
creator and user could have different point of views about it, creating
unnecessary conflict between the human race.
- From the caller point of view, the only distinction between a function
call and a currying pseudo-call, is the number of parameters.
div(6,3) # is a function call
div(6)# creates a new curryied function
So, in order to see if a expression is a function call or a magic currying,
you need to count (!) the number of parameters, without any visual clue
suggesting it.
- You cannot use advanced perl 6 features (like optional strict typing, or
default values for function parameters), on curryiable functions.
I would instead propose that every function object supports a "curry"
method, that performs such operation.
For example:
sub div($x,$y) {$x / $y}; # of &div = {$^x / $^y}
my &half = &div.curry(y=>2);
print half(6); # 3
This solves the unnecessary placeholder-currying marriage, and it is
certainly a more explicit syntax.
Incidentally, a newbie user would learn that there is a curry method being
called, and could google "curry perl" and even find some useful docs.
(In my humble opinion, this is something that is too many times forgotten in
the perl world. With the ultra-compact, idiomatic syntax, it is __very__
hard to learn perl the google way).
What do you think about it?
-angel
Re: More memory management changes
On Sat, May 18, 2002 at 12:18:14PM -0400, Dan Sugalski wrote: > At 9:53 PM +0200 5/15/02, Peter Gibbs wrote: > >The attached patch is the next set of proposed changes to the memory > >management routines, with the copy-on-write logic removed. > > Peter, did these go in? I don't think so, and I don't have time to properly test at the moment. But on a related note, what's the status of allowing the COW stuff in? Peter has done some benchmarking (not much but more than people do for anything else) and has so far only shown speedups. (And I've been writing perl5 code recently that would have been much simpler if I knew the core was doing COW so I didn't have to worry about several useless tens-of-MB copies per operation.) Essentially, what benchmarking or other legwork needs to be done to get COW in?
Re: More memory management changes
At 10:29 AM -0700 5/18/02, Steve Fink wrote: >On Sat, May 18, 2002 at 12:18:14PM -0400, Dan Sugalski wrote: >> At 9:53 PM +0200 5/15/02, Peter Gibbs wrote: >> >The attached patch is the next set of proposed changes to the memory >> >management routines, with the copy-on-write logic removed. >> >> Peter, did these go in? > >I don't think so, and I don't have time to properly test at the >moment. > >But on a related note, what's the status of allowing the COW stuff in? >Peter has done some benchmarking (not much but more than people do for >anything else) and has so far only shown speedups. If COW speeds things up in a normal case, and is essentially transparent to user code, I say go for it and put it in. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl6 currying
On Sat, 18 May 2002, Angel Faus wrote:
> ...curry example...
> But I am not sure I like the syntax. The problems I see are:
>
> - You only can curry placeholder-generated functions. So if you intend to
> make a function curryiable, you are forced to use place-holders, even if
> that's not the cleanest way of programming it.
I never read that. It seemed to me like you could curry just about any
function you please.
> - From the caller point of view, the only distinction between a function
> call and a currying pseudo-call, is the number of parameters.
>
>div(6,3) # is a function call
>div(6)# creates a new curryied function
>
> So, in order to see if a expression is a function call or a magic currying,
> you need to count (!) the number of parameters, without any visual clue
> suggesting it.
Very true. This is a mega-gotcha that should somehow be dealt with. In
classic Perl, it would warn you about not enough arguments, but in Perl6
it generates a curried function call? So I could say:
print foo(2,3);
And if foo was in fact expecting three arguments and I was just
brain-farting it would print some serialization of this? Or what? This
doesn't make a lot of sense.
> - You cannot use advanced perl 6 features (like optional strict typing, or
> default values for function parameters), on curryiable functions.
Good point.
> I would instead propose that every function object supports a "curry"
> method, that performs such operation.
>
> For example:
>
> sub div($x,$y) {$x / $y}; # of &div = {$^x / $^y}
>
> my &half = &div.curry(y=>2);
> print half(6); # 3
>
> This solves the unnecessary placeholder-currying marriage, and it is
> certainly a more explicit syntax.
I like it. Initially I was thinking a new "curry" operator (hmm... &$@!
perhaps? :), but I think we're just about out of characters for that.
Plus, with Perl6's OO design, C<.curry> fits well.
Perhaps if it's generated with placeholders, the C<.curry> would be
implicit. That way we can stay terse when the situation is simple. Like
with Damian's C...C example. When I'm writing scripts, I
don't want to type those 6 characters, but if I'm doing structured
programming, the clearer the better. To parallel this, when I'm writing
scripts, I'm going to use placeholder functions, but in structured
programming, I'm probably not.
Luke
Re: Perl6 currying
Angel Faus writes:
: Hi,
:
: I was reading Damian's new excellent diary entry in which he explains the
: new currying syntax for Perl6.
:
: (For the lazy ones it's reachable at
: http://www.yetanother.org/damian/diary_latest.html)
:
: This new feature allows to partially fill place-holder functions, such as:
:
: my &div = {$^x / $^y};
:
: my &half= &div(y=>2};
: print half(6); # 3
:
: This is a very neat feature, and very useful, as it's explained very well on
: Damian's page.
:
: But I am not sure I like the syntax. The problems I see are:
:
: - You only can curry placeholder-generated functions. So if you intend to
: make a function curryiable, you are forced to use place-holders, even if
: that's not the cleanest way of programming it.
I think that if you use an explicit signature, the declared variable
$^a is really just $a, so you wouldn't have to have arrows all over
the body of your function.
: - This means that the creator of a function needs to impose a policy on
: whether he expects the function users to use currying or not. A module
: creator and user could have different point of views about it, creating
: unnecessary conflict between the human race.
Well, yes, as I've been telling people (and as you point out below), we
need the policy anyway if we're going to support defaults. But yes,
there could certainly be difference of opinion between the creater and
the usor.
: - From the caller point of view, the only distinction between a function
: call and a currying pseudo-call, is the number of parameters.
:
:div(6,3) # is a function call
:div(6)# creates a new curryied function
:
: So, in order to see if a expression is a function call or a magic currying,
: you need to count (!) the number of parameters, without any visual clue
: suggesting it.
:
: - You cannot use advanced perl 6 features (like optional strict typing, or
: default values for function parameters), on curryiable functions.
There is the additional problem that you have a function returning a
completely different type (unrelated to its declared return type, if
any) depending on the argument count.
: I would instead propose that every function object supports a "curry"
: method, that performs such operation.
:
: For example:
:
: sub div($x,$y) {$x / $y}; # of &div = {$^x / $^y}
:
: my &half = &div.curry(y=>2);
: print half(6); # 3
:
: This solves the unnecessary placeholder-currying marriage, and it is
: certainly a more explicit syntax.
Yes, I've been wondering myself whether there ought to be some way
for the caller to override the prefs of the declaration with respect
to currying. Though it's possible that there's some overhead in making
any function curriable, since you essentially have to keep the original
template around in order to instantiantiate it whichever way. Imagine
if every function in C++ were really a generic on every parameter...
: Incidentally, a newbie user would learn that there is a curry method being
: called, and could google "curry perl" and even find some useful docs.
:
: (In my humble opinion, this is something that is too many times forgotten in
: the perl world. With the ultra-compact, idiomatic syntax, it is __very__
: hard to learn perl the google way).
I think that's a very valid point. I lucked out by naming Perl with
a word that wasn't a word. It's harder to search for Ruby.
: What do you think about it?
My one quibble with your proposal is that I think we still need
self-declaring, self-ordering parameters, and it could be argued that
if they exist they might as well curry automatically. Though perhaps
good style would dictate use of the curry method anyway. Certainly it
can also be argued that currying is not going to happen often enough in
stock Perl that it needs that ultimate in Huffman coding, the null
operator.
If we're going to make it a method, however, it's possible that "curry"
is the wrong popular name, despite its being the correct technical name.
There's really nothing about the word "curry" that suggest partial
binding to the casual reader. Perhaps we really want something like:
my &half = &div.prebind(y => 2);
or:
my &half = &div.rewrite(y => 2);
or even:
my &half = &div.assume(y => 2);
I think I like that last one the best. Maybe it would read better as
"assuming". But that's getting a bit long for Mr Huffman. Maybe it's
finally time to reach into our bag of English topicalizers and pull out
"with":
my &half = &div.with(y => 2);
Larry
Re: Perl6 currying
3uke Palmer writes: : Perhaps if it's generated with placeholders, the C<.curry> would be : implicit. That way we can stay terse when the situation is simple. Like : with Damian's C...C example. When I'm writing scripts, I : don't want to type those 6 characters, but if I'm doing structured : programming, the clearer the better. To parallel this, when I'm writing : scripts, I'm going to use placeholder functions, but in structured : programming, I'm probably not. I don't think the switch example is actually currying. It's really just using a self-declared parameter, which the switch statement is smart enough to feed the proper "other" argument to. Offhand I don't see a generalization of it that would let us pass in fancier curries usefully--it's got to resolve to a function that has a boolean result. What would a switch (or a C<=~> for that matter) do with a two-argument curry? And is that red, yellow, or green curry? Larry
Re: More memory management changes
The COW patch has been revised for minimal impact to the outside world. The only files changed are: resources.h, resources.c, string.h, string.c There is one API change: Parrot_reallocate_string has an additional parameter. However, nobody outside string.c really has any business calling that anyway; and currently nobody else does. The STRING structure has one change: a new field, void *buffer, points to the start of the physical buffer allocation. I tested a version that eliminated this requirement, by placing the allocated buffer length in the string tail; but this made the code in compact_string_pool very cumbersome, and the performance was several percent slower than my current implementation. Once the latest memory management patch is in, I will resync and submit the COW code as a separate patch, and we'll see what everybody thinks about it. I have just done a benchmark using Melvin's reverse.cola program. Reversing string.c went from 3.42 user seconds down to 3.12 with the COW patch; while reversing core_ops.c went from 94.39 to 92.26. Since this program does a large amount of stack manipulation, I suspect that the much smaller percentage improvement achieved on the larger file is due to stack overhead - I haven't had a change to profile it yet, but I will do as soon as I can. Unrelated subject: I see that Steve has modified string.c to get around the problem with the temporary transcoded strings - I believe we need to finalise a standard way of handling these situations soon. If anybody is interested, I will resync my previous 'neonate' patch - it needs a bit of work to fit with the latest changes to resources.c -- Peter Gibbs EmKel Systems
RE: [COMMIT] Embedding overhaul
Dan Sugalski:
# At 1:14 PM -0700 5/15/02, Brent Dax wrote:
# >Dan Sugalski:
# ># At 12:51 AM -0700 5/15/02, Brent Dax wrote:
# ># >-Parrot becomes Parrot_Interp
# ># >-Parrot_String is gone and the string_funcs.h functions are # no
# >longer # >externally visible. -A few structures have been renamed.
# ># >-config.h has been rearranged so that INTVAL, etc. are now
# ># aliases for
# ># >Parrot_Int, etc.
# ># >-A few things that were accidentally made external no longer are.
# >#
# ># This isn't a problem with config.h. config.h should *never* be used
# ># by anyone embedding Parrot, either directly or indirectly.
# >
# >Why not? Some parts of Parrot's embedding system have to be
# set up by
# >Configure.
#
# And those parts should go in embed.h. The bare minimum amount of
# stuff should go in there--the definitions of INTVAL, NUMVAL, Buffer,
# STRING (maybe), and the exported functions. A later phase of the
# build could probably set this up as well, as it'd have access to more
# information.
I'm trying to keep the number of dynamically-generated files to a
minimum. We don't lose anything by defining a small part of config.h
that's external, and we gain a static embed.h.
# Stuff like PMC definitions shouldn't go in it. PMC * should be
# typedef'd to void * in the embedding header.
What I do is declare things like
struct parrot_pmc_t;
typedef struct parrot_pmc_t* Parrot_PMC;
So we don't get warnings about type mismatches when we compile embed.c.
Actually, Parrot_PMC won't be in embed.h directly--it'll be in extern.h,
which defines the interface between the outside world and PMCs and
STRINGs. (I'm planning for extenders to use the same interface, which
is why it's in a separate header. embed.h will probably include
extern.h, so it'll be transparent to the user.)
# ># >I first noticed the problems with computed-goto when I
# found the #
# >>following line in test_main.c: # >
# ># > #ifdef HAVE_COMPUTED_GOTO
# ># >
# ># >See the problem?
# >#
# ># Yes. test_main.c should never have to know about computed
# goto cores
# ># or whatnot. The define's likely something generally passed on the
# ># command line to all the parrot core bits,
# >
# >True. Still, the idea of a define like this not being fixed
# somewhere
# >scares me a bit. If someone tries to send us a copy of
# their config.h
# >so we can debug a problem, we can't tell if they have cgoto enabled.
#
# That's definitely a problem. That #define should be in config.h, and
# *is* a problem.
Actually, the JIT does the same thing, so it's not *entirely* his fault.
# >Actually, it should know that Parrot may support a
# computed-goto core
# >and the flag to enable it is X. It shouldn't have to know if this
# >particular copy of Parrot is built with that capability.
# (It probably
# >should be able to detect it, however, so that it can handle
# cases like
# >the one in test_main's -h handler.)
#
# Flag handling, or at least feature enabling, should probably be done
# by core code. We should provide a set_feature() function
Right now we have something like this:
Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL);
I'm not sure how Parrot reacts to that if computed goto isn't available
on this platform, though.
# ># test_main.c should only use "parrot/embed.h", which
# shouldn't include
# ># any Parrot .h files
# >
# >I'm including three:
# >
# >-parrot/interpreter.h, which provides a forward definition of struct
# >Parrot_Interp and a full definition of enum Parrot_Interp_flag.
#
# We should have a typedef for Parrot_Interp to void * for embedders.
Right now we have a forward declaration of struct Parrot_Interp and a
typedef. The actual body of struct Parrot_Interp is private.
struct Parrot_Interp;
typedef struct Parrot_Interp * Parrot_Interp;
...
#ifdef PARROT_IN_CORE
...
typedef struct Parrot_Interp {
...
} Interp;
...
#endif
# >-parrot/warnings.h, which provides warning classes.
#
# Hrm, good point.
#
# >-parrot/config.h, which provides data like what a Parrot_Int
# (INTVAL)
# >is and what version of Parrot this is.
# >
# >All three are specifically crafted to expose as little as possible.
# >(Well, maybe not config.h, but it doesn't expose anything that isn't
# >prefixed. I should probably move most of the JIT stuff out of the
# >interface. In fact, I'll do that right now.)
#
# Cool.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [COMMIT] Embedding overhaul
At 3:16 PM -0700 5/18/02, Brent Dax wrote: >Dan Sugalski: ># At 1:14 PM -0700 5/15/02, Brent Dax wrote: ># >Dan Sugalski: ># ># At 12:51 AM -0700 5/15/02, Brent Dax wrote: ># ># >-Parrot becomes Parrot_Interp ># ># >-Parrot_String is gone and the string_funcs.h functions are # no ># >longer # >externally visible. -A few structures have been renamed. ># ># >-config.h has been rearranged so that INTVAL, etc. are now ># ># aliases for ># ># >Parrot_Int, etc. ># ># >-A few things that were accidentally made external no longer are. ># ># ># ># This isn't a problem with config.h. config.h should *never* be used ># ># by anyone embedding Parrot, either directly or indirectly. ># > ># >Why not? Some parts of Parrot's embedding system have to be ># set up by ># >Configure. ># ># And those parts should go in embed.h. The bare minimum amount of ># stuff should go in there--the definitions of INTVAL, NUMVAL, Buffer, ># STRING (maybe), and the exported functions. A later phase of the ># build could probably set this up as well, as it'd have access to more ># information. > >I'm trying to keep the number of dynamically-generated files to a >minimum. Why? >We don't lose anything by defining a small part of config.h >that's external, and we gain a static embed.h. There's too much risk of leakage. Once things leak, they can't easily be retracted. I'd rather not have them leak in the first place. ># Stuff like PMC definitions shouldn't go in it. PMC * should be ># typedef'd to void * in the embedding header. > >What I do is declare things like > > struct parrot_pmc_t; > typedef struct parrot_pmc_t* Parrot_PMC; > >So we don't get warnings about type mismatches when we compile embed.c. That works. >Actually, Parrot_PMC won't be in embed.h directly--it'll be in extern.h, >which defines the interface between the outside world and PMCs and >STRINGs. (I'm planning for extenders to use the same interface, which >is why it's in a separate header. embed.h will probably include >extern.h, so it'll be transparent to the user.) Keeping the interfaces separate is good, and keeping them compatible is also good. Works for me. ># ># >I first noticed the problems with computed-goto when I ># found the # ># >>following line in test_main.c: # > ># ># > #ifdef HAVE_COMPUTED_GOTO ># ># > ># ># >See the problem? ># ># ># ># Yes. test_main.c should never have to know about computed ># goto cores ># ># or whatnot. The define's likely something generally passed on the ># ># command line to all the parrot core bits, ># > ># >True. Still, the idea of a define like this not being fixed ># somewhere ># >scares me a bit. If someone tries to send us a copy of ># their config.h ># >so we can debug a problem, we can't tell if they have cgoto enabled. ># ># That's definitely a problem. That #define should be in config.h, and ># *is* a problem. > >Actually, the JIT does the same thing, so it's not *entirely* his fault. I'm not looking to place blame--I don't really care that much, and blame doesn't really buy us anything. I'd just rather it not happen, and get fixed when it does. ># >Actually, it should know that Parrot may support a ># computed-goto core ># >and the flag to enable it is X. It shouldn't have to know if this ># >particular copy of Parrot is built with that capability. ># (It probably ># >should be able to detect it, however, so that it can handle ># cases like ># >the one in test_main's -h handler.) ># ># Flag handling, or at least feature enabling, should probably be done ># by core code. We should provide a set_feature() function > >Right now we have something like this: > > Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL); > >I'm not sure how Parrot reacts to that if computed goto isn't available >on this platform, though. It should pitch a warning and then ignore the computed goto choice. It's not a fatal error, after all. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More memory management changes
At 11:05 PM +0200 5/18/02, Peter Gibbs wrote: >The COW patch has been revised for minimal impact to the outside world. >The only files changed are: resources.h, resources.c, string.h, string.c >There is one API change: Parrot_reallocate_string has an additional >parameter. However, nobody outside string.c really has any business calling >that anyway; and currently nobody else does. > >The STRING structure has one change: a new field, void *buffer, points to >the start of the physical buffer allocation. >I tested a version that eliminated this requirement, by placing the >allocated buffer length in the string tail; but this made the code in >compact_string_pool very cumbersome, and the performance was several percent >slower than my current implementation. I've been thinking about strings and COW. COW is likely to be a big enough win to justify the extra space in string headers for a start of string in addition to a start of buffer, and since the only things that care about it live in string.c, that's fine. So go ahead--I expect it may make COW a bit easier. >Once the latest memory management patch is in, I will resync and submit the >COW code as a separate patch, and we'll see what everybody thinks about it. Did we get you commit privs? If so, commit it. If not, get me your perl.org login and I'll get it taken care of. >Unrelated subject: I see that Steve has modified string.c to get around the >problem with the temporary transcoded strings - I believe we need to >finalise a standard way of handling these situations soon. If anybody is >interested, I will resync my previous 'neonate' patch - it needs a bit of >work to fit with the latest changes to resources.c Did we get the "temporarily alive" bit patch in? If not, lets do that for now. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Profiling PMCs
I decided to do some profiling and tinkering and I picked the PerlInt class
since its one of the most common. There is a large gap between our
MOPS benchmarks when using the plain INT registers as opposed to
the PMC regs.
There seems to be much room for optimization in the PMC virtual
methods, even if it means inlining code and breaking OOP reuse
a bit.
For example, profiling mops_p.pbc gives the following...
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds secondscalls ms/call ms/call name
52.73 2.32 2.321 2320.00 2320.00 cg_core
17.95 3.11 0.79
Parrot_PerlInt_subtract_i
nt
13.41 3.70 0.59 Parrot_PerlInt_get_bool
8.86 4.09 0.39
Parrot_PerlInt_subtract_b
int
7.05 4.40 0.31
Parrot_PerlInt_set_intege
r_native
0.00 4.40 0.00 642 0.00 0.00 add_to_free_pool
0.00 4.40 0.00 60 0.00 0.00 mem_sys_allocate
0.00 4.40 0.00 29 0.00 0.00 mem_allocate
So taking a look at PerlInt, I notice that subtract_int calls the
method set_integer_native. Now, the reasons for encapsulation
for methods for "setting" the core value in an object are not lost
on me, however I think the core PMCs are one place where we
should inline as much as possible. All set_integer_native does
is sets the value for now, I can't think of many other things
to actually encapsulate inside it.
There is the case where we might derive from PerlInt and the
child class reimplements its set_native, but I'm not sure that
this OOP constraint should dictate losing 10Million ops/sec, as
it does on my box.
Going from:
void subtract_int (INTVAL value, PMC* dest) {
dest->vtable->set_integer_native(INTERP, dest,
SELF->cache.int_val - value
);
}
To:
void subtract_int (INTVAL value, PMC* dest) {
dest->cache.int_val -= value;
}
Takes mops_p.pbc from:
Stock:
Elapsed time: 4.342769
M op/s:46.053566
To:
Modified:
Elapsed time: 3.619222
M op/s:55.260495
Granted, doing this means, if I make a new PMC that uses the PerlInt
vtable, then if I were to override set_int_native(), the rest of my inlined
ops would need overriding as well, however, realistically, I'm not
concerned that the PMC internals be an elegant OOP framework, when
it means losing this much performance.
What if we specifiy certain PMC classes as "final"? All that might mean is
we say, if you derive from a final PMC, you must expect:
1) To reimplement most of the vtable
2) To not rely on that PMC's interface never changing
Yeh I know that word is yucky and from Java land, but in this case, I think
that
"system" PMCs should take liberties for optimization.
-Melvin
RE: [COMMIT] Embedding overhaul
At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote: >># Flag handling, or at least feature enabling, should probably be done >># by core code. We should provide a set_feature() function >> >>Right now we have something like this: >> >> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL); >> >>I'm not sure how Parrot reacts to that if computed goto isn't available >>on this platform, though. > >It should pitch a warning and then ignore the computed goto choice. It's >not a fatal error, after all. I hold a different opinion, and that is, production release of Parrot should choose the cores at config time, and make the fastest (non-JIT) core the default, assuming it is stable. I don't see a reason to even provide a flag PARROT_CGOTO_FLAG and a runtime switch. If computed goto is there, and it is the fastest core, it should be THE core, the same goes for prederef if computed goto isn't available. -Melvin
Re: Profiling PMCs
At 7:25 PM -0400 5/18/02, Melvin Smith wrote: >Yeh I know that word is yucky and from Java land, but in this case, >I think that >"system" PMCs should take liberties for optimization. *All* PMCs should take liberties for optimization. PMC vtable entries are the only things that should know the internal structures, and they're allowed--heck, encouraged--to take any liberties needed for speed. I don't much care if it breaks inheritance at the PMC level. Too bad. The speed's more important here. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: [COMMIT] Embedding overhaul
At 7:31 PM -0400 5/18/02, Melvin Smith wrote: >At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote: >>># Flag handling, or at least feature enabling, should probably be done >>># by core code. We should provide a set_feature() function >>> >>>Right now we have something like this: >>> >>> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL); >>> >>>I'm not sure how Parrot reacts to that if computed goto isn't available >>>on this platform, though. >> >>It should pitch a warning and then ignore the computed goto choice. >>It's not a fatal error, after all. > >I hold a different opinion, and that is, production release of Parrot should >choose the cores at config time, and make the fastest (non-JIT) core >the default, assuming it is stable. Fair enough. When we release, there should be one JIT core, one normal core, and one safe core, and there shouldn't be a runtime choice as there shouldn't be a reason for a choice. In the mean time... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Profiling PMCs
At 07:33 PM 5/18/2002 -0400, Dan Sugalski wrote: >At 7:25 PM -0400 5/18/02, Melvin Smith wrote: >>Yeh I know that word is yucky and from Java land, but in this case, I >>think that >>"system" PMCs should take liberties for optimization. > >*All* PMCs should take liberties for optimization. PMC vtable entries are >the only things that should know the internal structures, and they're >allowed--heck, encouraged--to take any liberties needed for speed. > >I don't much care if it breaks inheritance at the PMC level. Too bad. The >speed's more important here. Well then, I'll take that as a yes, and will take a few "liberties" to add 20% to our benchmarks. :) -Melvin
Re: Profiling PMCs
At 7:35 PM -0400 5/18/02, Melvin Smith wrote: >At 07:33 PM 5/18/2002 -0400, Dan Sugalski wrote: >>At 7:25 PM -0400 5/18/02, Melvin Smith wrote: >>>Yeh I know that word is yucky and from Java land, but in this >>>case, I think that >>>"system" PMCs should take liberties for optimization. >> >>*All* PMCs should take liberties for optimization. PMC vtable >>entries are the only things that should know the internal >>structures, and they're allowed--heck, encouraged--to take any >>liberties needed for speed. >> >>I don't much care if it breaks inheritance at the PMC level. Too >>bad. The speed's more important here. > >Well then, I'll take that as a yes, and will take a few "liberties" >to add 20% to our benchmarks. :) D'oh! Yep, I wasn't clear--go for it. Also, it's perfectly fine for a coordinated group of PMCs (like, say, the ones that provide perl's base scalar behavior) to share grubby internal knowledge, though I'd like to keep that under control, as it's easy to get out of sync. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Profiling PMCs
>>>Also, it's perfectly fine for a coordinated group of PMCs (like, say,
>>>the ones that provide perl's base scalar behavior) to share grubby
>>>internal knowledge, though I'd like to keep that under control, as it's
>>>easy to get out of sync.
Ok, now that I'm looking closer, it appears my optimization might be broken,
depending on assumptions.
void subtract_int (INTVAL value, PMC* dest) {
dest->cache.int_val = SELF->cache.int_val - value;
}
Would be broken if we did
sub P0, P1, 5
and P0 wasn't a PerlInt.
I think the common case is:
sub P0, P0, 5
which is basically
dec P0, 5
but we don't currently only have dec/inc for INT and NUM, not PMC. Not good.
Maybe my optimization was well-intended but mis-placed.
-Melvin
RE: [COMMIT] Embedding overhaul
Dan Sugalski: # At 3:16 PM -0700 5/18/02, Brent Dax wrote: # >Dan Sugalski: # ># At 1:14 PM -0700 5/15/02, Brent Dax wrote: # ># >Dan Sugalski: # ># ># At 12:51 AM -0700 5/15/02, Brent Dax wrote: # ># ># >-Parrot becomes Parrot_Interp # ># ># >-Parrot_String is gone and the string_funcs.h # functions are # no # ># >longer # >externally visible. -A few structures have been renamed. # ># ># >-config.h has been rearranged so that INTVAL, etc. are now # ># ># aliases for # ># ># >Parrot_Int, etc. # ># ># >-A few things that were accidentally made external no # longer are. # ># ># # ># ># This isn't a problem with config.h. config.h should # *never* be used # ># ># by anyone embedding Parrot, either directly or indirectly. # ># > # ># >Why not? Some parts of Parrot's embedding system have to be # ># set up by # ># >Configure. # ># # ># And those parts should go in embed.h. The bare minimum amount of # ># stuff should go in there--the definitions of INTVAL, # NUMVAL, Buffer, # ># STRING (maybe), and the exported functions. A later phase of the # ># build could probably set this up as well, as it'd have # access to more # ># information. # > # >I'm trying to keep the number of dynamically-generated files to a # >minimum. # # Why? 1. When you generate a file dynamically, that means it isn't in CVS--the template is. 2. There's a potential for confusion when people want to make changes to the core. 3. Eventually Configure will have to be written in PASM, and I'd like to keep things as simple as possible for that. # >We don't lose anything by defining a small part of config.h # >that's external, and we gain a static embed.h. # # There's too much risk of leakage. Once things leak, they can't easily # be retracted. I'd rather not have them leak in the first place. If someone uses a symbol that isn't documented as external and we retract it, that's their problem. Remember that no matter how much we try to keep external interfaces well-defined, all they have to do is #include "parrot/parrot.h" and they get everything anyway. I'm not saying that we should make everything public and just say "only use this"--I'm saying that we shouldn't make our lives more difficult to prevent naughty behavior unless that's an explicit goal. # ># Stuff like PMC definitions shouldn't go in it. PMC * should be # ># typedef'd to void * in the embedding header. # > # >What I do is declare things like # > # > struct parrot_pmc_t; # > typedef struct parrot_pmc_t* Parrot_PMC; # > # >So we don't get warnings about type mismatches when we # compile embed.c. # # That works. # # >Actually, Parrot_PMC won't be in embed.h directly--it'll be # in extern.h, # >which defines the interface between the outside world and PMCs and # >STRINGs. (I'm planning for extenders to use the same # interface, which # >is why it's in a separate header. embed.h will probably include # >extern.h, so it'll be transparent to the user.) # # Keeping the interfaces separate is good, and keeping them compatible # is also good. Works for me. # # ># ># >I first noticed the problems with computed-goto when I # ># found the # # ># >>following line in test_main.c: # > # ># ># > #ifdef HAVE_COMPUTED_GOTO # ># ># > # ># ># >See the problem? # ># ># # ># ># Yes. test_main.c should never have to know about computed # ># goto cores # ># ># or whatnot. The define's likely something generally # passed on the # ># ># command line to all the parrot core bits, # ># > # ># >True. Still, the idea of a define like this not being fixed # ># somewhere # ># >scares me a bit. If someone tries to send us a copy of # ># their config.h # ># >so we can debug a problem, we can't tell if they have # cgoto enabled. # ># # ># That's definitely a problem. That #define should be in # config.h, and # ># *is* a problem. # > # >Actually, the JIT does the same thing, so it's not # *entirely* his fault. # # I'm not looking to place blame--I don't really care that much, and # blame doesn't really buy us anything. I'd just rather it not happen, # and get fixed when it does. Yeah. # ># >Actually, it should know that Parrot may support a # ># computed-goto core # ># >and the flag to enable it is X. It shouldn't have to know if this # ># >particular copy of Parrot is built with that capability. # ># (It probably # ># >should be able to detect it, however, so that it can handle # ># cases like # ># >the one in test_main's -h handler.) # ># # ># Flag handling, or at least feature enabling, should # probably be done # ># by core code. We should provide a set_feature() function # > # >Right now we have something like this: # > # > Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL); # > # >I'm not sure how Parrot reacts to that if computed goto # isn't available # >on this platform, though. # # It should pitch a warning and then ignore the computed goto choice. # It's not a fatal error, after all. I don't think it should warn unless we give them a way to reject
RE: [COMMIT] Embedding overhaul
Melvin Smith:
# At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote:
# >># Flag handling, or at least feature enabling, should
# probably be done
# >># by core code. We should provide a set_feature() function
# >>
# >>Right now we have something like this:
# >>
# >> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL);
# >>
# >>I'm not sure how Parrot reacts to that if computed goto isn't
# >>available on this platform, though.
# >
# >It should pitch a warning and then ignore the computed goto choice.
# >It's
# >not a fatal error, after all.
#
# I hold a different opinion, and that is, production release
# of Parrot should choose the cores at config time, and make
# the fastest (non-JIT) core the default, assuming it is stable.
#
# I don't see a reason to even provide a flag PARROT_CGOTO_FLAG
# and a runtime switch.
#
# If computed goto is there, and it is the fastest core, it
# should be THE core, the same goes for prederef if computed
# goto isn't available.
The current system was put into place so that we could do comparitive
benchmarks between cgoto and other cores even on systems with cgoto
enabled.
Having said that, I think that the default should be to use the fastest
non-JIT core, but there should be optional flags to force Parrot to use
a specific core.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Fri, May 17, 2002 at 05:40:30PM -0600, Luke Palmer wrote: > Back to from where this arose, however, I think LAST (and BETWEEN, if > it will exist) should probably be PRE blocks. This is the only way it > could be consistently possible to implement. It wouldn't make any > sense to have it a PRE block on a while and a NEXT block on a foreach. C can't be a C block, for the same reason "else" couldn't be a NAMED block. A C fires just after execution enters the current iteration's block. You're expecting C to fire in the block just after the final iteration, but there is no block after the final iteration. On C, I think we're all agreed that it should fire after the final statement in one iteration and before the first statement in the next iteration (if we get it at all). If you boil down the discussion to it's barest essentials, the only thing at question is what values the variables in the C block should have when it fires. The values of the previous iteration or the following iteration? The debate about look-aheads for arrays and array-like objects is a red herring (though it's been interesting). It isn't necessary for either option. Allison
New assembler difficulties.
So here I am, hacking BASIC to use keyed PMC's for variables to make it blazingly fast when I find out that to do this I need to use the new assembler. So I pop into lib\parrot and proceed with the build and I get this mess: C:\projects\parrot\parrot\lib\Parrot>perl makefile.pl Writing Makefile for Parrot::PakFile2 C:\projects\parrot\parrot\lib\Parrot>nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cp Op.pm blib\lib\Parrot\Op.pm cp OpTrans.pm blib\lib\Parrot\OpTrans.pm cp OpsFile.pm blib\lib\Parrot\OpsFile.pm cp Assembler.pm blib\lib\Parrot\Assembler.pm cp PMC.pm blib\lib\Parrot\PMC.pm cp Config.pm blib\lib\Parrot\Config.pm cp PackFile.pm blib\lib\Parrot\PackFile.pm cp String.pm blib\lib\Parrot\String.pm cp Types.pm blib\lib\Parrot\Types.pm cp Test.pm blib\lib\Parrot\Test.pm cp BuildUtil.pm blib\lib\Parrot\BuildUtil.pm cp PakFile2.pm blib\lib\Parrot\PakFile2.pm AutoSplitting blib\lib\Parrot\PakFile2.pm (blib\lib\auto\Parrot\PakFile2) cp Vtable.pm blib\lib\Parrot\Vtable.pm cp Optimizer.pm blib\lib\Parrot\Optimizer.pm C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\lib C:\Perl\lib\ExtUtils/xsubpp -typemap C:\Pe rl\lib\ExtUtils\typemap PakFile2.xs > PakFile2.xsc && C:\Perl\bin\perl.exe -IC:\Perl\lib -IC:\Perl\l ib -MExtUtils::Command -e mv PakFile2.xsc PakFile2.c Please specify prototyping behavior for PakFile2.xs (see perlxs manual) cl -c -I../../include -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCR YPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX -O1 -MD -DNDEBUG-DVERSION= \"0.01\" -DXS_VERSION=\"0.01\" -IC:\Perl\lib\CORE PakFile2.c PakFile2.c PakFile2.xs(21) : warning C4133: 'function' : incompatible types - from 'char [52]' to 'struct inter preter *' PakFile2.xs(21) : error C2198: 'Perl_croak' : too few actual parameters PakFile2.xs(32) : warning C4133: 'function' : incompatible types - from 'char [40]' to 'struct inter preter *' PakFile2.xs(32) : error C2198: 'Perl_croak' : too few actual parameters PakFile2.xs(48) : warning C4133: 'function' : incompatible types - from 'char [52]' to 'struct inter preter *' PakFile2.xs(48) : warning C4047: 'function' : 'const char *' differs in levels of indirection from ' long ' PakFile2.xs(48) : warning C4024: 'Perl_croak' : different types for formal and actual parameter 2 PakFile2.xs(69) : warning C4133: 'function' : incompatible types - from 'char [36]' to 'struct inter preter *' NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. So the new assembler's unhappy. Suggestions?
Re: Methods, and such
Aaron Sherman writes:
: On Wed, 2002-05-15 at 21:38, root wrote:
: >
: > I've always liked how VB allowed you to define "instance methods."
: > Basically a more elegant way of doing callbacks, plus allows some
: > structure within your callbacks. Will Perl6 allow this (Perl5 sortof did,
: > but since the "bless" way of doing things is going away...)
: >
: > Perhaps...
: >
: > class foo {...}
: >
: > $x = new foo; #BTW, is there some standard way of creating instances
: > #now?
:
: my $x is foo; # I think that's correct
Er, no. That just ties the variable $x to class foo, presuming there
is a class foo. Doesn't say anything at all about the *contents* of
$x. You can type the value of $x by saying:
my foo $x;
but that still doesn't create an instance.
Constructors haven't been designed yet, but one approach would be to
have the built-in opaque object type assume a constructor name of "new"
if you don't declare one. I can see some problems with that though.
Certainly the Perl 5 way of creating instances will continue to be
supported--that is, with the data structure totally orthogonal to the
class binding. Whether the new opaque objects are constructed inside
or outside of C is still to be decided.
Larry
Re: New assembler difficulties.
Clinton A Pierce wrote:
>
> So here I am, hacking BASIC to use keyed PMC's for variables to make it
> blazingly fast when I find out that to do this I need to use the new
> assembler. So I pop into lib\parrot and proceed with the build and I get
> this mess:
>
--snip--
>
> So the new assembler's unhappy. Suggestions?
Well, it's unhappy when you do lots of things. The code I was given was
not as complete/functional as I had been led to believe, inasmuch as it
doesn't live past test series 2 without some major tweaks that I'm
working on. And I'm not even going to comment on t/pmc... However, none
of this minor rant has anything to do with your problem.
I can't reproduce it locally, so I'm wondering if the Windows build
might not properly expand the Perl_croak call from 'Perl_croak("foo")'
to 'Perl_croak(aTHX_ "Foo")', as the UNIX .xs build does...
--
Jeff <[EMAIL PROTECTED]>
Re: New assembler difficulties.
Jeff wrote:
>
> Clinton A Pierce wrote:
> >
> > So here I am, hacking BASIC to use keyed PMC's for variables to make it
> > blazingly fast when I find out that to do this I need to use the new
> > assembler. So I pop into lib\parrot and proceed with the build and I get
> > this mess:
> >
> --snip--
> >
> > So the new assembler's unhappy. Suggestions?
>
> Well, it's unhappy when you do lots of things. The code I was given was
> not as complete/functional as I had been led to believe, inasmuch as it
> doesn't live past test series 2 without some major tweaks that I'm
> working on. And I'm not even going to comment on t/pmc... However, none
> of this minor rant has anything to do with your problem.
>
> I can't reproduce it locally, so I'm wondering if the Windows build
> might not properly expand the Perl_croak call from 'Perl_croak("foo")'
> to 'Perl_croak(aTHX_ "Foo")', as the UNIX .xs build does...
> --
> Jeff <[EMAIL PROTECTED]>
And of course it's got a few portability issues, as we discovered a
little while ago. One problem is the list of .o files in the
Makefile.PL, which should be a portable extension. I'll fix this as
well, I guess...
--
Jeff <[EMAIL PROTECTED]>
Re: New assembler difficulties.
At 09:27 PM 5/18/2002 -0400, Jeff wrote:
> > So the new assembler's unhappy. Suggestions?
>
>Well, it's unhappy when you do lots of things. The code I was given was
>not as complete/functional as I had been led to believe, inasmuch as it
>doesn't live past test series 2 without some major tweaks that I'm
>working on. And I'm not even going to comment on t/pmc... However, none
>of this minor rant has anything to do with your problem.
>
>I can't reproduce it locally, so I'm wondering if the Windows build
>might not properly expand the Perl_croak call from 'Perl_croak("foo")'
>to 'Perl_croak(aTHX_ "Foo")', as the UNIX .xs build does...
1. You're right, it's not expanding at all under Win32. Adding the aTHX_
makes this compile.
2. The Makefile's looking for things like bytecode.o when under Win32 it
should be bytecode.obj
3. After all this, the assembler will compile small programs. Feeding it
BASIC produces lots of warnings about uninitalized values and finally dies
with:
Unparsable argument, starting from '"', QUOTE
No line number, no context, nearly impossible to find to debug.
I think you're right, and you were given a pig in a poke.
Re: New assembler difficulties.
Clinton A Pierce wrote:
>
> At 09:27 PM 5/18/2002 -0400, Jeff wrote:
> > > So the new assembler's unhappy. Suggestions?
> >
> >Well, it's unhappy when you do lots of things. The code I was given was
> >not as complete/functional as I had been led to believe, inasmuch as it
> >doesn't live past test series 2 without some major tweaks that I'm
> >working on. And I'm not even going to comment on t/pmc... However, none
> >of this minor rant has anything to do with your problem.
> >
> >I can't reproduce it locally, so I'm wondering if the Windows build
> >might not properly expand the Perl_croak call from 'Perl_croak("foo")'
> >to 'Perl_croak(aTHX_ "Foo")', as the UNIX .xs build does...
>
> 1. You're right, it's not expanding at all under Win32. Adding the aTHX_
> makes this compile.
>
> 2. The Makefile's looking for things like bytecode.o when under Win32 it
> should be bytecode.obj
>
> 3. After all this, the assembler will compile small programs. Feeding it
> BASIC produces lots of warnings about uninitalized values and finally dies
> with:
>
> Unparsable argument, starting from '"', QUOTE
>
> No line number, no context, nearly impossible to find to debug.
>
> I think you're right, and you were given a pig in a poke.
That's somewhat unfair. I was upset, and shouldn't have let off steam
like that, so I apologize publicly. I just checked in a small patch to
handle quoting issues, and am working at the moment on what should be
the final PMC issue solutions, at least I hope. It was written back when
keys were going to be a separate set of registers, and we don't do that
any more.
--
Jeff <[EMAIL PROTECTED]>
[netlabs #596] .XS build process needs to be more portable
# New Ticket Created by Jeffrey Goff
# Please include the string: [netlabs #596]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=596 >
I've just patched lib/Parrot/Makefile.PL to check for a Win32 platform,
and if so, use .obj for the default object extension. However I did it
simply by checking $^O for 'Win'. This is probably not as portable as it
could be, but a quick look through ExtUtils::MakeMaker didn't reveal a
variable that could be used for determining the proper extension.
The possible problem in lib/Parrot/PakFile2.xs is slightly different,
and is a 5.6.1 issue. Modifying Perl_croak("foo") to Perl_croak(aTHX_
"foo") works on both UNIX and Win32, but I'm not sure if that's the
correct approach, and if we're simply tickling a bug in the appropriate
Win32 build. This isn't a major bug, it just needs to be looked at by
someone with more experience in this area than I have.
--
Jeff <[EMAIL PROTECTED]>
GC vtable method limitations?
So we're going to support some vtable operations for GC support. We currently have mark, and we're going to have collect. Is there a plan to make a freed method for when pmc header gets put back onto the free list? (This would require we call this method on all pmc's before moving anything to the freelist, in case of dependancies between pmcs and buffers) We need to define what they are, and are not allowed to do. As a general catch-all, we can say that no memory allocation or deallocation may occur during any of these routines, although we should be able to get more specific. Perhaps: mark: can't modify memory in any way aside from calling mark_used and buffer_lives. (Otherwise, we could adjust pointers in something which was already marked). collect: not sure what the goal of collect isto handle copying of your memory data, in case you need to fixup pointers? What are the limitations here? I'm going to say: no new headers or allocation of memory. (This could cause stuff to be allocated in the old pool that doesn't get copied over to the new one.) destruct: Can do anything you want. We'll need to either increase our DOD_block_level since it isn't re-entrant, but I don't think that's a big problem. We can probably increment it before freeing all the buffers, and decrement it when we're done. How do these sound? Thanks, Mike Lambert
inc/dec
I think the inc/dec op (NUM, NUM) should be (NUM, INT) While I'm adding the PMC support for inc/dec I'll fix that, unless I'm wrong. INC/DEC by a NUM is not in the PDD. -Melvin
[COMMIT] inc/dec/add ops and new PMC methods
Filled in some missing holes: -Implement PMC inc/dec functions and add ops to engine. 'inc P0, 5' is faster than 'set P0, P1, 5' which uses a vtable. -Corrected 'inc Nx, Ny' to 'inc Nx, Iy' as per the PDD -Added missing 'add Nx, Ny, Iz' op Updated mops_p.pasm to use dec op, however, the intent was not to optimize mops_p benchmark, but to optimize for a very common operation, which mops_p just happens to do. We now need to re-evaluate mops_p and how to accurately represent a cross-section of operations and not a specific case. Er, hmm we might need a few new tests, I was too lazy to write them, I did fix the existing ones for the erroneous inc Nx, Ny op. Btw, mops_p runs 20% faster, for now, but I wouldn't get too excited since it only uses 2 specific ops. -Melvin
GC Minor Doc Patch, Pool fix
Below adds docs at the top of each function about whether that function
calls pool compaction or dod. The dod functions and compaction functions
don't list the other one themselves, otherwise they'd be re-entrant. ;)
Also fixes a bug I found with GC_DEBUG. Namely, that during compaction,
when it allocs a new block, it passed along a null pool. That pool is
required in order to give the block the pool's minimum_block_size, which
otherwise would not be done.
This also affected the 'freeing' below such that it now skips the first
block (the block we just allocated).
This patch also eliminates GC_DEBUG for now, since it was sort of screwed
up. I still have to get my head around the new multiple arenas scheme, and
figure out how GC_DEBUG would interoperate with that.
Thoughts?
Mike Lambert
Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.54
diff -u -r1.54 resources.c
--- resources.c 15 May 2002 01:13:52 - 1.54
+++ resources.c 19 May 2002 06:09:50 -
@@ -26,7 +26,9 @@
struct Memory_Pool *);
-/* Create a new tracked resource pool */
+/* Create a new tracked resource pool
+ * Can perform: pool compaction
+ */
static struct Resource_Pool *
new_resource_pool(struct Parrot_Interp *interpreter, size_t free_pool_size,
size_t unit_size, size_t units_per_alloc,
@@ -52,6 +54,7 @@
/* Add entry to free pool
* Requires that any object-specific processing (eg flag setting, statistics)
* has already been done by the caller
+ * Can perform: pool compaction
*/
static void
add_to_free_pool(struct Parrot_Interp *interpreter,
@@ -68,9 +71,6 @@
&pool->free_pool_buffer,
(UINTVAL)(pool->free_pool_buffer.buflen * 1.2));
}
-#ifdef GC_DEBUG
-Parrot_go_collect(interpreter);
-#endif
/* Okay, so there's space. Add the header on */
temp_ptr = pool->free_pool_buffer.bufstart;
@@ -82,6 +82,7 @@
/* Get an entity from the specified free pool
* If the pool is empty, try a DOD sweep
* If the pool is still empty, call the replenishment function
+ * Can perform: dod, pool compaction
*/
static void *
get_from_free_pool(struct Parrot_Interp *interpreter,
@@ -107,7 +108,9 @@
}
/* We have no more headers on the free header pool. Go allocate more
- * and put them on */
+ * and put them on
+ * Can perform: pool compaction
+ */
static void
alloc_more_pmc_headers(struct Parrot_Interp *interpreter,
struct Resource_Pool *pool)
@@ -143,6 +146,9 @@
}
}
+/*
+ * Can perform: dod, pool compaction
+ */
PMC *
new_pmc_header(struct Parrot_Interp *interpreter)
{
@@ -160,6 +166,7 @@
/* Get a PMC from the free pool */
return_me = get_from_free_pool(interpreter,
interpreter->arena_base->pmc_pool);
+
/* Count that we've allocated it */
interpreter->active_PMCs++;
/* Mark it live */
@@ -170,6 +177,9 @@
return return_me;
}
+/*
+ * Can perform: nothing
+ */
void
free_pmc(PMC *pmc)
{
@@ -179,7 +189,9 @@
}
/* We have no more headers on the free header pool. Go allocate more
- * and put them on */
+ * and put them on
+ * Can perform: pool compaction
+ */
static void
alloc_more_buffer_headers(struct Parrot_Interp *interpreter,
struct Resource_Pool *pool)
@@ -214,7 +226,9 @@
}
}
-/* Get a buffer out of our free pool */
+/* Get a buffer out of our free pool
+ * Can perform: dod, pool compaction
+ */
Buffer *
new_buffer_header(struct Parrot_Interp *interpreter)
{
@@ -241,6 +255,9 @@
return return_me;
}
+/*
+ * Can perform: nothing
+ */
void
free_buffer(Buffer *thing)
{
@@ -254,7 +271,9 @@
}
}
-/* Mark all the PMCs as not in use. */
+/* Mark all the PMCs as not in use.
+ * Can perform: nothing
+ */
static void
mark_PMCs_unused(struct Parrot_Interp *interpreter)
{
@@ -277,7 +296,9 @@
}
}
-/* Mark all the buffers as unused */
+/* Mark all the buffers as unused
+ * Can perform: nothing
+ */
static void
mark_buffers_unused(struct Parrot_Interp *interpreter,
struct Resource_Pool *pool)
@@ -300,6 +321,9 @@
}
}
+/*
+ * Can perform: nothing
+ */
PMC *
mark_used(PMC *used_pmc, PMC *current_end_of_list)
{
@@ -325,14 +349,18 @@
/* Tag a buffer header as alive. Used by the GC system when tracing
* the root set, and used by the PMC GC handling routines to tag their
- * individual pieces if they have private ones */
+ * individual pieces if they have private ones
+ * Can perform: nothing
+ */
INLINE void
buffer_lives(Buffer *buffer)
{
buffer->flags |= BUFFER_live_FLAG;
}
-/* Do a full trace run and mark all the PMCs as active if they are */
+/* Do a full trace run and mark all the PMCs as active if they are
+ * Can perform: nothing
+ */
static void
trace_active_PMCs(struct Parrot_Interp *interpreter)
{
@@ -430
