perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

[perl-win32-gui-hackers] Distributing manifests [Was: Application that in installed in perl bin directory to start up samples]

[Robert M. <rm...@po...>]

Jeremy White wrote:
> One thing I did notice - and this is a minor issue and not really 
> related to your script - is how XP styles are handled. To get XP styles 
> turned on by default, a manifest file has to be in the same directory as 
> the running exe (i.e., perl or wperl) - if the manifest is missing, then 
> you get the "old" window look - as I had the manifest for perl, but not 
> for wperl I was getting an inconsistent look when toggling the console 
> window option. I'm wondering if these manifest files should be installed 
> automatically as part of the installation process?

I don't have access to XP, so have not looked into manifests.  I can see 
that distributing them (or otherwise making them available) would be a 
good thing, but I'm not so sure about installing them in the perl bin 
directory - is there any down side to doing that?

How about a Wiki page explaining what is needed as a starting point?

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

RE: [perl-win32-gui-hackers] Application that in installed in perl bin directory to start up samples

[Jeremy W. <jez...@ho...>]

>Is this a good thing to pursue?  Suggestions for changes or alternative 
>approaches welcome.  A better name for the script would be good too!

Nice - with a good set of examples it would certainly show what Win32-GUI is 
capable off.

One thing I did notice - and this is a minor issue and not really related to 
your script - is how XP styles are handled. To get XP styles turned on by 
default, a manifest file has to be in the same directory as the running exe 
(i.e., perl or wperl) - if the manifest is missing, then you get the "old" 
window look - as I had the manifest for perl, but not for wperl I was 
getting an inconsistent look when toggling the console window option. I'm 
wondering if these manifest files should be installed automatically as part 
of the installation process?

Regards,

jez.

RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

[Jeremy W. <jez...@ho...>]

>I'd appreciate it if people can build and what's in CVS and run their 
>current scripts against these changes to see what (if any) change in 
>behaviour you get.  I hope none (except perhaps for a few warnings), but I 
>need help to ensure I've covered all the ways people were accessing the 
>constants previously.  Additionally I'd like some confidence that I haven't 
>accidentally broken anything elsewhere - everything seems OK here, and all 
>the tests still pass (they didn't with my first attempt, showing the value 
>of having such tests).

Bareword "Win32::GUI::MB_OK" not allowed while "strict subs" in use at 
C:/perl/s
ite/lib/Client/WindowManager.pm line 120.
Bareword "Win32::GUI::MB_ICONINFORMATION" not allowed while "strict subs" in 
use
at C:/perl/site/lib/Client/WindowManager.pm line 120.

:)

In the WindowManager package I've got the following code:

  Win32::GUI::MessageBox($mainwindow,$text,"Message", Win32::GUI::MB_OK | 
Win32::GUI::MB_ICONINFORMATION);

Turns out I'm doing this all over the place - for example in another 
package:

$grahicwin = new Win32::GUI::Window (
   -parent      => $w,
   -name        => 'Time',
   -pos         => [8,160],
                -size        => [562,105],
   -popstyle    => Win32::GUI::WS_CAPTION | Win32::GUI::WS_SIZEBOX,
   -pushstyle   => Win32::GUI::WS_CHILD | Win32::GUI::WS_CLIPCHILDREN,
   -pushexstyle => Win32::GUI::WS_EX_CLIENTEDGE,

The reason I did this was to stop the namespace pollution of doing a use 
Win32::GUI in each package:)

Hopefully I'll have time later today to change my logic.

Cheers,

jez.

Re: [win32-gui] Re: [perl-win32-gui-hackers] an introduction

[Robert M. <rm...@po...>]

darrik wrote:
> And thank you, Robert, for adding me to the project.  I set up ssh and
> whatnot, so I'm in and ready to go.

great.

> It was my intent to work on low-priority bugs and feature requests, for
> familiarity and whatnot, but also to avoid anyone having to take the
> time to give me direction.

I'm happy either way, and certainly don't feel the need to give 
direction at this point.  I'd much rather you did what you were 
comfortable with.  My feeling was that there's not much suitable for 
'getting started' in the bugs and feature request lists - I think I 
picked off most of the easy ones when I was finding my way around!

> However, if there are specific things you
> have in mind you would like me to look at, I would be more than glad for
> the direction and will dig into it immediately (or what passes for such
> in my life).

I've not got much on my own list that I want for the V1.04 release, but 
a whole load for beyond that.  Without us going round in circles, if you 
want some ideas for things not in the bugs/rfe lists give me a shout.

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [win32-gui] Re: [perl-win32-gui-hackers] Notes on deprecated features

