Re: Safe Mode for Parrot -- Need a volunteer
Gregor N. Purdy <[EMAIL PROTECTED]> wrote: > Dan -- > Here's a first version that works with the regular core. > You have to explicitly define PARANOID, or the added code > won't get compiled. It IMHO should be a separate run core, which can be switched to, whenever safe execution is desired. Then we want to turn off some opcodes especially these, which would allow to escape from the safe core. Generally we need a classification of opcodes, so that we can disable e.g. all IO cops. WRT implementation: Putting the register range check in each opcode function just blows the core size. Its much simpler to have one central place to inspect the program code. I'd use the switched core (or better a safe switched core derived from it) as the base. Its a predereferenced core, so during safe prederef some of these checks can be done in advance. While its seems legitimate to check P and S registers for NULL, its suboptimal to generally disallow NULL registers. NULL PRegs are in use e.g. for C and if the code allows execution of dlfunc (probably not but ...) a NULL value for the dl-handle is valid. And finally composite keys may have registers too. leo
Re: Safe Mode for Parrot -- Need a volunteer
Leo -- Thanks for taking the time to review and comment. > > Here's a first version that works with the regular core. > > > You have to explicitly define PARANOID, or the added code > > won't get compiled. > > It IMHO should be a separate run core, which can be switched to, > whenever safe execution is desired. Then we want to turn off some > opcodes especially these, which would allow to escape from the safe > core. Generally we need a classification of opcodes, so that we can > disable e.g. all IO cops. The reason I wrapped the new code in an #ifdef PARANOID is precisely so that you could use cc -o to override the object file name and build two different .o files (one paranoid and one not) from a single source file. Of course, there are probably other things that need to be done, but I didn't want to make 2 * N new .c files to get paranoid versions of the N core .c files now. > WRT implementation: Putting the register range check in each opcode > function just blows the core size. Its much simpler to have one central > place to inspect the program code. > I'd use the switched core (or better a safe switched core derived from > it) as the base. Its a predereferenced core, so during safe prederef > some of these checks can be done in advance. I thought about prederef a bit right before submitting this, and I think the prederef code path is a great place to do the checks. In fact, I'm wondering if the prederef process shouldn't just do the paranoid checks always, since the point of its process is to make one slightly slower pass through things so that subsequent passes can get a speed boost. Maybe it won't be too much of a hit to leave PARANOID as a built-in part of it always. > While its seems legitimate to check P and S registers for > NULL, its suboptimal to generally disallow NULL registers. NULL PRegs > are in use e.g. for C and if the code allows execution of dlfunc > (probably not but ...) a NULL value for the dl-handle is valid. Only 'in' S and P registers are being checked for NULLness. I looked at dlfunc, and I think the right code is being generated for PARANOID. Maybe you could post a code snippet to point out where it is wrong... > And finally composite keys may have registers too. I have to admit I don't know much about the way the keyed stuff works. It appeared in Parrot after my big push of effort. I've been wanting to integrate it into Jako as a way of learning how it works, but alas my supply of tuits has been very low for some time. Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Moving imcc ...
Robert Spier <[EMAIL PROTECTED]> wrote: >> > Anyway, we're more than happy to do this once in a while.. We just >> > require detailed instructions as to what goes where. As Dan now seems to agree, that imcc (and other files) should go into its own subdirectory it would be fine, it we could the move be done. There are AFAIK only 5 things that need adjustment after the move: - config/gen/makefiles/root.in: IMCC_DIR in line 13 - imcc/TestCompiler.pm: 2 paths refering to root marked XXX - config/gen/makefiles.pl: s!languages/imcc!imcc! - config/gen/cflags.pl: toss the line regarding imcc/CFLAGS - MANIFEST: s!languages/imcc!imcc! Building/testing works fine with these changes done. TIA, leo
Predereferencing glossary.pod entry
I just put together an entry on predereferencing in the glossary, with pointers to info on various events in its history. I don't remember if it was a recent summary or what, but someone pointed out there was no such entry. Sorry I can't find the original email to notify you directly, but I hope you are watching... Regards, -- Gregor -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
problem with a test exemple on the Phalanx web site
on the page : http://qa.perl.org/phalanx/kwalitee.html ok( unlink $filename, "Remove $filename" ); should be written: ok( unlink( $filename), "Remove $filename" ); unless you want Perl to take "Remove $filename" as an arg for unlink and not for ok. Dominic
LF needed at end of pasm files?
The pasm files in examples/benchmarks give an error when run with parrot, because they lack a final line feed character (at the very end of the files): error:imcc:parse error, unexpected EOM, expecting '\n' in file 'examples/benchmarks/gc_waves_sizeable_data.pasm' line 85 I'd imagine this indicates a behavior change in imcc at some point. It's easy enough to add the LFs, but it might be better to not require the final line end character. JEff
Re: Devel::Cover can't find loaded modules
On Fri, Oct 03, 2003 at 10:44:24AM -0700, Ovid wrote: > Hi all, > > I was running some test code with Devel::Cover and I've had no problem > using it or generating pretty reports that make coworkers "ooh" and > "ahh". Unfortunately, I started running my test suite on a different > set of tests and started getting some strange errors (formatted for > clarity): > > Devel::Cover: Can't find file "blib/lib/Text/CSV.pm": ignored. > Can't locate object method "find_cv" via package "B::SPECIAL" > (perhaps you forgot to load "B::SPECIAL"?) at > /usr/local/stow/ASperl-5.6.1-629/lib/5.6.1/i686-linux/B.pm line 213. > > To narrow down the problem, I tried running this on a smaller set of > tests, only to get the above output, but with the following line > prepended: > > Devel::Cover: Can't find file "blib/lib/Storable.pm": ignored. > > I'm not sure how running fewer tests is generating more errors, but in > digging through Devel::Cover, I can't even find a reference to > Text::CSV The message here is trying to say that Devel::Cover is wanting to provide coverage information about Text::CSV and Storable, but is unable to locate these modules. That it is looking in blib/lib would suggest when you ran the test perl picked up those modules from a blib directory. That seems a little strange to me, but I'm sure you have your reasons. It is likely that when this message is given you are in a different directory and since the path is relative the module cannot be found. Do you actually want coverage on these modules? Normally you would not, unless you were running their own test suites. If you do not want the coverage information you can simply ignore the warning, or better, use -ignore +-inc and -select to narrow down the list of modules for which you want coverage information. This has the bonus of speeding up runtime by not collecting data you don't want. >nor has digging through B.pm shed any light (though I may > require therapy now). The find_cv error is a real bug. It will be caused either my me using the core B modules incorrectly (not handling the op tree correctly), or by me using B::Deparse in a way it was not expecting. > Googling has also been fruitless for me. > > Has anyone seen any errors like this before and can you give me some > guidance on what I can do to alleviate them? I'm trying to create a > small test case, but this has been pesky to narrow down. In the > meantime, I'm going to try to add signal handlers to dump stack traces > and maybe even symlink a 'blib/lib' to the appropriate libraries (what > a nasty hack!). Right. I don't think the blib problem is related to the find_cv one, so either ignore it or deal with it as I mentioned above. If you are able to narrow the bug down at all I'd be very grateful for a test case. And a patch if you fancy. Otherwise I'm slowly working through CPAN modules using cpancover and trying to fix bugs like this as I go. CPAN is my test suite ;-) If you just want to get some results from the thing, you could try determining which of the coverage criteria is causing the problem, though it may well be common to all the criteria. You could also try putting an eval around the deparse calls at the end of get_cover() in Devel::Cover.pm, though this will likely reduce the reported coverage where the error has occurred. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover can't find loaded modules
On Sat, Oct 04, 2003 at 07:23:09AM +1000, Andrew Savige wrote: > Ovid wrote: > > I was running some test code with Devel::Cover and I've had no problem using > > it or generating pretty reports that make coworkers "ooh" and "ahh". > > Unfortunately, I started running my test suite on a different set of > > tests and started getting some strange errors... > > I have no experience with Devel::Cover yet, but remember this post: > http://nntp.x.perl.org/group/perl.qa/2213 > which states that Devel::Cover cannot be run from the 't' directory I don't think there is anything special about the t directory that upsets Devel::Cover. The problem is related to relative paths and changing directories within the tests/test suite. As a partial solution to the problem you can try giving an absolute path to the database when Devel::Cover is run, eg perl -MDevel::Cover=-db,$PWD/cover_db ... This particular problem seems to have hit the top of the most wanted list so I'll see what I can do with it for the next release. Who are these people who change directories and don't put things back as they found them? ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Devel::Cover - what do the numbers mean ?
I have just used Devel::Cover successfully for the first time. I even got the HTML pages. Great! But what are those numbers and colors in the columns ? I could not find in the documentation. Please point me to the description if it is available somewhere. thanks Gabor
Re: Devel::Cover can't find loaded modules
On Sat, Oct 04, 2003 at 09:38:11PM +0200, Paul Johnson wrote: > Who are these people who change directories and don't put things back > as they found them? ;-) File::chdir
Re: Devel::Cover - what do the numbers mean ?
On Sat, Oct 04, 2003 at 11:00:33PM +0200, Gabor Szabo wrote: > But what are those numbers and colors in the columns ? > I could not find in the documentation. Please point me to the > description if it is available somewhere. Percentage of the code covered, I think.
Re: Devel::Cover - what do the numbers mean ?
On Sat, 4 Oct 2003 [EMAIL PROTECTED] wrote: > On Sat, Oct 04, 2003 at 11:00:33PM +0200, Gabor Szabo wrote: > > But what are those numbers and colors in the columns ? > > I could not find in the documentation. Please point me to the > > description if it is available somewhere. > > Percentage of the code covered, I think. That's what I thought and recalled from the presentation of Paul and I understand the red 50 in branch and the red 33 in cond but I don't understand the green 33 or the green 1 in stmt. And the best is the green 108 stmt. Sure I need some hand holding on this. Gabor
Re: Devel::Cover - what do the numbers mean ?
On Sat, Oct 04, 2003 at 11:25:27PM +0200, Gabor Szabo wrote: > On Sat, 4 Oct 2003 [EMAIL PROTECTED] wrote: > > > On Sat, Oct 04, 2003 at 11:00:33PM +0200, Gabor Szabo wrote: > > > But what are those numbers and colors in the columns ? > > > I could not find in the documentation. Please point me to the > > > description if it is available somewhere. > > > > Percentage of the code covered, I think. Right, in general. > That's what I thought and recalled from the presentation of Paul > and I understand the red 50 in branch and the red 33 in cond but > I don't understand the green 33 or the green 1 in stmt. > And the best is the green 108 stmt. Since a statement is either 0% covered or 100% covered I don't waste space by reporting the coverage as a percentage. Instead the statement column tells you the number of times the statement was exectued. Thus, anything over 0 is OK, and coloured green. The colours are just eye candy, they map to the numbers. The idea being that the red stuff is what you want to look at first. I suspect that you are right, and this is probably not documented anywhere. > Sure I need some hand holding on this. Sounds like you're basically there to me. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: problem with a test exemple on the Phalanx web site
At 1:01 PM -0400 10/4/03, Dominic Letarte wrote: on the page : http://qa.perl.org/phalanx/kwalitee.html ok( unlink $filename, "Remove $filename" ); should be written: ok( unlink( $filename), "Remove $filename" ); unless you want Perl to take "Remove $filename" as an arg for unlink and not for ok. Thanks. I rewrote it as is( unlink($filename), 1, "Remove $filename" ); Better to test for exactness than truth. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Devel::Cover - what do the numbers mean ?
On Sat, 4 Oct 2003, Paul Johnson wrote: > The colours are just eye candy, they map to the numbers. The idea being > that the red stuff is what you want to look at first. > > I suspect that you are right, and this is probably not documented > anywhere. Thanks for the answer ! Another question: I am running coverage analyzis on the test suit of CGI::Application with the intention of phalanxing it if Jesse (the author) agrees. This module is used by sub-classing it. Devel::Cover collects information and reports about each one of the sub-classes that are there to test only. I wonder if it possible to to tell Devel::Cover not to waste time on the coverage of these modules as they are not interesting ? OK that was my original question but now I am not sure. Maybe it is actually important to make sure each test sub-class is also covered well within its tests ? Or maybe that's just the means of achieving better testing of the real module ? Gabor
