Re: [PATCH] Disable GC at startup
Bryan C. Warnock wrote: > Oh, in which case, I agree with you. ;-) Oh, woops. :) For some reason I was assuming you were arguing against my patch. Anyways, below is a revised and simpler patch that implements the same semantics as before, but using Dan's new DOD_block_level and GC_block_level method for disabling the GC. Dan, are you still opposed to a non-GC_DEBUG version of this patch, in light of the discussion that ensued? Mike Lambert Index: interpreter.c === RCS file: /cvs/public/parrot/interpreter.c,v retrieving revision 1.82 diff -u -r1.82 interpreter.c --- interpreter.c 2 Apr 2002 06:24:14 - 1.82 +++ interpreter.c 14 Apr 2002 10:21:55 - @@ -494,8 +494,8 @@ interpreter->total_Buffers = 0; interpreter->memory_allocated = 0; interpreter->memory_collected = 0; -interpreter->DOD_block_level = 0; -interpreter->GC_block_level = 0; +interpreter->DOD_block_level = 1; +interpreter->GC_block_level = 1; /* Set up the memory allocation system */ mem_setup_allocator(interpreter); @@ -557,6 +557,9 @@ interpreter->pmc_reg_base->next = NULL; interpreter->pmc_reg_base->prev = NULL; Parrot_clear_p(interpreter); + +interpreter->DOD_block_level--; +interpreter->GC_block_level--; /* Need a user stack */ interpreter->user_stack = new_stack(interpreter);
Re: gcc3 issues?
At 11:47 PM -0700 4/13/02, Robert Spier wrote: >Looks like we've got a slew of gcc3 issues (which don't show up on the >tinderboxes, cause nobody's running a gcc3 box.) What sub-version of GCC 3? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: gcc3 issues?
On Sun 14 Apr 2002 16:01, Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:47 PM -0700 4/13/02, Robert Spier wrote: > >Looks like we've got a slew of gcc3 issues (which don't show up on the > >tinderboxes, cause nobody's running a gcc3 box.) > > What sub-version of GCC 3? FWIW bleadperl compiles OK with 3.0.4/64 on hppa-2.0w (64bit), but croacks on 3.1/64 (2002-04-08 snapshot). GNU developers are looking at it themselves -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.3 & 631 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: [EMAIL PROTECTED] http:[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: [PATCH] Disable GC at startup
At 6:37 AM -0400 4/14/02, Mike Lambert wrote: >Bryan C. Warnock wrote: > >> Oh, in which case, I agree with you. ;-) > >Oh, woops. :) For some reason I was assuming you were arguing against >my patch. Which is applied. I'd rather enforce the "No allocations until mem_setup_allocator is done, allocations just fine after" rule, but since I've not made it clear... :) Anyway, I think we're OK here, and worst case we pork out a little at the beginning. I don't think that's an issue--if the base allocation quantities are large we won't hit them, and if they're small we won't waste much, if any, memory. >Anyways, below is a revised and simpler patch that implements the same >semantics as before, but using Dan's new DOD_block_level and >GC_block_level method for disabling the GC. > >Dan, are you still opposed to a non-GC_DEBUG version of this patch, in >light of the discussion that ensued? If I was, it's too late now. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PRE-RELEASE] 0.0.5 upcoming
At 9:30 PM -0400 4/13/02, Jeff wrote: >Hopefully that'll get your attention. > >In the interests of accomplishing something this millennium, I'm >planning to tag version 0.0.5 at some time around 12:01am EST Monday, >April 15. I'll be watching mail up until the deadline, so if nobody >complains, Monday evening I'll run the test suites and if it's fit for >release, do so. Of course, running the test suites for the first time on >all platforms will have unexpected issues, so I'm simply going to say >that the release should be done before the end of the week. Works for me. If I can get the patches to the GC system working by then, I'll put 'em in, otherwise I'll wait. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: gcc3 issues?
Dan Sugalski wrote: > At 11:47 PM -0700 4/13/02, Robert Spier wrote: >> Looks like we've got a slew of gcc3 issues (which don't show up on the >> tinderboxes, cause nobody's running a gcc3 box.) > What sub-version of GCC 3? 3.0.4 (running on a relatively stock Pentium2 / RH7.2 system.) This came out of a weird conversation on IRC where someone who was using gcc3 as their default compiler was having trouble... so I tried it. -R
Re: gcc3 issues?
At 8:58 AM -0700 4/14/02, Robert Spier wrote: >Dan Sugalski wrote: >> At 11:47 PM -0700 4/13/02, Robert Spier wrote: >>> Looks like we've got a slew of gcc3 issues (which don't show up on the >>> tinderboxes, cause nobody's running a gcc3 box.) >> What sub-version of GCC 3? > >3.0.4 > >(running on a relatively stock Pentium2 / RH7.2 system.) Damn. Do the failing tests segfault? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: COW for strings
At 11:12 AM +0200 4/9/02, Peter Gibbs wrote: >I don't think we are in a position yet to prove much of anything as regards >real-world Perl programs, but just one data point as an example - using >examples/assembly/life.pasm (changed to 5000 generations) 10% speedup in some circumstances. OK, I'm sold. If the patch is reasonably clean, we'll put it in. Please document the heck out of it, as I expect it'll affect some base assumptions. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: gcc3 issues?
>>> What sub-version of GCC 3? >> 3.0.4 > > > Damn. Do the failing tests segfault? I didn't look that closely. Some of them definitely are spitting out wrong data. (Very odd.) I didn't notice any Segmentation Fault warnings in the output though, so I'd guess no, unless it's being trapped by the test harness. -R
Re: vector processing in Perl6?
At 5:26 PM -0700 4/13/02, Larry Wall wrote: >Well, Perl 5 doesn't really support compact arrays of known size, and >those are the only kind that are easy to think about when it comes to >vectorization. Actually, I can think of other possibilities. For instance, aren't some string operations (e.g., comparing two strings) vectorizable? But your overall point seems valid. Anyway, I'm hoping that quite a lot of this stuff shows up in Perl 6; my take is that the things that Perl is slow at are the things that I specify myself (e.g., complicated control structures and code); when it can simply go off and do something (e.g., I/O), it runs as fast as the C code that implements the thing it's doing. -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: Is there a way to turn GC completely off?
At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote: >At 5:35 PM -0400 4/13/02, Clinton A. Pierce wrote: >>I'm fighting a now-you-see-it now-you-don't kind of bug and I was >>wondering if there's a way to completely turn off garbage collection and >>memory re-use for debugging? > >Yes. The sweepoff and collectoff ops will turn of DOD runs and GC sweeps, >respectively. sweepon and collecton will re-enable them. (They are >attached to the counters, so they nest and you need to match off and on counts) > >Just added the things to CVS, so you'll need to resync to get 'em. Got 'em and tried them. Some bugs vanished, but others are still there. Hrm. At least I can eliminate some potential sources.
Re: gcc3 issues?
At 9:26 AM -0700 4/14/02, Robert Spier wrote: > >>> What sub-version of GCC 3? >>> 3.0.4 >> >> >> Damn. Do the failing tests segfault? > > >I didn't look that closely. Some of them definitely are spitting out >wrong data. (Very odd.) > >I didn't notice any Segmentation Fault warnings in the output though, so >I'd guess no, unless it's being trapped by the test harness. I think it's being trapped. Segfaults for me under OS X don't show in the output. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Is there a way to turn GC completely off?
At 1:24 PM -0400 4/14/02, Clinton A. Pierce wrote: >At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote: >>At 5:35 PM -0400 4/13/02, Clinton A. Pierce wrote: >>>I'm fighting a now-you-see-it now-you-don't kind of bug and I was >>>wondering if there's a way to completely turn off garbage >>>collection and memory re-use for debugging? >> >>Yes. The sweepoff and collectoff ops will turn of DOD runs and GC >>sweeps, respectively. sweepon and collecton will re-enable them. >>(They are attached to the counters, so they nest and you need to >>match off and on counts) >> >>Just added the things to CVS, so you'll need to resync to get 'em. > >Got 'em and tried them. Some bugs vanished, but others are still >there. Hrm. At least I can eliminate some potential sources. I was afraid of that. I'm seeing buffer corruption, which is what I'm currently tracking down. It likely isn't just my new code, then. Oh, well, at least we'll get a more stable interpreter. (I'm half-hoping the bugs you find turn out to be ours...) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
pasm.el and looping ops
pasm.el
Description: application/emacs-lisp
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.120
diff -u -r1.120 core.ops
--- core.ops 14 Apr 2002 02:05:46 - 1.120
+++ core.ops 14 Apr 2002 18:11:08 -
@@ -2571,6 +2571,80 @@
+=item B(in INT, in INT, in INT)
+
+$1: counter
+$2: target value
+$3: continue loop location
+
+If $1 is not equal to $2 (we haven't reached the target value) branch
+to the location specified in $3 and decrement $1.
+
+=cut
+
+inline op loop_down (out INT, in INT, in INT) {
+ if ($1-- != $2) {
+goto OFFSET($3);
+ }
+ goto NEXT();
+}
+
+=item B(out INT, in INT)
+
+$1: counter
+$2: continue loop location
+
+If $1 is not zero decrement $1 and branch to the location specified in
+$2.
+
+=cut
+
+inline op loop_downz (out INT, in INT) {
+ if ($1-- != 0) {
+goto OFFSET($2);
+ }
+ goto NEXT();
+}
+
+=item B(out INT, in INT, in INT)
+
+$1: counter
+$2: target value
+$3: continue loop location
+
+If $1 is not equal to $2 increment $1 and branch to the location
+specified in $3.
+
+=cut
+
+inline op loop_up (in INT, in INT, in INT) {
+ if ($1++ != $2) {
+goto OFFSET($3);
+ }
+ goto NEXT();
+}
+
+=item B(in INT, in INT, in INT)
+
+$1: counter
+$2: continue loop location
+
+If $1 is not equal to 0 increment $1 and branch to the location
+specified in $2. Note: This op is exists mainly for completeness, it
+is not expected to get used a lot.
+
+=cut
+
+inline op loop_upz (in INT, in INT) {
+ if ($1++ != 0) {
+goto OFFSET($2);
+ }
+ goto NEXT();
+}
+
+
+
+
=item B(in INT)
Branch forward or backward by the amount in $1.
--
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There's a crack in everything.
It's how the light gets in.
-Isonard Cohen
Re: pasm.el and looping ops
ok, please pardon the inconvience but everytime i send mail to perl6-internals the body of my message disappears... anyway, here's what i meant to say: [original email] i have written a simple emacs mode, providing highlighting, indentation, and compilation, for dealing with .pasm files, it's basic, but pasm isn't exactly the syntactic (sp?) manster perl5 is. i have written 4 different forms of looping ops with varying degrees of usefullness. i think that if these were to are accepted the form which gets used the most in real code should be renamed 'loop' (of course, since most code is/will be machine generated this may be completly irrelavent). comments/suggestions/criticisms regarding both pasm.el and the loop ops would be greatly appreciated. -- -Marco Ring the bells that still can ring. Forget the perfect offering. There's a crack in everything. It's how the light gets in. -Isonard Cohen
[Applied] pasm.el
Marco- i went ahead and added your pasm.el file under parrot/editor/. I'm not familiar enough with the ops to commit your other patch- i'll leave that for someone else. --Josh At 20:21 on 04/14/2002 +0200, Marco Baringer <[EMAIL PROTECTED]> wrote: > > ok, please pardon the inconvience but everytime i send mail to > perl6-internals the body of my message disappears... > > anyway, here's what i meant to say: > > [original email] > > i have written a simple emacs mode, providing highlighting, > indentation, and compilation, for dealing with .pasm files, it's > basic, but pasm isn't exactly the syntactic (sp?) manster perl5 is. > > i have written 4 different forms of looping ops with varying degrees > of usefullness. i think that if these were to are accepted the form > which gets used the most in real code should be renamed 'loop' (of > course, since most code is/will be machine generated this may be > completly irrelavent). > > comments/suggestions/criticisms regarding both pasm.el and the loop > ops would be greatly appreciated. > > -- > -Marco > Ring the bells that still can ring. > Forget the perfect offering. > There's a crack in everything. > It's how the light gets in. > -Isonard Cohen
[PATCH] Re: Is there a way to turn GC completely off?
The specific problem Clinton mentioned is yet another infant mortality
problem, this time in string_concat. I don't know what the current decision
is on handling these situations, but this one can be avoided by optimising
the code anyway. If the transcoding is done before making the result string,
we know the actual length, instead of using the maximum possible.
I haven't yet looked to see why basic needs to transcode string anyway.
--
Peter Gibbs
EmKel Systems
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
retrieving revision 1.68
diff -u -r1.68 string.c
--- string.c12 Apr 2002 01:40:28 - 1.68
+++ string.c14 Apr 2002 18:45:54 -
@@ -283,14 +283,14 @@
if (a != NULL && a->strlen != 0) {
if (b != NULL && b->strlen != 0) {
-result = string_make(interpreter, NULL, a->bufused +
- b->strlen * a->encoding->max_bytes,
- a->encoding, 0, a->type);
-mem_sys_memcopy(result->bufstart, a->bufstart, a->bufused);
+/* transcode first so we know the length and avoid infanticide
*/
if (a->type != b->type || a->encoding != b->encoding) {
b = string_transcode(interpreter, b, a->encoding, a->type,
NULL);
}
+result = string_make(interpreter, NULL, a->bufused +
b->bufused,
+ a->encoding, 0, a->type);
+mem_sys_memcopy(result->bufstart, a->bufstart, a->bufused);
mem_sys_memcopy((void *)((ptrcast_t)result->bufstart +
a->bufused),
b->bufstart, b->bufused);
result->strlen = a->strlen + b->strlen;
Re: TODO additions
In message <[EMAIL PROTECTED]> Tom Hughes <[EMAIL PROTECTED]> wrote: > I have developed patch for this in the form of a new routine > which returns a nul terminated C style string given a parrot > string as argument. It does this by making sure buflen is at > least one greater than bufused and then stuffing a nul in that > byte. > > This isn't a particularly brilliant fix so I'm attaching it here > for comments before I commit it. I haven't seen any major objections to this so I have committed it. It will at least ensure that file opening is stable for the upcoming release. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
Re: Is there a way to turn GC completely off?
[Follow up to my previous post] lib/Parrot/Assembler.pm creates all string constants with chartype = 0, which, by virtue of the sequence of the enums in include/parrot/chartype.h means unicode. So all string constants are type: unicode, encoding: singlebyte. I am not going to try and fix this one, but it does mean that the string transcoding routines are getting called when nobody expects it. There may well be other places in string.c where this causes problems; I will look at this shortly. -- Peter Gibbs EmKel Systems
Re: TODO additions
> > I have developed patch for this in the form of a new routine > > which returns a nul terminated C style string given a parrot > > string as argument. It does this by making sure buflen is at > > least one greater than bufused and then stuffing a nul in that > > byte. > > > > This isn't a particularly brilliant fix so I'm attaching it here > > for comments before I commit it. > > I haven't seen any major objections to this so I have committed > it. It will at least ensure that file opening is stable for the > upcoming release. If you want something to be looked at, commit it. :) This patch assumes the underlying string is an scii string, since it just sticks a null byte at the end of the string's original byte data. Transcoding to ascii might be more proper. Problem is, if the type syscalls expect is unicode (say plan9 or something), how do we indicate an endofstring? io.ops has an open which also is assuming the native type is ASCII. I submitted a patch that transcoded everything to ASCII, and added the byte, before calling PIO_open, but it seems that it was never applied with whatever patch it was a part of (warnings cleanup perhaps?) Mike Lambert
Re: [PATCH] Re: Is there a way to turn GC completely off?
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote: >The specific problem Clinton mentioned is yet another infant mortality >problem, this time in string_concat. I don't know what the current decision >is on handling these situations, but this one can be avoided by optimising >the code anyway. If the transcoding is done before making the result string, >we know the actual length, instead of using the maximum possible. > >I haven't yet looked to see why basic needs to transcode string anyway. Both with the sweepoff/collectoff and your patch I'm still seeing the behavior I described at the top of this thread. In fact, the behavior I'm seeing is getting *worse* with recent CVS updates. Eeeek! Nothing works. *panic* I'm off for the evening, but I'll try to come up with a small test case if there is such a beast.
Re: [PATCH] Re: Is there a way to turn GC completely off?
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote: >The specific problem Clinton mentioned is yet another infant mortality >problem, this time in string_concat. I don't know what the current decision >is on handling these situations, but this one can be avoided by optimising >the code anyway. If the transcoding is done before making the result string, >we know the actual length, instead of using the maximum possible. > >I haven't yet looked to see why basic needs to transcode string anyway. As a follow-up, I found one bug. Rather odd it is. The symptom is loading a program, doing a LIST and seeing only part of the code. Dumping the string-which-contains-the-code you can see the entire program in it (unlike the earlier described bug). The problem was in here: set S2, "" substr S2, S15, I1, LINEWIDTH save S2 bsr STRIPSPACE # (removes trailing whitespace) set I2, S2 # Quietly convert S2 to an int ge I2, I6, VFOUND So I'd pull things out of S15, strip the space off, look for something greater-than or equal-to I6. Problem was this test was *failing*. Putting diagnostics in I found out that S2 wasn't getting converted correctly to an integer in I2. *puzzle*. Changing the conversion part of the code to: save S2 bsr ATOI restore I2 Fixes the problem. The insane thing is that ATOI essentially loads a string register from the stack, coverts it, and then puts it back as an integer -- almost exactly what was failing before.
Re: Unary dot
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote: > Of course, one of the big reasons we went with $self was the pun: > > my $self = shift; > > which we won't have now. Unless we always hide the invocant and > force you to say > > my $self = invocant; > > or some such mummery. But that seems a bit retro. But now we have endless possibilities for $self.ish $self.less $self.centred $self.obsessed etc. -- "But Sidley Park is already a picture, and a most amiable picture too. The slopes are green and gentle. The trees are companionably grouped at intervals that show them to advantage. The rill is a serpentine ribbon unwound from the lake peaceably contained by meadows on which the right amount of sheep are tastefully arranged." Lady Croom - Arcadia
Re: [PRE-RELEASE] 0.0.5 upcoming
Jeff wrote: > > Hopefully that'll get your attention. > > In the interests of accomplishing something this millennium, I'm > planning to tag version 0.0.5 at some time around 12:01am EST Monday, > April 15. I'll be watching mail up until the deadline, so if nobody > complains, Monday evening I'll run the test suites and if it's fit for > release, do so. Of course, running the test suites for the first time on > all platforms will have unexpected issues, so I'm simply going to say > that the release should be done before the end of the week. 0.0.5 has been tagged in CVS. Expect an official release after I remember how to upload and unpack under VMS. Also, a new roadmap has been proposed and will be available for all to see later this week. > -- > Jeff <[EMAIL PROTECTED]>
Re: [PATCH] Re: Is there a way to turn GC completely off?
> As a follow-up, I found one bug. Rather odd it is. The symptom is loading > a program, doing a LIST > and seeing only part of the code. Dumping the > string-which-contains-the-code you can see the entire program in it (unlike > the earlier described bug). The problem was in here: Clint, in terms of getting things in Parrot fixed, I think it's better if you can provide a way to generate the bug, no matter how complex the case is. Non-simple test cases are better than no test cases at all, imo. For example, I was able to reproduce the missing line 20 bug, and that was fixed with Peter's patch. I played a few games of WUMPUS tonight on my MSVC-compiled parrot, but haven't seen anything out of the ordinary. It works flawlessly, and is really cool to see something like that working on Parrot. The only things I could complain about would be case-sensitivity in commands (it's annoying to keep the capslock key and get screwed up when switching to other applications :), and the one or two seconds it takes to generate the maze and set itself up. Do you have any test cases for reproducing the two bugs you just mentioned in this thread? Thanks, Mike Lambert
Re: Unary dot
> One of the features I like about Eiffel is what Meyer calls the Uniform
> Access principle...It sounds as though Perl 6 is heading towards supporting
> this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
write:
class Foo { # version 1
my $.bar_attr is public;
}
then you'll get an automagically created lvalue accessor method that will allow
you to write:
my $foo = Foo.new();
$foo.bar_attr = 1;
and then later define a real C method to encapsulate it:
class Foo { # version 2
my $.bar_attr;
method bar_attr is rw($rvalue) () {
if exists $rvalue {
croak "Negative value" if $rvalue < 0;
$.bar_attr = $rvalue;
}
return $.bar_attr;
}
}
More interestingly, it may also be that, by default, the C (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still have the same Uniform Access effect.
This would help Perl 6 support legacy Perl 5 OO code
(not to mention legacy Perl 5 OO coders ;-)
Damian
Re: Subroutine variables are like underwear
Yes, subroutine variables *are* like underwear.
But parameter names *aren't* like underwear.
Because they're not (primarily) subroutine variables.
So they're like the labels on the knobs, dials, and buttons of your favourite
elctronic device. They're part of the *interface*, not (primarily) part of the
implementation. They should be chosen with care, and not changed on a whim.
I do, however, understand the desire to allow them to change, or to be
somewhat "fuzzy" (i.e. "filename" vs "file_name" vs "file"). And I agree that
it could
be a very useful facility.
But your proposed syntax is...err...less than ideal.
If we were to have this, I'd far rather we use the existing mechanism
for annotating variables. Namely: properties.
For example:
sub load_data ($filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
Damian