[Robert M. <rm...@po...>]

Glenn Linderman wrote:
> On approximately 5/16/2006 12:31 PM, came the following characters from 
> the keyboard of Robert May:
>> As you all know I feel that backwards compatibility is important, and 
>> have been striving not break existing scripts when making changes. 
>> However, going forwards some things will have to change, and I thought 
>> it would be worthwhile for me to outline my strategy for deprecating 
>> and then removing/changing functionality.  I would appreciate comments 
>> on the following:
>>
>> (1) When making a change backwards compatibility will be maintained 
>> wherever possible.  When a change in behaviour is desirable (for 
>> example 'use Win32::GUI;' not exporting 360+ Constants) then a release 
>> (in this case 1.04) will issue a 'deprecated' warning stating that 
>> behaviour will change in the future, and explaining what changes 
>> should be made.
> 
> Care should be taken that the message (or the documentation for the 
> message) points the user to how to eliminate the warning, how to fix the 
> behaviour warned about, so that it works warning-free with the current 
> code, and will not encounter known future warnings or errors when the 
> feature is removed.
> 
> I think this is basically what you are saying.

That was what I intended.

>> (2) A subsequent release (depending on the gaps in the release cycle 
>> and the severity of the change this might be the following release - 
>> in this example 1.05) may change behaviour, but will issue a warning 
>> that the behaviour has changed (may die instead depending on the change).
> 
> If old syntax can be retired, that paves the way for being able to die 
> or perpetuate an error message.  It may not always be the case that the 
> old syntax should be retired. "use Win32::GUI;" seems like syntax that 
> should be made to work without warning even once the constants are removed.
> 
> If it is possible to issue the warning, or remind about the removed 
> feature, at the time of attempted use of the removed feature (constants) 
> that would be nice, but I haven't spent time to figure out if that is 
> possible in this case.

I'll give an example of what I expect for the constants stuff.  I 
certainly don't intend to remove 'use Win32::GUI;', but it's behaviour 
will change, and it won't export any constants.

Currently
   use Win32::GUI;
exports over 300 arbitrary constants into the callers name space.  IMHO 
this construct should either export all constants, or none.  Now that 
all constants is more than 6500, I can't see how this should be all.

My plan:

Win32::GUI v1.04 will issue the following warning for 'use Win32::GUI;', 
whilst still exporting the same 300+ constants:
"'use Win32::GUI;' is currently exporting constants into the callers 
scope. This functionality is deprecated. Use 'use Win32::GUI();' or list 
your required exports explicitly instead. Used at FILENAME line LINENUMBER."

Win32::GUI v1.05 will stop exporting the 300+ constants, and will warn 
that that is what it has done.  Something like:
"'use Win32::GUI;' behaviour has changed since v1.04: better written as 
'use Win32::GUI();'.  Used at FILENAME line LINENUMBER."

Win32::GUI v1.06 will stop issuing the warning, whilst maintaining the 
v1.05 behaviour.


Compare this with use of Win32::GUI::constant("ES_WANTRETURN");

In 1.04, a warning issued, but old functionality remains:
"Use of Win32::GUI::constant() is deprecated. Use 
Win32::GUI::Constants::constant() instead.  Used at FILENAME line 
LINENUMBER."

In 1.05, it will die with a message:
"Use of Win32::GUI::constant() has been removed. Use 
Win32::GUI::Constants::constant() instead.  Used at FILENAME line 
LINENUMBER."

In 1.06 the function will not exist.


And finally with the if($a = Win32::GUI::ESWANTRETURN) usage:

In 1.04, a warning:
Use of 'Win32::GUI::ES_WANTRETURN' is deprecated. Use 
'Win32::GUI::Constants::ES_WANTRETURN' instead.  Used at FILENMAE line 
LINENUMBER."

In 1.05, death:
Use of 'Win32::GUI::ES_WANTRETURN' has been removed. Use 
'Win32::GUI::Constants::ES_WANTRETURN' instead.  Used at FILENMAE line 
LINENUMBER."

In 1.06 you'll probably get a warning from perl about an undefined 
subroutine.


Of course, spotting any of this in the 1.04 release depends on the use 
script running with warnings on - without that the first thing you'll 
notice is your script failing/dying under 1.05 ....

Does this work?

Rob.

[perl-win32-gui-hackers] Application that in installed in perl bin directory to start up samples

[Robert M. <rm...@po...>]

All,

On the plane last week I was struggling with something that I have been 
mulling over for a while - I want the samples/demos that we distribute 
to be more accessible.

