Front page | perl.perl5.porters |
Postings from June 2006
>> Frankly, I've seen almost zero reasons for patches needing to be >> submitted HERE (if I'm understanding your patch rejection claim as being >> to here to be correct). > > Then you arent looking closely enough, or dont know enough about the > Win32's API to actually know when such support would benefit things. > Sorry to put it so harshly but thats my view. My point is that I, and anyone else, should not HAVE to know the APIs, just like I don't know how many other things work. >> Since Vanilla was created, we've fixed literally dozens of Win32 bugs, >> and with only one exception (IO::Socket) has there been any need for any >> involvement from this list. > > Yeah, youve fixed some bugs, ive fixed some bugs, we all fix bugs. > > Considering functionality consider File::Spec still doesnt use the > Win32 API where it should be doing so, but youve probably never needed > File::Spec to behave properly. You cant install all modules properly > on Win32 without Win32API::File, you cant monitor process properly > without Win32::Process, you cant monitory directory change events > without Win32::ChangeNotify, you cant write to the eventlog without > Win32::EventLog. You cant write to the registry without > Win32API::Registry. Yada yada yada. As I said, the fixes need to not break existing code. File::Spec::Win32's basic functions can be loaded and used even when not on a Win32 host, which is useful for various purposes, and code doing this is in current use. Would you break that code to add the feature you want? As to the rest, none of it necessarily needs to be in the core. Win32API::File perhaps for the use of ExtUtils::Install, but little else is critical, NOW. What should or should not be in the core is an entirely different conversation. I don't need to look at Win32::Process, I don't need to do change notification. If I want to do it, I'll install a module. This ALREADY works just fine with Win32API::Registry. I need File::HomeDir on windows, it needs Win32::TieRegistry, that needs Win32API::Registry, they all install, and I continue onwards. That is no reason to be in the core. You've asserted that the core should contain some complete minimum set of functionality. That is your prerogative as a distribution author should you choose to create one, but it's still no reason to be in the core. >> As for merging Win32 stuff into core, which has been mentioned before as >> well, I'm still not clear that we have sufficient evidence for it. Such >> evidence needs to be extremely clear, and not based solely on the >> opinions and assertions of individuals. > > Its not an opinion when i say these things. They are facts. You cant > do things you should be able to do with a core perl. > > And frankly I think you should be more receptive of what Win32 > programmers with experience tell you. For two reasons, if you listen > you might avoid repeating hard lessons they have learned, but much > more importantly you will be less likely to discourage them from > participating. There is somethign incredibly frustrating when someone > without any experience telling you that an opinion you have formed > over many frustrating hours of hard work is rubbish. Frankly if I have > to prove things to YOU then im not going to bother and think a lot of > Win32 people will feel the same. > > OTOH, if somebody posts a suggestion and you dont understand it, a > positive reception to the post and a requerst for clarification would > probably go a long way. > >> Again, this is half the reason why Vanilla will be left is pure-core. > > Yes i agree with that objective. However since the objective is to get > CPAN modules running instead of getting CPAN running properly I think > youll only get half the job done. You see the problem is that if you > dont know the API reasonably well you dont even know when something > could be done better via the API. These are two entirely different objectives. First is that Perl works on Win32. Second is that it works better. I see little point in making significant changes to existing code, when currently it doesn't work at all, even if the current implementation is non-ideal. It is far far easier to establish proof-of-concept cases to prove one's assertions and provide real evidence for one's opinions when you can back it up with working code. As I've said a number of times, when it comes down to wanting a change that needs to be made, opinions don't cut it, nor do assertions that things are fact. Ultimately it comes down to code. >> I think we may be relatively close to enough evidence for perhaps >> including Win32API::File. > > Id have thought the case would be simple. You cant upgrade Pathtools > and several other modules without it (under some operating conditions > anyway). You cant upgrade XS modules that are in use without it. To me > thats about the end of the story. Indeed. And while previously we had only words, through your excellent efforts, we now have what I think is probably clear enough proof, in the form of ExtUtils::Install. And if you wanted to campaign for the addition of Win32API::File ONLY to the core, on the basis that ExtUtils::Install is in the core, then I'd be happy to support that. But the rest, the upgrading of File::Spec, I've yet to see more than just assertions. Do you have an URIs etc? Do you have a proof of concept module that shows it working we can see? Adam K