Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • > To write tests for extremely hard-to-test code without mocking half of the known universe including the DBI -- this was the original reason.

    Holy crap, why didn't I know this exists.

    This is way way cool.

    I have some really evil testing cases that I've been to write for ages, but lacked a way to sanely inject stuff into the guts of code.

    Some questions though...

    The version dependency is current 5.008, is there any way it can go back to 5.005, or is it's use of internals just going to make 5.008 something t

    • Hey Alias,

      Re: 5.005, it *might* work, but I'm afraid to find out.

      As for examples, read through the t/* directory. They print stuff out on each line, so the output of the program reflects the post-modification state. If you can sort it out from reading and playing with those, send me some doc patches.

      I'd take your interest as plenty of motivation to go do some more (doubtlessly needed) work on the documentation, but I'm in middle of something else I need to hurry up and get done so I can go get some other
  • I didn't see this when you uploaded it. You've saved me having to write it myself. Thank you!

  • You said

    To search-and-replace dangerous code constructs, to upgrade them, such as replacing blocking reads with Coro-friendly calls that give up the CPU to runable contexts.

    That sounds really neat. But... can you prove it works? Or can you prove that (and when) it fails? Warn us when it just isn't sure?

    Everybody in the Perl world that Perl is extremely difficult to parse. That's the reason why you shouldn't use Switch in production. Because, it might work most of the time, but there is no warning if it fails.

    So, if this system could just garantee to us that what it produced works identically to the original code, when it indeed is the case, or warn us when it found


    • I'm not sure we're talking about the same thing. B::Splice does not parse Perl, and it doesn't use PPI to try to parse Perl. It uses B::Generate. Go read the perldoc then comment again if anything you meant to say still applies.

      As far as targeting professionals, I don't remember saying anything about that either. In fact, my post taunted the Perl community for acting too much like professionals and not enough like mad scientists. Er, pardon me... it seems as though you're having a conversation with you
  • You use B::Generate for Code::Splice and typesafety, but even dev version, 1.06_2, has serious problems.
    Code::Splice itself has cpantesters results "PASS (1) FAIL (6) NA (1)".

    I already see some cases to use Code::Splice for testing.

    • The documentation clearly states that it requires my own version of B::Generate, that's posted in my author area on CPAN. I should probably just fork B::Generate and maintain a copy full on (I want to add support for creating lexicals on the fly, especially since a lot of ops need temps on the pad)... anyway, that's something I can't worry about right now, but would reconsider if people actually did start using the sucker.

      Thanks for your comment. Feel free to email me questions or examples of things you'v