Tk has as whole demo framework that can run demos from a app that is 
installed as a script in the perl bin directory - and hence is more 
often than not on the users path (try typing 'widget' at your command 
prompt)

I've knocked up a demo application that I think would be suitable 
(attached) - basically it finds the demos directory (based on the path 
of GUI.pm), reads in the demo files, displaying them in a tree-view, 
with a right hand panel that displays the source of the selected file, 
and a button to run the sample.

If you've got a build directory for the latest code, drop the attached 
file into the root directory and run:
   perl -Mblib win32-gui-demos.pl
to see what it does with the most recent current sample set (including 
the fixes I just committed).  If you don't have a most recent CVS build, 
then just run it, and see if you have any of the samples installed - but 
note that some of them are broken.

Is this a good thing to pursue?  Suggestions for changes or alternative 
approaches welcome.  A better name for the script would be good too!

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] Notes on deprecated features

[Robert M. <rm...@po...>]

As you all know I feel that backwards compatibility is important, and 
have been striving not break existing scripts when making changes. 
However, going forwards some things will have to change, and I thought 
it would be worthwhile for me to outline my strategy for deprecating and 
then removing/changing functionality.  I would appreciate comments on 
the following:

(1) When making a change backwards compatibility will be maintained 
wherever possible.  When a change in behaviour is desirable (for example 
'use Win32::GUI;' not exporting 360+ Constants) then a release (in this 
case 1.04) will issue a 'deprecated' warning stating that behaviour will 
change in the future, and explaining what changes should be made.

(2) A subsequent release (depending on the gaps in the release cycle and 
the severity of the change this might be the following release - in this 
example 1.05) may change behaviour, but will issue a warning that the 
behaviour has changed (may die instead depending on the change).

(3) A later release may remove the warnings.

(4) Release notes will have a section on deprecated/changed/removed 
behaviour.

I think an approach like this is pragmatic (in most cases), giving users 
at least 2 release cycles to fix their code, whilst not imposing too 
high a burden on us maintainers to maintain backwards compatibility for 
ever.

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

[Robert M. <rm...@po...>]

I just committed changes to GUI.pm, GUI.xs (and removed 
GUI_Constants.cpp) to introduce the 'delegation' of constant support in 
Win32::GUI to Win32::GUI::Constants.  Other files change - see the 
CHANGELOG for details

I'd appreciate it if people can build and what's in CVS and run their 
current scripts against these changes to see what (if any) change in 
behaviour you get.  I hope none (except perhaps for a few warnings), but 
I need help to ensure I've covered all the ways people were accessing 
the constants previously.  Additionally I'd like some confidence that I 
haven't accidentally broken anything elsewhere - everything seems OK 
here, and all the tests still pass (they didn't with my first attempt, 
showing the value of having such tests).

You will find that you probably get warnings for the old usage.  Before 
we release this on the unsuspecting masses:
(1) Are the warnings too noisy?  I.e. do you end up with thousands of 
the same warning?
(2) Are the warnings suitably worded?  I.e. is it clear what changes you 
should be making?
(3) Does including "no warnings 'deprecated';" in your script silence 
the warnings?

As a side affect of this I had to visit the samples folder, and update 
some of the demos to 'use Win32::GUI()'.  In this process I've made each 
demo script run under strict and warnings; fixed some bug:
- added a bitmap so the SplashScreen demo works
- using FindBin module so that demos that load files can find them even 
if the the working directory is elsewhere (more on why I want this later)
- fixed huge resource leaks in Draw.pl and Region.pl;  Added some code 
to Region.pl to clear the background, it is now a little more obvious 
what it is doing.
- added some missing constants to Win32::GUI::Constants

Here's hoping it all hangs together for you.
Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] an introduction

[darrik <da...@my...>]

Thank you, Robert, Glenn and Jeremy, for making me feel quite welcome.

And thank you, Robert, for adding me to the project.  I set up ssh and
whatnot, so I'm in and ready to go.

It was my intent to work on low-priority bugs and feature requests, for
familiarity and whatnot, but also to avoid anyone having to take the
time to give me direction.  However, if there are specific things you
have in mind you would like me to look at, I would be more than glad for
the direction and will dig into it immediately (or what passes for such
in my life).

Let me know at your convenience.

And again, thanks much for the welcome (as I was a tad nervous). ;)

Darrik

