[perl #809] [PATCH] Adding the system stack to the GC
# 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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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.
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
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
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.
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