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.
  • In November/December, I built an alpha release of "Vanilla Perl 6" (combining Parrot and Rakudo).

    I found it to be uninstallable (because it hard-coded all the filesystem paths at compile time which made it almost impossible to make an installer) and it leaked memory so fast that most simple test benchmarks I created consumed more than the 2gig process limit after running for a few minutes.

    I concluded that the implementation was not sufficiently stable for me (as a person who doesn't know C) to do anything u

    • I should add that it's a perfectly reasonable point of view to state that because I'm not a contributor, or even a user, of Rakudo I don't really have any right to complain about it.

      But unfortunately that still means I end up not using it.

      • You may have taken my comments the opposite way in which I intended them. I find it very interesting that the project with orders of magnitude fewer users has much, much more active development.

        (By the way, I just fixed a pile of memory leaks in Rakudo.)

        • What do you see the requirements of a "stable" release as, in terms of performance issues like memory leaks?

          • It'd be nice if "stable" releases never had bugs or regressions or memory leaks or misfeatures or incompatibilities, but that's not going to happen. If that's your criteria, you're going to find everything but TeX wildly unsatisfying.

            Obviously you have to set your expectations for "stable" in terms of the project's roadmap, intended purpose, and intended audience, but with those caveats in mind, the single most important characteristic I see is "Does it do what the developers intend it to do so far?"

            My cri

            • I like to use the the same concepts, definitions and terminology for software bugs, regressions, memory leaks, misfeatures and incompatibilities as the medical profession does for human bugs, regressions, leaks, misfeatures and incompatibilities. The medical profession has a lot of experience with issues that present shades of grey.

              For (medically defined) chronic conditions, like memory leaks, you can use assessment criteria similar to those for mental illness.

              Many people present degrees of dementia, psycho

              • I find quibbling about the definitions of words very dull, but....

                I'd suggest that when most people use the word "stable", they refer to a release that is free from debilitating defects for the majority of users and use cases.

                All I can find from you about these "debilitating defects" you found are two comments in IRC -- no bug reports, no messages to the mailing list, no description of steps to reproduce, no context as to what you were doing to trigger them. I started investigating Rakudo memory leaks in detail a few days ago when (I believe) Geoff Broadwell and Jonathan pointed me to a test case.

                A defect so long underreported doesn't strike me as "debilitating" to the point of making software unusable.

                • Nobody likes quibbling about words. It's just that your definition of stable seems to differ from many people.

                  I did a fairly simple three line program with a loop in it, and it consumed all my system memory in about a minute.

                  It possible that it's just me jumping to conclusions.

                  Because it did it so fast and so blatantly, and we were still at pre-1.0 releases, I just assumed that it was a known problem, and moved on because I lacked the time or skills to investigate it further.

                  I didn't really take the time to

                  • I just assumed

                    I find it easier to merge duplicate tickets than to fix bugs no one tells me exist. (I have a decent history of fixing Parrot bugs, memory leaks, and performance problems.)

                • I should add that this journal entries almost exactly describes my experience and demonstrates why I just assumed that it was something that was known about.

                  http://use.perl.org/~korpenkraxar/journal/ [perl.org]