Robert May wrote:
> Hi Darrik,
> 
> Firstly let me apologise for the length of time it's taken me to get
> back to you, although I see that some of the regulars have already
> welcomed you into the fold.  Also let me thank you for offering some of
> your time, and I hope that we can make your time spent here worthwhile.
> 
> I think I've added you to the project as a developer with CVS access -
> but the sourceforge user interface has its quirks (you'll come to love
> it), so please let me know if you have any problems.  You should also
> have the correct permissions to administrate tracker items.  You'll find
> documentation on SourceForge to help you get set up, and please call on
> us here if you need any assistance.
> 
> I think your plan of picking some "low-priority" items to start to find
> your way around is a good plan - but please note that the 'priority'
> assigned in the trackers is fairly arbitrary:  most have the default
> '5'; a couple of items that I though were important to deal with have
> higher priority, and a few lower.  Those with priority '1' have been
> dealt with, and will be closed when we make the next release.  If you
> can't find anything that you think is suitable for starting with in the
> trackers, then let me know, and I have a whole list of other items from
> which I would be happy to select a handful for you to have a look at.
> 
> Good luck, and welcome on board.
> 
> Regards,
> Rob.

Re: [perl-win32-gui-hackers] CVS Commit - Win32::GUI::Constants added

[Jeremy W. <jez...@ho...>]

>In the mean time, can anybody suggest why it might be a bad idea to remove 
>'Win32::GUI' from the @ISA of Win32::GUI::Class Win32::GUI::MenuButton or 
>Win32::GUI::MenuItem?

Not that I can think off.

Cheers,

jez.

Re: [perl-win32-gui-hackers] CVS Commit - Win32::GUI::Constants added

[Robert M. <rm...@po...>]

Jeremy White wrote:
> Ok - builds fine under my environment, with all tests passing.

Thanks for the feedback.

I was feeling brave this-afternoon and I've made the changes to GUI.pm 
and elsewhere to remove the existing constants support and integrate 
Win32::GUI::Constants.  I think I resolved the issues that I introduced, 
but the current implementation has an (unnecessarily?) complex 
inter-twining of class hierarchies and AUTOLOADing, and I had to make a 
couple of changes in areas that I wasn't expecting to.

I'll keep running the new code for a couple of days here, then check it 
in for everyone to have a play with, and find out if

(1) I've seriously broken any existing scripts.
(2) If the deprecated warnings that I've added are too noisy.
(3) the new functionality works

In the mean time, can anybody suggest why it might be a bad idea to 
remove 'Win32::GUI' from the @ISA of Win32::GUI::Class 
Win32::GUI::MenuButton or Win32::GUI::MenuItem?

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] an introduction

[Robert M. <rm...@po...>]

Hi Darrik,

Firstly let me apologise for the length of time it's taken me to get 
back to you, although I see that some of the regulars have already 
welcomed you into the fold.  Also let me thank you for offering some of 
your time, and I hope that we can make your time spent here worthwhile.

I think I've added you to the project as a developer with CVS access - 
but the sourceforge user interface has its quirks (you'll come to love 
it), so please let me know if you have any problems.  You should also 
have the correct permissions to administrate tracker items.  You'll find 
documentation on SourceForge to help you get set up, and please call on 
us here if you need any assistance.

I think your plan of picking some "low-priority" items to start to find 
your way around is a good plan - but please note that the 'priority' 
assigned in the trackers is fairly arbitrary:  most have the default 
'5'; a couple of items that I though were important to deal with have 
higher priority, and a few lower.  Those with priority '1' have been 
dealt with, and will be closed when we make the next release.  If you 
can't find anything that you think is suitable for starting with in the 
trackers, then let me know, and I have a whole list of other items from 
which I would be happy to select a handful for you to have a look at.

Good luck, and welcome on board.

Regards,
Rob.

darrik wrote:
> Greetings.  My name is Darrik Mazey.  I've been a (mostly reading,
> sometimes posting) member of the win32-gui-users list since early 2003.
>  I've been using Win32::GUI for quite some time and thought I'd try and
> contribute a little of my spare time back into the project.  The project
> has made leaps and bounds since the 0.665 version, and it's my hope that
> I can be of some use.  In that spirit I have recently joined the hackers
> list as well.
> 
> I exported the cvs source and began to familiarize myself with it.  Once
> I feel comfortable with that, I will try and work on either some low
> priority bugs or feature requests that no one has taken up yet.  If
> anyone has any suggestions, tips, unstated best practices, advice, or
> whatever, I'd welcome and greatly appreciate it.
> 
> In a brief About Me, I just want to state that I've been programming for
> many years (C, C++, but my love is for Perl), but I have never
> contributed to a sourceforge project before.  Hopefully my inexperience
> in this respect will be forgiven, and I will do my absolute best to
> observe the standards and practices to which you are accustomed, and
> also welcome any pointers, critiques, and helpful criticism you can send
> my way.
> 
> Regards,
> 
> Darrik
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> http://perl-win32-gui.sourceforge.net/
> 

