Parrot Borking
Hi, I'm having problems with Parrot Segfaulting. What is the most likely line of attack to find out what the cause is ( gdb, parrot debugger, praying, etc.). I'm not a C programmer but I read it fairly well and it is a lot of years since I last used a debugger. My source tree was updated from CVS about 12 hours ago and was rebuilt from realclean. Thanks, Steve Gunnell
[perl #37928] [TODO] build - Parrot::Configure::RunSteps rename
Committed as r10566 & r10567. -J --
Re: relational data models and Perl 6
Rob Kinyon <[EMAIL PROTECTED]> writes: > On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote: >> Minor nit: we're discussing to the relational algebra and not the >> relational Calculus (unless the topic changed and I wasn't paying >> attention. I wouldn't be surprised :) > > Algebra, in general, is a specific form of calculus. So, we're > speaking of the same thing, just in different terms. Umm... I think you have that relationship the wrong way around. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: Parrot Borking
On Dec 18, 2005, at 10:58, Steve Gunnell wrote: Hi, I'm having problems with Parrot Segfaulting. What is the most likely line of attack to find out what the cause is ( gdb, parrot debugger, praying, etc.). gdb and or valgrind --tool=memcheck Be sure to use always a recent svn checkout, I just fixed an ugly source of segfaults yesterday (related to macros). If that doesn't help, please try to provide a progam (snippet) that exhibits the problem. leo
Strange behaviour of PIR register $P0 vs others
Hi, I get some strange behaviour in the attached code snippet. The problem is with the lines marked with a '*'. If the global 'r' is stored into $P0, and in the second marked line it is called, the output of the print statements furhter below is: Lua_Proto_2_0 2 instead of the expected 1 2 Now, if I change the register from $P0 to, say, $P10 (in both marked lines), I do get the expected results. (the code is generated, so somewhat inefficient) I don't understand really the difference between $P0 and $P10, this shouldn't make any difference, should it? I just got a fresh Parrot, shouldn't be the problem here) thanks, klaas-jan .sub _LuaMain :main LuaProto_1_0() end .end .sub LuaProto_1_0 .lex 'p', $P0 .lex 'q', $P1 $P0 = new .Float $P0 = 1 $P1 = new .Float $P1 = 2 $P2 = find_name 'LuaProto_2_0' $P2 = newclosure $P2 global 'r' = $P2 *$P0 = global 'r' *($P10,$P11) = $P0() global 'b' = $P11 global 'a' = $P10 $P1 = global 'a' $P2 = global 'b' print $P1 print "\n" print $P2 print "\n" .end .sub LuaProto_2_0 :outer(LuaProto_1_0) :lex find_lex $P0, 'p' find_lex $P1, 'q' .return($P0,$P1) .end
Graph::Usage
-BEGIN PGP SIGNED MESSAGE- Moin, since no one commented on rewritten my graph-usage package I have gone ahead and uploaded it to CPAN as Graph::Usage. Now you should be able override the detectionlogic and create graphs from usage/dependency trees as you like :) If you have any questions or comments, please don't hesitate to email me. Best wishes, Tels - -- Signed on Sun Dec 18 20:22:56 2005 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "I intend to live forever, or die trying." -- Groucho Marx -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQ6W3lHcLPEOTuEwVAQHVkAf+J9VM2etNGqlRoq+JpMybkIMm98DtXIEO hHaFIMjZDNk6W5hBjNPh8Kf/bffyvR4bg2uxE35PNfc3yyH7DO2V0cdPD0jVsM9c uuHgWt9E7/k7qd2RxWUlSIvriOv9WsJaBaXForThafDuTGdmI0kidhWVpPsct9eM 05VmqvchwXjS3TzFO02y+sCOSLkKrjjI9WfEM3qAqbnHh9flMB5HJ2i+XNd6CwGy 5aAesgrQilqIqYoNtJhmiVNJwmBsq8rE87uBjcD4/8xpFdPRdIU7MYBkpthZzqpv 9q7Y1ScoTx1Y/412xP6A5CUVReJtyY7cW/L0tpLgnQLEgRREunP+7Q== =h58h -END PGP SIGNATURE-
Re: handling undef - second draft
I have occasionally felt it would be nice to be able to distinguish between shifting an explicit undef value off an array and calling shift() on an empty array without having to test the length of the array. Is that likely to fall out of any of the current thinking? I do not want shift() on an empty array to die by default. -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/
[perl #37924] [TODO] build - load steps by namespace
Committed as r10571. I decided not to use Module::Pluggable at this time as it tries to loading things like the 'hints' modules for all platforms. -J --
Re: handling undef - second draft
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes: PS> I have occasionally felt it would be nice to be able to PS> distinguish between shifting an explicit undef value off an array PS> and calling shift() on an empty array without having to test the PS> length of the array. Is that likely to fall out of any of the PS> current thinking? I do not want shift() on an empty array to die PS> by default. that could easily be done with a property on the shifted value like undef but 'Empty'. an undef from an element is shifted as is. so it is more a feature to add to shift than to undef. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: handling undef - second draft
On Sat, 2005-12-17 at 17:27 -0800, Darren Duncan wrote:
> 3. A flag that says we know that some operation failed, such as would
> be exploited in the " err "
> situations.
> This concept is like an exception which isn't thrown but returned.
"Dropping" an exception, perhaps? :)
> 1. I accept the proposal that we just make another class that
> implements the SQL concept of a null value, perhaps named Null or
> SQL::Null, rather than having this behaviour in the core language, so
> that should simplify the rest of the discussion. If someone wants
> undefs to propagate through expressions like SQL's NULLs do, rather
> than failing or defaulting, then this can be done with the new class.
> A Null object would be defined but false. It would overload standard
> operators so that most expressions involving it would propagate a
> Null object, or compare unequally as desired. Therefore, this sort
> of behaviour will be isolated and standard data types won't behave
> this way by default.
I think this is out of scope; if a module chooses to use "undef" as a
well defined part of its interface, that's its call.
> 2. Modify the 'Exceptions' section of S04 so that built-in functions
> return a 'error' or 'failure' or 'exception' if they fail, instead of
> an "interesting value of undef". The behaviour and handling of or
> response to these is essentially unchanged, but the value is called
> something more distinctive and it is not called 'undef'. Instead of
> testing for .defined(), invoke a different method like .failed() or
> .error() instead; invoking .defined() on an error should perhaps
> return true instead of false. Perhaps update err() to activate on
> the error rather than or in addition to undef.
I'm not sure what this adds. You ask for a system call, you don't get a
result. In other words, the result is undefined, and it has a
supplemental error.
It just seems a bit silly to make the "err" operator have to call *two*
methods in sequence, it would be a hack just for system calls.
Besides, aren't all these values just "undef but { .error = '...' }"
etc?
> 3. Have the functionality of 'use fatal' turned on by default in
> large programs, though not one-liners, and it can be turned off
> otherwise. It is safer to have them brought to your attention where
> you make a conscious effort to respond to or dismiss them.
>
> 4. An expression or statement having an 'err' would impose a
> try-block around the expression it is attached to, so the right thing
> still happens when errors are thrown by default. And 'err' is a
> conscious effort to deal.
>
> 5. Autovivification in larger programs should not happen by default,
> unless you have something like 'use autovivify;'. But with
> one-liners it would work by default.
>
> 6. Attempts to use undef where a defined value is expected, such as
> wherever they currently generate warnings, should be upgraded to a
> stricture and fail by default in larger programs. But like with
> other strictures, this would be turned off by default in one-liners.
> If the DWIM behaviour is wanted in larger programs, one can say 'no
> strict undefs;' or such.
I think we need to be very careful not to impose too many good practice
measures on the developer. All of the situations you describe (except
perhaps autovivification) can potentially be picked up by the compiler,
and warnings generated.
> There may be remaining holes in my suggestions, but hopefully I dealt
> with the worst ones from the preceeding first draft.
FWIW, I didn't read the first thread.
Sam.
Re: Change 26165 broke ext/threads/t/stress_re.t test on Win32 (and patch to t/test.pl and/or Test::Harness)
On 12/18/05, demerphq <[EMAIL PROTECTED]> wrote: > On 12/17/05, chromatic <[EMAIL PROTECTED]> wrote: > > On Saturday 17 December 2005 08:23, demerphq wrote: > > > > > It seemed to me that > > > a better patch would be to change the way harness handles directives > > > so it recognizes TODO & SKIP as being a valid directive. > > > > What would that mean? SKIP tests don't run. TODO tests do. > > > > If the test doesn't run, I think it's a SKIP and nothing else. > > Well, Test::Harness aka the opposite point of view and considers it a > TODO and not a SKIP at all as the TODO is first. > > And Test::More::todo_skip() outputs "not ok" for the test, but > test.pl::todo_skip() emits "ok" for the test, which Test::Harness > treats as an unexpected success. If Test::Harness realized that TODO & > SKIP meant both then it could differentiate between the case of > todo_skip() and the case of a real todo that unexpectedly succeeds or > fails. After all it needs to support scenarios where the output isnt > being manufactured by either Test::Builder or test.pl, so you can't > just rely on fixing either. (IMO anyway) > > BTW, none of this is my logic, its legacy code. If you want to > question whether it makes sense to have something be both TODO and > SKIP at the same time ask the person that wrote todo_skip() in the > first place. > > :-) Anyway, i hope all of these patches aren't warnocked because of the Test::Harness discussion. The facts are that test.pl::todo_skip() and Test::Harness don't play together properly and thus T::H reports things as unexpectedly passed when they aren't. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
