[perl #809] [PATCH] Adding the system stack to the GC

2002-07-13 Thread via RT

# New Ticket Created by  Mike Lambert 
# Please include the string:  [perl #809]
# in the subject line of all future correspondence about this issue. 
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=809 >


Okay, patch is included below. Here are the relevant times from the gc
bench suite:
gc_alloc_reuse.pbc  12.058001   12.056999
gc_generations.pbc  3.9649995.769
gc_header_new.pbc   3.9249993.924999
gc_waves_headers.pbc0.8719970.871999
gc_waves_sizeable_data.pbc  7.059   7.140001
gc_waves_sizeable_headers.pbc   5.3169995.358

I believe gc_generations is slower due to the many DOD calls that are
performed (and each DOD requires a stack walk). In general,
the stack-walk makes the new version a little bit slower, or perhaps the
same, in all cases.

Note that the patch implementation is a bit ugly because of the seperation
of pmc and header pools. I have another GC refactoring patch in the wings
which should remedy this situation.

Also note the problem I mentioned earlier, which may very well crop it's
head up with this patch under 'real-world' conditions. See below sig.

Mike Lambert

> Also, I think I've discovered a situation which might not be
> resolvable. How do we determine id a given buffer is alive? We walk the
> stack and check for potential pointers into buffer memory. If the stack
> contains garbage pointers, we might have bad references into buffer
> memory. I can check for alignment within the buffer pool, and so it should
> be safe to set the BUFFER_live_FLAG on them.
>
> However, when we perform a collection, that means that we could be taking
> a garbage pointer in the buffer, and attempting to copy the memory it
> pointed to, into new memory.
>
> This could give us GPFs if we access bad memory, I think. Even if we check
> to ensure the buffer points into valid collectable memory (making it
> slower), we still have the issue of buflen being set to MAX_INT or
> something, and killing the system. :|
>
> The same caveats apply to pmc headers which happen to have
> PMC_buffer_ptr_FLAG set.
>
> How should we get around this particular problem, or is it spelling the
> doom of this particular solution?
>
> Thanks,
> Mike Lambert


-- attachment  1 --
url: http://bugs6.perl.org/rt2/attach/3798/3520/778163/diff.txt



? vc60.pdb

? parrot.pdb

? classes/vc60.pdb

? lib/Parrot/PakFile2.def

Index: interpreter.c

===

RCS file: /cvs/public/parrot/interpreter.c,v

retrieving revision 1.91

diff -u -r1.91 interpreter.c

--- interpreter.c   4 Jul 2002 20:39:44 -   1.91

+++ interpreter.c   13 Jul 2002 09:10:52 -

@@ -404,6 +404,8 @@

 runops(struct Parrot_Interp *interpreter, struct PackFile *code, size_t offset)

 {

 opcode_t *(*core) (struct Parrot_Interp *, opcode_t *);

+void *dummy_ptr;

+interpreter->lo_var_ptr = &dummy_ptr;

 

 interpreter->code = code;

 interpreter->resume_offset = offset;

Index: resources.c

===

RCS file: /cvs/public/parrot/resources.c,v

retrieving revision 1.72

diff -u -r1.72 resources.c

--- resources.c 4 Jul 2002 20:39:44 -   1.72

+++ resources.c 13 Jul 2002 09:10:56 -

@@ -123,6 +123,7 @@

 mem_sys_allocate(sizeof(PMC) * pool->units_per_alloc);

 memset(new_arena->start_PMC, 0, sizeof(PMC) * pool->units_per_alloc);

 new_arena->used = pool->units_per_alloc;

+new_arena->total = pool->units_per_alloc;

 new_arena->next = NULL;

 new_arena->prev = pool->last_Arena;

 /* Is there a previous arena */

@@ -132,6 +133,12 @@

 

 pool->last_Arena = new_arena;

 

+if (pool->start_arena_memory > new_arena->start_PMC)

+pool->start_arena_memory = new_arena->start_PMC;

+

+if (pool->end_arena_memory < new_arena->start_PMC + sizeof(PMC) * 
+pool->units_per_alloc)

+pool->end_arena_memory = new_arena->start_PMC + sizeof(PMC) * 
+pool->units_per_alloc;

+

 /* Note it in our stats */

 interpreter->total_PMCs += pool->units_per_alloc;

 

@@ -200,6 +207,7 @@

 memset(new_arena->start_Buffer, 0, 

pool->unit_size * pool->units_per_alloc);

 new_arena->used = pool->units_per_alloc;

+new_arena->total = pool->units_per_alloc;

 new_arena->next = NULL;

 new_arena->prev = pool->last_Arena;

 /* Is there a previous arena */

@@ -209,6 +217,12 @@

 

 pool->last_Arena = new_arena;

 

+if (pool->start_arena_memory > new_arena->start_Buffer)

+pool->start_arena_memory = new_arena->start_Buffer;

+

+if (pool->end_arena_memory < new_arena->start_Buffer + sizeof(Buffer) * 
+pool->units_per_alloc)

+pool->end_arena_memory = new_arena->start_Buffer + sizeof(Buffer) * 
+pool->units_per_alloc;

+

 /* Note i

Re: Parrot contribution

2002-07-13 Thread John Porter


Ask Bjoern Hansen wrote:
> [EMAIL PROTECTED] (John Porter) writes:
> 
> > Yeah, look at the so-called Parrot FAQ.  Someone needs to
> > get serious and make a real FAQ for parrot developers.
> 
> I'm sure noone would mind if you start one!

Does no one on this mailing see my point?

It does not work to ask the people who need the doc to write
the doc.  Those with the knowledge must write the doc, so 
that those without the knowledge can read it.

In this case, I'm talking about questions that (presumably)
get asked frequently on irc.  I fail to see how such a FAQ
could be written by anyone other than a regular on the
channel.  For all I know, there are no frequently asked
questions on the irc channel.  For all I know, there are no
newbie parrot developers on the channel.

-- 
John Douglas Porter


__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com



Re: Parrot contribution

2002-07-13 Thread Sean O'Rourke

On Sat, 13 Jul 2002, John Porter wrote:

>
> Ask Bjoern Hansen wrote:
> > [EMAIL PROTECTED] (John Porter) writes:
> >
> > > Yeah, look at the so-called Parrot FAQ.  Someone needs to
> > > get serious and make a real FAQ for parrot developers.
> >
> > I'm sure noone would mind if you start one!
>
> It does not work to ask the people who need the doc to write
> the doc.  Those with the knowledge must write the doc, so
> that those without the knowledge can read it.

You're right, but on the other hand, it doesn't work for the people who
know the system to ask the questions.  The people who need the doc are in
the best position to know what is clear and what is obscure.  If it's not
even clear where to dive in, say so -- "getting started" may be a specific
area in which docs are lacking.  What kinds of questions do you run into
trying to approach the system for the first time?  What do you think there
should be pointers to?  What is most helpful in the docs/ directory?  What
is least helpful?

To help even more, you could collect the answers to these questions when
you receive them, and make the resulting FAQ part of your contribution to
Parrot.  Write the FAQ you wish had existed when you first came.

> For all I know, there are no frequently asked questions on the irc
> channel.  For all I know, there are no newbie parrot developers on the
> channel.

You're mostly right here, too -- from what I've seen, IRC is more a place
where "oldbies" hash things out.  But it doesn't have to be this way --
#parrot is a friendly channel, and its denizens seem receptive to
questions.

/s




Re: Parrot contribution

2002-07-13 Thread Nicholas Clark

On Sat, Jul 13, 2002 at 06:41:22AM -0700, John Porter wrote:
> channel.  For all I know, there are no frequently asked
> questions on the irc channel.  For all I know, there are no
> newbie parrot developers on the channel.

Having read but deleted rather too much of this thread to respond to the
right bit, I'd like to say that I feel it unwise to rely on an IRC channel.
It assumes

1: Would be developers have a permanent internet connection (or sufficiently
   cheap that they can stay connected to IRC for long periods)

2: Would be developers are working in the same (or close) timezones to the
   main core of developers. (Real timezones don't matter - who is awake on
   what sleep cycle does)

Maybe there are now enough well spread developers to provide 24 hour cover
on IRC, so concern 2 isn't an issue. But number 1 could well be, as I presume
we're hoping to appeal to developers outside North America, South Korea and
the parts of north west Europe with broadband.

I appreciate that everyone is volunteering to work on it (and even Dan was
volunteering to work on it before this year) so there is no compulsion for
anyone to do what they don't want. However, if what you want is parrot
well written, then the "I'm too busy working on it so I don't have time to
document it" is not the best way to achieve it over the long term.

I was working somewhere where the chief technical architect, a very smart
guy, was far too busy doing stuff to write it down, and also didn't view it
as a priority as "I don't need to write it down, it's all in my head".

This was fine, but did not scale. *He* knew the answers to all his questions,
as he genuinely didn't forget technical things. (and still does not)
But it was no good to anyone else, and he soon got fed up with being asked
questions by people who wanted to know stuff documented in his head.
We all had the choice of "spend lots of time working out what something does"
or "ask XXX" and as we were being pressured to get stuff done fast each of us
individually would attempt to "ask XXX" whenever possible, falling back to
"work it out". And we were being paid, so we weren't the sort of people to
drift off and not contribute if we found this entry hurdle too high.

An IRC channel is good for discussions. But it doesn't archive them,
index them, collate them and provide them as reference for any new
would be recruits. I'm not saying that anyone has to write the docs, or
even the skeleton of the docs for their code - everyone and anyone can just
keep writing code if they so feel. But if they do just write code without
any form of overview documentation, then they're still going to be writing
code for a long time to come, because they won't recruit many helpers.

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/



Re: Parrot contribution

2002-07-13 Thread Dave Mitchell

On Sat, Jul 13, 2002 at 03:48:31PM +0100, Nicholas Clark wrote:
> I was working somewhere where the chief technical architect, a very smart
> guy, was far too busy doing stuff to write it down, and also didn't view it
> as a priority as "I don't need to write it down, it's all in my head".

And once again, I'd like to remind people of the following section in
PDD7:

=item Developer files

For each source file (eg a F F pair), there should be an
accompanying developer file called F. This text file contains
documentation on all the implementation decisions associated with the
source file. (Note that this is in contrast to PDDs, which describe
design decisions). This is the place for mini-essays on how to avoid
overflows in unsigned arithmetic, or on the pros and cons of differing
hash algorithms, and why the current one was chosen, and how it works.
In principle, someone coming to a particular source file for the first
time should be able to read the F<.dev> file and gain an immediate
overview of what the source file is for, the algorithms it implements,
etc.

Currently no particular format or structure is imposed on the developer
file, but it should have as a minimum the following sections:

=over 4

=item Overview

Explain the purpose of the source file.

=item Data structures and algorithms

Explain how it all works.

=item History

Record major changes to the file, eg "we moved from a linked list to a
hash table implementation for storing Foos, as it was found to be much
faster".

=item Notes

Anything that may be of interest to your successors, eg benchmarks of
differing hash algorithms, essays on how to do integer arithmetic.

=item References

Links to pages and books that may contain useful info relevant to the
stuff going on in the code - eg the book you stole the hash function
from.

=back

-- 
But Pity stayed his hand. "It's a pity I've run out of bullets", he
thought. - "Bored of the Rings"



Re: [netlabs #789] [PATCH] Squish some warnings

2002-07-13 Thread Tom Hughes

In message <20020712010920$[EMAIL PROTECTED]>
  Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:

> # New Ticket Created by  Simon Glover
> # Please include the string:  [netlabs #789]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=789 >
> 
> 
> 
>  stack_chunk is now Stack_Chunk...

Applied. Somebody update the ticket please...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




Send questions for the FAQ

2002-07-13 Thread Dan Sugalski

Okay, it's reasonably obvious that we're lacking in documentation in 
spots, and it's also reasonably obvious that we need to fix that. 
Docs for the source need to be forthcoming, so we'll work on that.

It's also pretty obvious that people have questions and the FAQ isn't 
sufficient. So lets fix that.

If you've got questions you want answered, post them with a subject 
line of PARROT QUESTION. (Yes, all caps, it's easy to pick out) We'll 
gather them up, then answer the things and stow the answers in the 
repository.

(It'd be a reasonably good idea to take a browse through the existing 
docs first, as well as the talks on parrotcode.org)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk



Re: Parrot contribution

2002-07-13 Thread Ashley Winters

On Saturday 13 July 2002 07:39 am, Sean O'Rourke wrote:
> To help even more, you could collect the answers to these questions when
> you receive them, and make the resulting FAQ part of your contribution to
> Parrot.  Write the FAQ you wish had existed when you first came.

I would find that handy. I'm sure the answers would be enlightening.

How much "why?" can this list handle, anyways? If I subscribe to the CVS 
commit list and start asking you folks for explanations of the interesting, 
undocumented patches, would you answer my questions if I submitted doc 
patches with the answers? I haven't even compiled Parrot before, so you'd be 
getting genuine n00b questions. Be warned.

Is there a complete description, or even listing, of command-line switches 
outside of parrot -h or whatever? running.pod doesn't quite do it for me.

Ashley Winters

-- 
When you do the community's rewrite, try to remember most of us are idiots.




Re: [netlabs #790] [PATCH] MANIFEST update

2002-07-13 Thread Tom Hughes

In message <20020712005836$[EMAIL PROTECTED]>
  Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:

> # New Ticket Created by  Simon Glover
> # Please include the string:  [netlabs #790]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=790 >
> 
> 
> 
>  Self-explanatory.

Applied. Somebody please update the ticket...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




Re: [netlabs #788] [PATCH] Array fixes (and tests)

2002-07-13 Thread Tom Hughes

In message <20020711221132$[EMAIL PROTECTED]>
  Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:

> # New Ticket Created by  Simon Glover
> # Please include the string:  [netlabs #788]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=788 >
> 
> 
> 
>  This patch fixes a number of off-by-one errors in array.pmc, and adds a
>  few more tests.

Applied. Somebody please update the ticket...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




Re: [netlabs #757] Problem mixing labels, comments and quote-marks

2002-07-13 Thread Tom Hughes

In message <20020703012231$[EMAIL PROTECTED]>
  Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:

>  This code:
> 
>   A:# prints "a"
>   print "a"
>   end
> 
>   doesn't assemble; the assembler dies with the error message:
> 
> Use of uninitialized value in hash element at assemble.pl line 844.
> Couldn't find operator '' on line 1.
> 
>   If you remove the ""s from the comment, it works fine. Likewise, if
>   you put the label, op and comment on the same line, ie:
> 
>A: print "a"   # prints "a"
>  end
> 
>   then it assembles and runs OK.

Here's a patch that will fix this. I havn't committed it because I'm
not sure why the assember wasn't dropping comments that included quotes
so I'm giving people who know more about the assembler than me a chance
to comment first...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/


Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.77
diff -u -r1.77 assemble.pl
--- assemble.pl 4 Jul 2002 18:36:17 -   1.77
+++ assemble.pl 13 Jul 2002 17:30:48 -
@@ -433,7 +433,7 @@
 
   $self->{pc}++;
   return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank 
lines
-  $line=~s/#[^'"]+$//;   # Remove trailing comments
+  $line=~s/#.*$//;   # Remove trailing comments
   $line=~s/(^\s+|\s+$)//g;   # Remove leading and trailing whitespace
   #
   # Accumulate lines that only have labels until an instruction is found..



Re: [netlabs #758] [PATCH] Fixes for example programs

2002-07-13 Thread Tom Hughes

In message <20020703015823$[EMAIL PROTECTED]>
  Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:

> # New Ticket Created by  Simon Glover
> # Please include the string:  [netlabs #758]
> # in the subject line of all future correspondence about this issue.
> # http://bugs6.perl.org/rt2/Ticket/Display.html?id=758 >
> 
> 
> 
>  Fixes to various of the PASM examples in light of recent changes in the
>  assembler.

Applied. Somebody please update the ticket...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




Re: [netlabs #757] Problem mixing labels, comments and quote-marks

2002-07-13 Thread brian wheeler

On Sat, 2002-07-13 at 12:32, Tom Hughes wrote:
> In message <20020703012231$[EMAIL PROTECTED]>
>   Simon Glover (via RT) <[EMAIL PROTECTED]> wrote:
> 
> >  This code:
> > 
> >   A:# prints "a"
> >   print "a"
> >   end
> > 
> >   doesn't assemble; the assembler dies with the error message:
> > 
> > Use of uninitialized value in hash element at assemble.pl line 844.
> > Couldn't find operator '' on line 1.
> > 
> >   If you remove the ""s from the comment, it works fine. Likewise, if
> >   you put the label, op and comment on the same line, ie:
> > 
> >A: print "a"   # prints "a"
> >  end
> > 
> >   then it assembles and runs OK.
> 
> Here's a patch that will fix this. I havn't committed it because I'm
> not sure why the assember wasn't dropping comments that included quotes
> so I'm giving people who know more about the assembler than me a chance
> to comment first...


I believe it wasn't dropping the comments with quotes as a side effect
of not wanting to break things like:
print "#"

which breaks with the included patch.  I basically had the same patch
you do, but wasn't able to figure out how to handle the above case *and*
do the right thing with  # prints "a"


Brian



> 
> Tom
> 
> -- 
> Tom Hughes ([EMAIL PROTECTED])
> http://www.compton.nu/
> 
> 

> Index: assemble.pl
> ===
> RCS file: /cvs/public/parrot/assemble.pl,v
> retrieving revision 1.77
> diff -u -r1.77 assemble.pl
> --- assemble.pl   4 Jul 2002 18:36:17 -   1.77
> +++ assemble.pl   13 Jul 2002 17:30:48 -
> @@ -433,7 +433,7 @@
>  
>$self->{pc}++;
>return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank 
>lines
> -  $line=~s/#[^'"]+$//;   # Remove trailing comments
> +  $line=~s/#.*$//;   # Remove trailing comments
>$line=~s/(^\s+|\s+$)//g;   # Remove leading and trailing whitespace
>#
># Accumulate lines that only have labels until an instruction is found..




Re: [netlabs #757] Problem mixing labels, comments and quote-marks

2002-07-13 Thread Tom Hughes

In message <20020713174114$[EMAIL PROTECTED]>
  brian wheeler <[EMAIL PROTECTED]> wrote:

> On Sat, 2002-07-13 at 12:32, Tom Hughes wrote:
> > In message <20020703012231$[EMAIL PROTECTED]>
> > Here's a patch that will fix this. I havn't committed it because I'm
> > not sure why the assember wasn't dropping comments that included quotes
> > so I'm giving people who know more about the assembler than me a chance
> > to comment first...
> 
> I believe it wasn't dropping the comments with quotes as a side effect
> of not wanting to break things like:
>   print "#"
> 
> which breaks with the included patch.  I basically had the same patch
> you do, but wasn't able to figure out how to handle the above case *and*
> do the right thing with  # prints "a"

Of course... The attached patch should handle that I think...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/


Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemble.pl,v
retrieving revision 1.77
diff -u -r1.77 assemble.pl
--- assemble.pl 4 Jul 2002 18:36:17 -   1.77
+++ assemble.pl 13 Jul 2002 17:49:58 -
@@ -430,10 +430,13 @@
 
 sub _annotate_contents {
   my ($self,$line) = @_;
+  my $str_re = qr(\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\" |
+  \'(?:[^\\\']*(?:\\.[^\\\']*)*)\'
+ )x;
 
   $self->{pc}++;
   return if $line=~/^\s*$/ or $line=~/^\s*#/; # Filter out the comments and blank 
lines
-  $line=~s/#[^'"]+$//;   # Remove trailing comments
+  $line=~s/^((?:[^'"]+|$str_re)*)#.*$/$1/; # Remove trailing comments
   $line=~s/(^\s+|\s+$)//g;   # Remove leading and trailing whitespace
   #
   # Accumulate lines that only have labels until an instruction is found..



Parrot_open_i_sc_sc

2002-07-13 Thread Bryan Logan


Here's the code I have:

open I0, "test.txt", "<"
open I1, "testdtxt", "<"
end

I assemble and load it into pdb and get this:

Parrot Debugger 0.0.1

(pdb) list
1  open_i_sc_sc I0,"test.txt<","<"
2  open_i_sc_sc I1,"testdtxt","<"
3  end

(pdb)

The first one is listed as "test.txt<" instead of "test.txt"
And when I run it through gdb:

GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) break Parrot_open_i_sc_sc
Breakpoint 1 at 0x804b146: file core.ops, line 146.
(gdb) run -t openfile.pbc
Starting program: /home/bryan/parrot/parrot -t openfile.pbc
PC=0; OP=10 (open_i_sc_sc); ARGS=(I0=0, "test.txt<", "<")

Breakpoint 1, Parrot_open_i_sc_sc (cur_opcode=0x814b8a0,
interpreter=0x8139750) at core.ops:146
146   $1 = (INTVAL)fopen(string_to_cstring(interpreter, ($2)),
string_to_cstring(interpreter, ($3)));
(gdb) cont
Continuing.
PC=4; OP=10 (open_i_sc_sc); ARGS=(I1=0, "testdtxttest.txt", "<")

Breakpoint 1, Parrot_open_i_sc_sc (cur_opcode=0x814b8b0,
interpreter=0x8139750) at core.ops:146
146   $1 = (INTVAL)fopen(string_to_cstring(interpreter, ($2)),
string_to_cstring(interpreter, ($3)));
(gdb)

Notice the first time I hit I had "test.txt<", which is what pdb showed,
but notice the second time, I have "testdtxttest.txt"

Is this an assembler problem or a problem with open?

--
Bryan Logan




[PATCH] byteorder.c

2002-07-13 Thread Tanton Gibbs

Hi,

Its been a long time since I've posted anything to this list, mainly because
my company graciously gave me 1 1/2 years to get a Ph.D. as long as I agreed
to work full time too :) (and by the way I don't have a masters :)  So, I've
been very busy.  Nevertheless, I saw the recent complaints about lack of
documentation and thought I might help out.  Here is an initial attempt at
adding comments to byteorder.c and adding a byteorder.dev file.  If you like
this, then I will continue going through the files and adding comments to
each one as well as a .dev file.  However, I thought I would start with a
small file and make sure everyone likes it before proceeding.

Thanks!
Tanton Gibbs



byteorder.diff
Description: Binary data


byteorder.dev
Description: Binary data


Re: Parrot contribution - #parrot stream parser.

2002-07-13 Thread Jim Cromie

Nicholas Clark wrote:

>
>An IRC channel is good for discussions. But it doesn't archive them,
>index them, collate them and provide them as reference for any new
>would be recruits. I'm not saying that anyone has to write the docs, or
>even the skeleton of the docs for their code - everyone and anyone can just
>keep writing code if they so feel. But if they do just write code without
>any form of overview documentation, then they're still going to be writing
>code for a long time to come, because they won't recruit many helpers.
>
>Nicholas Clark
>

Yes, - and here seems like a good opportunity :-)

=Q

can we could invent a super-lightweight markup language
that #parrot-eers would type into the stream to put meta-info into it ?

,


If we could devise a sufficiently easy markup scheme, then it becomes
possible/worthwhile to automate a irc-channel semantic-packetizer
which just parses on the markup.

..

=ex

Im trying one on for size right now.  started by a pod-esq symbol,
and either ended by a bare period, or continued by a bare comma;
the =q above does both.  (how about =? , nope =q easier tottype

..

=ex.refined.  Of course, above could get a bit clumzy, all that whitespace.
so we can use paragraph chunking, with ^=(\w+)(?:\.\s*)?  to find the 
now-embedded
pod.

=Q

Anyone know of a formalizm that labels the conversational elements of a 
dialog ?

something a little deeper than question, answer.

a decent punt is to rate chunks on one or more scales.
newbieness = 1-10
repeated-q= 1-10

we could have

=q. nb=5,rq=8

as a kind of geek code that refers to stuff just upstream, giving it a 
kind of rating.

it suggests a voting scheme that could devolve (quite) a bit, turning 
#parrot into an
unpleasant psychological experience, but Im sure your friendly 
#parroteers wont do that.
(and the channel server could filter the =markup)

its worth pointing out that rq (repeated-question) has some value, esp 
if it can be
 found and linked. rq=10.yesterday-10am-est

=ex

consider how you would might grade an essay - on its elements.
spelling=3,
gramatics=9
flow=0
intro=
elaboration=
example=
inference=
conclusion=

=q.  wonder whats on CPAN ?  :-)  

Net::IRC::Daemon ??  podlators ?? Pod::

=cutpasteextraneous example, presumably would demonstrate bug in 
context..

[jimc@harpo jimc]$ perl -v

This is perl, v5.8.0 built for i686-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2002, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

[jimc@harpo jimc]$







Re: Parrot_open_i_sc_sc

2002-07-13 Thread Tom Hughes

In message <[EMAIL PROTECTED]>
  Bryan Logan <[EMAIL PROTECTED]> wrote:

> Here's the code I have:
> 
> open I0, "test.txt", "<"
> open I1, "testdtxt", "<"
> end
> 
> I assemble and load it into pdb and get this:
> 
> Parrot Debugger 0.0.1
> 
> (pdb) list
> 1  open_i_sc_sc I0,"test.txt<","<"
> 2  open_i_sc_sc I1,"testdtxt","<"
> 3  end

This is a bug in the debugger (and also in the opcode tracing) where
it is assuming that constant strings in the byte code are zero terminated
when they aren't, and it is therefore overrunning and printing bits of
the next string or whatever. I have just committed a fix.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/




The quest for no compiler warnings

2002-07-13 Thread Nicholas Clark

On gcc we turn on -Wpadded

In file included from include/parrot/interpreter.h:46,
 from include/parrot/parrot.h:114,
 from register.c:13:
include/parrot/op.h:80: warning: padding struct to align `arg_count'

which is this:

typedef struct {
op_type_t type;
const char *name;
const char *full_name;
const char *func_name;
const char *body;
const char jump;
INTVAL arg_count;   /* Includes opcode as one arg */
arg_type_t types[PARROT_MAX_ARGS];
arg_dir_t dirs[PARROT_MAX_ARGS];
} op_info_t;

do we want to leave the warning turned on and have noise, re-order the struct
to avoid the warning, turn the warning off, or "cheat" in some way by changing
what jump is (int, same but 3 more chars after it, anonymous union, bitfield
being 4 ways I can think of that ought to work) ?

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/



Re: Parrot contribution - #parrot stream parser.

2002-07-13 Thread Leon Brocard

Jim Cromie sent the following bits through the ether:

> can we could invent a super-lightweight markup language
> that #parrot-eers would type into the stream to put meta-info into it ?

OK, I'll finally join this discussion. Yes, IRC is handy for realtime
questions like (just an example as it happened last night):

19:33 < blogan> What's the best way to debug parrot?
19:33 < seano> probably parrot -t
19:33 < seano> 'least that's what I do.  launch a "parrot -t foo.pbc" in gdb
19:36 < blogan> OK, it's the -t that's the key.
19:37 <@acme> if you want to debug parrot code, there's also the parrot
  debugger: do make pdb

And look, once we found a problem it made it straight to the list. IRC
is useful as a supplement to the list. Sometimes it's easier to hash
things out in real time, but mostly people just want to check
something out before either producing a patch or initiating further
discussion onlist. Don't worry about IRC. If you want to help develop
parrot, it's another avenue but you're not missing important things in
the Parrot world if you're not on it as everything happens
onlist.

OK, apart for general "more docs" what in particular does anyone not
understand about Parrot? We'll try and help and then add docs or
whatever.

HTH, Leon

ps as it so happens, blogan's question could go into a faq...
-- 
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/

 I'd love to go out with you, but I'm taking punk totem pole carving