in reply to Re^13: 5.10 imminent?
in thread 5.10 imminent?

Why not just use their shorter and unambiguous actual name?

Well, two reasons, the most important being I was in a rush (relatively speaking -- i was procrastinating doing something with a deadline at the time) and couldn't be bothered to look up the /actual/ names. (Sorry about that.) But the other reason is that you can actually control the names of the files, by using the -p option with configsmoke. Try doing perldoc lib\configsmoke from the run directory for more options.

Regarding your friend the technical author, i know what you mean. Its hard to document/explain something that you know really well without falling into these types of traps. Review by third parties is always useful.

Anyway, do remember that not a lot of people have set up smoke, and even less on win32, and that the package is a work in progress. Contributing back improved documentation would be very useful. :-)

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^15: 5.10 imminent?
by BrowserUk (Patriarch) on Apr 14, 2007 at 00:12 UTC
    (Sorry about that.)

    Again, unnecessary. My words were more of a defense of my acting "stupid", than any critism of your timely intervention in this thread. I have to wonder about the need for the ability to change the names, but there is undoubtedly some system somewhere where the default names happens to coincide with the system command for formatting the hard drive or some such :)

    Anyway, do remember that not a lot of people have set up smoke, and even less on win32,

    Understood. I started the process at 18:22:14, and I'm trying to take notes as I go. I didn't expect it to take this long or require this amount of manual intervention.

    The problem is that the test suite makes several calls to system functions that cause my firewall to intervene with popups requesting authorisation. Pre-authorising perl.exe and miniperl.exe doesn't help much because it also detects changes in authorised executables and as the smoketest keeps rebuilding them--it still keeps prompting. Still doesn't allow unattended operation.

    This is the same problem I encountered when I considered setting up smoke testing on win32 some some 4 years ago.

    Alternatives:

    1. Disconnect from the internet and disable the firewall.

      The tests will still fail.

      Many years ago, crazyinsomniac or podmaster suggested (in a post I can't now find), that he had tried to float the idea of removing/disabling these tests that cause internet access with p5p, but it fell on deaf ears.

    2. Leave the internet connection active and disable the firewall.

      Not an option. My firewall logs record some 280+ attempted incoming scans of various ports in the 7 hours this has been running.

    3. Other...?
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      I have to wonder about the need for the ability to change the names

      Well, I have two sets in my smoke directory, one for "maint" (Aka Perl 5.8.x) and one for "current" (Aka Perl 5.9.x). You didnt run perldoc yet did you? :-)

      The problem is that the test suite makes several calls to system functions that cause my firewall to intervene with popups requesting authorisation.

      Personally I'd just tell your firewall to ignore anything in the smoke tree. Alternatively just let the tests fail i guess. If anybody wants to know why they will ask.

      ---
      $world=~s/war/peace/g

[reply]
        Well, I have two sets in my smoke directory, one for "maint" (Aka Perl 5.8.x) and one for "current" (Aka Perl 5.9.x). You didnt run perldoc yet did you? :-)

        Seems to me that if Test::Smoke were included in the distribution, a) it would save another install step; b) it could be set up to test the distribution is was a part of and each distribution would be 'self-contained'.

        Alternatively, a command line parameter to the batchfile could identify the relative path of the distribution to be tested.

        And no, I didn't run perldoc yet. I thought I'd get through the first run with the default settings before getting sidetracked in to looking at what options were available and being tempted to try them out. Just trying to get a consistant set of notes written down vefore thinking about variations :)

        Personally I'd just tell your firewall to ignore anything in the smoke tree.

        I don't think my firewall has that option, (and I'm not sure I like the implications of it if it has), but I'll look into it.

        BTW. The smoketest just finished. It ended with: 

        c:\Perl\src\run>smokecurrent.cmd
mkdir : No such file or directory at lib\archiverpt.pl line 115

        [download]

        I saw an option during configuration asking about archiving, I selected the default which I think was 'Don't keep an archive'. Does that explain the above message? Or has something failed that invalidates the test?

        I was antisipating seeing some message telling me what to send where to complete the process, but I haven't. So, what should I be sending and where?

        Note: I chose not to configure an email address during the setup. I don;t like automated transmissions--I like to know what is being sent--does that screw things up?

        Phew! 9 hours and about 200 manual interventions. And I'm meant to do this daily?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Seekers of Perl Wisdom