RE: [perl-win32-gui-hackers] CVS Commit - Win32::GUI::Constants added

[Jeremy W. <jez...@ho...>]

>I just added my code for the Win32::GUI::Constants module that we have 
>discussed here recently.  The build process is internally a bit convoluted, 
>but should happen smoothly from the outside!

>As always comments on success and/or failures in your build environment are 
>encouraged.

No cup final for you eh?:)

Ok - builds fine under my environment, with all tests passing.

Cheers,

jez.

[perl-win32-gui-hackers] CVS Commit - Win32::GUI::Constants added

[Robert M. <rm...@po...>]

I just added my code for the Win32::GUI::Constants module that we have 
discussed here recently.  The build process is internally a bit 
convoluted, but should happen smoothly from the outside!

I've not built under perl 5.6 or cygwin yet, but I don't envisage any 
problems there.

Still to do:
- Integrate the module with GUI.pm, so that we can seamlessly use the 
same options from the 'use Win32::GUI' statement.
- Re-implement Win32::GUI::constant() to delegate (with a deprecated 
warning) to Win32::GUI::Constants::Constant()
- Remove the existing constant implementation: remove code from GUI.pm 
and remove GUI_constants.cpp;  update Makefile.PL as necessary

I hope I'll have these changes before long - I've got a few other things 
to look at first.

As always comments on success and/or failures in your build environment 
are encouraged.

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] Changes to SourceForge CVS platform

[Robert M. <rm...@po...>]

Dear hackers,

Please the announcement from the SourceForge Team, copied verbatim below.

Main points:

(1) Web access to CVS is now:
http://perl-win32-gui.cvs.sourceforge.net/perl-win32-gui/Win32-GUI/

(2) Anyone who has checked out source will need to do create a new 
working copy using perl-win32-gui.cvs.sourceforge.net as the host rather 
than the old cvs.sourceforge.net

If you have any problems, then reply to this mail on this list, and 
we'll try to sort them out together.

Regards,
Rob.


--- Begin Included Message ---

Greetings,

You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.

The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.

The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.

Summary of changes, effective 2006-05-12:

1. Hostname for CVS service

Old: cvs.sourceforge.net
New: PROJECT_UNIX_NAME.cvs.sourceforge.net

This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.

cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim

would be changed to

cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim


2. ViewCVS

We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.


3. Sync delay

Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.

New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.

Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.


4. Read-only rsync service

As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.

All projects should be making regular backups of their CVS repository
contents using this service.


5. Nightly tarball service

Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.

We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.


6. Points of failure

In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.

Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).

Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.

This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires.



Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04


Thank you,

The SourceForge.net Team

--- End Included Message ---

-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] Part 2 & 3 of COM in C

[Jeremy W. <jez...@ho...>]

http://www.codeproject.com/useritems/com_in_c2.asp
http://www.codeproject.com/useritems/com_in_c3.asp

Quality.

Cheers,

jez.

RE: [perl-win32-gui-hackers] an introduction

[Jeremy W. <jez...@ho...>]

Hi,

>I exported the cvs source and began to familiarize myself with it.  Once
>I feel comfortable with that, I will try and work on either some low
>priority bugs or feature requests that no one has taken up yet.  If
>anyone has any suggestions, tips, unstated best practices, advice, or
>whatever, I'd welcome and greatly appreciate it.

If you haven't already done so, create a sourceforge ID, and drop an email 
to Rob May who will give you permissions to check in code.

As for advice...For me the biggest learning curve was perl XS - the perl 
documentation isn't ideal (for a starting point see perlxs and perlapi) - 
the best resource I've found is the book Extending and Embedding Perl by Tim 
Jenness and Simon Conzens. Most of the XS code for win32-GUI is 
straightforward.

Choosing a low priority bug or feature requests is a good way to start - if 
it's just about learning, just play and ask questions:) If you think you'll 
be checking it in at some point, ask the list first as someone else might be 
working on the same thing. Rob is working on some big chunks of 
functionality, and some coordination might be required.

All the best, and welcome to the team.

Regards,

jez.

[perl-win32-gui-hackers] an introduction

[darrik <da...@my...>]

Greetings.  My name is Darrik Mazey.  I've been a (mostly reading,
sometimes posting) member of the win32-gui-users list since early 2003.
 I've been using Win32::GUI for quite some time and thought I'd try and
contribute a little of my spare time back into the project.  The project
has made leaps and bounds since the 0.665 version, and it's my hope that
I can be of some use.  In that spirit I have recently joined the hackers
list as well.

