Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by adamk (Chaplain)
on Apr 02, 2006 at 09:45 UTC ( #540721=note: print w/ replies, xml ) Need Help??


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

Let me restate my previous point.

I'm NOT saying that it isn't a good thing to support more compilers. Playing well with others is a GOOD thing.

And most of this grant is not about adding MinGW compatibility, because almost everything works already anyway.

This grant is firstly about fixing things in Bundle::CPAN that don't work, or have major bugs, on any Win32 platform, Vanilla or Strawberry or ActivePerl or otherwise.

Because there's a lot of bugs for things as simple as Term::ReadLine::Perl, or that to relate to the fact CPAN.pm doesn't play well with the Windows firewall. All the normal portability and platform-specific stuff.
And the second part is fixes to deal with other secondary problems that have emerged because the bulk of Windows users currently don't need to use CPAN, and a few bug fixes to remove assumptions caused by CPAN authors treating ActivePerl bundled modules as if they are in the core and thus not listing those dependencies in their (Makefile|Build).PL

That's what THIS grant is about. IT's about making all the modules in the Perl toolchain intrinsically sane on Windows.

This doesn't invalidate the importance of adding support for newer and different compilers. But it is a mostly orthogonal task, and so it would be the subject of a different grant.

And in the process, this grant creates an option for people to use a Perl distribution that is both simple to install, without requiring a knowledge of C, and entirely libre from the compiler on up.

Because I for one don't write C, can't stand Visual Studio, and just want my Perl modules to install, without having to care about C compilers.


Comment on Re^5: [JOB] The Perl Foundation seeks Windows Developer
Re^6: [JOB] The Perl Foundation seeks Windows Developer
by demerphq (Chancellor) on Apr 02, 2006 at 20:18 UTC

    and a few bug fixes to remove assumptions caused by CPAN authors treating ActivePerl bundled modules as if they are in the core and thus not listing those dependencies in their (Makefile|Build).PL

    IMO the much better solution is to just put those modules in Core in the first place.

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

      Even if certain Windows-specific modules were added to the core _today_, these fixes would still need to be done to deal with older installed Perl versions.

      Whether or not something should be in the core is an orthogonal problem to this grant, but I'll address it in my reply to one of your other comments, below.

        Even if certain Windows-specific modules were added to the core _today_, these fixes would still need to be done to deal with older installed Perl versions.

        Ive said it a lot of times Adam, a lot of these fixes can't be done without proper access to the Win32 API. And as long as that API is reachable only through a non core module set the issues involved with adding better support become much more difficult. You can't just say "am I on Win32? Yes ok, better use the Win32 tools" you have to say "am I on Win32 AND do i have the required modules available". Which complicates things and means that less Win32 folk are going to bother to try to add proper Win32 support to core modules.

        Not only that, but look at the mantra of P5P, it basically says "fix what you like, but you can't use non-core modules to do it". Which means for instance that functionality in EU-I simply cant be used or tested under a core build. (Although what I find really amusing is that you can added Win32 API support to core modules, but only via XS, for some reason providing that access through a perl layer is verbotem. So we have Win32API calls for specialized purposes scattered throughout the core, but always hidden so that end users can't make use of them in interesting new ways. Which is bad because it raises the skills requirement for improving Win32 perl, not only do you need to be conversant with the API, you need to be a good perl programmer, and a good C/XS programmer.)

        As an example using core perl there is only one sharing mode that you can open a file with, using Win32API::File there are a variety, including the mode that Windows itself uses to lock DLL's but still allow them to be renamed. (Annoyingly the default open mode for Cygwin is different from the default open mode of native builds. This is why you can delete files opened with Cygwin perl, but not AS perl)

        Similarly since Win32API::File is omitted from Core it is unsurprising to me that File::Temp uses broken *NIX based logic to do its thing on Win32. Wheras if Win32API::File were included in core then the author of F::T (apparently not a win32 developer) might have looked at the documentation for Win32API::File and found out that Windows supports an OS level temporary file which will be autodeleted once all filehandles to it are closed. Or with even better API support he might have found the API call that windows provides to produce a guaranteed unique temporary file.

        But since this stuff isn't available to Core, and since non Win32 developers seem to have this strange aversion to using MSDN library search, (maybe because they know that since there is no support for such in core there isnt any point in searching) the fact is that non-win32 programmers will never even know that there are better ways to do things on Win32.

        So I stick to my guns: adding proper win32 API support to core is not a nice to have, its an essential part of improving Perl support on Win32. And doing it in blead even will be a signal to the community that the investment in making the code work better on Win32 will not be a wasted one.

        And as a closing thought consider this: In VB you can bind to a Win32 API call with one line of code. In Perl you cant bind to API at all out of the box. That VB can provide better OS access than Perl does is just wrong.

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

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2014-07-12 20:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (241 votes), past polls