ANNOUNCE: ActivePerl 5.14.4.1405 and 5.16.3.1603 released
ActiveState is pleased to announce the release of - ActivePerl 5.14.4 build 1405 - ActivePerl 5.16.3 build 1603 complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's New? === All builds are based on the latest corresponding core release of Perl and include updated bundled modules as well. Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1603 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: 'moving' an activeperl install to a new machine (xp to windows 7)
On Fri, Mar 15, 2013 at 1:12 PM, Greg VisionInfosoft gai...@visioninfosoft.com wrote: hi all, ive got a wonderfully working activeperl 5.8.9 environment that was originall setup on Windows XP. so that i dont need to reinstall the many, many packages that ive ammased throughout the years - i had the thought to simply copy my entire 'perl' folder from the older windows xp pc to my newer windows 7 pc. certainly this will move perl and all packages just fine... I think this should work fine as long as you preserve the original install location, i.e. if it was installed into C:\Perl, then put it into C:\Perl on the new machine as well. the problem with this, is i dont know how to preserve the built-in PPM database functionality. I don't think you need to. PPM should recreate everything for you automatically when you invoke it again. Note thought that PPM has changed a bit since the days of Perl 5.8, so things may be different, but it can't hurt to just try it. On the other hand, maybe this is a good opportunity to move to a newer version of Perl? Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ANNOUNCE: ActivePerl 5.12.5.1206, 5.14.3.1404, and 5.16.2.1602 released
ActiveState is pleased to announce the release of - ActivePerl 5.12.5 build 1206 (Business Edition only) - ActivePerl 5.14.3 build 1404 - ActivePerl 5.16.2 build 1602 complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's New? === All builds are based on the latest corresponding core release of Perl and include updated bundled modules as well. Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1601 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: dealing with Win32::OLE in when on non-win32 platforms?
On Fri, Nov 2, 2012 at 2:39 PM, Dave Horner d...@thehorners.com wrote:
Hello,
I found this address from the following:
http://vlsicad.ucsd.edu/Resources/SoftwareLinks/ActivePerl/Perl-Win32/perlwin32faq12.html
I am looking for guidance on how to use Win32::OLE qw(in) on multiple
platforms.
It works fine on windows, but on other platforms, I'd like the code to
not be used.
I tried using tricks like:
eval 'require Win32::OLE qw( in )';
if ($@) {
But I am still getting:
Array found where operator expected at myscript.pm line 1693, at end of line
(Do you need to predeclare in?)
Which is coming from the line:
my @drivelist=$objnet-EnumNetworkDrives();
foreach my $value (in @drivelist) {
inside of the if ($@) { block, which I was hoping wouldn't be compiled
and checked on non-win32 platforms.
Any suggestions on how I go about defining in or properly
conditionally including Win32::OLE and it's in definition.
You need to make sure that the Perl compiler understands that 'in' is a function
and not a bareword. You can do this by either adding this line to
your file (before
you make any calls to 'in'):
sub in;
Or you can write all calls to in() with parenthesis:
foreach my $value (in(@drivelist)) {
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.16.1
ActiveState is pleased to announce ActivePerl 5.16.1 build 1601, a complete, ready-to-install binary distribution of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl ActivePerl 5.16 is now based on the 5.16.1 release. You can read about all the changes since Perl 5.16.0 in the perldelta document: http://docs.activestate.com/activeperl/5.16/lib/pods/perl5161delta.html In addition, the 64-bit version of ActivePerl 5.16.1 for Windows now automatically supports building and installing additional modules with MinGW64 and dmake. These tools are available via PPM the same way MinGW has already been supported in the 32-bit version. Also improved is the way Perl will automatically configure itself on Mac OS X to the installed version of XCode to locate the GCC compiler and tools. Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1601 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.16.0
ActiveState is pleased to announce ActivePerl 5.16.0 build 1600, a complete, ready-to-install binary distribution of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl ActivePerl 5.16 is now based on the 5.16.0 release. You can read about all the changes since Perl 5.14.0 in the perldelta document: http://docs.activestate.com/activeperl/5.16/lib/pods/perl5160delta.html Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1600 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Calling a Perl exe with VB - VB/Windows changing current path
An executable built by PerlApp can call the PerlApp::exe() function to get the location of the executable itself. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Ashley Hoff Sent: Thursday, April 12, 2012 5:38 PM To: perl-win32-users@listserv.ActiveState.com Subject: Calling a Perl exe with VB - VB/Windows changing current path Howdy Fellow Win32 Perl users. At the moment we are in the process of modding a few file munging app’s to make them Cross platform – this means taking the existing Perl from our Unix based servers, making them compatible with Win32, compiling using PDK and then modding some existing Windows apps (VB 6) to call the compiled Perl. (We are using the existing VB apps, as apparently Ops can’t use command line and don’t like change L ) Everything seems to work fine until you navigate to a file via the Windows front end, which then changes the current path to where ever the file is located, which the Perl app is picking up on. This is an issue as I want to write a report to a subdirectory of where the app is, not where the files are found. I have overcome the issue at the moment using Cwd 'abs_path' and abs_path($0), then using a substitute to re-construct the path of where the Reports are to go. What I would like to know, is there a way that Perl can keep in control of its current path? Or is this something that I should get our VB guru’s to look at? (they have asked me to fix it in the Perl….. Maybe they are just being lazy) Cheers Ashley --- Disclaimer: Confidentiality: This message contains privileged and/or confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, re-transmit, copy or take any action in reliance on it. If you have received this message in error please delete the document and notify Data Action immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Data Action. Viruses: Any loss/damage incurred by using this material is not the sender's responsibility. Data Actions' entire liability will be limited to resupplying the material. No warranty is made that this material is free from computer virus or any other defect. --- ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: gui debuggers?
Daniel, There is no GUI debugger included in ActivePerl (I think Mark may be mixing it up with the GUI interface to Perl::Critic, which was initially added to the PDK, but has been moved to ActivePerl since then). However, the GUI debugger from your PDK should still work with the latest ActivePerl, even though PerlApp friends won't (I can't remember what was included in PDK 6, but generally everything that was labeled a productivity tool should be version independent, whereas everything labeled a deployment tool has code that needs to be adapted to each Perl release). Cheers, -Jan On Mon, 19 Mar 2012, Daniel Rawson wrote: Mark - Thanks . . . I get the command-line debugger when I start with -d . . . more research, I guess :-) Dan On 03/19/12 06:37 AM, Mark Dootson wrote: I think you'll find ActivePerl 5.14.2 comes with its own graphical debugger. If it doesn't load by default with -d, you must have some setting present that prevents this. On 19/03/2012 10:15, Daniel Rawson wrote: My work system was recently upgraded to Windows 7 and ActivePerl 5.14.2 - I had been using v5.8 + PDK v6 for years. Unfortunately, the old 32-bit PDK doesn't work with my company-provided install of 5.14.2. In addition, the Devel::ptkdb module is not available for 5.14. I've been using the regular command-line debugger, but I would love to find another GUI debugger. Suggestions? Thanks Dan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: gui debuggers?
The relevant value is PERL5DB. It should have been set by pdkdebug
for you, but maybe there is some permissions issue if you don't
run it elevated.
pdkdebug will set this variable in the registry under the Perl key,
but you can also add it manually to the environment yourself.
The value should be something like:
{BEGIN {require qC:\...\bin\lib\PerlDB.pl}}
without the quotes, and you have to figure out the exact path yourself
(it may not even be under the PDK/bin/lib directory in PDK6, I can't
remember).
Cheers,
-Jan
On Mon, 19 Mar 2012, Daniel Rawson wrote:
Jan -
Thanks . . . I did finally get it to install, but it won't start by default
from perl -d :-(
I tried setting PERL5LIB to the install path, but that didn't help. The
debug listener is running,
and -query shows that it's running in local mode . . . . any other ideas?
Thanks!
Dan
On 03/19/12 12:55 PM, Jan Dubois wrote:
Daniel,
There is no GUI debugger included in ActivePerl (I think Mark
may be mixing it up with the GUI interface to Perl::Critic,
which was initially added to the PDK, but has been moved to
ActivePerl since then).
However, the GUI debugger from your PDK should still work with
the latest ActivePerl, even though PerlApp friends won't
(I can't remember what was included in PDK 6, but generally
everything that was labeled a productivity tool should be
version independent, whereas everything labeled a deployment
tool has code that needs to be adapted to each Perl release).
Cheers,
-Jan
On Mon, 19 Mar 2012, Daniel Rawson wrote:
Mark -
Thanks . . . I get the command-line debugger when I start with -d . .
. more research, I guess :-)
Dan On 03/19/12 06:37 AM, Mark Dootson wrote:
I think you'll find ActivePerl 5.14.2 comes with its own graphical
debugger. If it doesn't load by default with -d, you must have some
setting present that prevents this.
On 19/03/2012 10:15, Daniel Rawson wrote:
My work system was recently upgraded to Windows 7 and ActivePerl
5.14.2 - I had been using v5.8 +
PDK v6 for years. Unfortunately, the old 32-bit PDK doesn't work with
my company-provided install of
5.14.2. In addition, the Devel::ptkdb module is not available for
5.14.
I've been using the regular command-line debugger, but I would love
to find another GUI debugger.
Suggestions?
Thanks
Dan
--
The information contained in this communication and any attachments is
confidential and may be
privileged, and is for the sole use of the intended recipient(s). Any
unauthorized review, use,
disclosure or distribution is prohibited. Unless explicitly stated otherwise
in the body of this
communication or the attachment thereto (if any), the information is provided
on an AS-IS basis
without any express or implied warranties or liabilities. To the extent you
are relying on this
information, you are doing so at your own risk. If you are not the intended
recipient, please notify
the sender immediately by replying to this message and destroy all copies of
this message and any
attachments. ASML is neither liable for the proper and complete transmission
of the information
contained in this communication, nor for any delay in its receipt.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: gui debuggers?
On Mon, 19 Mar 2012, Daniel Rawson wrote: Chris - That's what I was afraid of . . . .my 5.14.2 install is definitely 64-bit, but the old PDK is from 2004, so it's certainly 32-bit :-( The 32-bit PDK debugger should still work with 64-bit Perl. They run in separate processes and just exchange information in text format. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Why can't linker find CreateJobObjectA ?
On Sun, 18 Mar 2012, Sisyphus wrote: On Wed, 14 Mar 2012, Mark Dootson mark.doot...@znix.com wrote: Hi, On 11/03/2012 23:52, Sisyphus wrote: An afterthought or two: It's a bug, right ? (It smells like a bug to me.) Is it a bug in perl ? I'm thinking that CORE/win32.h should be assigning the value associated with the actual OS on which perl is running, rather than just assigning the minimum supported value. Sorry for jumping into the thread late, but here are the reasons for how things are done the way they are (which by implication means I don't consider the current state to be a bug): CORE/win32.h does indeed define WINNNT, and it is being set to the lowest version of Windows still supported by that Perl version. Note that since Perl 5.12 the minimum Windows version is Windows 2000, so WINNT is now set to 0x0500 and CreateJobObjectA should be accessible without any problems. If you need to access newer APIs from C code, then the proper way to do this is to runtime-link to them using GetProcAddress. You can see an example in my implementation of the link() function for Perl when we still supported Windows NT (and Windows 95): http://perl5.git.perl.org/perl.git/commitdiff/6b980173#patch12 +BOOL (__stdcall *pfnCreateHardLinkW)(LPCWSTR,LPCWSTR,LPSECURITY_ATTRIBUTES); +WCHAR wOldName[MAX_PATH]; +WCHAR wNewName[MAX_PATH]; + +if (IsWin95()) + Perl_die(aTHX_ PL_no_func, link); + +pfnCreateHardLinkW = + (BOOL (__stdcall *)(LPCWSTR, LPCWSTR, LPSECURITY_ATTRIBUTES)) + GetProcAddress(GetModuleHandle(kernel32.dll), CreateHardLinkW); +if (pfnCreateHardLinkW == NULL) + pfnCreateHardLinkW = Nt4CreateHardLinkW; On Windows 95 it will simply fail with an error message if you invoke the link() function, but otherwise the Perl is still loadable and functional. On Windows NT and later it tries to locate the CreateHardLinkW() API at runtime (and uses a backup internal implementation when it isn't available). This means a single Perl binary can be used on all supported Windows versions, and still have newer functionality available on the later versions. All this code got ripped out in Perl 5.12 when the minimum Windows version was raised to Windows 2000 and CreateHardLink() was now guaranteed to be available. If your own XS or Inline code doesn't want to do this (because the module doesn't provide any value at all if the newest APIs are not available), then you can just set WINNT at the top of your code before you include the Perl header files. win32.h will not redefine the symbol if it is already defined: #ifndef _WIN32_WINNT # define _WIN32_WINNT 0x0500 /* needed for CreateHardlink() etc. */ #endif Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32::OLE events callback not executed
On Mon, 19 Mar 2012, Howard Tanner wrote: I couldn't get any events to be fired either. Perhaps Jan can weigh in since he seems to be around today. Sorry, I don't know _why_ it isn't working, but I've seen others run into the same problem with SAPI. Unfortunately I don't have time to play with SAPI stuff myself, so I won't be able to help much. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: simple question about using activestates PPM repository
The problem is that there are two PPM4 repositories for ActivePerl 5.8, one for builds 818-824, and one for builds 825 and later. I can’t remember the details, but there was some issue fixed in build 825 that made PPM build a lot mode modules. But modules built against 825 may link against symbols added in 825, so may not load/work correctly in earlier versions. But the improvement in 825 was obviously big enough that we thought it would justify having to maintain 2 repositories. Now, the 818-824 repository hasn’t been updated anymore since August 2009, so it will not contain any modules released after that time. You may be able to use modules from the 825+ repo, but certain modules do break in mysterious ways if you do that, so I would recommend against it. Please note that ActiveState announced that the 5.8 and 5.10 repositories would no longer be updated in June 2011, and would become unavailable at the end of 2011. So the fact that the 825+ repo is still available and updated is rather coincidental and should not be relied on for the future. Given that Perl 5.16 is around the corner, I would urge you to upgrade to at least 5.14 in the near future. As per our support policy, Perl 5.12 will become unsupported as well once 5.16 is released. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Friday, March 16, 2012 10:38 AM To: Perl-Win32-Users@listserv.activestate.com Subject: simple question about using activestates PPM repository im t rying to install a perl module from this activestate repository url page ( http://code.activestate.com/ppm/WebService-Dropbox/ http://code.activestate.com/ppm/Test-TCP/ ) it states... ultra easy to install, merely type 'ppm install Test-TCP' expanding that instruction with the [+] at right doesnt really shed any more lower level info thats actually required to make this happen. it says: 1.Download and install http://www.activestate.com/activeperl/downloads ActivePerl 2.Open Command Prompt 3.Type ppm install Test-TCP but in fact, ppm has a notion of 'repositories' its been set up to look through. when i inspect the currently entered activestate ppm url that my ppm (v 4.01) uses, it shows this url: http://ppm4.activestate.com/MSWin32-x86/5.8/820/package.xml when i then try 'ppm install WebService-Dropbox', ppm fails with... C:\Perl\binppm install WebService-Dropbox Downloading ActiveState Package Repository packlist...not modified Downloading trouchelle packlist...not modified Downloading theoryx5 packlist...not modified Downloading sisyphusion.tk 5.8 packlist...not modified ppm install failed: Can't find any package that provide WebService-Dropbox yet, i know that in fact, that there is both a .tar.gz and matching .ppd file for this package thats available at activestate - at these specific urls: http://ppm4.activestate.com/MSWin32-x86/5.8/825/A/AS/ASKADNA/WebService-Dropbox-1.05.tar.gz http://ppm4.activestate.com/MSWin32-x86/5.8/825/A/AS/ASKADNA/WebService-Dropbox-1.05.ppd (i know this as ive manually downloaded them to my pc, originally i was going to just manually download the required tar.gz and .ppd files but all of these dependencies to also get and isntall manually is finally taking its toll on me.) there must be something wrong in the url ive set to use for activestates ppm repository and/or perhaps there is some need to 'refresh' my ppm to make sure its 'seeing' all of the latest packages (eg, perhaps ppm caches this list and its not been locally updated for years now). finally to say, years ago, i was able to enter the listed activestate package.xml url into a browser to get back an ASCII human readable list of all packages. today when i try the same thing, all of my browsers crash when i enter that url into them. and if i instead use a perl 'http-get' script to move the file to my pc (thus bypassing a web 'browser', it does indeed move to my pc and create a 1.5 mb file on my pc, but alas, when i try to open it, the contents are binary, not ASCII. what gives here? most all other repositories allow one to download the package.xml list in a human readable ascii form. i dont understand if somethings broken here with the actual package.xml file, and/or if there is merely a simple fix i need to do with my ppm to cause it to 'see all of the latest active state packages available for perl 5.8.8 build 820 any help would be GREATLY appreciated, greg ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Daylight Savings Time?
On Thu, 26 Jan 2012, Barry Brevik wrote: In list context it returns the DST state as the last value so (localtime())[-1] would give that value. OK, that is just lame of me to miss that. Thank you so much. Not sure if this matters to you, but at least older versions of Windows (before Vista) did not store historical DST information (the Olson database). Instead it would apply the latest set of DST rules to all previous years as well, so the DST state for dates in the past may be incorrect. But even though historical data is now available in the OS, I would still double check if the C runtime library used by Perl makes use of it or not. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Window 7 x64, @inc search question
On Mon, 09 Jan 2012, Brian Raven wrote: On Mon, 09 Jan 2012, Styma, Robert E (Robert) wrote: Well I tried upgrading to the newest Perl 5.14 which is also 64 bit capable. I discovered that Tk.pm is not yet available from ppm. So I backed off to 5.12 which says Tk.pm is available on the ppm web site. For reasons I have not yet figured out, I get timeouts accessing ppm4.activestate.com. Firewall/proxy settings? That address gets me redirected to http://code.activestate.com/ppm. That should only happen for the build status pages. The actual repos do live on the ppm4 site. You can check access status for the ppm repos by running these commands: $ ppm repo sync --force Downloading ActiveState Package Repository packlist...done Updating ActiveState Package Repository database...done $ ppm log Last minute of /Users/jan/Library/Logs/ppm4.log: 2012-01-09T10:16:18 6 [ppm:84] ppm help repo 2012-01-09T10:16:32 6 [ppm:84] ppm repo sync --force 2012-01-09T10:16:33 6 [Web.pm:102] GET http://ppm4.activestate.com/darwin/5.12/1204/package.xml == 200 OK (1459885 bytes in 1.20 sec - 1189 KB/s) 2012-01-09T10:16:56 6 [ppm:84] ppm log Looking up Tk suggests that the latest version (804.030) fails to build, and the previous version (804.029) fails some tests for Perl 5.14. Which is a shame. Fortunately for me all of my Tk scripts are all on Linux. I have long since given up on Tk. I don't know if things have changed, but the new maintainers seemed to care only about Linux, so things were quite broken on Windows for quite a while. And it is legacy technology now anyways, as I doubt that it will ever be updated to a newer Tk version, so things like native themed widget support, or plain native OS X support will not be possible. [...] Just as a slightly off topic question. Since my original question was answered with a top post, is this acceptable on this list? The guys on the Fedora lists get all bent out of shape if someone top posts. My preference with regard to top posting is probably with the Fedora guys, as this post might suggest. However, a lot of the posters to this list seem to prefer top posting (or just use a mail agent that encourages it). I would complain, but I think I would be swimming against the tide. Plus, I can find more interesting things to do than get worked up about it. My preference is inline replies too, but more than top posting, I do hate HTML email for inline replies. So I'll either ignore HTML posts altogether, or I'll answer them with a top posted answer... Rarely, when I really want to reply inline, I might make the effort to convert HTML messages back to plain text. But it makes me think twice if I really have to reply at all. :) Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Window 7 x64, @inc search question
Your description on how things are looked up sounds correct. You may want to run `perl -V` to check the list of directories in @INC, and the order in which they are searched (the order of lib and site/lib has changed between 5.6 and 5.14). Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Styma, Robert E (Robert) Sent: Friday, January 06, 2012 8:30 AM To: perl-win32-users@listserv.ActiveState.com Subject: Window 7 x64, @inc search question Robert E. Styma I have just joined this mailing list. I am responsible for an assortment of perl programs which I have inherited and am testing and adjusting to get them running under a Windows 7 X64 environment. At the time the code was written we were using Perl 5.6.1. When I discovered problems, I removed the old Perl and upgraded to: ActivePerl-5.14.2.1402-MSWin32-x64-295342.msi The problem I encountered remained the same. Here is the deal. ...\Perl\lib has a directory called File which has the file functions. In the Perl\site\lib we use there is also a directory called File which includes among other things, File\Recurse.pm. This comes up as a not found on when run on a Windows 7 x64 machine. If I copy the Recurse.pm to the ...\Perl\lib it is found. On Windows XP and Windows 7 x86 the Recurse.pm is found in the Perl\Site\Lib\File directory and the other appropriate modules are found in Perl\Lib\File. I only tested this on the Perl 5.6.1 version since it works. I suspect the problem is due to changes in the underlying OS code used to do the search. I personally think that naming the Perl\Site\Lib folder the same as a Perl\Lib folder was a poor choice. However, that is what is there and I want to make sure that this is the expected behavior before I try to untangle this with changes to the code. I am looking for confirmation that someone else has seen such behavior or that this is known to be the way it should work. If what is being done should work, then I need to figure out what to try next. Thanks in advance for any suggestions. Bob Styma ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: FYI... Time::Local::timelocal breaks in 2038
Are you sure? Please include the Perl version used to run your program. And
remember that you need Perl 5.12.0 or later to get
proper Y2038 support in code Perl functions…
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Rothenmaier, Deane C.
Sent: Tuesday, January 03, 2012 11:29 AM
To: perl-win32-users@listserv.ActiveState.com
Subject: FYI... Time::Local::timelocal breaks in 2038
Perl gurus,
The following code demonstrates a catastrophic failure in the timelocal
function of the Time::Local package on Jan. 19th, 2038:
use strict;
use warnings;
use Time::Local;
sub convert_date_to_epoch {
my $str_date = shift;
$str_date =~ /^(\d{4})(\d{2})(\d{2})$/;
return( timelocal( 0, 0, 0, $3, $2 - 1, $1 - 1900 ));
}
my $date = 20380118;
my $bignum = convert_date_to_epoch( $date );
print epoch number for $date = $bignum\n;
$date = 20380119;
$bignum = convert_date_to_epoch( $date );
print epoch number for $date = $bignum\n;
The result of the second subroutine call is:
Day too big - 24855 24854
Sec too small - 24855 74752
Cannot handle date (0, 0, 0, 19, 0, 2038) at bignum.pl line 11
Don’t think this will affect many of us coding now, but if somebody’s looking
more than 26 years into the future, well, they’re in a
pickle.
Deane Rothenmaier
Programmer/Analyst – IT-StdCfg
Walgreens Corp.
2 Overlook Point #N51022D
MS 6515
Lincolnshire, IL 60069
224-542-5150
Blessed are they who have nothing to say and who cannot be persuaded to say it.
– James Russell Lowell
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActiveState announces ActivePerl 5.14.2
On Wed, 02 Nov 2011, alex.ign...@atcoitek.com wrote: Hello Jan, will PerlApp 8.2.1 build 292072 compile this version of Perl? No, Perl 5.14 support has only been added in the PDK 9.1 release. How can I find out this info in the future? Look at the cumulative release notes from the latest release, e.g. right now: http://docs.activestate.com/pdk/9.1/Release.html Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Perl 5.14 and Win32
On Tue, 01 Nov 2011, Barry Brevik wrote: Right now, I'm on Perl 5.8.8, mostly because I have the Dev Kit for that version and I have not upgraded yet. I'd really like to upgrade to 5.12 or 5.14, but I have heard that Dave Roth's Win32 extensions do not work under those versions. Can anyone confirm or deny this? What about any other Win32 extensions? I require these extensions, so I don't know what to do. You'll have to be more specific. List the extensions by name! Describe how they don't work! Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Perl 5.14 and Win32
On Tue, 01 Nov 2011, Barry Brevik wrote: You'll have to be more specific. List the extensions by name! Describe how they don't work! OK, Win32::OLE Win32::ODBC Win32::Lanman Win32::Console Win32::Registry Win32::NetAdmin Win32::Process Win32::Daemon Do these all work under 5.14? I believe all of them except Win32::Lanman should work. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.14.2
ActiveState is pleased to announce ActivePerl 5.14.2 build 1402, a complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl ActivePerl 5.14 is now based on the 5.14.2 release. You can read about all the changes since Perl 5.14.1 in this perldelta document: http://docs.activestate.com/activeperl/5.14/lib/pods/perl5142delta.html Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1402 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Non-blocking keyboard?
On Fri, 07 Oct 2011, Barry Brevik wrote:
I'm writing a program where a process runs in a loop. I want to
process keyboard input without disturbing the main process in the
loop. I'm trying to use the Win32::Console module for this task (see
code below), but the module blocks on the Input statement.
Is there some way to make this non-blocking, or maybe even use a
different technique entirely that does not block? I tried whipping an
IOCTL statement on it, but I either did it wrong, or it does not work.
use strict;
use warnings;
use Win32::Console;
my $STDIN = new Win32::Console(STD_INPUT_HANDLE);
$STDIN-Mode(ENABLE_PROCESSED_INPUT);
# Un-buffer STDOUT.
select((select(STDOUT), $| = 1)[0]);
while (1)
{
my @input = $STDIN-Input();
I think you wanted to call PeekInput() instead of Input() here.
But GetEvents() may be even better if you only want to see if there
are waiting keyboard events at all.
if (defined $input[0] and $input[0] == 1)
{
if ($input[1])
{
last if $input[5] == 27; # ESC key.
if ($input[5] == 8) {print \x08, ' ', \x08; next;} #
Backspace key.
print chr($input[5]);
}
}
}
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Help with Win32::Process::Create()
On Tue, 23 Aug 2011, Barry Brevik wrote:
I ALREADY HAVE some code that does this (see below). My question is- is
there a way to periodically poll the outside process to determine if it
is still running? I've tried a few things already and none of them work.
if (defined $process) {
if ($process-GetExitCode() == Win32::Process::STILL_ACTIVE()) {
# process is still running
...
}
else {
# process has terminated; PID is still valid
...
# release process handle so the OS can do full cleanup
# of the already terminated process
$process = undef;
}
}
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: I have a secondary Inbox folder and trying to read the messages in the 2ndary inbox
On Mon, 25 Jul 2011, Wagner, David --- Sr Programmer Analyst --- CFS wrote: I got some code from a reply I found on Perl Monks and brought over to my Desktop and ran the code. It does what I am after, BUT I do not want the default inbox, but another inbox. The code for the default inbox is: my $folder = $namespace-GetDefaultFolder(olFolderInbox); How do I get a different folder to read from messages from??? Sorry, no time to test right now, but I suspect something like this might work: my $folder = $namespace-Folders(Outlook Data File)-Folders(Alternate Input); Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: I have a secondary Inbox folder and trying to read the messages in the 2ndary inbox
On Mon, 25 Jul 2011, Wagner, David --- Sr Programmer Analyst --- CFS wrote: On Mon, 25 Jul 2011, Jan Dubois wrote: Sorry, no time to test right now, but I suspect something like this might work: my $folder = $namespace-Folders(Outlook Data File)-Folders(Alternate Input); Thanks, Jan. That was close, but what I ended up was doing a properties against the other inbox: \\Mailbox - Email.Reports So I removed the \\ and used that portion for the first Folders and for the second Folders used Inbox and was able to read... Yes, that is exactly the same idea. The first name is the MAPI folder or *.pst file name, and the second one is the name of your folder inside of it. My sample strings assumed the default Outlook 2010 *.pst filename, and an alternate folder for a second inbox inside the same file. BTW, it may be possible to write your example like this: my $folder = $namespace-Folders(Mailbox - Email.Reports\\Inbox); I appreciate the insight. Know you are busy, but when the time is available, where does one find out such info. Never would have found it. I looked at the MS Outlook 12.0 Object Library. I found Folders and if that is the right Folders, I do not see it.. In this case I just looked at some scripts I had already written to figure it out. When I don't have any previous samples, then I have to do the same thing as everyone else: search on Google, read the object model docs, and experiment with trial error. It *is* a time consuming thing for anything non-standard, but navigating the folder hierarchy is still pretty common. Now, configuring custom AutoArchive settings for each folder is something I wasted several hours on. :) Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActiveState announces ActivePerl 5.14.1 and 5.12.4
On Mon, 18 Jul 2011, Brzezinski, Paul J wrote: Any updates on when the next release of the PDK will be released? I thought I recall something about an updated release of PDK is required to support Perl 5.14. Yes, you need PDK 9.1 for Perl 5.14 support in PerlApp etc. It is currently in QA and should be released really soon now. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Help with file redirect
On Tue, 05 Jul 2011, Barry Brevik wrote: I am writing an app that has a lot of screen output which it writes to STDERR. The screen output is copious, but I need it right now for debugging; I can get rid of it later. My question is if it is possible to write to STDERR and a named file at the same time? I'd rather not go through the code and change every print statement. You could use the `tee` command on the commandline. A pure Perl implementation is here: http://search.cpan.org/~dagolden/Tee-0.14/lib/Tee.pm Or you multiplex the handle at the Perl level with a PerlIO::tee layer: http://search.cpan.org/~gfuji/PerlIO-Util-0.72/lib/PerlIO/tee.pm Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.14.1 and 5.12.4
ActiveState is pleased to announce ActivePerl 5.14.1 build 1401 and ActivePerl 5.12.4.1205, complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl ActivePerl 5.14 is now based on the 5.14.1 release. You can read about all the changes since Perl 5.14.0 in this perldelta document: http://docs.activestate.com/activeperl/5.14/lib/pods/perl5141delta.html In addition, PerlScript and Perl for ISAPI support have been fixed in build 1401 for Windows as well. ActivePerl 5.12 is now based on the 5.12.4 release. You can read about all the changes since Perl 5.12.3 in this perldelta document: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5124delta.html Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1401 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: help with PPM activestate repository install (email-sender)
I have no idea what the package Net-SMTP-Server is supposed to contain; it is not on CPAN. I notice that the SMTP-Server package contains Net::SMTP::Server, so maybe both packages are the same, with just a different name, and you don’t need to install both? For OS X the canonical Perl user mailing list is mac...@perl.org. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Friday, May 20, 2011 1:15 PM To: Perl-Win32-Users@listserv.ActiveState.com Subject: help with PPM activestate repository install (email-sender) when I run PPM and indicate to install ‘Email-Sender’, magical things begin to happen… then I get: Installing 3 packages failed ERROR: File conflict for 'C:/Perl/html/site/lib/Net/SMTP/Server/Client.html'. The package Net-SMTP-Server has already installed a file that package SMTP-Server wants to install. might anyone know how I can ‘get around’ this problem – to otherwise force this package to install (despite the fact that some previously installed module installed ‘client.html’. I assume my deleting ‘client.html’ will likely not fully resolve this (as sometinng is otherwise remembering that Net-SMTP-Server installed ‘client.html’. PS – im learning that many of the email modules that use SSL/TLS simply don’t exist on Windows platform due to some restriction on how Windows implements non-blocking sockets. can anyone suggest an ‘osX Perl’ forum, where I can learn whats required to install packages on osX? I do have access to a Apple computer, though its not my system, and the owner is not a Perl programmer. thanks. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.14.0
ActiveState is pleased to announce ActivePerl 5.14.0 build 1400,
a complete, ready-to-install binary distribution of Perl.
Builds for Windows, Mac OS X and Linux are made freely available.
Builds for Solaris, HP-UX and AIX are available with ActivePerl Business
Edition. For detailed information or to download these releases, see:
http://www.activestate.com/activeperl
What's new in ActivePerl
ActivePerl 5.14 is now based on the 5.14.0 release. You can read about all
the changes since Perl 5.12.0 in the perldelta document:
http://docs.activestate.com/activeperl/5.14/lib/pods/perl5140delta.html
Some highlights of 5.14 are:
- Improved Unicode support, especially for regular expressions. You
can now explicitly request ASCII/Unicode/locale semantics with the
/a, /u, and /l regexp modifiers.
- The s/// substitution operator has a non-destructive /r option. For
example this statement will not modify the elements of @orig:
my @copy = map { s/cat/dog/r } @orig;
- Exception handling is more reliable; $@ doesn't get clobbered by
destructors anymore.
Getting Started
===
Whether you're a first-time user or a long-time fan, our free resources
will help you get the most from ActivePerl.
Mailing list archives:
http://code.activestate.com/lists/activeperl/
Supported Platforms
===
ActivePerl is available for the following platforms:
- Windows/x86 (32-bit)
- Windows/x64 (64-bit) (aka AMD64)
- Mac OS X
- Linux/x86 (32 bit)
- Linux/x86_64 (64-bit) (aka AMD64)
- Solaris/SPARC (32-bit and 64-bit) (Business Edition only)
- Solaris/x86 (32-bit)(Business Edition only)
- HP-UX/PA-RISC (32-bit)(Business Edition only)
- AIX/PowerPC (32-bit)(Business Edition only)
More information about the Business Edition can be found here:
http://www.activestate.com/business-edition
Custom builds are available in the Enterprise Edition:
http://www.activestate.com/enterprise-edition
Feedback
Everyone is encouraged to participate in making Perl an even better
language.
For bugs related to ActiveState use:
http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1400
For bugs related directly to Perl please use the 'perlbug' utility.
Enjoy!
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: [OLE] Controlling AutoCAD = 2010 fails with Win32::OLE. Error 0x8001010a.
On Thu, 03 Mar 2011, Manuel Reimer wrote: Hi Manuel, [...] http://through-the-interface.typepad.com/through_the_interface/2010/02/handling-com-calls-rejected- by-autocad-from-an-external-net-application.html This C# and so I tried to port this over to C++ to be able to add this to the OLE.xs file. I've attached the patch file with my proof of concept code. As you see in my patch, I commented out the code, initializing OLE in multi threading mode, to make the CoRegisterMessageFilter call succeed. The way to tell Win32::OLE to use OleInitialize() is to call Win32::OLE-Initialize(Win32::OLE::COINIT_OLEINITIALIZE()); right after you use Win32::OLE. Put it inside a BEGIN block if you may call any OLE functionality at compile time (e.g. while loading other code). Problem with this patch: It doesn't work. Anything, it does, is crashing the Perl interpreter... :-( It is not crashing for me just running the bundled test suite. Do you have some sample script that crashes that doesn't involve AutoCAD, as I don't have a copy of that application available. Is someone here able to have a look at this and perhaps fix this code? I haven't really looked at your code; just applied the patch, built the module and ran the tests, with no crash in sight. So I assume the crash only happens when the MessageFilter is actually being invoked. I'll try to look at your implementation to see if I can find anything that could go wrong, but having a reproducible crash would make this easier. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: spurious deaths in script execution due to read-only Config?
On Wed, 23 Feb 2011, Brian Raven wrote:
On Wed, 23 Feb 2011, Christian Walde wrote:
Solution: Make sure $_ isn't pointing at %Config when Exporter.pm
happens. This can be done as simple as this:
map { require ActiveState::Path } 1;
(Though i'm sure more elegant solutions exist.)
[...]
Regarding your work around. Map in a void context is usually frowned
upon. Perhaps grep or possibly ...
for ('now') { require ActiveState::Path }
... should have the same effect, i.e. aliasing $_ to something
(hopefully) innocuous.
It turns out the canonical solution is to add
local *_;
at the top of the subroutine. Read all the gory details in perlsub.pod...
The important part to remember is:
local $_;
is not safe! It does not mean that $_ is now undef and that you can
do whatever you want with it. It may still have magic attached to
it, and (in this case) it may still be associated with a tied hash
or array element.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: perl won't alarm?
On Wed, 23 Feb 2011, Robert W Weaver wrote: Is there a way I can protect my routine from hanging system calls? alarm() will not interrupt a blocking system call on Windows. If you want to timeout on subprocesses, then you may want to look at Win32::Job. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Pulling PERL Exectuable x86 vs x64
Load Config.pm and look at $Config{ptrsize}. It is either 4 or 8, telling you
that you are running 32-bit or 64-bit Perl.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Michael Cohen
Sent: Tuesday, February 22, 2011 1:06 PM
To: perl-win32-users@listserv.ActiveState.com
Subject: Pulling PERL Exectuable x86 vs x64
Is there a simple way to determine what flavor of PERL is running from within a
program, specifically one that is wrapped within
PERLAPP? In other words, I need to determine if the PERL is 32-bit or 64-bit,
to determine if it is running in WoW64 or not. I
realize it is easy to determine the flavor of the OS, but this is not that
question.
Regards,
Michael Cohen
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: NTFS hard file links
On Tue, 22 Feb 2011, Brian H. Oak wrote: Your builtin link() is a godsend! If only I'd known years ago I could have saved a lot of heartache trying to kludge Win32::API::Prototype into working in my programs. Looks like I added support for it in 1999: http://perl5.git.perl.org/perl.git/commitdiff/6b980173 I did a lot of testing of link() over this last weekend, and got mixed results. Here's my test environment: \FolderA\LinkTest.txt Original file \FolderA\FolderB\LnkdFil1.txt First hardlink \FolderA\LnkdFil2.txt Second hardlink I create a straight copy of an original text file in FolderA, naming it LinkTest.txt. I create a hardlink to LinkTest.txt in FolderB, naming it LnkdFil1.txt. I test that it is an actual hardlink by opening and editing both files; changes to either file show up in the other when opened. So far, so good. But then I create another hardlink to LinkTest.txt in FolderA (same folder as LinkTest.txt this time), naming it LnkdFil2.txt. Now I should have a total of three filesystem hardlinks pointing to the single original file on disk, right? Yes I unlink the original LinkTest.txt, and that should leave me with two remaining links to the same file on disk (since NTFS uses link counting, in much the same way as Perl employs reference counting). But testing demonstrates that I now have two separate files on disk -- each with a single link to it -- rather than two links to the same file. I cannot reproduce this. How did you check for it? Here is a crude script that works for me: #!perl use strict; use warnings; my $tmp = C:\\tmp; system(rd/s/q $tmp\\lntest); system(del $tmp\\lntest.txt $tmp\\link.txt); system(echo foo $tmp\\lntest.txt); mkdir($tmp\\lntest) or die; link($tmp\\lntest.txt, $tmp\\lntest\\link.txt) or die; link($tmp\\lntest\\link.txt, $tmp\\link.txt) or die; system(echo bar $tmp\\lntest.txt); system(type $tmp\\link.txt); unlink($tmp\\lntest.txt) or die; system(echo baz $tmp\\lntest\\link.txt); system(type $tmp\\link.txt); __END__ c:\tmpperl lntest.pl foo bar foo bar baz So *after* I deleted C:\tmp\lntest.txt I appened to C:\tmp\lntest\link.txt and the appended text shows up in the C:\tmp\link.txt link, proving that the remaining link has not been broken by the first unlink(). I suspect that you are doing some operation that is not updating a file, but deleting and re-creating it. This will always break hard links. Do I have a bad understanding of the concepts, of how hardlinks are supposed to work? Am I doing something wrong, or in the wrong order? Or is there some deficiency in the implementation of Windows hardlinks through link()? link() will just invoke CreateHardLinkW() under the covers, so you should see exactly the same effect with your Win32::API based implementation. One final question: since symlinks were enabled in NTFS.sys v6.0 (Windows Vista) and above, is there any possibility that the builtin symlink() function can be made to silently Do the Right Thing on recent versions of Windows? Yes, there is, but I'm not sure it can still be done in time for Perl 5.14. There is just one more 5.13.11 dev release planned for March, and then 5.14 should come out in April/May, and new features may no longer be allowed into the tree (besides I don't think I have time to do this right away anyways). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: NTFS hard file links
On Thu, 17 Feb 2011, Brian H. Oak wrote: For years now I've been using Win32::API::Prototype to access kernel32.dll and set up CreateHardLink() for use in a program. But something in the upgrade from 32-bit 5.10 to 64-bit 5.12 is incompatible with Win32::API::Prototype. Now I'm looking for an alternative method for creating hard links that works with 64-bit 5.12. Does anyone know of a compatible module that provides this functionality? Have you tried the link() builtin function? It should call the CreateHardLink() function internally. I think I implemented it back in the 5.004 or 5.005 days, with an compatibility hack for Windows NT4, which doesn't have CreateHardLink(). Anyways, please let me know if it doesn't work; it is supposed to do the right thing automatically. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces new ActivePerl builds of 5.12.3 (and 5.8.9)
ActiveState is pleased to announce ActivePerl 5.8.9 build 829, and ActivePerl 5.12.3 build 1204, complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl * ActivePerl 5.12 is now based on the recent 5.12.3 release. * The -d switch on the #! line will now properly invoke the debugger in Perl 5.12 (it already worked in 5.8.9 and 5.10.1). * For Perl 5.8 on Mac OS X the Tk module has been compiled to avoid absolute references to the installed Perl version. This makes it possible to run packaged Tk applications (using PerlApp) to run on OS X systems that don't have ActivePerl installed. * All bundled modules have been updated to their latest stable releases. Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1204 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: perlapp on win 7 64 bit?
On Wed, 22 Dec 2010, Spencer Chase wrote: [It would be best if you could post PDK related problems to the PDK mailing list and not to the general perl-win32-users; please remove perl-win32-user from follow-up posts.] I am trying to make exe files for win32 systems on my 64 bit installation. I can run the scripts with all the needed modules using Komodo but I can not make exes that include the required perl 5.8. These scripts need perl 5.8 but it is not binary compatible with 64 bit windows. This is the error message I get if I try to change the source for perl in the main perlapp window. Any way to get around this other than running perlapp from the 32 bit installation which requires rebooting. You seem to be mixing 32-bit ActivePerl with 64-bit PDK or vice versa. That doesn't work; both must be either 32-bit or 64-bit. You can install all versions side-by-side on Windows 7 64-bit, but you should make sure that you put consistent versions on your PATH. The default install locations are: 32-bit: C:\Perl 64-bit: C:\Perl64 32-bit: C:\Program Files (x86)\ActiveState Perl Dev Kit 9.0.1 64-bit: C:\Program Files\ActiveState Perl Dev Kit 9.0.1 The reason to install both 32-bit and 64-bit PDK is that some tools (just PerlMSI and the Graphical Debugger, I think) are only available in the 32-bit releases, and you can use these tools to package or debug 64-bit applications. For PerlApp itself it isn't strictly necessary to use the 32-bit versions to build 32-bit executables, you can also use the 64-bit PDK and use the `--target windows-x86` option to request cross-platform wrapping. But either way should work fine. The only thing that will not work is using a 32-bit ActivePerl with a 64-bit PerlApp or the other way around. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Komodo in Win XP mode
On Fri, 04 Feb 2011, Spencer Chase wrote: [It would be best if you could post PDK related problems to the PDK mailing list and not to the general perl-win32-users; please remove perl-win32-user from follow-up posts.] I can not get many things to work in Windows 7 64 bit when using PDK and Komodo. I decided to try installing XP mode so I don't have to reboot to my 32 bit partition or run another computer just to maintain scripts that use incompatible modules. I was able to install various active perls as well as PDK but I can not get Komodo to work at all. It will not open. I have installed it from an msi downloaded and copied within the XP mode file system. This is the only reason I bought XP mode and am feeling a little ripped off as I always do when I buy something from I have no idea why you had problems with XP mode, but there shouldn't have been any reason to use it in the first place. Please try to run matching versions of ActivePerl and PerlApp, as I just recommended in another reply to you, and report any further problems you have on the PDK mailing list. If you have problems with Komodo on 64-bit Windows 7, then please post to the Komodo discussion list and ask for advice there! Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Community User
On Fri, 04 Feb 2011, Phillip Richcreek wrote: I probably missed an announcement! The ASPN site lists a category they're calling Community, which is the only one that even comes close to describing my situation. Is it the case that the perl documentation is no longer available to community users online? I don't see that as a problem. It's just that I've always accessed the documentation there and was not aware that (apparently) the html is and has been stored locally during the installation process. The documentation is still online at http://docs.activestate.com/ I've also noticed a dramatic decrease in the acitivity on this and the other ASPN forums that I subscribe to -- pdk, xml, admin, activeperl. Are there new forums and, if so, are they available to community users? There are some web forums that kind of duplicate the topics of some mailing lists here: http://community.activestate.com/main Personally I'm no fan of web forums, so I never go there. So I have no idea how much traffic they get. I agree that the Perl mailing lists have less traffic than 10 years ago. All Windows related stuff happens here on perl-win32-users; the other perl-win32-* lists are more or less dead and should probably be decommissioned. On the other hand there seem to be a lot more blogging about Perl than there was 10 years ago. :) Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: PDK exe fails to run due to Data:Manip errors
On Fri, 21 Jan 2011, Jason Lowder wrote: I have an application that makes use of the Data:Manip module. It runs fine and compiles fine, but when running the exe I get: Name Date::Manip::Lang::english::Language used only once: possible typo at /C:\Tools\PerlScripts\DataCopy_zzScott\datacopy.exeDate/Manip/Base.pm line 1844. Use of uninitialized value $beg in string comparison (cmp) at /C:\Tools\PerlScripts\DataCopy_zzScott\datacopy.exeDate/Manip/TZ.pm line 1035. [...] I know from a previous compile problem that the compiler attempts to set variables at compile time, but the values for this module won't be set until runtime. How would I go about compiling this? Any suggestions? It would help if you could show a small sample program that reproduces the problem you are having. If this is the wrong Perl users group I apologize. Yes, this message would be more on-topic on the PDK mailing list. Please continue the thread over there (make sure you are subscribed to the PDK list, and remove perl-win32-users from your replies). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: [Trivial Pursuit] Which Win32 perl was the first to be built with -Dusethreads ?
On Thu, 23 Dec 2010, Sisyphus wrote:
Earliest perl that I have that was built with -Dusethreads was a perl-5.8.8
that I built myself using MinGW ... but I don't have any perls between 5.8.0
(which was *not* built with -Dusethreads) and 5.8.8.
$Config{usethreads} wasn't set correctly on Windows until 5.8.1:
http://perl5.git.perl.org/perl.git/commitdiff/7e0017d3
Does anyone here know if there were any pre-5.8.8 builds of ActivePerl that
were built with -Dusethreads ?
It looks though that there has been an integration error in the early
ActivePerl 5.8 sources, and the value has been overwritten with undef
from the $Config{use5005threads} setting until ActivePerl 5.8.6.811.
I would use $Config{useithreads} (note the additional i in front of
threads) on Perl 5.8 and later, which should always be correct. Or
if you really work with the perl5005 thread implementation too:
my $usethreads = $] 5.008 ? $Config{usethreads} : $Config{useithreads};
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces new ActivePerl builds of 5.8.9, 5.10.1, and 5.12.2
ActiveState is pleased to announce ActivePerl 5.8.9 build 828, ActivePerl 5.10.1 build 1008, and ActivePerl 5.12.2 build 1203, complete, ready-to-install binary distributions of Perl. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl What's new in ActivePerl * All bundled modules have been updated to their latest stable releases. * DBD::Pg has been added for all builds. * DBD::Oracle has been included in 64-bit builds for Linux and Windows (it was already included in 32-bit builds for Linux and Windows in earlier releases). * PerlScript has been added in the 64-bit Windows release of ActivePerl 5.12.2 build 1203. Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1203 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: does anyone know how to get a TRUE ntfs directory listing? using Perl, or otherwise
You can run `dir /a` to see files with the “system” and “hidden” attributes, but you will still not see the NTFS metadata entries. They cannot be manipulated at the file system level and are rather pointless to copy as some of their content depends on the disk geometry (think “file allocation table”). There are many other things to consider though: there is file system redirection happening when you run 32-bit apps on 64-bit Windows, there are “alternate data streams” on files etc. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Thursday, December 09, 2010 11:43 AM To: perl-win32-users@listserv.ActiveState.com Subject: does anyone know how to get a TRUE ntfs directory listing? using Perl, or otherwise does anyone know how to; a. get a TRUE ntfs directory listing? meaning listing all of the files and/or directories found at any given directory level? for example if one does… c: cd\ dir they will NOT see all files found at the root of the c drive (examples are the files that store the NTFS volume info, such as ‘$MFT’, etc…) or… if one does a fresh install of windows, and gets the properties of the following ‘empty’ directory (empty in terms of what Windows Explorer GUI shell tell’s one) C:\Documents and Settings\user\Local Settings\Temporary Internet Files. but in fact, not truly empty. with Windows Explorer GUI showing no files or directories (after a fresh XP install), the properties of that folder indicate a quantity of non-normally viewable files and folders. or… if one wanted to truly copy ALL files found in, and under, the user profile folder. in all of these cases, there are files in existence on the NTFS volume that Microsoft wants to hide and make difficult to access. I was hoping that someone in this mailing list has found a tool (perl or otherwise) that allows one to get a TRUE directory listing of all files at any given NTFS directory level. additionally, I would like to be able to do an xcopy type of thing where ALL files get copied, not just those files that Microsoft wishes to provide access to. thanks ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Module instalaltion error (nmake)
On Tue, 23 Nov 2010, Sisyphus wrote: 'cl' is the compiler that comes with MS compilers such as Visual Studio. Alternatively you could use MinGW's gcc compiler - though to effect that in something as old as ActivePerl 5.8.4 you might also have to install ExtUtils::FakeConfig. Is there no ppm package of PadWalker available for 5.8 ? I haven't checked, but the ActiveState PPM repositories for PPM3 haven't been updated in years. Only the PPM4 repositories used by ActivePerl 5.8.8.818 and later are getting new modules built for them anymore. It looks like there is a copy of PadWalker in the trouchelle repository for 5.8 that should work on 5.8.4: http://trouchelle.com/perl/ppmrepview.pl Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: lame question \\\\.\\pipe\\pipename vs '\\.\pipe\pipename'
From `perldoc perldata`: String literals are usually delimited by either single or double quotes. They work much like quotes in the standard Unix shells: double-quoted string literals are subject to backslash and variable substitution; single-quoted strings are not (except for \' and \\). You need \’ to be an escape, otherwise single quoted strings can’t include single quotes themselves. And consequently you need \\ to be an escape, otherwise single quoted strings couldn’t end with a backslash (it would just be an escaped single quote). So you’ll unfortunately still need to double backslashes once you have more than one in a row, like in UNC filenames). Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Wednesday, October 20, 2010 10:10 AM To: perl-win32-users@listserv.activestate.com Subject: lame question .\\pipe\\pipename vs '\\.\pipe\pipename' forgive my ignorance here, but I thought single quoted, or apostrophized [however you call this character] (‘) text strings were supposed to be interpreted by perl in an unaltered manner. sample code, indicating how to reference a named pipe in the Win32::Pipe module, shows something like this… “.\\pipe\\pipename file:///\\pipe\pipename ” (note enclosed in quotes) I thought the excessive quantities of backslashes seemed silly, so I instead used single quotes and tried… ‘\\.\pipe\pipename’ (note enclosed in apostrophies) only to find that my client pipe program did not work. I then did a simple test print program; print ‘\\.\pipe\pipename’; and I was surprised to see what actually printed to the screen was instead; \.\pipe\pipename (note the first \ is not shown in output!) this explained why my client pipe program was working… but it left me scratching my head to ask, “why is the backslash character being interpreted as a special perl operator when it is found within apostrophies?” I thought that only happened when the backslash is found within quotes, such as (print “\x43”), which should print a capital C thanks in advance to anyone who can explain this to me. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32::Pipe::CallNamedPipe does this function normally work?
The version of Win32::Pipe on CPAN (and in ActivePerl) may be a different version than the one mentioned on Dave’s website. You should check out the sample program included in Win32-Pipe to see how it works: http://cpansearch.perl.org/src/JDB/Win32-Pipe-0.024/eg/ Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Wednesday, October 20, 2010 1:50 PM To: perl-win32-users@listserv.activestate.com Subject: Win32::Pipe::CallNamedPipe does this function normally work? when I run this simple client program use strict; use warnings; use Win32::Pipe; my $Data; Win32::Pipe::CallNamedPipe(.\\Pipe\\EPICIPCDPLX file:///\\\Pipe\EPICIPCDPLX , 3, $Data); print data read from epic = $Data\n; I get this error; Can't locate auto/Win32/Pipe/CallNamedPi.al in @INC (@INC contains: C:/Perl/site /lib C:/Perl/lib .) at C:\perlsrc\pipe\epic_item_import2.pl line 5 the online documentation http://www.roth.net/perl/pipe/#new() says; CallNamedPipe( $PipeName, $SendData, $RecieveData [, $TimeOut ] ) This function will connect to the specified named pipe ($PipeName) then it will send the the specified data ($TimeOut parameter is a value in milliseconds indicating how long the function waits to connect, to send and to recieve data. NOTE: This is not an object method. It can only be used as a function call as in: Win32::Pipe::CallNamedPipe( server\\pipe\\My Named Pipe file:///\\\server\pipe\My%20Named%20Pipe , Test Data, $Data ); NOTE 2: The third parameter must be a scalar variable, not a reference nor a constant. Returns TRUE (1) if successful and FALSE (0) if it fails. but if I search Win32::Pipe.pm for ‘Callnamedpipe’ the string is not found anywhere in the c:\perl\site\lib\win32\pipe.pm file! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8
The problem with Win32::MemMap is that it was never released as source code AFAICT, so nobody but Amine will be able to compile it for a different platform (its internals are also implemented in Delphi, not standard C code, making things even more interesting…). But he still seems to hang around on the internet. Send him email at ami...@videotron.ca and see if he replies. Maybe he still has the full sources somewhere. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Wagner, David --- Senior Programmer Analyst --- CFS Sent: Monday, October 18, 2010 3:12 PM To: gai...@visioninfosoft.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 15:53 To: perl-win32-users@listserv.activestate.com Subject: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 I was able to find MemMap.ppd (and matching MemMap.tar.gz) at a website. [Wags] Unsure what happened or where Amine went, but to the best of my knowledge he vanished from the Perl scene almost 10 years ago, give or take a year or two. I had another module of his which I was using and it had to do with changes within a folder for a file. Much nicer than anything else that was around, but it quit working and Amine quit responding. So unsure who is maintaining and handling. Now, I could be completely wrong, but I have not seen or heard of Amine on any of the Perl lists. Anyone know differently?? Unsure who would be maintaining the code, but not changing who is actually handling the changes??? If you have any questions and/or problems, please let me know. Thanks. Wags ;) David R. Wagner Senior Programmer Analyst FedEx Services 1.719.484.2097 Tel 1.719.484.2419 Fax 1.408.623.5963 Cell http://Fedex.com/us ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8
If you follow that line of reasoning, then you have to realize that Perl 5.8 wasn’t out in 2001 either, so the binary really would be for 5.005 or 5.6. The ppd file and tarball don’t seem to match up. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 3:36 PM To: david.wag...@fedex.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 well if this is so, it would be my guess that the ppd file must be incorrect! whom ever wrapped up this tar.gz file with a matching ppd said in the ppd that it requires perl version 5.10 I don’t think perl 5.10 existed ten years ago (give or take a couple), but I could be wrong. perhaps if I change the line in the ppd file to say perl 5.8, ppm will install it, and it might actually work. it cant hurt to try. perhaps once installed, viewing the contents of the memmap.pm file, might reveal to me if there are any special notes about which perl versions the module will actually work with. thanks for the info… _ From: Wagner, David --- Senior Programmer Analyst --- CFS [mailto:david.wag...@fedex.com] Sent: Monday, October 18, 2010 3:12 PM To: gai...@visioninfosoft.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 15:53 To: perl-win32-users@listserv.activestate.com Subject: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 I was able to find MemMap.ppd (and matching MemMap.tar.gz) at a website. [Wags] Unsure what happened or where Amine went, but to the best of my knowledge he vanished from the Perl scene almost 10 years ago, give or take a year or two. I had another module of his which I was using and it had to do with changes within a folder for a file. Much nicer than anything else that was around, but it quit working and Amine quit responding. So unsure who is maintaining and handling. Now, I could be completely wrong, but I have not seen or heard of Amine on any of the Perl lists. Anyone know differently?? Unsure who would be maintaining the code, but not changing who is actually handling the changes??? If you have any questions and/or problems, please let me know. Thanks. Wags ;) David R. Wagner Senior Programmer Analyst FedEx Services 1.719.484.2097 Tel 1.719.484.2419 Fax 1.408.623.5963 Cell http://Fedex.com/us ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8
Interesting! I had another look, and it turns out that the Delphi code is just a separate DLL that doesn’t know anything about Perl internals. It is not called directly from Perl, but via Win32-API. Therefore Win32::MemMap does indeed seem to work on multiple Perl versions as long as you have the correct version of Win32::API installed. I don’t follow your questions about named pipes though. Win32::MemMap is about shared memory, not named pipes. What am I missing? Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 4:27 PM To: j...@activestate.com; david.wag...@fedex.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 you are correct. I felt I had nothing to loose here, so I modified the architecture line in the ppd to say ‘MSWin32-x86-multi-thread-5.8’ (knowing that ten years ago likely his module is probably not thread safe – as im a newbie and don’t yet even program with threads). I was pleasantly surprised to see that ppm did then install from my locally available files. the first tests I ran with it actually worked. my main problem here is I don’t understand his naming scheme for the win32 named pipe. running sysinternals accesschk –osv, I see a named pipe as EPICIPCDPLX. the win32 programmer who created this named pipe (in a win32 delphi program) references this named pipe as \\.\pipe\EPICIPCDPLX file:///\\.\pipe\EPICIPCDPLX yet in amines test scripts, he uses a rather different naming convention for his ‘sample named pipe’. here is his code fragment… use Win32::MemMap; my $size=12349; # size in bytes my $obj=new Win32::MemMap; my $mem=$obj-OpenMem(//MemMap/Perl,$size); $obj-LastError; $size = $mem-GetSize(); print size of sm = $size\n; $datasize = $mem-GetDataSize(); print datasize of sm = $datasize\n; this program does actually run and work for perl 5.8 build 822. however I don’t understand how I would\should convert my existing win32 named pipe from \\.\pipe\EPICIPCDPLX file:///\\.\pipe\EPICIPCDPLX to his naming syntax? //EPICIPCDPLX //MemMap/EPICIPCDPLX its not very clear to me, so I cant interact with the (already defined by another win32 process) shared memory map. any suggestions? _ From: Jan Dubois [mailto:j...@activestate.com] Sent: Monday, October 18, 2010 4:03 PM To: gai...@visioninfosoft.com; david.wag...@fedex.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 If you follow that line of reasoning, then you have to realize that Perl 5.8 wasn’t out in 2001 either, so the binary really would be for 5.005 or 5.6. The ppd file and tarball don’t seem to match up. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 3:36 PM To: david.wag...@fedex.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 well if this is so, it would be my guess that the ppd file must be incorrect! whom ever wrapped up this tar.gz file with a matching ppd said in the ppd that it requires perl version 5.10 I don’t think perl 5.10 existed ten years ago (give or take a couple), but I could be wrong. perhaps if I change the line in the ppd file to say perl 5.8, ppm will install it, and it might actually work. it cant hurt to try. perhaps once installed, viewing the contents of the memmap.pm file, might reveal to me if there are any special notes about which perl versions the module will actually work with. thanks for the info… _ From: Wagner, David --- Senior Programmer Analyst --- CFS [mailto:david.wag...@fedex.com] Sent: Monday, October 18, 2010 3:12 PM To: gai...@visioninfosoft.com; perl-win32-users@listserv.activestate.com Subject: RE: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Greg Aiken Sent: Monday, October 18, 2010 15:53 To: perl-win32-users@listserv.activestate.com Subject: looking for amine's 'MemMap' module for Win32 x86 Perl version 5.8 I was able to find MemMap.ppd (and matching MemMap.tar.gz) at a website. [Wags] Unsure what happened or where Amine went, but to the best of my knowledge he vanished from the Perl scene almost 10 years ago, give or take a year or two. I had another module of his which I was using and it had to do with changes within a folder for a file. Much nicer than anything else that was around, but it quit working and Amine quit responding. So unsure who is maintaining
RE: Win32::OLE on MS Word using Selection.Find.Execute
On Sun, 12 Sep 2010, Peter Buck wrote: Does anyone have an example of a perl script acting on MS Word documents using Win32::OLE and Selection.Find.Execute? Actually, I do, and it is even part of the Win32::OLE module distribution on CPAN. But since it is not being installed with the actual module itself it is somewhat hard to find: http://cpansearch.perl.org/src/JDB/Win32-OLE-0.1709/eg/word2pod.pl The script takes a Word document and tries to convert it to POD. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.12.2 build 1202
ActiveState is pleased to announce ActivePerl 5.12.2 build 1202, a complete, ready-to-install binary distribution of Perl 5.12.2. Builds for Windows, Mac OS X and Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl New in ActivePerl 5.12.2 Build 1202 === * Based on the new Perl 5.12.2 release * Contains many additional modules, including Devel::NYTProf, Moose and Perl::Critic * Includes a GUI frontend for Perl::Critic that was previously only available as part of the ActiveState Perl Dev Kit Read the full release notes here: http://docs.activestate.com/activeperl/5.12/release.html For a summary of all changes in Perl 5.12.2 please read the perl5122delta document: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5122delta.html ActivePerl 5.12 is now fully supported by the ActiveState Perl Dev Kit 9.0.1, and ActivePerl 5.12.2.1202 is the recommended Perl version for all new users! New in ActivePerl 5.12 (relative to 5.10) = * New package NAME VERSION syntax * The ... operator * Implicit use strict * Unicode improvements * Y2038 compliance * qr// overloading * Pluggable keywords * Experimental \N regexp escape Read an expanded version of this list on our blog: http://www.activestate.com/blog/2010/04/whats-new-activeperl-rollout-features-perl-512 Or read the exhaustive list of changes in 5.12.0 and 5.12.1 in the perl5120delta and perl5121delta documents: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5120delta.html http://docs.activestate.com/activeperl/5.12/lib/pods/perl5121delta.html For some background information about the renewed Perl 5 development efforts you may also want to read: http://www.activestate.com/blog/2010/04/perl-5-is-alive Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://code.activestate.com/lists/activeperl/ Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business-edition Custom builds are available in the Enterprise Edition: http://www.activestate.com/enterprise-edition Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1202 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Tkx vs. Tcl Dev Kit
Kanhaiya wrote: Whic one is better for GUI based perl application? Perl Tkx OR ActiveTcl with Tcl Dev Kit I'm confused and not finding any solution. I think you are confused about how Tkx actually works: Tkx is a Perl interface to Tcl/Tk using the Tcl.pm module to access a Tcl interpreter. ActivePerl contains a packaged Tcl interpreter and a set of common widgets all bundled with the Tkx module, so this is all you need to create Tkx applications with Perl; you don't need ActiveTcl for it. If you want to install additional Tk widgets, then you can install ActiveTcl *in addition* to ActivePerl and configure Tkx to use the local Tcl installation instead of the one bundled with ActivePerl. If you want to wrap a Tkx application into a standalone executable, then you may want to use PerlApp from the *Perl* Dev Kit. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.12.1 build 1201
ActiveState is pleased to announce ActivePerl 5.12.1 build 1201, a complete, ready-to-install binary distribution of Perl 5.12.1. Builds for Windows, Mac OS X, Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl New in ActivePerl 5.12.1 Build 1201 === This is a bug fix maintenance release; there are no new features. For a summary of all changes please read the perl5121delta document: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5121delta.html The PPM repositories for ActivePerl 5.12 are mostly up-to-date by now. Note though that the ActiveState Perl Dev Kit (PDK) does not yet include support for Perl 5.12; if you need to wrap your application with PerlApp or any of the other PDK deployment tools, then you should not yet update to ActivePerl 5.12. New in ActivePerl 5.12.0 Build 1200 === * New package NAME VERSION syntax * The ... operator * Implicit use strict * Unicode improvements * Y2038 compliance * qr// overloading * Pluggable keywords * Experimental \N regexp escape Read an expanded version of this list on our blog: http://blogs.activestate.com/2010/04/whats-new-in-activeperl-rollout-of-features-from-perl-5-12/ Or read the exhaustive list of changes in the perl5120delta document: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5120delta.html For some background information about the renewed Perl 5 development efforts you may also want to read: http://blogs.activestate.com/2010/04/perl-5-is-alive/ Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ActivePerl Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business_edition/ Custom builds are available in the Enterprise Edition: http://www.activestate.com/activeperl/enterprise Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1201 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Using mingw64 with x64 ActiveState builds.
On Sun, 18 Apr 2010, Sisyphus wrote: [...] And there's no such problem with these mingw64 compilers if they're the compiler that actually built perl. It's just when I try to use these compilers with x64 builds of ActivePerl that the strange DynaLoader errors can eventuate. I'll eventually take a look at this, but for now have considered mingw-w64 to be too experimental to spend any time on it. Once it is sufficiently stable I'll generate a PPM package for one of the builds and make it available similar to the current MinGW package; maybe even replace the current 32-bit MinGW with the 32-bit version of MinGW-W64 as well. But that won't be happening for at least another 2 months... Note that you always had access to a free 64-bit compiler by downloading the Windows 2003 R2 Platform SDK (hich actually is even the compiler used to build ActivePerl 64-bit itself, due to it linking to the 64-bit version of MSVCRT.dll and not a compiler version specific one like MSVCR80.dll). So ... do I file a bugzilla bug report at ActiveState and provide those patches ? If mingw64 is ever going to work with the x64 builds of ActivePerl, then something like them will be needed. (If the descision to exclusively use sezero's builds was made, then those patches could be simplified - there's currently a fair amount of kludge in them just to accommodate the possibility of the 'x86_64-w64-mingw32-' prefix.) I'm fine with making the modules as flexible as possible, even though the PPM package for MinGW will most likely choose the smaller package, which I assume has the more standard names. Or do we decide that mingw64 will never work satisfactorily with the x64 builds of ActivePerl and just forget about it ? Or do we decide that, since the compiler that built the x64 ActivePerls is freely available (unlike the compiler that builds the x86 versions), then there's not even any need to have the x64 builds work with mingw64 ? Previous experience tells me that, in any event, Schwern is unlikely to ever apply my MM_Win32.pm patch - but I think ActiveState now use their own version of ExtUtils::MakeMaker. (ActivePerl/Config.pm is, afaik, outside of Schwern's jurisdiction :-) Don't forget that I do have commit access to ExtUtils::MakeMaker too: http://www.mail-archive.com/makema...@perl.org/msg02880.html I just don't want to commit anything that will need to be reverted or fixed in a short while, so I'm waiting until we have figured out exactly how this should work. It is my goal to reduce the remaining local changes in modules bundled by ActivePerl to the bare minimum necessary, and ideally to no changes at all for any modules that are on CPAN and can therefore be updated via PPM or any of the CPAN shells. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.12.0 build 1200
ActiveState is pleased to announce ActivePerl 5.12.0 build 1200, a complete, ready-to-install binary distribution of Perl 5.12. Builds for Windows, Mac OS X, Linux are made freely available. Builds for Solaris, HP-UX and AIX are available with ActivePerl Business Edition. For detailed information or to download these releases, see: http://www.activestate.com/activeperl New in ActivePerl 5.12.0 Build 1200 === * New package NAME VERSION syntax * The ... operator * Implicit use strict * Unicode improvements * Y2038 compliance * qr// overloading * Pluggable keywords * Experimental \N regexp escape Read an expanded version of this list on our blog: http://blogs.activestate.com/2010/04/whats-new-in-activeperl-rollout-of-features-from-perl-5-12/ Or read the exhaustive list of changes in the perl5120delta document: http://docs.activestate.com/activeperl/5.12/lib/pods/perl5120delta.html For some background information about the renewed Perl 5 development efforts you may also want to read: http://blogs.activestate.com/2010/04/perl-5-is-alive/ Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ActivePerl Supported Platforms === ActivePerl is available for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business_edition/ Custom builds are available in the Enterprise Edition: http://www.activestate.com/activeperl/enterprise Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1200 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActiveState announces ActivePerl 5.12.0 build 1200
On Wed, 14 Apr 2010, Jan Dubois wrote: ActiveState is pleased to announce ActivePerl 5.12.0 build 1200, a complete, ready-to-install binary distribution of Perl 5.12. Oops, forgot to mention 2 things: * The PPM repositories for ActivePerl 5.12 are currently being built. Some modules are already there, but it may take another week or so to attempt to build *all* modules on CPAN for all platforms. * The Perl Dev Kit does not yet support Perl 5.12. This support will be added in an upcoming release. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: .pl to DLL creation
Kprasad wrote: Could anyone tell me that what is process to create DLL file from perl script (.pl) file? Depends on what you want to do with that DLL file. The ActiveState Perl Dev Kit has tools to create either a COM control (PerlCtrl) or a .NET assembly (PerlNET) from code written in Perl. http://www.activestate.com/perl_dev_kit/ There is however *no* mechanism to turn a Perl script into a DLL and then have Perl functions be callable directly from e.g. C code without going through COM or .NET. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Determining if a file is open
On Thu, 18 Feb 2010, Greg Aiken wrote: other things to experiment with; a. if the file may be successfully renamed, this implies its not being held open (clunky solution, as would require you to rename once, then again to bring it back to its original filename - but low tech), or This is not correct. You can rename a file that is in use (you cannot delete it when it is in use, but that doesn't help you much here). Trying to open the file for updating is a much simpler test to make sure nobody holds the file open for writing. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.10.1 build 1007 and ActivePerl 5.8.9 build 827
ActiveState is pleased to announce ActivePerl 5.10.1 build 1007 and ActivePerl 5.8.9 build 827, complete, ready-to-install Perl distributions for Windows, Mac OS X, Linux, Solaris, AIX and HP-UX. For detailed information or to download these releases, see: http://www.activestate.com/activeperl New in ActivePerl 5.10.1 Build 1007 === The following security vulnerability has been addressed: Perl UTF-8 Regex Processing Bug Lets Users Deny Service A user can create a specially crafted UTF-8 code that, when processed by the regular expression parser, will cause the parser to crash. There has been no CVE requested/assigned for this vulnerability yet, but it is being listed by SecurityTracker at http://www.securitytracker.com/alerts/2009/Oct/1023077.html New in both ActivePerl 5.10.1 Build 1007 and ActivePerl 5.8.9 Build 827 === * perl.exe and wperl.exe now contain an application manifest that tells Windows Vista, Windows 2008 and Windows 7 to run the executable with the same privileges as the invoker. This avoids getting redirected to the Virtual Store sandbox while trying to access certain parts of the filesystem. The application manifest also requests that version 6 of the Common Controls library should be used by the application; use the Win32::VisualStyles module in your application if you want to continue to use the Windows 2000 style of the dialogs. * On Mac OS X 10.6 (Snow Leopard) it is now possible to build Perl extensions containing XS code. * On Windows the -t operator now only returns a true value if the filehandle is really connected to a console. In earlier releases it would return a true value for any kind of character device, including the NUL device. * The new ap-iis-config utility can be used to configure IIS for use with ActivePerl. It works for all supported Windows versions and their corresponding IIS releases, including Windows Vista, Windows Server 2008, and Windows 7. This tool is also used by the Windows installer to automatically configure IIS during installation if requested by the installer settings. * PPM is now capable of downloading modules from ActivePerl Business Edition repositories. You can find more information about ActivePerl Business Edition at http://www.activestate.com/business_edition * Most bundled modules have been updated to their latest released version from CPAN. Use the `ppm query` command to check the exact version included in this release. Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ActivePerl Supported Platforms === ActivePerl includes installers for the following platforms: - Windows/x86 (32-bit) - Windows/x64 (64-bit) (aka AMD64) - Mac OS X - Linux/x86 (32 bit) - Linux/x86_64 (64-bit) (aka AMD64) - Solaris/SPARC (32-bit and 64-bit) (Business Edition only) - Solaris/x86 (32-bit)(Business Edition only) - HP-UX/PA-RISC (32-bit)(Business Edition only) - AIX/PowerPC (32-bit)(Business Edition only) More information about the Business Edition can be found here: http://www.activestate.com/business_edition/ Custom builds are available in the Enterprise Edition: http://www.activestate.com/activeperl/enterprise Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1006 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Help with slow startup
On Mon, 18 Jan 2010, Michael Ellery wrote:
Thanks for that patch. I've patched the file on my system and rebooted -
now I see times shown below. Now my first startup time is only double my
steady state time, which seems to be an improvement (previous run was
more than 3 times the subsequent time). However, since the patch appears
in a .pm file, shouldn't this change have an impact *every time* the
script is executed, or is this code only loaded under certain conditions?
I suspect that there is some OS level caching going on. I think some of
the type libraries installed on your machine are stored on a network drive
and not on a local disk.
I don't have time to work out right now if we need those file tests at all,
but I have another idea that might speed up the code some more: In front
of the line that you modified with the patch insert the following line:
local ${^WIN32_SLOPPY_STAT} = 1;
Please let me know if this has any effect on your startup time.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Help with slow startup
On Tue, 19 Jan 2010, Michael Ellery wrote: Can you shed a little light on what this WIN32_SLOPPY_STAT does - I'm guessing it uses a faster set of APIs for gathering file stat info - perhaps at the cost of accuracy? The normal Perl implementation of stat() on Windows actually opens the file. That seems to be the only way to make sure updates from hardlinks get propagated. But hardlinks are rarely used on Windows, and information like nlink (the hardlink count from the stat buffer even less so), so for most purposes not doing the file open is not a problem. Of course the largest savings come from not opening a file that is on a network share and not local, because those open()s are really slow. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Help with slow startup
On Mon, 18 Jan 2010, Michael Ellery wrote: I have a slow startup problem with a library I have written. The observed behavior is that perl scripts that use my library *intermittently* take 30 seconds to startup. If I run them again immediately thereafter, they drop back down to about 10 seconds to startup. If I wait for some time (several hours, perhaps, although I'm not sure what the trigger is), then the script will exhibit slow startup again for the first execution and behave normally thereafter. Rebooting also causes the problem to reappear. Please try this patch to Win32::OLE::Const: http://code.google.com/p/libwin32/source/diff?spec=svn465r=465format=sidepath=/trunk/Win32-OLE/lib/Win32/OLE/Const.pm It specifically deals with some slowness in Win32::OLE::Const that _may_ be the problem you are seeing. I guess I should make a Win32::OLE CPAN release to get this change out to the rest of the world. So please confirm if this solves your problem! Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: How to simulate VB Casting for $perl_objects via Win32::OLE?
Win32::OLE uses late binding (the IDispatch interface, aka OLE Automation);
there is no such thing as casting to different objects
as there is only a single IDispatch interface per object. This is the same as
using Jscript or VBScript, but not VB or C++ which
normally use early binding.
It is up to the developer of the object to make sure all interfaces are
automation accessible. Ask them for sample code in VBScript
or VBA. If you cannot access the interfaces from there, then you won't be able
to access them via Win32::OLE either.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
w...@serensoft.com
Sent: Wednesday, December 16, 2009 11:40 AM
To: perl-win32-users@listserv.ActiveState.com
Subject: How to simulate VB Casting for $perl_objects via Win32::OLE?
Hi --
Short version: how can we simulate .NET/VB object-type CASTing, in Win32::OLE
Perl?
Long version:
We're building a bridge between a java-web-app and a .net-based-desktop app.
Perl is the glue language of choice, of course :)
Where we've got trouble is that the .net programmers tell us we need to cast
object_1 to be type object_2, and we haven't see how
that's done in the Win32::OLE manual pages.
For example we start with a Collection, iterate through
CoursesCollection-Item(ix) and from there we get a
StudentsCollection-Item( foo ) which is a generic object but needs to be CAST
as a 'proper' Student object instead. How do we do
that in Win32::OLE?
my $classes = App-Classes;
my $class_ct = $classes-Count;
for ( my $class_ix = 1; $class_ix = $class_ct; $class_ix ++ ) {
my $class = $classes-Item( $class_ix );
my $students = $class-Students;
my $stu_ct = $students-Count;
for ( my $stu_ix = 1; $stu_ix = $stu_ct; $stu_ix ++ ) {
my $stu = $students-Item( $stu_ix );
# $stu is a GENERIC object here with only basic methods
# need to 'cast' it to Student type so we can get grades
my $grades = $stu-Grades; # boom! (Name not found, meaning no such method)
}
}
We were hoping the objects were classed somehow inside Perl, but all objects
appear to be simply Win32::OLE objects, and even trying
to get to the hash keys gives an error...
Any pointers/flames welcome. Thanks!
--
will trillich
Tis the set of the sails / And not the gales / That tells the way we go. --
Ella Wheeler Wilcox
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: PerlScript OLE browser [was How to simulate VB Casting for $perl_objects via Win32::OLE?]
Ok, here is what Graham from ActiveState support tells me:
You may also need to go to the Security tab in the Internet Options, select
Local intranet and click on the Sites button.
Then disable the Automatically detect intranet network and instead select the
individual choices underneath manually.
I wonder if we shouldn't drop the OLE browser from ActivePerl; it is hard to
get it working, and enabling it leaves you with a
security vulnerability unless you can trust all web pages on your local
intranet.
Note that both Microsoft Visual Studio and Microsoft Office come with Object
browsers themselves, so if you have either of them, it
might be easier to use those browsers instead (the Win32::OLE browser is
basically a re-implementation of the one from Office 97 in
Perl and DHTML).
Cheers,
-Jan
From: trill...@gmail.com [mailto:trill...@gmail.com] On Behalf Of
w...@serensoft.com
Sent: Wednesday, December 16, 2009 3:11 PM
To: Jan Dubois
Cc: perl-win32-users@listserv.activestate.com
Subject: PerlScript OLE browser [was How to simulate VB Casting for
$perl_objects via Win32::OLE?]
Thanks Jan. We've got the .NET wonks working on just this approach.
BTW... what does it take to get the PerlScript OLE browser to work? I tried a
quick test (below) and PerlScript is working in IE,
but the OLE browser frames are all empty except for the default could not
load gripe at the bottom. Is there a start-condition of
some sort? (And Initialize and script ActiveX controls not marked as safe is
set to Enable for the local intranet zone...)
script language=PerlScript
$window-{status} = 'Hi from PerlScript!'; # works!
/script
http://www.xav.com/perl/site/lib/Win32/OLE/Browser/Browser.html
file:///C:/Perl/html/lib/Win32/OLE/Browser.html
file:///C:\Perl\html\lib\Win32\OLE\Browser.html
On Wed, Dec 16, 2009 at 2:10 PM, Jan Dubois j...@activestate.com wrote:
Win32::OLE uses late binding (the IDispatch interface, aka OLE Automation);
there is no such thing as casting to different objects
as there is only a single IDispatch interface per object. This is the same as
using Jscript or VBScript, but not VB or C++ which
normally use early binding.
It is up to the developer of the object to make sure all interfaces are
automation accessible. Ask them for sample code in VBScript
or VBA. If you cannot access the interfaces from there, then you won't be able
to access them via Win32::OLE either.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
w...@serensoft.com
Sent: Wednesday, December 16, 2009 11:40 AM
To: perl-win32-users@listserv.ActiveState.com
Subject: How to simulate VB Casting for $perl_objects via Win32::OLE?
Hi --
Short version: how can we simulate .NET/VB object-type CASTing, in Win32::OLE
Perl?
Long version:
We're building a bridge between a java-web-app and a .net-based-desktop app.
Perl is the glue language of choice, of course :)
Where we've got trouble is that the .net programmers tell us we need to cast
object_1 to be type object_2, and we haven't see how
that's done in the Win32::OLE manual pages.
For example we start with a Collection, iterate through
CoursesCollection-Item(ix) and from there we get a
StudentsCollection-Item( foo ) which is a generic object but needs to be CAST
as a 'proper' Student object instead. How do we do
that in Win32::OLE?
my $classes = App-Classes;
my $class_ct = $classes-Count;
for ( my $class_ix = 1; $class_ix = $class_ct; $class_ix ++ ) {
my $class = $classes-Item( $class_ix );
my $students = $class-Students;
my $stu_ct = $students-Count;
for ( my $stu_ix = 1; $stu_ix = $stu_ct; $stu_ix ++ ) {
my $stu = $students-Item( $stu_ix );
# $stu is a GENERIC object here with only basic methods
# need to 'cast' it to Student type so we can get grades
my $grades = $stu-Grades; # boom! (Name not found, meaning no such method)
}
}
We were hoping the objects were classed somehow inside Perl, but all objects
appear to be simply Win32::OLE objects, and even trying
to get to the hash keys gives an error...
Any pointers/flames welcome. Thanks!
--
will trillich
Tis the set of the sails / And not the gales / That tells the way we go. --
Ella Wheeler Wilcox
--
will trillich
Tis the set of the sails / And not the gales / That tells the way we go. --
Ella Wheeler Wilcox
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Using Win32::API to call C# methods?
On Mon, 09 Nov 2009, Jason Lowder wrote: I'm attempting to use a C# method from my Perl script but am receiving a return code of 127 and unknown error for $!. You cannot call .NET code using Win32::API. It is not native x86 code, but code for a virtual machine that must be executed by the .NET runtime. You can call .NET code from Perl using PerlNET from the ActiveState Perl Dev Kit. You can find more information (and download a trial version) here: http://www.activestate.com/perl_dev_kit/ http://docs.activestate.com/pdk/8.1/PerlNET_overview.html A free alternative if you only want to call into .NET might be the Win32::CLR module from CPAN. You'll need to compile it yourself with the corresponding Microsoft C++ compiler. I've never tried it myself, so I don't know if it works or not. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: POE in PPM4 repository for Perl 5.10
Every new version uploaded to CPAN will automatically be compiled and tested by the PPM build machines. You can see that the latest versions of POE all fail to run their tests on Windows without errors: http://ppm4.activestate.com/idx/PO.html There is a single test failure: # Failed test 'timeout for connection' # at C:\cpanfly\var\megalib\POE\Test\Loops/connect_errors.pm line 61. t/30_loops/select/connect_errors.t 1..3 ok 1 - found unused port: 3001 not ok 2 - timeout for connection ok 3 - run() returned successfully Failed 1/3 subtests I've tried to build the latest version of POE manually (ActivePerl 5.10.1.1006, VC6, Win2K), and got the same test failure. Please contact the module authors about the problem. If they upload a fixed version to CPAN then it should automatically appear on the PPM servers within a few days. Cheers, -Jan PS: The best contact point for this kind of problem is probably to file a bug at http://bugs.activestate.com in the ActivePerl category with the component set to ppm_server or ppm_modules. As a second choice emailing to the PPM mailing list is probably better than the general-purpose perl-win32-users or activeperl mailing lists. From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Olivier Mengué Sent: Tuesday, October 27, 2009 9:59 AM To: perl-win32-us...@activestate.com Subject: POE in PPM4 repository for Perl 5.10 Hi, It looks like POE has not been updated for a while in the ActiveState PPM4 repository at http://ppm4.activestate.com/MSWin32-x86/5.10/1003/ The latest version in the repository is 1.006 (May 2009) while the latest available on CPAN is 1.280 (October). See ppm search POE I'm also using POE-Wheel-Run-Win32. The latest version in the PPM4 repository has been recently upgraded and is now 0.18. It is now dependent on POE 1.280 which is not available, so I can not install it, neither be able to use the previous version. See ppm search POE-Wheel-Run-Win32 Can someone fix this inconsistency by upgrading POE ? What is the contact point to report such issues ? Olivier. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: where is Win32-DDE
You can find the old sources here: http://mirrors.develooper.com/perl/backpan/authors/id/D/DE/DEWEG/Win32-DDE-0.02.zip You should be able to install it from the bribes repository with PPM if you want to: ppm repo add bribes ppm install Win32-DDE Note that the module only supports cold DDE, not warm (notifications only, client has to request data), or hot (notifications already contain updated data) connections. You can probably do virtually everything you can do with cold DDE better with OLE Automation nowadays (Win32::OLE). DDE is kind of a dead protocol. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Daniel Burgaud Sent: Friday, October 09, 2009 3:00 PM To: Perl-Win32-Users Subject: where is Win32-DDE Hi Does anyone know where to get DDE? CPAN nor PPM does not have it. Otherwise, anyone knowledgeable on the DDE Protocol instead? ie, I'd like to write one or at least try to. ;) Dan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Build 1006 has some unexpected Config values
On Thu, 03 Sep 2009, Sisyphus wrote:
With build 1006, I'm getting the following:
#
C:\_32perl -V:cc
Set up gcc environment - 3.4.5 (mingw-vista special r3)
cc='C:/_32/ap1005/site/bin/gcc.exe';
C:\_32perl -V:ld
Set up gcc environment - 3.4.5 (mingw-vista special r3)
ld='C:\_32\ap1005\site\bin\g++.exe';
C:\_32perl -V:make
make='C:\_32\ap1005\site\bin\dmake.exe';
C:\_32
#
This is an intentional change. It enables the dmake/MinGW suppot even for
users that manually setup the PATH to include Perl\bin but forget to include
the Perl\site\bin directory as well.
Is it acceptable to have those Config values specify the full path and
extension ?
Acceptable by whom? :) The documentation doesn't really say one way or the
other:
| cc (cc.U):
| This variable holds the name of a command to execute a C compiler which
| can resolve multiple global references that happen to have the same
| name. Usual values are 'cc' and 'gcc'.
| Fervent ANSI compilers may be called 'c89'. AIX has xlc.
So it is customary to have a plain name, but it doesn't say that you can't
have the full name (including the file extension).
I did have to fix some tests inside ExtUtils::* module to deal with this
correctly, so I should better get on with getting those changes into
the next ExtUtils::MakeMaker release as well...
This prevents Inline::C from building as C:/_32/ap1005/site/bin/gcc.exe.exe
(which, of course, doesn't exist) can't be found by the C/Makefile.PL. And
I'll argue that that is a bug in Inline::C. The first GCC on the PATH could
be a gcc.bat wrapper, and Inline::C would then miss that one as well.
Would you mind filing a bug report for it?
I'm sure I've written the odd Makefile.PL or two where I've done something
like:
if($Config{make} eq 'dmake') {
# do something
}
That will now have to be rewritten as:
if($Config{make} =~ /dmake/) {
# do something
}
ExtUtils::MM_Win32 uses this mechanism:
sub is_make_type {
my($self, $type) = @_;
return !! ($self-make =~ /\b$type(?:\.exe)?$/);
}
I could make a (weak) argument that in addition to .exe it should also
allow .bat, .cmd, and .com, but I'm not aware of anyone using non-.exe
wrappers for nmake/dmake.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Build 1006 has some unexpected Config values
On Thu, 03 Sep 2009, Sisyphus wrote:
From: Jan Dubois j...@activestate.com
Is it acceptable to have those Config values specify the full path
and extension ?
Acceptable by whom? :) The documentation doesn't really say one way
or the other:
| cc (cc.U):
| This variable holds the name of a command to execute a C compiler which
| can resolve multiple global references that happen to have the same
| name. Usual values are 'cc' and 'gcc'.
| Fervent ANSI compilers may be called 'c89'. AIX has xlc.
That's what I was wondering. If it's not prohibited, then it's permitted :-)
Well there you go then! :)
As a further datapoint, $Config::Config{ar} on 64-bit AIX contains not
just the commandname ar but even additional flags ar -X64.
Of course that is quite a dangerous precedent, as it means we couldn't
really store pathnames with spaces in these %Config entries because
applications would know if the individual words would be part of a
single long pathname, or if they represented options to the command. :(
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActiveState announces ActivePerl 5.10.1 build 1006
On Fri, 28 Aug 2009, Sisyphus wrote: On Fri, 28 Aug 2009, Jan Dubois j...@activestate.com wrote: ActiveState is pleased to announce ActivePerl 5.10.1 build 1006, a complete, ready-to-install Perl distribution for Windows, Mac OS X, Linux, Solaris, and AIX. There's apparently a (presumably) minor bug with the Windows x64 build (msi package only) that came to light in the perlmonks thread http://www.perlmonks.org/index.pl?node_id=791470 . It's reported there that the 'perl -V' output begins with Summary of my perl5 (revision 5 version 10 subversion 0) which is the wrong subversion number. I installed from the zip package, and it correctly states the subversion number as '1'. I cannot reproduce the problem with a clean install. I haven't yet tried installing 5.10.1 on top of 5.10.0. That should work too, but I typically install into a new location every time. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.10.1 build 1006
ActiveState is pleased to announce ActivePerl 5.10.1 build 1006, a complete, ready-to-install Perl distribution for Windows, Mac OS X, Linux, Solaris, and AIX. For detailed information or to download these releases, see: http://www.activestate.com/Products/activeperl New in ActivePerl 5.10.1 Build 1006 === * Significant changes that have occurred in the Perl 5.10.1 release, including some incompatible changes to the select statement and the smart matching operator, are documented in the perl5101delta manpage. http://docs.activestate.com/activeperl/5.10/lib/pods/perl5101delta.html * The following security vulnerabilities have been addressed: - CVE-2009-1391 Off-by-one error in the inflate function in Zlib.xs in Compress::Raw::Zlib Perl module before 2.017, as used in AMaViS, SpamAssassin, and possibly other products, allows context-dependent attackers to cause a denial of service (hang or crash) via a crafted zlib compressed stream that triggers a heap-based buffer overflow. This CVE was already addressed in ActivePerl build 1005 but was not mentioned in the change log. - CVE-2009-1884 Off-by-one error in the bzinflate function in Bzip2.xs in the Compress-Raw-Bzip2 module before 2.018 for Perl allows context-dependent attackers to cause a denial of service (application hang or crash) via a crafted bzip2 compressed stream that triggers a buffer overflow, a related issue to CVE-2009-1391. * PPM now always scans all the .packlist files that are newer than the corresponding PPM database for that install area. This means that modules installed manually, or via the CPAN shell will immediately be listed by `ppm query` and can be uninstalled with `ppm remove`. * On 32-bit Windows the CPAN shell will automatically download and install the MinGW GCC compiler and the dmake utility if it cannot find a C compiler and make utility on the PATH. In other situations (e.g. when you run `perl Makefile.PL` from the commandline) ActivePerl will only display a warning and information how to manually install the MinGW compiler. * All modules shipped as part of core Perl will now be included in the PPM database. That allows `ppm upgrade` to automatically detect if updates for any of the core modules are available from a PPM repository. * Almost all bundled modules have been updated to their latest released version from CPAN. Use the `ppm query` command to check the exact version included in this release. - This release contains DBI version 1.607 and SQL-Statement version 1.15. This combination is the most recent one that does not break operation of the DBD-CSV module. The latest versions at the time of the ActivePerl 5.10.1.1006 release are DBI 1.609 and SQL-Statement 1.20 which showed several regressions when used with DBD::CSV in ActiveState's testing. - The JSON-XS module has been removed from the ActivePerl distribution. Please install it using `ppm install JSON-XS` if you need it. Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ActivePerl Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1006 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: GUI based perl
On Thu, 30 Jul 2009, Serguei Trouchelle wrote: I'd say Tkx because Tk is no longer developed. In case you haven't seen it, the TkDocs site has a tutorial that shows how to use the latest Tk bindings from Tcl, Ruby, Python and Perl, using the Tkx interface for the Perl code: http://www.tkdocs.com/tutorial/index.html Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Perl and memory...
On Tue, 28 Jul 2009, Chris Wagner wrote: At 06:48 PM 7/28/2009 +0300, Serguei Trouchelle wrote: I'm not sure. Ending thread on Windows deallocates memory as it said in MSDN, but I'm not exactly sure how Perl handles all this stuff. So that could be Windows specific? The application I made was on Solaris. I actually thought it was a memory leak in my code. After I found out Perl couldn't free() memory I gave up on trying to shrink the process size and implemented a multiprocess system to deal with the memory issue. It was ActiveState Perl though. Jan? I'm somewhat surprised that even the Windows version returns memory back to the OS. Perl on Windows used to use separate heaps for each interpreter and they got freed when the interpreter got freed. But nowadays everything is using malloc/free from the C runtime library. So I guess it really depends on the runtime library if it will return heap blocks back to the system or not. It is also not clear to me if you were looking at physical or virtual memory allocation. In some ways it doesn't make sense to obsess about returning memory to the OS too much: if you don't use it anymore, it will just get paged out to disk. And other processes have their own virtual memory anyways. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
On Mon, 13 Jul 2009, Sisyphus wrote:
From: Jan Dubois j...@activestate.com
I've added that code, and also tried to use it for the
ActivePerl::Config hack that tells ExtUtils::Liblist::Kids about the
MinGW library location:
Again, I've struck no need to remove the additional 2 lines that you
have, but again, the application of that patch doesn't break anything.
I don't know why $ENV{ACTIVEPERL_MINGW}/lib was being pushed onto
@libpath in the first place. For me, that resolves to my perl/site/lib
directory and there's certainly no reason for me to push that location
onto @libpath. Did it ever serve a purpose for anyone ?
Good point; the code is actually broken when you invoke gcc via the
forwarders in Perl\site\bin.
However, when you have C:\MinGW\bin in your PATH, then it would add
C:\MinGW\lib, which is where all the libfoo.a import libraries for the
standard Windows libraries are stored. Adding this directory gets rid of
these warnings:
Note (probably harmless): No library found for -lkernel32
Note (probably harmless): No library found for -luser32
Note (probably harmless): No library found for -lgdi32
Note (probably harmless): No library found for -lwinspool
Note (probably harmless): No library found for -lcomdlg32
Note (probably harmless): No library found for -ladvapi32
Note (probably harmless): No library found for -lshell32
Note (probably harmless): No library found for -lole32
Note (probably harmless): No library found for -loleaut32
Note (probably harmless): No library found for -lnetapi32
Note (probably harmless): No library found for -luuid
Note (probably harmless): No library found for -lws2_32
Note (probably harmless): No library found for -lmpr
Note (probably harmless): No library found for -lwinmm
Note (probably harmless): No library found for -lversion
Note (probably harmless): No library found for -lodbc32
Note (probably harmless): No library found for -lodbccp32
Note (probably harmless): No library found for -lmsvcrt
At least for modules using Module::Install, like Par-Packer. The
warnings are harmless, but it seems better to suppress them than
to confuse a user that something might be wrong when actually it
isn't.
I guess I'll need to add some more code to ActivePerl::Config
to replace Perl\site\lib with Perl\site\lib\auto\MinGW\lib.
So any objections to appending that location to LIBRARY_PATH?
Cheers,
-Jan
PS: MinGW-5.1.4.1 seems to be on the external PPM servers now
if you want to give it a try.
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
On Sun, 12 Jul 2009, Sisyphus wrote:
1) I've found that we can't actually build perl using the MinGW that
gets installed using ppm. This happens because windres.exe cannot
be found. Adding the perl/site/lib/auto/MinGW folder fixes the
problem, but perhaps it would be better to put an executable named
windres.exe in perl/site/bin - as has been done for ar, g77, g++,
gcc and dlltool. Btw, what does the source code for those
executables look like ?
I've built a new MinGW package 5.1.4.1 for PPM that includes the forwarder
for windres.exe.
I found a somewhat surprising WTF in the MinGW installer itself: even though
the version number is unchanged at 5.1.4 the following 3 included packages
have been updated from the last time I downloaded it:
from: binutils-2.17.50-20060824-1.tar.gz
to: binutils-2.19.1-mingw32-bin.tar.gz
from: mingwrt-3.15.1-mingw32.tar.gz
to: mingwrt-3.15.2-mingw32-dev.tar.gz
from: w32api-3.12-mingw32-dev.tar.gz
to: w32api-3.13-mingw32-dev.tar.gz
If you have any contact with the MinGW developers you may want to mention
that updating the version number of MinGW might be a good idea. I would
have expected that at least the Build number would be changed in the
mingw.ini file, but even that remained at 11.
The 5.1.4.1 PPM package will have all the latest bits, so you may want
to give it a spin. It may take a day or two before it becomes visible on
the external PPM server.
2) ExtUtils::Liblist::Kid.pm contains the following:
if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
push @libpath, split /;/, $ENV{LIB};
}
It would be really neat if the same could be done for MinGW, by adding
the following code immediately after the above code:
# For the benefit of MinGW:
if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
push @libpath, split /;/, $ENV{LIBRARY_PATH};
}
I've added that code, and also tried to use it for the ActivePerl::Config
hack that tells ExtUtils::Liblist::Kids about the MinGW library location:
--- lib/ActivePerl/Config.pm.~1~Sun Jul 12 23:50:01 2009
+++ lib/ActivePerl/Config.pmSun Jul 12 23:50:01 2009
@@ -86,7 +86,15 @@
# assume MinGW or similar is available
$gcc =~ s,\\,/,g;
my($mingw) = $gcc =~ m,^(.*)/bin/gcc\.exe$,;
- $ENV{ACTIVEPERL_MINGW} = $mingw if defined $mingw;
+ if (defined $mingw) {
+ $mingw .= /lib;
+ if (defined $ENV{LIBRARY_PATH}) {
+ $ENV{LIBRARY_PATH} .= ;$mingw;
+ }
+ else {
+ $ENV{LIBRARY_PATH} = $mingw;
+ }
+ }
_override(cc, gcc);
_override(ccname, gcc);
--- lib/ExtUtils/Liblist/Kid.pm.~1~ Sun Jul 12 23:50:01 2009
+++ lib/ExtUtils/Liblist/Kid.pm Sun Jul 12 23:50:01 2009
@@ -272,8 +272,8 @@
if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
push @libpath, split /;/, $ENV{LIB};
}
-if ($GC and exists $ENV{ACTIVEPERL_MINGW} and $ENV{ACTIVEPERL_MINGW}) {
-push @libpath, $ENV{ACTIVEPERL_MINGW}/lib;
+if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
+push @libpath, split /;/, $ENV{LIBRARY_PATH};
}
foreach (Text::ParseWords::quotewords('\s+', 0, $potential_libs)){
This should make it easier to eventually get the changes back into the CPAN
version. Do you see any problem with pushing the MinGW/lib directory to
the end of LIBRARY_PATH even though GCC will already have this location
built in? I'll do some testing before the next release myself, but feel
free to try it and see if you find any problems with this.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: MinGW - additional question from relative newbie
On Mon, 13 Jul 2009, Greg Aiken wrote: The problem is that my main computer is not direct connected to the internet, so I cant issue a 'ppm install MinGW' command. Does anyone know of a step by step manual installation/configuration sequence that one may follow to manually install MinGW to an ActivePerl computer? In a way where it will be able to install modules that require 'xs' code compilation? Where I can download all required files from my internet-connected PC, then copy them to my non-internet-connected PC, and manually do this installation and configuration. You need to download the following 4 files: http://ppm4.activestate.com/MSWin32-x86/5.10/1006/-/--/MINGW/dmake-4.11.20080107.ppd http://ppm4.activestate.com/MSWin32-x86/5.10/1006/-/--/MINGW/dmake-4.11.20080107.tar.gz http://ppm4.activestate.com/MSWin32-x86/5.10/1006/-/--/MINGW/MinGW-5.1.4.1.ppd http://ppm4.activestate.com/MSWin32-x86/5.10/1006/-/--/MINGW/MinGW-5.1.4.1.tar.gz Put all of them into a single directory on the target computer and install them (dmake fist, followed by MinGW): ppm install dmake-4.11.20080107.ppd ppm install MinGW-5.1.4.1.ppd Don't worry about the download URL above; these PPM packages will install correctly into any ActivePerl 5.8.8 build 818 and later and all 5.10 versions. As usual, latest released ActivePerl versions recommended. Make sure you have C:\Perl\site\bin in your PATH in addition to the regular C:\Perl\bin (the installer should have done this for you automatically). You need to use dmake, not make or nmake with MinGW. That should be it. Let us know if you run into any problems. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: 2 MinGW-related feature requests.
On Sun, 12 Jul 2009, Sisyphus wrote:
Should I submit the 2 proposals below to bugzilla ?
Yes, please!
1) I've found that we can't actually build perl using the MinGW that
gets installed using ppm. This happens because windres.exe cannot
be found. Adding the perl/site/lib/auto/MinGW folder fixes the
problem, but perhaps it would be better to put an executable named
windres.exe in perl/site/bin - as has been done for ar, g77, g++,
gcc and dlltool. Btw, what does the source code for those
executables look like ?
Note that all the *.exe files are all the same. You can just copy any of
them to windres.exe in the same directory to get another forwarder.
Which is all those executables do: they take their commandline and
replace the actual executable name with something that redirects to
../lib/auto/MinGW/bin/ and then re-execs themselves. The only exception is
if the name is dmake.exe, in which case it gets redirected to
../lib/auto/dmake/ instead.
The only reason the forwarders exists is to keep the relative directory
structure of the MinGW install intact *and* be able to let PPM install
and remove it. Which means it can only install into the site/bin and
site/lib trees.
2) ExtUtils::Liblist::Kid.pm contains the following:
if ($VC and exists $ENV{LIB} and $ENV{LIB}) {
push @libpath, split /;/, $ENV{LIB};
}
It would be really neat if the same could be done for MinGW, by adding the
following code
immediately after the above code:
# For the benefit of MinGW:
if ($GC and exists $ENV{LIBRARY_PATH} and $ENV{LIBRARY_PATH}) {
push @libpath, split /;/, $ENV{LIBRARY_PATH};
}
Yes, sounds like a good idea to me too. Will add it to ActivePerl,
but please file a bug to make sure it doesn't get lost.
I've been using this in my own builds of perl for quite some time, and
it's a very handy amendment to have in place. (Amending Kid.pm by hand
every time I update EU::MM/perl does, however, become rather
tiresome.) I asked Schwern to put it in the official release of
EU::MM, but he refused - worried it might break something. It then
occurred to me that, since ActivePerl ships with ActiveState's own
version of EU::MM, ActiveState might be willing to include that code.
(Better still if someone can convince Schwern to stick it in the
official release.)
Yes, I would like to be able to get all the ActivePerl modifications
into the CPAN version of ExtUtils::MakeMaker, but it is not easy to
generalize them enough to make them useful outside ActivePerl.
And Schwern just pulled the HTML generation extensions from the CPAN
version *again* because there was some problem with it.
Anyways, I hope I'll get around to it eventually, but in the meantime
we can stick the MinGW stuff into ActivePerl at least.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: MSDOS Path
On Thu, 18 Jun 2009, Phillip Richcreek wrote: I'm troubleshooting a problem with CAM:PDF that has appeared after I installed 5.10 along with a more recent version of CAM::PDF than I was running with 5.8. During my troubleshooting, I've modified the MSDOS Path value and now, before proceeding, I want to confirm that I have the correct perl folders/directories in the Path. The perl directories in Path are: C:\Perl\site\bin; C:\Perl\bin; C:\Program Files\ActiveState Komodo Edit 5\; C:\Program Files\ActiveState Perl Dev Kit 7.3\bin; C:\Program Files\ActiveState Perl Dev Kit 7.3 Deployment\bin; There is no reason to install PDK 7.3 Deployment if you already have PDK 7.3 Pro, as the later is a full superset of the former. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Automate an ActiveX Process
On Mon, 15 Jun 2009, Phillip Richcreek wrote: I want to automate -- eliminate user interaction -- a process that states in its doc... Miraplacid Text Driver registers itself as an ActiveX object and could be used from any scripting and OLE-compliant software. Using this ability, you can control the printing process directly from your script or application. To create component, use following constructions JScript: var obj = WScript.CreateObject(Miraplacid.TextDriver); VBScript: set obj = WScript.CreateObject(Miraplacid.TextDriver) Visual Basic: Set obj = CreateObject(Miraplacid.TextDriver) use Win32::OLE; my $obj = Win32::OLE-new(Miraplacid.TextDriver); I'd like to write the automation script in perl. Can someone give me some guidance on how to do this? I have a request in to the product's support group but so far they have not responded. Read the documentation for Win32::OLE and the object model of your application for further information. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Math-Currency install...where is it?
On Thu, 11 Jun 2009, Phillip Richcreek wrote: I installed a package called Math-Currency under 5.8 some time ago. More recently I installed perl 5.10 and now am unable to find a repository where Math-Currency resides. The ppmprofile entry from 5.8 looks like this: SOFTPKG NAME=Math-Currency VERSION=0,44,0,0 TITLEMath-Currency/TITLE ABSTRACTExact Currency Math with Formatting and Rounding/ABSTRACT AUTHORJohn Peacock lt;jpeac...@cpan.orggt;/AUTHOR IMPLEMENTATION OS NAME=MSWin32 / ARCHITECTURE NAME=MSWin32-x86-multi-thread-5.8 / CODEBASE HREF=MSWin32-x86-multi-thread-5.8/Math-Currency-0.44.zip / PROVIDE NAME=Math::Currency VERSION=0.44 / PROVIDE NAME=Math::Currency::GBP VERSION=0.41 / PROVIDE NAME=Math::Currency::JPY VERSION=0.41 / /IMPLEMENTATION /SOFTPKG Is CODEREF supposed to identify the repository the package was installed from? And shouldn't it include a root directory? This shows that you installed Math::Currency from a local ZIP file and not from a repo, e.g. something like this: ppm install Math-Currency-0.44.pdd Math::Currency is not available from the PPM repositories because it doesn't pass its own test suite on Windows (and OS X). You can always build and install it yourself using the CPAN shell and ignore the test failures. Use `ppm install MinGW` to install the gcc compiler and dmake utility to get a complete build environment (warning, expands to 80MB or so). I still have the 5.8 Math-Currency directory in the 5.8 site/lib.Is there some way to access it from there? This doesn't work when a module contains XS code, but Math::Currency is plain Perl code, so you could just copy the *.pm files over to the corresponding place in your 5.10 tree. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: :UserAgent 'Ordinal not Found'
On Wed, 10 Jun 2009, Phillip Richcreek wrote: I'm getting the following error(s) using LWP::UserAgent... (POP-UP) Perl.exe - Ordinal not found The ordinal 3212 could not be located in the dynamic link library LIBEAY32.dll (from perl script) 501 Protocol scheme 'https' is not supported (Crypt::SSLeay not installed) at getChaseChecking.pl line 21. I have, in fact, installed Crypt::SSLeay, which put LIBEAY32.dll into perl/bin. There ARE other LIBEAY32's present in the MSDOS path and I've tried using those as well and get the same result. I now have perl/bin at the front of the path. I also downloaded a more recent verions of LIBEAY32 from sourceforge and got the same result. This is indeed a problem of mismatched libeay32.dll files. I'm not sure why putting perl/bin in front of the PATH doesn't help (are you sure libeay32.dll is in perl/bin and not perl/site/bin?). To avoid this kind of problem ActivePerl contains Crypt::SSLeay statically linked to OpenSSL, so it doesn't use libeay32.dll and ssleay32.dll at all. Therefore you may want to try to update to the latest ActivePerl if you cannot solve your problem any other way. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: LWP::UserAgent 'Ordinal not Found'
On Wed, 10 Jun 2009, Serguei Trouchelle wrote: Also, try to copy libeay32.dll from perl/bin to /perl/site/lib/auto/Crypt/SSLeay That is a good suggestion. I don't remember off-hand if Crypt::SSLeay also needs ssleay32.dll, but generally it is a good idea to copy both DLLs as they are a matched pair. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ActiveState announces ActivePerl 5.8.9.826 and 5.10.0.1005
ActiveState is pleased to announce ActivePerl 5.8.9 build 826 and ActivePerl 5.10.0 build 1005, complete, ready-to-install Perl distributions for Windows, Mac OS X, Linux, Solaris, and AIX. For detailed information or to download these releases, see: http://www.activestate.com/Products/activeperl New in ActivePerl 5.8.9 Build 826 = * The following security vulnerabilities in the Crypt::SSLeay module were addressed in this release by upgrading the OpenSSL libraries to version 0.9.8k: - CVE-2009-0590 (ASN1 printing crash) The function ASN1_STRING_print_ex() when used to print a BMPString or UniversalString will crash with an invalid memory access if the encoded length of the string is illegal. Any OpenSSL application which prints out the contents of a certificate could be affected by this bug, including SSL servers, clients and S/MIME software. - CVE-2009-0789 (Invalid ASN1 clearing check) When a malformed ASN1 structure is received its contents are freed up and zeroed and an error condition returned. On 64-bit Windows this can cause an invalid memory access later resulting in a crash when some invalid structures are read, for example RSA public keys. Any OpenSSL application on 64-bit Windows which uses the public key of an untrusted certificate could be crashed by a malformed structure. Including SSL servers, clients, CA and S/MIME software. - CVE-2008-5077 (Incorrect checks for malformed signatures) Several functions inside OpenSSL incorrectly checked the result after calling the EVP_VerifyFinal function, allowing a malformed signature to be treated as a good signature rather than as an error. This issue affected the signature checks on DSA and ECDSA keys used with SSL/TLS. One way to exploit this flaw would be for a remote attacker who is in control of a malicious server or who can use a 'man in the middle' attack to present a malformed SSL/TLS signature from a certificate chain to a vulnerable client, bypassing validation. * PerlEx no longer sets the MOD_PERL environment variable (the change from build 825 has been reverted), as it has undesirable side-effects. * The -p function used to always return a false value on Windows. It now correctly detects if the filehandle argument is a pipe or not. Also the Fcntl::S_IFIFO constant is now defined. * A potential buffer overflow in Perl for ISAPI has been fixed. Whenever Perl for ISAPI wrote an error message to the log file it would potentially write beyond the end of a heap buffer. * All bundled modules have been updated to their latest versions. New in ActivePerl 5.10.0 Build 1005 === The changes in ActivePerl build 1005 are the same as for build 826 with the exception that PerlEx in build 1004 didn't claim to be mod_perl, so this didn't need to be reverted. Latest DBD::mysql binaries for Windows == In unrelated news, we've also updated the Windows PPM repositories with the latest DBD::mysql binaries for Perl 5.8, 5.10, and 64-bit 5.10. You can install them simply by running ppm install DBD-mysql Getting Started === Whether you're a first-time user or a long-time fan, our free resources will help you get the most from ActivePerl. Mailing list archives: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ActivePerl Feedback Everyone is encouraged to participate in making Perl an even better language. For bugs related to ActiveState use: http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=826 http://bugs.activestate.com/enter_bug.cgi?product=ActivePerlversion=1005 For bugs related directly to Perl please use the 'perlbug' utility. Enjoy! ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: [OT] Having multiple x64 compilers on Windows Vista 64
On Wed, 27 May 2009, Sisyphus wrote: I currently have the Microsoft Platform SDK for Windows Server 2003 R2 compiler. I would like to also install Windows SDK for Windows Server 2008 and .NET Framework 3.5 from http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDCdisplaylang=en Will installation of the latter clobber the former in any way ? It's important that I don't lose the 2003 version, as it seems to be no longer readily available from MS. (All links to it quickly turn into links to the 2008 version when it comes to strating a download.) Really? I didn't have any problems finding and downloading it so far: http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADBdisplaylang=en I normally don't use the web install as I have a complete download sitting on a local disk normally, but it looks like the web install is still working too. But I *would* like to be able to switch between the two. Will that be possible if I go ahead and install the 2008 version ? Yes, they install into different directories. The 2003 version is even still called the Platform SDK while the 2008 version is now called the Windows SDK. You can install multiple SDKs on the same machine; just make sure you don't let it set up environment variables automatically but use the setenv.cmd for each version as you need it. On an on-topic note does the unavailability of the 2003 version mean that, at some stage, it will be no longer used to build the x64 versions of ActivePerl ? That's a pretty vague question. It is entirely possible that at some stage we will switch the compiler used to build ActivePerl for x64, but being unable to download the 2003 SDK would not be enough of a reason. I believe (but have not tested this) that it should be possible to compile additional modules with the 2008 compiler and use them with the 2003 compiled ActivePerl. It may require a patch to ExtUtils::MM_Win32 in the already released versions of ActivePerl to handle the manifest binding correctly, but otherwise it should just work. The advantage of the 2003 SDK compiler for x64 (and VC6 for x86) is that they don't require additional runtime libraries; they link against MSVCRT.dll which is already part of Windows. So any application generated with PAR / PerlApp / Perl2Exe doesn't need to bundle MSVCR80.dll. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: [OT] Having multiple x64 compilers on Windows Vista 64
On Thu, 28 May 2009, Sisyphus wrote: - Original Message - From: Jan Dubois j...@activestate.com It's important that I don't lose the 2003 version, as it seems to be no longer readily available from MS. (All links to it quickly turn into links to the 2008 version when it comes to strating a download.) Really? I didn't have any problems finding and downloading it so far: http://www.microsoft.com/downloads/details.aspx?familyid=0BAF2B35-C656-4969-ACE8-E4C0C0716ADBdisplaylang=en On that page, just below the Overview heading I see the following note: NOTE: This version of the Platform SDK has been superceded by the Windows SDK for Windows Server 2008 and .NET Framework 3.5. And the Web Install link leads to http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDCdisplaylang=en which offers a Windows SDK for Windows Server 2008 and .NET Framework 3.5 download. The DVD ISO image link also leads to Windows SDK for Windows Server 2008 and .NET Framework 3.5. Yes, as the text says, these are all helpful pointers to the latest releases. Or ... have I misinterpreted what I'm seeing there ? (Perhaps the continue link still leads to the installation of the SDK 2003 ?) Indeed, the Continue button is exactly what you have to press. It does its usual Windows Genuine Advantage verification and then lets you install the SDK, [...] The advantage of the 2003 SDK compiler for x64 (and VC6 for x86) is that they don't require additional runtime libraries; they link against MSVCRT.dll which is already part of Windows. So any application generated with PAR / PerlApp / Perl2Exe doesn't need to bundle MSVCR80.dll. Yes, this is a good reason for using that particular compiler to build perl. As long as that compiler remains readily available, I see no cause for concern. Well, VC6 is no longer available if you don't already have it. You can still generate compatible binaries with MinGW, which will also link against MSVCRT.dll, or you can use a later VC version, but then you'll need to also use the version specific runtime library as well, which also works as long as you are careful not to mix runtime objects, e.g. don't call msvcr80.free() on a pointer that you received from msvcrt.malloc(), or call msvcrt.fread() on a FILE* that you received from msvcr80.fopen(). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: [OT] Having multiple x64 compilers on Windows Vista 64
On Thu, 28 May 2009, Sisyphus wrote: Jan Dubois j...@activestate.com wrote: Or ... have I misinterpreted what I'm seeing there ? (Perhaps the continue link still leads to the installation of the SDK 2003 ?) Indeed, the Continue button is exactly what you have to press. It does its usual Windows Genuine Advantage verification and then lets you install the SDK, That's good to know - thanks, Jan. Sorry for the confusion. I've installed the SDK 2008. I have an AMD64 processor and Windows Vista64 SP1, so I ran: C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\setenv /Release /ia64 /2008 That tells me: The IA64 compilers are not currently installed. Please go to Add/Remove Programs to update your installation. IA64 is the Itanium Architecture, which is not a common platform for Windows. If I specify /x64 as the second switch I get the same message, except s/IA64/x64/. And if I specify either /x86 or /vista, then it's the x86 compilers that are reported as missing. Runing 'cl /?' reports that 'cl' is not recognized as an internal or external command, operable program or batch file. Where are these compilers supposed to be ? (I would've thought in separate folders under C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin, but there are no folders in that directory.) I can find Add/Remove Programs in the control panel on XP, but not on Vista (using Classic View of the control panel). And is going to Add/Remove Programs really going to help ? I'll continue looking - and maybe even try installing again. In the meantime, any help appreciated. I think you have to run the web installer again, and then make sure you *do* select the AMD64/x64 tools. I think by default it only installs the 32-bit x86 tools, and it doesn't include the C compiler (you have to install VS Express edition to get the free 32-bit compiler). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActivePerl -x64, and another problem with mixing compilers.
On Tue, 26 May 2009, Sisyphus wrote: Jan Dubois j...@activestate.com wrote: You can actually install different versions of MSVCR80.dll on the same machine; they go into different directories under C:\Windows\WinSxS (the side-by-side installation directory). That's one helluva directory on my machine: 13 GB 14,121 folders 51,537 files Is that normal ? It is normal if you are running Vista or 2008 Server, in which case this tree contains every single file of the OS (including the components that have not been installed). All other installed files are really just NTFS hardlinks into this tree. You'll notice that you can install IIS or other optional components without having to reinsert your original media; all the files are already inside the component store on your disk. Be prepared that this directory will continue to grow: any Windows update, any service pack etc will only add files to this tree. No update/upgrade operation will ever remove an old version of a component from WinSxS. If you are running Windows XP however then the directory should be much smaller; typically less than 100MB, depending of which Microsoft libraries you have installed, as XP doesn't use the new component architecture itself. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
New DBD-mysql 4.011 PPM packages for Windows
I spent some time yesterday to teach the Windows PPM build machines how to automatically build DBD-mysql, and as a result we now have the latest version for 5.8, 5.10 and 5.10 64-bit on the ActiveState PPM repositories. I would appreciate if someone could give them a spin to confirm they all work as expected (they do pass all regression tests with a MySQL 5 server, but I haven't tested different server versions etc). Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: ActivePerl -x64, and another problem with mixing compilers.
On Tue, 26 May 2009, Foo JH wrote: Running the *appropriate* vcredist_x64.exe fixes the problem. (The appropriate one being the one for VC++ 2008, not the one for VC++ 2005.) Does this mean that if there is an existing app which ref the VC2005 dll, there will be a collision problem? No, the DLLs have different names, e.g. MSVCR80.dll for VS2005 and MSVCR90.dll for VS2008 (MSVCR70.dll was for VS.NET and MSVCR71.dll for VS 2003). The confusion was just the name of the *installer* for the redistributable DLLs, which doesn't contain a version number. But the files being installed by the identically named installers are different. You can actually install different versions of MSVCR80.dll on the same machine; they go into different directories under C:\Windows\WinSxS (the side-by-side installation directory). That's why applications linking against MSVCR80.dll need a binding manifest so that the OS knows which one of potentially multiple copies of MSVCR80.dll should be loaded for the application. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Install a Package from Local Directory
On Tue, 19 May 2009, Phillip Richcreek wrote: My experience installing perl extensions is limited to packages obtained from repositories. I want to install a package called 'email spider', or 'spiderawy', which I downloaded from www.mewsoft.com, not from an official repository. Can I use ppm to install spiderawy? No, please use the instructions from mewsoft about installation of their software: http://www.mewsoft.com/help/auction/installation.html Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Excel problem
On Fri, 08 May 2009, Glenn Linderman wrote:
So I open a workbook with macros, and then another workbook with data,
and run A_macro... as follows...
require Win32::OLE;
require Win32::OLE::Const;
Win32::OLE::Const-Load('Microsoft Excel');
$Win32::OLE::Warn = 3;
$Win32::OLE::Warn = 3;
my $Excel = Win32::OLE-new('Excel.Application', 'Quit');
my $gl = $Excel-Workbooks-Open(
$ENV{'APPDATA'} . \\Microsoft\\Excel\\XLSTART\\gl.xls);
my $Book = $Excel-Workbooks-Open(SomeData.xls);
$Excel-Run(gl.xls!A_macro);
$Book-Close( 0 );
$gl-Close( 0 );
$Excel-Close;
I get an error on the last line:
Win32::OLE(0.1707) error 0x80020011: Does not support a collection
in METHOD/PROPERTYGET at d:\my\perl\src\roster_data.pl line 3352
Your sample program above doesn't have over 3000 lines, so the error
message and the code don't seem to be related.
Any clues as to what this message means, in this context? And how I can
cure it?
I have a suspicion that your program is not running under use strict.
Could you enable use strict and see if the error message changes?
Without use strict Win32::OLE will retry some failed method calls
as indexing into unnamed collections instead. That code exists
solely for backwards compatibility and is generally not desirable.
Cheers,
-Jan
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Excel problem
On Fri, 08 May 2009, Glenn Linderman wrote: On approximately 5/8/2009 12:54 PM, came the following characters from the keyboard of Jan Dubois: Well, you didn't provide the mapping from line 3352 to $Excel-Close(). It sure looks like I said I get an error on the last line, and [...] So you did. I'm sorry, I don't quite understand how I missed that. I removed the line, tested the program. The error didn't recur, and Excel didn't stay around. Thanks for the help. I'm not a fan of MS, Excel, or OLE, preferring to spend time doing useful things, but sometimes I try to cut-n-paste some MS stuff into my programs when they must interface to some preexisting use... I've read some stuff, but error messages like these are totally useless without long experience. Poor error messages, and poor error handling are two of my biggest beefs with post MS-DOS MS software. MS-DOS wasn't too bad, but it has only gotten worse since. [...] No, it is not the require. The issue is that Win32::OLE is checking $^H at runtime, but $^H is not a lexical variable. So it's value doesn't represent the proper state of use strict at the time the call was compiled. I'm glad you understand that! All I know, is I used strict, so if OLE isn't (or can't) detect that properly, then probably it shouldn't try to do things based on strict or not... That too is my fault, back in ancient history (1998) before I officially maintained Win32::OLE I had rewritten large parts of Win32::OLE to make them more powerful and more sane (IMO), including the removal of the weird anonymous collection retry logic. But I got some resistance from the people at ActiveState (I didn't work there at that time) and as a compromise only disabled the hack under use strict on the assumption that all sane code would use strict anyways. I simply did not understand the hinting mechanism in $^H correctly at that time, and regretted not fighting harder to get the hack removed ever since. But anyways, none of the objecting parties are actively involved with ActiveState or Perl anymore, so I guess I'm free to fix this now. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Net::SSLeay on Windows X64
On Fri, 08 May 2009, Sisyphus wrote: From: Sisyphus sisyph...@optusnet.com.au One test failed (t/local/00_ptr_cast.t), but it fails only because it fails to compile a test program: It's a bug in the test script. With some help from http://www.perlmonks.org/index.pl?node_id=762762 , I finally found that the executable fails to build because bufferoverflowU.lib is not linked in. In This is only a problem when you are using the VC compiler from the Windows 2003 R2 Platform SDK. It is a variant of VS2005, but links against MSVCRT.dll instead of MSVCR80.dll. MSVCRT.dll does not contain the code necessary for the /GS buffer overrun protection new to VS2005, so it has to be linked into the generated executables statically. I guess you probably already knew this, but wanted to state it explicitly for the list archives. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: VC 8 and 64-bit ActivePerl
On Wed, 06 May 2009, Sisyphus wrote: Jan Dubois j...@activestate.com wrote: Either that, or you could embed the manifest manually into your Common.dll using the mt.exe tool. Thanks Jan. I've taken a look at 'mt /?' and can't see anything there that makes any sense at all to me. Do you know the actual command I need to run ? It would be something like this: mt -nologo -manifest Common.dll.manifest -outputresource:Common.dll;2 There's no 'manifest' file anywhere in the build directory (apart from the MANIFEST that ships with the XML-LibXML-Common source). I've tried updating to EU::MM-6.50, but that makes no difference. The *.manifest file gets written by link.exe when it builds the DLL using VC 8. It should be in the same directory as the *.dll. You need to call mt.exe after link.exe. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: VC 8 and 64-bit ActivePerl
On Thu, 07 May 2009, Sisyphus wrote: From: Jan Dubois j...@activestate.com Note that I'm not actually building XML-LibXML-Common with VC 8. I'm using the Platform SDK, Windows Server 2003 R2 compiler. It's just that I'm linking against dynamic xml2 and iconv libraries that were built with VC 8. Are you sure you are dynamically linking against xml2 and iconv libraries? In that case there would be no need for your DLL to contain the manifest; only the xml2 and iconv2 libraries themselves would have to embed it. I suspect that you are statically linking against some code that has been compiled with VC8, so you'll have a direct reference to MSVCR80.dll in you DLL. You can check with depends.exe, dumpbin.exe, or simply link /dump /imports Common.dll to see which external references you have. If you have a reference to MSVCR80.dll then you did statically link some VC8 generated code. It all works fine, except for the runtime error. (There must surely be a way of resolving this without having to build the libraries using the SDK compiler.) I did find a manifest file for an x86 Net::SSH2 dll, and I've tried to create a manifest file for Common.dll based on it. But I don't seem to be able to get it right. With my Common.dll.manifest file in place, I can then successfully run the mt.exe command, but 'nmake test' then outputs the error: Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 The minimum change for the Manifest would be to change the architecture from x86 to amd64, but it is possible that the assembly version number of MSVCR80.dll needs to be adjusted as well. This is the main point of having the manifest in the first place that you can select a specific version of MSVCR80.dll from the assembly cache even if multiple versions are installed side-by-side in %WINDIR%\\WinSxS. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: VC 8 and 64-bit ActivePerl
On Wed, 06 May 2009, Sisyphus wrote: Playing around trying to build XML-LibXML-Common-0.13 on 64-bit ActivePerl (build 1004, perl-5.10.0). I'm using the Platform SDK for Windows 2003 R2 compiler (which is the compiler that was used to build perl), but the x64 libxml2 and libiconv libraries I'm building against were built using the VC 8 compiler. It all builds fine, but as soon as the tests are run , there's this nasty runtime error crops up when the attempt is made to load XML::LibXML::Common: ## C:\_32\comp\XML-LibXML-Common-0.13nmake test Microsoft (R) Program Maintenance Utility Version 7.00.8882 Copyright (C) Microsoft Corp 1988-2000. All rights reserved. C:\_64\perl1004\bin\perl.exe -Iblib\lib -Iblib\arch test.pl 1..8 # Running under perl version 5.01 for MSWin32 # Win32::BuildNumber 1004 # Current time local: Thu May 7 10:37:41 2009 # Current time GMT: Thu May 7 00:37:41 2009 # Using Test.pm version 1.25 Can't load 'blib\arch/auto/XML/LibXML/Common/Common.dll' for module XML::LibXML: :Common: load_file:%1 is not a valid Win32 application at C:/_64/perl1004/lib/DynaLoader.pm line 202. at test.pl line 10 Compilation failed in require at test.pl line 10. BEGIN failed--compilation aborted at test.pl line 10. NMAKE : fatal error U1077: 'C:\_64\perl1004\bin\perl.exe' : return code '0x2' Stop. ## I'm wondering: a) What's causing this ? Is it because of the VC 8 compiler involvement ? Yes. The VC8 compiled code links against MSVCR80.dll, and you'll need to embed an assembly binding manifest into your DLL to make sure it can load this library at runtime. b) What to do about it ? Do I need to build libxml2 and libiconv for myself using the Platform SDK compiler ? Either that, or you could embed the manifest manually into your Common.dll using the mt.exe tool. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: VC 8 and 64-bit ActivePerl
On Wed, 06 May 2009, Sisyphus wrote: Sisyphus sisyph...@optusnet.com.au wrote: That's accompanied by a pop-up informing me that a runtime error (R6034) has occurred. In part, the pop-up says An application has made an attempt to load the C runtime library incorrectly. That just means that you are trying to load MSVCR80.dll as a dependency but haven't specified binding information in your manifest. You *must* use a manifest with VC 8. Cheers, -Jan ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: Win32::Process Help Needed - Main Process Exits While Children Run
Hi Michael,
You may want to look at the Win32::Job module. As long as your vendor programs
don't get started with the break away from job
attribute you should be able to check the status of all processes started
inside the job object. Maybe some combination of the
watch() and status() methods of the watch object will do what you want.
Cheers,
-Jan
From: perl-win32-users-boun...@listserv.activestate.com
[mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of
Michael Cohen
Sent: Wednesday, March 11, 2009 4:26 PM
To: perl-win32-users@listserv.ActiveState.com
Subject: Win32::Process Help Needed - Main Process Exits While Children Run
I have a piece of code that has been running for a number of years, until now.
My vendor changed the way they created a program,
and that new program exits before its children's processes are finished. In
the past, the following snippette has worked fine for
me:
my $progFullPath = c:\\temp\\foobar.exe;# Not the real program
my $commandLine = foobar opt1 opt2; # Again, just an example
my $ProcessObj;
Win32::Process::Create($ProcessObj,
$progFullPath,
$commandLine,
0,
NORMAL_PRIORITY_CLASS,
.)|| die print Win32::FormatMessage( Win32::GetLastError() );
while (!($done)) {
$done = 1 if ($ProcessObj-Wait(100));
$main-update; # TK update
}
As noted above, the Wait(100) would work fine if the parent program does not
exit prematurely. However, now that that is no
longer true:
a) How do I determine all of the children processes on Windows (specifically
XP at this point)?
b) How do I wait until all children processes are finished?
I have been searching the web for various options for several hours, and just
cannot come up with one at this point. If anyone has
any suggestions, pointers, solutions, etc., I would be most appreciative of
your help.
Regards,
Michael Cohen
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: PDK - perlnet application deployment
I think perl58.dll should be bundled inside the generated executables automatically, at least with the latest PDK release, but the PerlNET DLLs will have to be distributed separately. Cheers, -Jan From: perl-win32-users-boun...@listserv.activestate.com [mailto:perl-win32-users-boun...@listserv.activestate.com] On Behalf Of Jer A Sent: Friday, January 02, 2009 3:23 PM To: perl-win32-users@listserv.activestate.com Subject: PDK - perlnet application deployment All, Is it possible that I can bind the required restributable runtime dll's (eg. perl58.dll, perlnet rt dlls) to my perlNET application, so I can ship it all and run it as one dll/exe? Jeremy _ Easily add maps and directions to your online party invites. Click http://www.microsoft.com/windows/windowslive/events.aspx to learn how. ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