I exported the cvs source and began to familiarize myself with it.  Once
I feel comfortable with that, I will try and work on either some low
priority bugs or feature requests that no one has taken up yet.  If
anyone has any suggestions, tips, unstated best practices, advice, or
whatever, I'd welcome and greatly appreciate it.

In a brief About Me, I just want to state that I've been programming for
many years (C, C++, but my love is for Perl), but I have never
contributed to a sourceforge project before.  Hopefully my inexperience
in this respect will be forgiven, and I will do my absolute best to
observe the standards and practices to which you are accustomed, and
also welcome any pointers, critiques, and helpful criticism you can send
my way.

Regards,

Darrik

Re: [win32-gui] Re: [perl-win32-gui-hackers] Win32::GUI::Constants revisited - proposed changes and performance figures

[Robert M. <rm...@po...>]

Reini Urban wrote:
> 2006/5/1, Robert May <rm...@po...>:

[stuff about different hashing options]

> Good to see that finally gperf found its successors: Perfect and MPH.
> gperf is completely insatisfactory not finding a solution, esp. when
> you know that it comes from a common lisp programmer.

I didn't have problems with gperf not finding solutions, but to be fast 
it needed to generate HUGE, sparse lookup tables (about 33,000 entries 
for my 1588 constants).  In order to make the lookup table smaller, I 
had to go for options that cause it to use binary searches or large 
switch statements, which make its output slower.

> http://burtleburtle.net/bob/hash/perfect.html looks fine. Go for it.

I've got a bit of work to do to the original code to get it to fit into 
a sensible build process, but I'm most of the way there.  I intend to 
keep the generated code cleanly separated from the rest of the module, 
making it easy to swap algorithms later if we find other solutions or 
the existing ones are improved.

> But don't forget to support EXPORT tag groups and wildcards.
> use Win32::GUI::Constants qw(!/^T/); #don't export T* constants

Already there - I'll be supporting the full Exporter.pm syntax (but I'm 
not actually using Exporter, as it has some pretty large memory 
overheads itself).

Regards,
Rob.

Re: [perl-win32-gui-hackers] Win32::GUI::Constants revisited - proposed changes and performance figures

[Reini U. <ru...@x-...>]

2006/5/1, Robert May <rm...@po...>:
> I have looked into 3 alternative hashing strategies, all implemented in
> XS (as an aside, the overhead of calling an XS function that does
> nothing compares very favourably with a perl hash lookup, and so
> previous concerns that I had about XS calls being slow seem unfounded):
>
> Strategy 1:  non-order preserving minimal perfect hash, based on the
> algorithm and C source from
> http://burtleburtle.net/bob/hash/perfect.html  I will call this the
> 'Perfect' algorithm
>
> Strategy 2:  non-order preserving (non-minimal) perfect hash, generated
> using gperf: http://gnuwin32.sourceforge.net/packages/gperf.htm  I will
> call this the 'Gperf' algorithm.
>
> Strategy 3: Order-preserving minimal perfect hash. based on the code
> from: http://www.ibiblio.org/pub/Linux/devel/lang/c/mph-1.2.tar.gz  I
> will call this the 'MPH' algorithm
>
> The original ladder-of-if's found in GUI_constants.cpp will be called
> the 'Win32::GUI' algorithm
>
> The current hash implementation discussed here for Win32::GUI::Constants
> will be called the 'Hash' algorithm.

Good to see that finally gperf found its successors: Perfect and MPH.
gperf is completely insatisfactory not finding a solution, esp. when
you know that
it comes from a common lisp programmer.

http://burtleburtle.net/bob/hash/perfect.html looks fine. Go for it.

But don't forget to support EXPORT tag groups and wildcards.
use Win32::GUI::Constants qw(!/^T/); #don't export T* constants
--
Reini

[perl-win32-gui-hackers] Win32::GUI::Constants revisited - proposed changes and performance figures

[Robert M. <rm...@po...>]

I've been re-visiting the code I wrote some months ago, and discussed 
here, to provide us with a faster and more readily extensible way of 
having access to all the Win32 API constants that we might need.

This is long.  Sorry.

The main purpose of this mail is to document the research and test 
results that I have from the last week, but first I'd like to write down 
what I intend to change in Win32::GUI itself:

Proposal for change in Win32::GUI
=================================

- Win32::GUI::Constants will become the module that supports constants. 
  It will be possible for end-users to use this module directly, or to 
pass the same export requests to Win32::GUI directly (as we previously 
discussed).  So either

   use Win32::GUI qw(export_list);

