Slash Boxes
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.
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 useful with it yet. That basically put it in my "Interesting, but give it 6 months and then try again".

    BUT, at least I could try it out, because there was a Perl 6 binary. Even if I couldn't build an installer, at least I had a simple default "perl6.exe" that I and the other Perl nerds I was hanging out with could poke and see real Perl 6 code running.

    And for almost a year before perl6.exe arrived, I was arguing that Perl 6 was too hard for anyone to see as being "real", because there was no executable.

    Now Perl 6 is seen as being real, but almost nobody is using it because there's no (as far as I'm aware anyway) easy downstream channels that the majority of people can use.

    Every parrot/rakudo release should be accompanied (at the very least) by three to four packages. An /opt/rakudo standalone installer for .deb, .rpm and whatever packaging system Mac OS X uses, and a Vanilla/Strawberry-style installer for C:\rakudo on Windows.

    These should be prominently advertised in all the release announcements and be treated as the primary consumption mechanism for users. The tarball should be treated the same as it is for Perl 5, a special case for consumption by distribution packagers, and people with special complex needs.

    Contributions by people outside the project is almost always going to be a function of the number of users. If the recommended installation method [] is for me to learn how to use a version control system I don't know, then checkout from the svn trunk, install a compiler toolchain, then build the product myself, then sorry but I just don't have the time to do that right now.

    "I made it, you can use it" is just fine, but not if the use is limited to elites (which I most certainly am not).

    Once I've started to use it and invested something in it, then there's an incentive for me to help improve it. But not before.

    • Yeah, I don't know .. I don't think it's the responsibility of the upstream to maintain the distribution packages, too... looks like Allison is maintaining the parrot deb anyway though!
      • It's the responsibility of the upstream to make it both possible and (ideally) easy for the downstream to package it.

        For your new project with no existing downstream channels, it's a fairly basic thing to engage with the people most likely to be your downstream and go out of your way to make life easy for them.

        And for channels without an existing community to do any of the work (like Win32) it's probably going to mean doing it yourself, at least for the startup period.

        Maintaining the channels are one of the

    • 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

                • 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.


    • For the record, I totally agree that Rakudo's current installation is very sub-optimal. Part of the reason for this has been that until recently (within the past week), Parrot didn't really provide sufficient hooks for us to be able to build and run Rakudo against anything but Parrot's build tree, short of doing a fair bit of copying things around and specialized linking to make it work.

      I just haven't wanted to invest a lot of my time into building (temporary) scaffolding to work around the missing pieces