perl 5.10 ActiveScript engine
..I just upgraded to 5.10 (uninstalled 5.8 and installed 5.10, actually) and I can't seem to execute using the perl ActiveScript engine. For instance, I try this simple script: use strict; say "Hello World"; and try to run with cscript -- cscript crashes. In our application, we also have a custom ActiveScript host (so we can execute ActiveScript engines) and we can also no longer run using the PerlScript engine. We get an exception thrown from the InitNew method on the IActiveScriptParse interface. Is the activescript engine broken in this release? TIA, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: perl 5.10 ActiveScript engine
Jan Dubois wrote: > On Thu, 20 Dec 2007, Michael Ellery wrote: >> ..I just upgraded to 5.10 (uninstalled 5.8 and installed 5.10, actually) >> and I can't seem to execute using the perl ActiveScript engine. For >> instance, I try this simple script: >> >> >> >> use strict; >> say "Hello World"; >> >> >> >> and try to run with cscript -- cscript crashes. >> >> In our application, we also have a custom ActiveScript host (so we can >> execute ActiveScript engines) and we can also no longer run using the >> PerlScript engine. We get an exception thrown from the InitNew method >> on the IActiveScriptParse interface. Is the activescript engine broken >> in this release? > > Yes, it looks like it is broken. :( The same issue probably afflicts > PerlEx and Perl for ISAPI as well. > > I'll see that we can get this fixed ASAP. > > Cheers, > -Jan > Any estimate when we might see a fix for this issue? Do you expect to produce a new 5.10 build or just a patch to the current build? Thanks, Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::OLE and VT_INT
just running some quick COM code in perl and I notice this: if I call a property or method that returns VT_I4, Win32::OLE maps that to a perl integer in scalar context. When I call a property or method that returns VT_INT, however, it gets mapped to a perl string. Is this deliberate? Is it correct behavior? I can work around my current issue by just doing int() around my values, but it seemed strange to me that these two cases produced slightly different scalars. Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::OLE and VT_INT
Jan Dubois wrote:
> On Wed, 09 Jan 2008, Michael Ellery wrote:
>> just running some quick COM code in perl and I notice this: if I call
>> a property or method that returns VT_I4, Win32::OLE maps that to a
>> perl integer in scalar context. When I call a property or method that
>> returns VT_INT, however, it gets mapped to a perl string. Is this
>> deliberate? Is it correct behavior? I can work around my current issue
>> by just doing int() around my values, but it seemed strange to me that
>> these two cases produced slightly different scalars.
>
> It is a bug in Win32::OLE: it doesn't handle VT_INT (nor VT_UINT)
> explicitly and therefore tries to coerce it into VT_BSTR (using
> VariantChangeTypeEx) before turning it into a Perl scalar. At the Perl
> level this shouldn't really matter though, as strings are converted back
> to integers/numbers automatically whenever needed.
>
> I don't know why it was never handled explicitly; I just checked, and
> even the wtypes.h from VC98 lists VT_INT as a valid type for a VARIANT.
>
> I'll fix it in a future Win32::OLE release.
>
> Cheers,
> -Jan
Jan,
Thanks for the quick response. In my case, I only noticed the behavior
because I am passing the output to another property - and that property
put wasn't expecting a string. It went something like this:
my $foo = $oleObject->Some_VT_INT_Property;
$oleObject->{Some_VARIANT_Property} = $foo;
The VT_TYPE coming into my put_Some_VARIANT_Property was actually
VT_BSTR in this case, which I was not expecting. Simply wrapping int()
around the get call works fine, but a fix to Win32::OLE would be great.
I think I'll also update my VARIANT processing on the put.
Thanks,
Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
properties, VT types, and Win32::OLE
Given some object and a property:
my $obj = new Win32::OLE("SOME.class");
my $val = $obj->{SomeProperty};
...is there some way to determine the VT type of $val (or of
SomeProperty, equivalently). I often run into strange problems where I
expect a 32 bit negative value from some property, but when I simply
print it, perl shows it as a large positive value. It is bit equivalent
to the expected negative value, but somehow not being interpreted with
the corrected sign-ed-ness. The first thing I would like to check is
the VT type that Win32::OLE thought it got -- then I'll see if I agree
with how Win32::OLE is converting to perl scalars based on the VT type.
Advice appreciated.
-Mike Ellery
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: properties, VT types, and Win32::OLE
Jan Dubois wrote:
> On Mon, 04 Feb 2008, Michael Ellery wrote:
>> Given some object and a property:
>>
>> my $obj = new Win32::OLE("SOME.class");
>> my $val = $obj->{SomeProperty};
>>
>> ...is there some way to determine the VT type of $val (or of
>> SomeProperty, equivalently). I often run into strange problems where I
>> expect a 32 bit negative value from some property, but when I simply
>> print it, perl shows it as a large positive value. It is bit
>> equivalent to the expected negative value, but somehow not being
>> interpreted with the corrected sign-ed-ness. The first thing I would
>> like to check is the VT type that Win32::OLE thought it got -- then
>> I'll see if I agree with how Win32::OLE is converting to perl scalars
>> based on the VT type.
>
> I haven't tested this, but you should be able to do something like this:
>
> my $prop = Win32::OLE::Variant->new();
> $obj->Dispatch('SomeProperty', $prop);
> print "V_VT(prop)=%d\n, $prop->Type);
>
With two minor syntax fixes to the print line, this works great. Thanks!
-Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::OLE and hidden methods
Can Win32::OLE access methods/props marked as hidden in the IDL? There happens to be one property we have marked as such and I tried the naive thing: my $secret = $object->HiddenProperty ...and it was rejected. Is there some way to ask Win32::OLE to ignore the hidden attribute? TIA, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
ppm repository for 5.10
Many thanks to the people at ActiveState for all the work in getting us a release of 5.10. I've been holding off on upgrading for the package compatibility problem. Is there now a complete ppm repository available for 5.10? Are there any packages that were available in 5.8 that are no longer available in 5.10? Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: rsync for Win32
Sisyphus wrote: > I couldn't find a Cygwin version of rsync under Cygwin's Setup.exe (though > it wouldn't surprise me if such a beast existred) and the 2 windows > executables that I've tried (rsync-wrap.exe and rsync.exe both croak on the > command). I have a fairly recent install of Cygwin and it looks like there is an rsync: $ which rsync /usr/bin/rsync ..I have not used it, so I can't attest that it actually works. --Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Can a Perl script be called as a COM object?
Howard Maher wrote: > One of our possible vendors said that if Perl scripts can be callable COM > objects, then we can interface with their engine. Does anyone know whether > Perl scripts can be? The languages that they suggest are VB6, C++, and > .NET... The Perl.NET project has pretty much been scrapped, correct? > Thanks in advance for any help you can give us. > try a web search for "Windows Script Components". ActiveState perl works nicely as a scriplet engine. --Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::Process::Create
..I use this function pretty regularly to spawn procs on windows, but I've often wanted to minimize the console or main window that was launched. Does anyone know how to do this? In the corresponding WIN32 API, there is a STARTUPINFO structure that allows this, but looks like it's not part of the Win32::Process API. Advice appreciated. -Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::Process::Create
Sisyphus wrote: > > What happens if you launch the script using the wperl executable instead > of the perl executable ? > I don't even know what wperl is, although it does look like it's part of my current perl install (I have never heard of it before now). In any event, it's not an option for us since most of our stuff runs in the context of the perlSE.dll (ActiveScript engine). > Have you checked the various flags constants ? From the docs: > > -- > EXPORTS >The following constants are exported by default: > >CREATE_DEFAULT_ERROR_MODE > -- > > I was thinking specifically of CREATE_NO_WINDOW constant (but perhaps > that does something else). > I believe this corresponds to this process creation flag (from MSDN docs): CREATE_NO_WINDOW 0x0800 The process is a console application that is being run without a console window. Therefore, the console handle for the application is not set. This flag is ignored if the application is not a console application, or if it is used with either CREATE_NEW_CONSOLE or DETACHED_PROCESS. I'm really looking for something that works more generally (for console and non-console apps alike). In older versions of the win32 API, I'm pretty sure there was a field in the STARTUPINFO that allowed the caller to request the app be started mimimized, but the current docs don't show such an option. Perhaps my best bet it to try to call ShowWindow directly ?? ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::Process::Create
Jan Dubois wrote: > > If you need to wait for your subprocesses, then you may want > to use this somewhat obscure form: > > my $pid = system(1, $cmdline); > # ... > waitpid $pid, 0; > > (This is documented in `perldoc perlport` as a Win32 specific extension > to system(), but not mentioned in `perldoc -f system`). > okay - thanks to everyone for the advice. I never knew this "non-blocking" version of system() existed - very interesting. Based on my quick tests, it looks like this version might still use the shell (although I can't tell). For instance, I wasn't able to start a cmd.exe instance to run a batch file using system(1, ...) in my quick tests, but that might have been pilot error. I'll give Win32::GUI::Show a shot - that might be my best option for now. Thanks, Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::OLE -- assignment to property of type IUnknown..how?
I have a COM component with a property defined like this (IDL):
[propput, id(30), helpstring("property TestSuite")] HRESULT
TestSuite([in] IUnknown *pVal);
[propget, id(30), helpstring("property TestSuite")] HRESULT
TestSuite([out, retval] IUnknown **ppVal);
..basically it gets/sets a dual interface object that is implemented in
a different COM component.
Using Win32::OLE, it doesn't let me do a normal property assignment --
i.e. this fails:
$myObj->{TestSuite} = $someOtherObj;
..however, it DOES let me do by ref assigment:
$myObj->LetProperty('TestSuite', $someOtherObj);
Can someone explain why? I would prefer (for consistency with other
properties) to use the SetProperty style of assignment instead of
LetProperty - is there something I need to change in my IDL to make the
SetProperty style work?
Thanks,
Mike Ellery
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Win32::OLE -- assignment to property of type IUnknown..how?
Jan Dubois wrote:
> On Wed, 28 May 2008, Michael Ellery wrote:
>> I have a COM component with a property defined like this (IDL):
>>
>> [propput, id(30), helpstring("property TestSuite")] HRESULT
>> TestSuite([in] IUnknown *pVal);
>
> Try adding a second line here:
>
> [propputref, id(30), helpstring("property TestSuite")] HRESULT
> TestSuite([in] IUnknown *pVal);
>
> (identical to the previous line, except propput => propputref).
>
> Not sure if this is enough, but maybe it is sufficient to get the
> required IDispatch glue generated for you.
>
> Cheers,
> -Jan
that seems to do the trick - thank you!
-Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
OLE Events and STDIN
Win32 Users, I would like to accept OLE Events in my script - I've written working code that successfully receives events. Now I want to also receive some console (stdin) input. I typically use Term::Readline for this, although I'm happy to try something else. The basic problem is that Win32:OLE MessageLoop() spins forever (or until QuitMessageLoop is called). Is there any way I can do something else, like check for console input, when MessageLoop is running? Or, perhaps I can do some kind of polling loop where I check for events, check for stdin input and then sleep briefly (I'm not sure if such a thing is possible). TIA, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: OLE Events and STDIN
Jan Dubois wrote: > > You may get something working by using Term::ReadKey::ReadKey() in > non-blocking mode interleaved with calls to Win32::OLE->SpinMessageLoop(). > thanks for this advice -- I'm going to give Spin/ReadKey a try first. It has the undesirable polling loop aspect but i think it would actually be fine for my purposes. > In general it would be better to provide a GUI for your input, > using Tk, Tkx, Win32::GUI, wxPerl etc. which would avoid the problem > altogether. > It's been a long time since I've tried any GUI programming in perl, but IIRC usually there is a point where you have to call a message loop in order to allow the UI to process messages. How would that work with with Win32::OLE's MessageLoop()? Obviously I can't have two message loops going - would the UI message loop be sufficient to deliver my COM events (in other words, I'd never have to call OLE's MessageLoop)? -Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Problem with Win32::ToolHelp module
apologies if this is not the right place for module specific questions...but here goes... I'm running 5.8.8 and have had Win32::ToolHelp installed for some time. Just recently, I started getting a failure when trying to use the package - specifically: "Can't load 'C"/Perl/site/lib/auto/Win32/ToolHelp/TollHelp.dll for module Win32::ToolHelp: load_file: The specified module could not be found at C:/Perl/lib/DynaLoader.pm line 230" I've looked on the filesystem, and ToolHelp.dll is there in the location mentioned. I've even tried "ppm install --force Win32::ToolHelp" to see if that would fix it, but it hasn't. Any idea what might be wrong and what else I could try to fix it? TIA, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Problem with Win32::ToolHelp module
Stuart Arnold wrote: > Did you copy/paste or type the error in? There seems to be a typo: > "TollHelp.dll" > ToolHelp/TollHelp.dll > typo -- sorry. That is ToolHelp.dll. Thanks, Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Problem with Win32::ToolHelp module
Michael Ellery wrote: > apologies if this is not the right place for module specific > questions...but here goes... > > I'm running 5.8.8 and have had Win32::ToolHelp installed for some time. > Just recently, I started getting a failure when trying to use the > package - specifically: > > "Can't load 'C"/Perl/site/lib/auto/Win32/ToolHelp/TollHelp.dll for > module Win32::ToolHelp: load_file: The specified module could not be > found at C:/Perl/lib/DynaLoader.pm line 230" > > I've looked on the filesystem, and ToolHelp.dll is there in the location > mentioned. I've even tried "ppm install --force Win32::ToolHelp" to see > if that would fix it, but it hasn't. > > Any idea what might be wrong and what else I could try to fix it? > after some investigation, it appears to be a case of installation of 5.8 on top of 5.6 without cleanly reinstalling all packages. I generally only do clean installs, but I was dealing with an "inherited" system and wasn't as careful as I should have been. Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
NET SSH2 ppm for 5.10
does anyone know of a source for a NET::SSH2 ppm for 5.10? I managed to get this from uwinnipeg for 5.8, but ppm is telling me it can't find it in the 5.10 repository (now that I've upgraded). Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: NET SSH2 ppm for 5.10
Serguei Trouchelle wrote: > > Try this: > > ppm install http://trouchelle.com/ppm10/Net-SSH2.ppd > yes, indeed - that seems to have worked for me. Thanks for that...and to Rob for offering his own private build to me. Regards, Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::TieRegistry question
Win32-ers,
Does anyone know off-hand what TieRegistry should do with a statment
like this:
$Registry->{'LMachine/Software/Bar'} = {'SubKey/' => { '/SomeValue' => 1 }};
..specifically, with respect to the type of the SomeValue entry? I had
thought that it would create a DWORD value since the value assigned is
integer, but based on a quick experiment, I seem to assume wrong (it
creates a REG_SZ). Anyone have any insight into this? What's the
"right" way to create/assign REG_SZ values?
Thanks,
Mike Ellery
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Adding to the perl include search path
Win32 users: What's the best way to add a new path to perl's @INC search path? Our product installs several perl modules and I would like to make those modules available to all perl scripts without asking users to add the 'use lib "mypath"' business in every script. I'm only concerned with windows (Activestate) perl at this point, but a solution that worked generally would be fine too. Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Win32::OLE and script components with perl 5.10
I've recently upgraded to activeperl 5.10 (looks like it's build 1004)
and I've just noticed that I can no longer instantiate my script
components (which are written in "PerlScript"). Specifically, the perl
interpreter process crashes.
So, wanting to eliminate my WSCs, I went back to basics and took the
canonical example in the docs
(http://docs.activestate.com/activeperl/5.10/Windows/WindowsScriptComponents.html):
description="Easy"
progid="Easy.WSC"
version="1.00"
classid="{74bb1ba9-2e69-4ad6-b02c-c52f3cbe153b}"
(NOTE - there is a error in the docs and the > for the registration open
tag has to be moved to AFTER the properties). Once I do this, register
the component and then try to run the following script:
use strict;
use warnings;
use Win32::OLE;
Win32::OLE->Option(Warn => 3);
my $r = new Win32::OLE('Easy.WSC');
print "hello, world\n";
...I still get a crash. Has anyone else had luck instantiating WSCs with
Win32::OLE in perl 5.10?
Thanks,
Mike Ellery
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Net::XMPP
Just curious if anyone out there has experience getting Net::XMPP to work with perl 5.8.x on windows? I did manage to get it installed (via ppm), but I'm encountering some runtime errors that make me think more packages are required (it seems to be complaining about Authen::SASL::Cyrus at the moment, which I can't find in any repos). Any advice appreciated. -Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: Can I 'yield' to the system?
Barry Brevik wrote: > Re: Active Perl 5.8.8 running on Windows. > > Back when I was doing some Assembly language programming, there was a > system call to "yield" to the Windows operating system, in other words, > give up the rest of your time slice. > > Is there a way to do this with Perl? I'm writing an app that > continuously loops waiting for something to do, and it would be good to > give control back to the OS when idle. There is Win32::GUI::DoEvents(), > but I am unsure if this really does the same thing. > how about sleep ... or usleep (provided by Time::HiRes) ? -Mike ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: WIN32::OLE WMI Out params
I haven't followed your thread closely, but it seems like the relevant
bits from your first link are these:
my $objSecDescriptor = Win32::OLE::Variant-> new (VT_DISPATCH|VT_BYREF);
my $retval =
$objDirectorySecSetting->GetSecurityDescriptor($objSecDescriptor);
..which seems to be filling the $objSecDescriptor with an out param.
If your out param is an array, you might need to add VT_ARRAY to the
variant flags when you create it. Does something like that work for you ?
-Mike
Michael wrote:
> Hi Steven,
>
> Well I tried your suggestion and I think that the Win32::OLE::Variant
> module might be the solution, as I have found some other examples where WMI
> [out] and variants are used.
>
> http://www.infoqu.com/dev/perl-programming/using-perl-with-wmi-to-set-folder-level-permissions-16930-1/
> http://www.perlmonks.org/?node_id=325823
>
> However I'm in way over my head here, so unless someone could cut it out in
> pieces , I don't think that
> I'll get any further.
>
> /Michael
>
>
> On Fri, 4 Dec 2009 02:12:03 -0700, "Steven Manross"
> wrote:
>> Below...
>>
>>> -Original Message-
>>> From: perl-win32-users-boun...@listserv.activestate.com
>>> [mailto:perl-win32-users-boun...@listserv.activestate.com] On
>>> Behalf Of Michael
>>> Sent: Thursday, December 03, 2009 6:45 AM
>>> To: perl-win32-users@listserv.ActiveState.com
>>> Subject: RE: WIN32::OLE WMI Out params
>>>
When troubleshooting OLE issues, it is best to have the
>>> following code
after each OLE command...
If (Win32::OLE-> LastError() != 0) {
print "error calling blah: " . Win32::OLE-> LastError() . "\n";
exit 0;
}
...Or something similar, so you can see what OLE had issues
>>> with (if
anything). It might lead you in a direction that fixes it.
Steven
>>> Added to the script, but no issues reported.
>>>
>>> /Michael
>> Well, then my next guess is the use of the Variant module (because no
>> error is thrown from OLE).
>>
>> Some OLE calls require to be cast of a certain type before they work.
>>
>> use Win32::OLE::Variant;
>>
>> my $nodes = Variant(VT_ARRAY|VT_VARIANT, 0);
>>
>> #I might also try VT_VARIANT or VT_ARRAY|VT_BSTR instead of
>> VT_ARRAY|VT_VARIANT
>>
>> #then
>> my $objChildGroups = $objGetRoot->GetChildNodeGroups($nodes, TRUE);
>>
>> Play around with this... I'm not the greatest Variant script writer
>> here, to know exactly which combination will work (if this is it) based
>> on the object type as I've only run into this a few times before, but
>> you can get examples from your perl install here (depending on your perl
>> build version) of similar options to try and all the VT_* types:
>>
>> C:\Perl\html\lib\Win32\OLE\Variant.html
>>
>> HTH
>>
>> P.S. I googled OV_NodeGroup and found someone else with your same
>> problem on an HP board (or so it seems). :(
>>
>> Steven
>>
>>> ___
>>> Perl-Win32-Users mailing list
>>> Perl-Win32-Users@listserv.ActiveState.com
>>> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>>>
> ___
> Perl-Win32-Users mailing list
> Perl-Win32-Users@listserv.ActiveState.com
> To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: WIN32::OLE WMI Out params
Michael wrote:
> Okay - Just to sum up the whole thing.
>
> The original VBScript <
> Option Explicit
>
> Dim objWMIService, objOV_NodeGroup, objGetRoot, objChildGroups, arrNodes,
> objItem
>
> Set objWMIService = GetObject("winmgmts:root\HewlettPackard\OpenView\data")
>
> Set objOV_NodeGroup = objWMIService.Get("OV_NodeGroup")
> Set objGetRoot = objOV_NodeGroup.GetRoot()
> objChildGroups = objGetRoot.GetChildNodeGroups(arrNodes, True)
>
> WScript.Echo "Child Group Count: " & objChildGroups & vbCrLF
>
> For Each objItem In arrNodes
> WScript.Echo "Name: " & objItem.Name
> Next
> EOF
>
> Returns the following:
>
> Child Group Count: 25
>
> Name: {36716FD8-E600-46FB-90CA-1263E0C62509}
> Name: {38FF8E8E-2DDC-4895-A7EB-0DC7DF50EC25}
> Name: {3E575181-0225-4553-9722-46F841B9FA76}
> Name: {8A412133-F571-42BC-8A66-4B242EB3BAC4}
> Name: {E14D965C-1FBB-40EC-A784-5F9F39F82281}
> Name: OpenView_AIX
> Name: OpenView_External
> Name: OpenView_HPUX
> Name: OpenView_Linux
> Name: OpenView_NNM
> Name: OpenView_OpenVMS
> Name: OpenView_OpenVMS(itanium)
> Name: OpenView_SNMP
> Name: OpenView_Solaris
> Name: OpenView_Tru64
> Name: OpenView_Unknown
> Name: OpenView_Windows2000
> Name: OpenView_WindowsNT
> Name: OpenView_WindowsServer2003
> Name: OpenView_WindowsServer2008
> Name: OpenView_WindowsVista
> Name: OpenView_WindowsXP
> Name: Root_Special
> Name: Root_Unix
> Name: Root_Windows
>
> And the Perl-Script with the modification < #!perl
> use strict;
> use warnings;
> use Win32::OLE qw(in with);
> use Win32::OLE::Variant;
> use Data::Dumper;
>
> my $objWMIService =
> Win32::OLE->GetObject("winmgmts:root/HewlettPackard/OpenView/data") or die
> "WMI connection failed.\n";
> if (Win32::OLE-> LastError() != 0) {
> print "Error calling GetObject: " . Win32::OLE->LastError() . "\n";
> exit 0;
> }
>
> my $objOV_NodeGroup = $objWMIService->Get("OV_NodeGroup");
> if (Win32::OLE-> LastError() != 0) {
> print "Error calling Get: " . Win32::OLE->LastError() . "\n";
> exit 0;
> }
>
> my $objGetRoot = $objOV_NodeGroup->GetRoot();
> if (Win32::OLE-> LastError() != 0) {
> print "Error calling GetRoot: " . Win32::OLE->LastError() . "\n";
> exit 0;
> }
>
> my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT, 0);
> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF);
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR, 0);
> #my $nodes = Win32::OLE::Variant->new(VT_DISPATCH|VT_BYREF);
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR|VT_BYREF, 0);
> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF);
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
>
> my $objChildGroups = $objGetRoot->GetChildNodeGroups($nodes, "True");
> if (Win32::OLE-> LastError() != 0) {
> print "Error calling GetChildNodeGroups: " . Win32::OLE->LastError() .
> "\n";
> exit 0;
> }
> print "Child Group Count: " . $objChildGroups . "\n";
>
> print Dumper($nodes);
>
>
> foreach my $objItem (in $nodes) {
> print 'Name: ' . $objItem->{Name} . "\n";
> }
>
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT, 0); Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27197068)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF); Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27197828)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR, 0); Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27198308)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_DISPATCH|VT_BYREF); Returns
> ##Error calling GetChildNodeGroups: Win32::OLE(0.1709) error 0x80010105:
> "The server threw an exception"
> ##in METHOD/PROPERTYGET "GetChildNodeGroups"
>
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
> Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27199076)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR|VT_BYREF, 0);
> Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27197684)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF); Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27199620)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
> Returns
> ##Child Group Count: 25
> ##$VAR1 = bless( do{\(my $o = 27199524)}, 'Win32::OLE::Variant' );
> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>
> Does any of
Re: WIN32::OLE WMI Out params
Michael wrote:
> On Fri, 04 Dec 2009 17:10:26 -0800, Michael Ellery
> wrote:
>> Michael wrote:
>>> Okay - Just to sum up the whole thing.
>>>
>>> The original VBScript <>>
>>> Option Explicit
>>>
>>> Dim objWMIService, objOV_NodeGroup, objGetRoot, objChildGroups,
> arrNodes,
>>> objItem
>>>
>>> Set objWMIService =
>>> GetObject("winmgmts:root\HewlettPackard\OpenView\data")
>>>
>>> Set objOV_NodeGroup = objWMIService.Get("OV_NodeGroup")
>>> Set objGetRoot = objOV_NodeGroup.GetRoot()
>>> objChildGroups = objGetRoot.GetChildNodeGroups(arrNodes, True)
>>>
>>> WScript.Echo "Child Group Count: " & objChildGroups & vbCrLF
>>>
>>> For Each objItem In arrNodes
>>> WScript.Echo "Name: " & objItem.Name
>>> Next
>>> EOF
>>>
>>> Returns the following:
>>>
>>> Child Group Count: 25
>>>
>>> Name: {36716FD8-E600-46FB-90CA-1263E0C62509}
>>> Name: {38FF8E8E-2DDC-4895-A7EB-0DC7DF50EC25}
>>> Name: {3E575181-0225-4553-9722-46F841B9FA76}
>>> Name: {8A412133-F571-42BC-8A66-4B242EB3BAC4}
>>> Name: {E14D965C-1FBB-40EC-A784-5F9F39F82281}
>>> Name: OpenView_AIX
>>> Name: OpenView_External
>>> Name: OpenView_HPUX
>>> Name: OpenView_Linux
>>> Name: OpenView_NNM
>>> Name: OpenView_OpenVMS
>>> Name: OpenView_OpenVMS(itanium)
>>> Name: OpenView_SNMP
>>> Name: OpenView_Solaris
>>> Name: OpenView_Tru64
>>> Name: OpenView_Unknown
>>> Name: OpenView_Windows2000
>>> Name: OpenView_WindowsNT
>>> Name: OpenView_WindowsServer2003
>>> Name: OpenView_WindowsServer2008
>>> Name: OpenView_WindowsVista
>>> Name: OpenView_WindowsXP
>>> Name: Root_Special
>>> Name: Root_Unix
>>> Name: Root_Windows
>>>
>>> And the Perl-Script with the modification <>> #!perl
>>> use strict;
>>> use warnings;
>>> use Win32::OLE qw(in with);
>>> use Win32::OLE::Variant;
>>> use Data::Dumper;
>>>
>>> my $objWMIService =
>>> Win32::OLE->GetObject("winmgmts:root/HewlettPackard/OpenView/data") or
>>> die
>>> "WMI connection failed.\n";
>>> if (Win32::OLE-> LastError() != 0) {
>>> print "Error calling GetObject: " . Win32::OLE->LastError() . "\n";
>>> exit 0;
>>> }
>>>
>>> my $objOV_NodeGroup = $objWMIService->Get("OV_NodeGroup");
>>> if (Win32::OLE-> LastError() != 0) {
>>> print "Error calling Get: " . Win32::OLE->LastError() . "\n";
>>> exit 0;
>>> }
>>>
>>> my $objGetRoot = $objOV_NodeGroup->GetRoot();
>>> if (Win32::OLE-> LastError() != 0) {
>>> print "Error calling GetRoot: " . Win32::OLE->LastError() . "\n";
>>> exit 0;
>>> }
>>>
>>> my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT, 0);
>>> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF);
>>> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR, 0);
>>> #my $nodes = Win32::OLE::Variant->new(VT_DISPATCH|VT_BYREF);
>>> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
>>> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_BSTR|VT_BYREF, 0);
>>> #my $nodes = Win32::OLE::Variant->new(VT_VARIANT|VT_BYREF);
>>> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT|VT_BYREF, 0);
>>>
>>> my $objChildGroups = $objGetRoot->GetChildNodeGroups($nodes, "True");
>>> if (Win32::OLE-> LastError() != 0) {
>>> print "Error calling GetChildNodeGroups: " . Win32::OLE->LastError() .
>>> "\n";
>>> exit 0;
>>> }
>>> print "Child Group Count: " . $objChildGroups . "\n";
>>>
>>> print Dumper($nodes);
>>>
>>>
>>> foreach my $objItem (in $nodes) {
>>> print 'Name: ' . $objItem->{Name} . "\n";
>>> }
>>>
>>> #my $nodes = Win32::OLE::Variant->new(VT_ARRAY|VT_VARIANT, 0); Returns
>>> ##Child Group Count: 25
>>> ##$VAR1 = bless( do{\(my $o = 27197068)}, 'Win32::OLE::Variant' );
>>> ##Not a HASH reference at GetChildNodeGroups.pl line 46.
>>>
>>> #my $nodes = Win32::OLE::Variant->new(VT
Help with slow startup
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. I'm using Win32::OLE quite extensively to interact with several of our COM objects - and I even have some COM calls in one of by BEGIN blocks. All of this works fine, with the exception of this intermittent startup lag. I have trouble reproducing the problem, so I even have trouble diagnosing it further (using process explorer, etc). Does anyone have any suggestion or advice for what might be going on and how to track it down? I'm wondering if there is some caching of COM objects going on perhaps that could be going on? I'm running on Windows XP 32 bit (perhaps that matters, I don't know). I've tried running with -dprof and here's what it shows for the first and second runs: FIRST RUN: Total Elapsed Time = 37.44117 Seconds User+System Time = 2.947177 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 70.8 2.087 2.079 1730 0.0012 0.0012 Win32::OLE::Dispatch 9.03 0.266 0.421 2 0.1329 0.2103 Win32::OLE::Const::_Typelibs 5.26 0.155 0.155744 0.0002 0.0002 Win32::OLE::Const::_Typelib 3.19 0.094 0.714 39 0.0024 0.0183 STRIDE::Test::BEGIN 1.56 0.046 0.759 4 0.0115 0.1899 main::BEGIN 1.53 0.045 0.041796 0.0001 0.0001 Win32::OLE::DESTROY 1.36 0.040 1.053 1729 0. 0.0006 Win32::OLE::AUTOLOAD 1.09 0.032 0.032 2 0.0160 0.0160 Win32::OLE::new 1.05 0.031 0.031 5 0.0062 0.0062 Devel::Symdump::_symdump 1.05 0.031 0.031 4 0.0077 0.0077 Config::BEGIN 1.05 0.031 0.045 8 0.0039 0.0057 Pod::POM::BEGIN 0.54 0.016 0.016 1 0.0160 0.0160 Win32::OLE::Uninitialize 0.54 0.016 0.016 1 0.0160 0.0160 Devel::Symdump::_partdump 0.54 0.016 0.016 5 0.0032 0.0032 File::Basename::BEGIN 0.54 0.016 0.016 6 0.0027 0.0027 Text::Wrap::BEGIN SECOND RUN: Total Elapsed Time = 10.91888 Seconds User+System Time = 2.918880 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 75.3 2.200 2.238 1730 0.0013 0.0013 Win32::OLE::Dispatch 10.1 0.295 0.419 2 0.1474 0.2094 Win32::OLE::Const::_Typelibs 4.25 0.124 0.124744 0.0002 0.0002 Win32::OLE::Const::_Typelib 2.19 0.064 0.590 39 0.0016 0.0151 STRIDE::Test::BEGIN 1.61 0.047 0.047 5 0.0094 0.0094 Devel::Symdump::_symdump 1.30 0.038 0.035 2536 0. 0. Win32::OLE::Tie::FETCH 0.55 0.016 0.016 1 0.0160 0.0159 ActivePerl::Config::override 0.55 0.016 0.016 3 0.0053 0.0053 DynaLoader::BEGIN 0.55 0.016 0.016 5 0.0032 0.0032 Pod::POM::View::HTML::BEGIN 0.55 0.016 0.016 7 0.0023 0.0023 IO::Handle::BEGIN 0.55 0.016 0.636 4 0.0040 0.1589 main::BEGIN 0.55 0.016 0.015 8 0.0020 0.0019 Pod::POM::BEGIN 0.55 0.016 0.027 30 0.0005 0.0009 STRIDE::Test::AddAnnotation 0.55 0.016 0.016 42 0.0004 0.0004 Pod::POM::Node::new 0.51 0.015 0.015414 0. 0. Pod::POM::Node::AUTOLOAD So, clearly it's showing the discrepancy in total time, but nothing stands out as far as the code that is profiled by dprof. Any advice about other things I should try? Thanks, Mike Ellery ___ 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 1/18/2010 4:52 PM, Jan Dubois wrote: > 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=svn465&r=465&format=side&path=/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 > > Jan, 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? Thanks, Mike C:\s2>dprofpp tmon_FIRST.out Total Elapsed Time = 20.19217 Seconds User+System Time = 2.898179 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 75.2 2.181 2.173 1730 0.0013 0.0013 Win32::OLE::Dispatch 8.11 0.235 0.326 2 0.1174 0.1628 Win32::OLE::Const::_Typelibs 3.14 0.091 0.091744 0.0001 0.0001 Win32::OLE::Const::_Typelib 2.69 0.078 0.450 23 0.0034 0.0196 STRIDE::BEGIN 1.55 0.045 0.041796 0.0001 0.0001 Win32::OLE::DESTROY 1.38 0.040 1.133 1729 0. 0.0007 Win32::OLE::AUTOLOAD 1.10 0.032 0.032 2 0.0160 0.0160 Win32::OLE::new 1.07 0.031 0.031 5 0.0062 0.0062 Devel::Symdump::_symdump 1.07 0.031 0.541 39 0.0008 0.0139 STRIDE::Test::BEGIN 0.55 0.016 0.016 1 0.0160 0.0160 Win32::OLE::bootstrap 0.55 0.016 0.031 2 0.0080 0.0153 Pod::POM::parse_file 0.55 0.016 0.016 8 0.0020 0.0020 DynaLoader::dl_load_file 0.55 0.016 0.016 4 0.0040 0.0040 Config::BEGIN 0.55 0.016 0.016 15 0.0011 0.0011 STRIDE::Test::MethodInfo::new 0.55 0.016 0.016 5 0.0032 0.0032 Pod::POM::View::HTML::BEGIN C:\s2>dprofpp tmon_SECOND.out Total Elapsed Time = 10.09317 Seconds User+System Time = 2.742174 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 74.9 2.056 2.064 1730 0.0012 0.0012 Win32::OLE::Dispatch 9.63 0.264 0.342 2 0.1319 0.1708 Win32::OLE::Const::_Typelibs 2.84 0.078 0.078744 0.0001 0.0001 Win32::OLE::Const::_Typelib 1.71 0.047 0.047 5 0.0094 0.0094 Devel::Symdump::_symdump 1.68 0.046 0.419 23 0.0020 0.0182 STRIDE::BEGIN 1.42 0.039 1.039 1729 0. 0.0006 Win32::OLE::AUTOLOAD 1.17 0.032 0.527 39 0.0008 0.0135 STRIDE::Test::BEGIN 1.13 0.031 0.031269 0.0001 0.0001 Win32::OLE::Tie::Store 0.58 0.016 0.016 2 0.0080 0.0080 Win32::OLE::new 0.58 0.016 0.016 1 0.0160 0.0159 ActivePerl::Config::override 0.58 0.016 0.031 5 0.0032 0.0061 Storable::BEGIN 0.58 0.016 0.032 5 0.0032 0.0064 Win32::OLE::BEGIN 0.58 0.016 0.557 4 0.0040 0.1394 main::BEGIN 0.58 0.016 0.016 14 0.0011 0.0011 STRIDE::Function::_perlFromPayload 0.58 0.016 0.016 20 0.0008 0.0008 STRIDE::TestPoint::BEGIN C:\s2>dprofpp tmon_THIRD.out Total Elapsed Time = 10.09317 Seconds User+System Time = 2.775174 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 77.0 2.137 2.129 1730 0.0012 0.0012 Win32::OLE::Dispatch 8.94 0.248 0.326 2 0.1239 0.1628 Win32::OLE::Const::_Typelibs 2.81 0.078 0.078744 0.0001 0.0001 Win32::OLE::Const::_Typelib 1.73 0.048 0.403 23 0.0021 0.0175 STRIDE::BEGIN 1.69 0.047 0.047 5 0.0094 0.0094 Devel::Symdump::_symdump 1.69 0.047 0.511 39 0.0012 0.0131 STRIDE::Test::BEGIN 1.12 0.031 0.031 2 0.0155 0.0155 Win32::OLE::new 1.01 0.028 0.963 3 0.0094 0.3209 STRIDE::TestPoint::Wait 0.58 0.016 0.016 3 0.0053 0.0053 B::BEGIN 0.58 0.016 0.016 5 0.0032 0.0032 base::BEGIN 0.58 0.016 0.016 4 0.0040 0.0040 Pod::POM::Nodes::BEGIN 0.58
Re: Help with slow startup
On 1/19/2010 4:17 PM, Jan Dubois wrote:
> 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
>
>
Jan,
thanks again for these mysterious patches. Yes, this had a positive
effect - now with this patch plus the previous patch in place, my first
vs. subsequent run times are 15s vs 10s. This is a considerable
improvement over the 30s vs 10s that I was previously seeing.
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?
As for typelibrary location - all of my com objects and typelibs should
be local (I build debug locally). The only thing I'm aware of that
*could* be pulled from the network are the debug symbols from microsoft,
which we store on a network share since they are rather large. This slow
startup time is observed with release builds of our objects too (I have
not yet tried your patches with a release build..), and those should
have no network dependencies. Our com objects are all compiled code and
the typelib info is built-in, so we don't ship separate typelib files (I
don't know if that makes any difference here...)
Thanks again for your help.
-Mike
___
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Syntax::Highlight::Perl PPM problem in 5.10 repo ?
I need to generate some HTML for some perl code, so I thought I would try Syntax::Highlight::Perl. I used ppm to install it, but I was not able to use the module (not found). Upon further investigation, I found that only a Syntax::Highlight::Perl6 package was installed. When I do a search, here is what I see: C:\Documents and Settings\mikee>ppm search syntax-highlight-perl 1: Syntax-Highlight-Perl Perl 6 Syntax Highlighter Version: 0.64 Released: 2009-06-25 Repo: ActiveState Package Repository 2: Syntax-Highlight-Perl-Improved Highlighting of Perl Syntactical Structures Version: 1.01 Released: 2004-05-04 Repo: ActiveState Package Repository 3: Syntax-Highlight-Perl6 Perl 6 Syntax Highlighter Version: 0.80 Released: 2010-03-25 Repo: ActiveState Package Repository ..it's that first entry that seems to be causing me problems. Does anyone have advice about how to resolve this? Should I just install directly from CPAN? Thanks, Mike Ellery ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