or

   use Win32::GUI::Constants qw(export_list);

will have the same behaviour with respect to exporting constants.

- I will deprecate the way Win32::GUI currently exports over 300 
constants without being explicitly asked. In the 1.04 release
   use Win32::GUI;
will still export the same constants, but will generated a 'deprecated' 
warning, including instructions about the correct syntax to use.

- I will deprecate calling the Win32::GUI::constant() function directly. 
  Again, it will continue to work in the 1.04 release and generate a 
'deprecated' warning.

- There will need to be a small XS based constant lookup function within 
Win32::GUI to support the small number of places that Win32::GUI itself 
currently uses Win32::GUI::constant() - only to lookup the Win32__GUI__ 
constants, which don't belong in the new Win32::GUI::Constants package 
anyway.

Changes to Win32::GUI::Constants
================================

The last time we talked about this I had implemented 
Win32::GUI::Constants in pure perl, basing the lookup on a perl hash.  I 
had reservations about the memory usage and speed of this 
implementation, and have done some further research to look at the 
reality.  It turns out that the perl hash is *very* fast, but uses a lot 
of memory.

I have looked into 3 alternative hashing strategies, all implemented in 
XS (as an aside, the overhead of calling an XS function that does 
nothing compares very favourably with a perl hash lookup, and so 
previous concerns that I had about XS calls being slow seem unfounded):

Strategy 1:  non-order preserving minimal perfect hash, based on the 
algorithm and C source from 
http://burtleburtle.net/bob/hash/perfect.html  I will call this the 
'Perfect' algorithm

Strategy 2:  non-order preserving (non-minimal) perfect hash, generated 
using gperf: http://gnuwin32.sourceforge.net/packages/gperf.htm  I will 
call this the 'Gperf' algorithm.

Strategy 3: Order-preserving minimal perfect hash. based on the code 
from: http://www.ibiblio.org/pub/Linux/devel/lang/c/mph-1.2.tar.gz  I 
will call this the 'MPH' algorithm

The original ladder-of-if's found in GUI_constants.cpp will be called 
the 'Win32::GUI' algorithm

The current hash implementation discussed here for Win32::GUI::Constants 
will be called the 'Hash' algorithm.

There are a number of results to share.  It has been difficult to ensure 
that I am really comparing like-with-like;  where there appears to be 
data points missing, it is because I have not found a satisfactory (read 
quick enough) way of generating these points, and I feel that I have 
enough knowledge of the algorithms to extrapolate further behaviour.

All performance tests were made on Win98, ActiveState Perl 5.8.7 (build 
813), using the Benchmark module's cmpthese() function and the 
:hireswallclock pragma specified.

The performance figures are measured while retrieving every constant - 
this will give us a good average figure.  I have made no attempt to 
benchmark worst and best case figures.  The figures are from a lightly 
loaded 750Mhz PIII machine, and tests were repeated to ensure 
consistancy - in all case a maximum vriation of +/-5% was achieved.

All XS parts were compiled with MS VC++ 6 compiler with the -O flag set

