Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^4: [JOB] The Perl Foundation seeks Windows Developer

by xdg (Monsignor)
on Apr 02, 2006 at 21:15 UTC ( [id://540800]=note: print w/replies, xml ) Need Help??


in reply to Re^3: [JOB] The Perl Foundation seeks Windows Developer
in thread [JOB] The Perl Foundation seeks Windows Developer

I could see the standard response to questions about build problems of packages on win32 being "it works with Vanilla Perl, so it must be Active State that is broken", which wouldn't help many users.

It wouldn't help many users of ActiveState Perl, you mean. If ActiveState is broken and something else works, isn't that an improvement for users in general? Maybe some friendly co-opetition would improve ActiveState, too.

As to the Scalar::Util thing -- it has more to do with the fact that ActiveState's auto-build procedure uses their earliest 5.8 Perl release as the the basis for PPM generation without any upgrades to any modules in core. 8xx PPM's are supposed to be ones that will work with the earliest 5.8 Perl released by ActiveState -- which was several years ago. So anyone depending on ActiveState-built PPM's has to accept a 3-year lag in compatibility.

It's compounded by the fact that Perl can't easily replace core modules on Windows if they are in-use. demerphq has recently patched ExtUtils::Install to use the Win32 API to do this on Windows (and the old files are removed at the next reboot). That's great news for VanillaPerl, but doesn't help ActiveState as, again, they're stuck with ExtUtils::Install from 5.8.0.

The inability to rely upon any upgrades to core modules in 5.8 is a major flaw in my opinion. I'm sure there have been substantial bug-fixes to numerous core modules from 5.8.0 to 5.8.8. But any distribution that depends on certain behavior of upgraded modules will fail a dependency version requirements checks for building a PPM or may not behavior properly if the dependency version is ignored.

A good example of that is File::Spec and company. Look at the Changes file and look at how many Win32 bug fixes there have been in the last year alone. There are a lot. Any any code which relies upon those bugs being fixed can't require a modern File::Spec and still pass ActiveState's PPM build process.

The point is that this is not "standard version control ripples" as you put it. This is a fundamental difference in the philosophy of module packaging, distribution and support. Both are valid and they just serve different "customers" who have different wants.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^5: [JOB] The Perl Foundation seeks Windows Developer
by syphilis (Archbishop) on Apr 03, 2006 at 03:28 UTC
    demerphq has recently patched ExtUtils::Install to use the Win32 API to do this on Windows (and the old files are removed at the next reboot). That's great news for VanillaPerl, but doesn't help ActiveState as, again, they're stuck with ExtUtils::Install from 5.8.0.

    Not so. The latest build of ActiveState perl has EU::MM-6.30, which includes EU::I-1.33 - all of which is stock-standard perl 5.8.8.

    Cheers,
    Rob

      The latest ActiveState build is standard 5.8.8. But the ActiveState automated PPM build farm is the first 5.8 release by ActiveState.

      That means that for any module to be automatically built into a PPM, it has to be backwards compatible with Perl 5.8.0 core modules, even if the latest ActiveState release includes updates.

      Here's an example from the PPM Build Status for my own Class::InsideOut:

      # Tried to use 'Class::InsideOut'. # Error: "refaddr" is not exported by the Scalar::Util module # Can't continue after import errors at D:\cpanrun\depot\main\contrib- +patched\perl\CPAN\src\Class-InsideOut\blib\lib/Class/InsideOut.pm lin +e 16 # BEGIN failed--compilation aborted at D:\cpanrun\depot\main\contrib-p +atched\perl\CPAN\src\Class-InsideOut\blib\lib/Class/Idubious

      Now let's climb in the way-back machine to Perl 5.8.0 in July 2002 and look at the Scalar::Util source:

      # Scalar::Util.pm # # Copyright (c) 1997-2001 Graham Barr <gbarr@pobox.com>. All rights re +served. # This program is free software; you can redistribute it and/or # modify it under the same terms as Perl itself. package Scalar::Util; require Exporter; require List::Util; # List::Util loads the XS our @ISA = qw(Exporter); our @EXPORT_OK = qw(blessed dualvar reftype weaken isweak tainted read +only openhandle); our $VERSION = $List::Util::VERSION;

      Notice how refaddr is missing? For reference, in Perl 5.8.0, $List::Util::VERSION happens to be 1.07.

      By Perl 5.8.1 in September 2003, Scalar::Util was up to 1.13 and refaddr was available in core Perl.

      But -- to my point -- Class::InsideOut can't be built automatically into a PPM by ActiveState because their build farm is designed to be backwards compatible nearly 4 years all the way to 5.8.0.

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        But -- to my point -- Class::InsideOut can't be built automatically into a PPM by ActiveState because their build farm is designed to be backwards compatible nearly 4 years all the way to 5.8.0.

        Oh, theres a simple and easy solution to that. Dont use Scalar::Util to get refaddr(). Get it from Data::Dump::Streamer instead. At the same time you can add the DDS serilization support you mentioned a while back. And since DDS builds just fine under the PPM infrastructure everything will work out nicely.

        And if you want a less painful to use reftype() function you can get it from DDS too. :-)

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

Re^5: [JOB] The Perl Foundation seeks Windows Developer
by BrowserUk (Patriarch) on Apr 02, 2006 at 21:47 UTC
    It's compounded by the fact that Perl can't easily replace core modules on Windows if they are in-use. The inability to rely upon any upgrades to core modules in 5.8 is a major flaw in my opinion

    I don't get this? I install upgrades to core modules all the time and I never have to re-boot afterwards. What is this all about?


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Classic example is Cwd. CPAN uses Cwd internally. This means the Cwd.dll is locked when you try to build and install Pathtools from CPAN shell. The simple solution is to exit CPAN and go to the Pathtools directory and do the build by hand. But that only works if you are using ExtUtils::MakeMaker to do the build. If you use Module::Build then you have the same problem as CPAN would as MB also uses Cwd.dll

      Likewise this problem shows up in situations where you are upgrading XS modules that are in use elsewhere in the system. For instance i have some processes that run 24 hours a day. With the updated ExtUtils::Install I can install new versions of XS modules that this process uses, and it Just Works. Without the new version EU::I Just Fails because the dlls are locked and cannot be deleted.

      The strategy employed by the newer EU-I code is to try to rename the locked dll to a temporary name, install the new code, and schedule the renamed dlls for deletion at boot. If the rename fails it installs using a temporary name and arranges the replacement of the in use file at reboot.

      So, there are a variety of ways that you could avoid needing this functionality, but that doesnt mean the functionality is unneeded.

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

        Needless to say, (or perhaps it does need to be said?), I do understand both the problem you addressed and the MoveFileEx & MOVEFILE_DELAY_UNTIL_REBOOT solution that I assume you have used to address it.

        As an aside to the primary subject of this thread, I believe that for most situations, (Ie. excluding the one you cite of a longing running Perl process that is using the DLL that is to be replaced), there is a somewhat easier solution that removes the need for the above API. I need to test it, but I will post/email you the details once I have and you can see if you think that it merits inclusion as a part of your fix.

        In simple terms, if the module to be replaced is in use only by the current perl process (Ie. the one attempting to perform the replacement), then calling FreeLibrary(), or possibly FreeLibraryAndExitThread(), then overwrite the DLL, and the call LoadLibrary() to make the new version available to the current process--if required.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

      As I understand it, if a file is open, e.g. C:\perl\lib\CPAN.pm, that file can't be deleted by Windows. You can install a newer version as C:\perl\site\lib\CPAN.pm, but @INC lists C:\perl\lib before C:\perl\site\lib, so you'll wind up using the older version when you think you're using the newer one.

      demerphq's patch (not yet on CPAN) uses Win32 API calls that effectively rename the open file, install the new file in place of the old one, and schedule the renamed old file for deletion upon next reboot. (Ever see how Windows install/uninstall programs tell you they can't complete until rebooting? Same thing.)

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        As I understand it, if a file is open, e.g. C:\perl\lib\CPAN.pm, that file can't be deleted by Windows.

        Whilst true, this is a Good Thing(TM) not a bad one. And the simple answer is to close the file before you try and delete it. Of course, that doesn't solve the real problem, but it would for the problem as you describe it.

        But the bigger problem is that your understanding of the actual problem that demerphq has addressed in incorrect.

        Ever see how Windows install/uninstall programs tell you they can't complete until rebooting?

        Of course.

        Same thing.

        Actually not!

        For the real problem see demerphqs post at Re^6: [JOB] The Perl Foundation seeks Windows Developer.

        And that succinctly demonstrates my biggest fear with respect to the proposal in the OP. It is being driven by the needs of people who do not know the platform and it's APIs, and are proposing solutions without a full understanding of the real problems, or the possibilities available for solving them.

        Did you ever hear/read the lyrics to the old XTC song, Making plans for Nigel?


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://540800]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2024-03-29 00:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found