Unless otherwise stated all memory figures were obtained using WinTop 
(from Microsoft's Windows 95 kernel toys distribution)

- Comparison of existing Win32::GUI and new Hash algorithms
-----------------------------------------------------------
No memory comparison available, as it's too hard to separate out the 
constant code from Win32::GUI.  Performance benchmarks for retrieving 
all 364 constants:

              Rate Win32::GUI       Hash
Win32::GUI  691/s         --       -58%
Hash       1653/s       139%         --

showing the new hash implementation to be well over twice as fast as the 
  existing implementation, and we know that the existing linear search 
performed by Win32::GUI will get slower as the number of constants 
increases.

- Comparison of Hash, Perfect, Gperf and MPH algorithms
-------------------------------------------------------
Performance comparisons, retrieving 1588 constants:

          Rate     MPH   Gperf Perfect    Hash
MPH     182/s      --     -0%    -13%    -40%
Gperf   183/s      0%      --    -13%    -40%
Perfect 211/s     15%     15%      --    -30%
Hash    303/s     66%     66%     44%      --

Memory usage comparisons, as deltas from a baseline, having loaded the 
module (and nothing else) over and above the baseline.  It should be 
noted that a number of the generation tools (most notably gperf) have 
many options for trading off memory usage for speed.  In general I was 
aiming for better memory usage, as it quickly became clear that if 
memory is not an issue then the Hash alogithm wins.

All figures in Kbytes:

              Hash  Perfect  Gperf  MPH
DLL Size        0       57     94   78
Memory Usage  416      160    164  176  (delta over common baseline)

I was a little surprised at the memory overhead of the Hash algorithm, 
as Devel::Size estimated the hash size at a little over 88Kbytes, but 
loading the module with out populating the hash clearly showed that 
nearly all of the 416Kbytes (all bar about 50Kbytes) was attributable to 
the hash.

On the basis of these numbers I am going to choose the 'Perfect' 
algorithm to implement the Win32::GUI::Constants module:  it's 
performance is clearly better than what we have today, whilst using well 
under half the memory footprint of the Hash algorithm.

Regards,
Rob.

RE: [perl-win32-gui-hackers] Commit Win32::GUI::DropFiles

[Jeremy W. <jez...@ho...>]

>As always, any reports of success and/or failure are welcome.

All ok under XP. Nice work.

Cheers,

jez.

[perl-win32-gui-hackers] Commit Win32::GUI::DropFiles

[Robert M. <rm...@po...>]

All,

Over the last week or so you'll have seen a number of commits from me - 
this was all heading towards being able to commit the 
Win32::GUI::DropFiles code that I've been working on.

The currently committed code bases compiles and all tests pass under the 
following environments:

Platform  Perl           Compiler
win98     AS Perl 5.6.1  MS VC6/nmake
win98     AS Perl 5.6.1  gcc 3.4.5 (mingw-special)/name
win98     cygwin  5.8.7  gcc 3.4.4 (cygming-special)/nmake
win98     AS Perl 5.8.7  MS VC6/nmake
win98     AS Perl 5.8.7  gcc 3.4.5 (mingw-special)/name
win2k     AS Perl 5.6.1  MS VC7/nmake
win2k     AS Perl 5.6.1  gcc 3.4.2 (mingw-special)/name
win2k     cygwin  5.8.7  gcc 3.4.4 (cygming-special)/nmake
win2k     AS Perl 5.8.7  MS VC7/nmake
win2k     AS Perl 5.8.7  gcc 3.4.2 (mingw-special)/name

I hope that the implementation committed conforms to what we discussed 
on this list some weeks ago now - I think it does, and it includes a 
pretty comprehensive test suite.

There is one problem that I have encountered with the build process: 
under AS Perl 5.6.1 ExtUtils::MakeMaker has a bug (EU::MM v5.45 that is 
fixed in EU::MM v5.47).  If you want to build under AS perl 5.6.1 you'll 
need to upgrade your EU:MM - alternatively I can point out how to 
manually edit the generated Makefile to fix both the subdirs and test 
targets.

As always, any reports of success and/or failure are welcome.

Regards,
Rob.

Re: [win32-gui] [perl-win32-gui-hackers] Problems building under Mingw

[Robert M. <rm...@po...>]

Fix committed.  Typo in a variable type definition (LPCTSTR vs LPTSTR)

Rob.

Jeremy White wrote:
> GetFileVersionInfoSizeA(
> CHAR*, DWORD*)'
> GUI.xs:5629: error: invalid conversion from `const TCHAR*' to `CHAR*'
> GUI.xs:5629: error:   initializing argument 1 of `BOOL 
> GetFileVersionInfoA(CHAR*
> , DWORD, DWORD, void*)'
> 
> I'll have a play and see if I can track it down.
> 
> Cheers,
> 
> jez.
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> http://perl-win32-gui.sourceforge.net/
> 

Re: [perl-win32-gui-hackers] Creating a new Win32-GUI class

[Robert M. <rm...@po...>]

Jeremy White wrote:
 > Robert May wrote:
>> How about something like this:
>> - The 'userdata' member of the (internal) stored data always holds a 
>> hash.  The UserData method stores the passed SV in the 'UserData' 
>> member of that hash.
>> The 'Data' method stores the passed SV in the hash with a key equal to 
>> the current classname (obtained from ref($_[0])).  As you can't have 2 
>> classes with the same name in an inheritance hierarchy, nothing ever 
>> clobbers anything else.
>>
>> This would be problematic if you ever wanted access to your instance 
>> data from a different package from where you set it - but you really 
>> should be using accessor methods to do this anyway.
>>
>> Does this work, and is it sensible?
> 
> Very interesting and elegant solution. I can't see why this wouldn't 
> work. Just so I understand you:
> 
> The userData SV on PERLWIN32GUI_USERDATA, will become a hash if it is 
> ever used (perhaps we should rename this member?). When the user calls 
> the UserData method to store data, the data is stored in the hash with 
> the key 'UserData'. If the Data method is used to store data, the class 
> name of the object will be used to store the data in the hash.

Exactly as I intended.  Yes to re-naming the userdata member.

Rob.