Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert M. <rm...@po...> - 2005-11-22 22:26:01
|
I am please to announce that v1.03 of Win32::GUI is available for download from SourceForge. Win32::GUI is a Perl extension allowing creation of native Win32 GUI applications. MORE INFORMATION Project Homepage: http://perl-win32-gui.sourceforge.net/ Project summary and download: http://sourceforge.net/projects/perl-win32-gui/ Release notes: http://sourceforge.net/project/shownotes.php?group_id=16572&release_id=373056 RELEASE SUMMARY This is a summary of changes between Win32-GUI V1.02 and V1.03 See the CHANGELOG file in the distribution for the full detail. V1.03 is primarily a bug-fix release. New Features in V1.03 ===================== + New methods: - Win32::GUI::DC StretchBlt - Win32::GUI GetParent UserData + New events: - none + New Documentation: - Win32::GUI::RichEdit SetCharFormat GetCharFormat SetEventMask - Win32::GUI::GetAsyncKeyState - Win32::GUI::Timer and all Timer methods - various other minor documentation corrections and enhancements + Other New things - Added Version information to GUI.dll: right-click to see Version - many tests added - added listvew_drag_drop.pl to the samples demonstrating the use of drag/drop with a ListView - ImageList support is now complete under MinGW and Cygwin if headers are recent enough (w32api V3.2 or higher) - Updated all the Tutorial documentation and added tutorial examples to the demos directory. Fixes in V1.03 ============== + Reported Bugs - Fix to 4 item call to TrackPopupMenu. Tracker 1241830 - GUI.pm Fix to logic in Win32::GUI::Class::new for perl 5.8.6 and above. Tracker:1236053 - GUI.pm fixed Win32::GUI::Brush to return undef on failure - GUI_messageloops.cpp: Tracker 1246429 fixed WM_CTLCOLORSTATIC for handling readonly Edit controls - Tooltip.xs, GUI.xs fixed Tooltip styles (Tracker: 1273134) - GUI_MessageLoops.cpp change all mouse event handlers to use GET_X_LPARAM and GET_Y_LPARAM rather than HIWORD and LOWORD (Tracker: 1262098) - GUI.xs fixed UnHook() to resolve perl 5.6/5.8 differences in av_delete, causing a warning in perl 5.8 (Tracker: 1164766) - GUI.xs: Changed DoModal's use of GetParent to GetWindow(hwnd, GW_OWNER). (Tracker: 1165626) - GUI_messageloops.cpp: Tracker:1236283 Change to WM_ERASEBACKGROUND to allow -background to work with windows + Other Bugs - GUI_messageloops.cpp: Fixed WM_CTLCOLOR* to use window class background brush if there is one - Richedit.xs fix SetCharCofmat/GetCharFormat option - GUI.pm Timer fixes (Reini Urban) - GUI.pm fixed Win32::GUI::DC::new() with no params to return a correct object - GUI_Constants.cpp: correct TMP_NONOTIFY to TPM_NONOTIFY (aschwarz1309) - Listbox.xs: fixed buffer overrun in GetText causing crash (Jez White) - Combobox.xs: fixed buffer overrun in GetLBText causing crash (Jez White) - GUI.xs: fixed return value of GetAsyncKeyState - Re-worked Win32::GUI::Timer package implementation. Now destruction works correctly. Contributors to this release: ============================= Dan Dascalescu Reini Urban Jeremy White aschwarz1309 Robert May My thanks to all the others who have provided invaluable comments and testing. -- Rob. 22nd November 2005 |
|
From: Robert M. <rm...@po...> - 2005-11-21 22:41:51
|
All, I just checked in what I hope will be the last set of changes for a 1.03 release. If anyone has time to check out the current CVS HEAD and confirm that it builds and that the tests run OK I would be grateful. I've built and run the tests on win98, perl 5.6.1 and 5.8.7, with both MinGW and VC compilers. I've been running the module before this last set of changes (that only affects Makefile.PL, tests and documentation) for the last week under win98 and w2k (perl 5.8.7) with no (unknown/unexpected) issues. I have not built/tested under cygwin, as I don't currently have an environment available. I hope to tag these files as 1.03 and release tomorrow evening (UK time). Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
|
From: Eric H. <eh...@co...> - 2005-11-15 19:00:39
|
I had to use the Change method to get this routine to work. Anyone know
why
You can't declare titlebar and resizeable in the MDI child when
declared?
Wont work unless you specify in change method. Does it have to do with
Inheritance from the parent preventing this?
use Win32::GUI;
$M_F =3D new Win32::GUI::Menu(
"&File" =3D> "File",
" > &Exit" =3D> "Exit",
);
$F =3D new Win32::GUI::MDIFrame (
-title =3D> "Scrolling Window Demo",
-name =3D> "Frame",
-menu =3D> $M_F,
-toolwindow =3D> 1,
);
$F->AddMDIClient(-name =3D> "Client",);
$W =3D $F->{Client}->AddMDIChild(-name =3D> "Window",);
$F->Change(-top =3D> 100, -left =3D> 25, -width =3D> 950, -height =3D> =
500,
-minsize =3D> [250,150], -maxsize =3D> [950,500],);
$W->Change(-top =3D> 0, -left =3D> 0, -width =3D> 950, -height =3D> 500,
-titlebar =3D> 0, -resizable =3D> 0,);
$DT_DateOne =3D new Win32::GUI::DateTime($W,
-name =3D> "DT_DateOpened",
-top =3D> 50,=20
-left =3D> 100,=20
-height =3D> 20,
-width =3D> 110,
-shownone =3D> 1,
);=09
$DT_Date2 =3D new Win32::GUI::DateTime($W,
-name =3D> "DT_Date2",
-top =3D> 150,=20
-left =3D> 300,=20
-height =3D> 20,
-width =3D> 110,
-shownone =3D> 1,
);=09
$DT_Date3 =3D new Win32::GUI::DateTime($W,
-name =3D> "DT_Date3",
-top =3D> 250,=20
-left =3D> 500,=20
-height =3D> 20,
-width =3D> 110,
-shownone =3D> 1,
);=09
$DT_Date4 =3D new Win32::GUI::DateTime($W,
-name =3D> "DT_Date4",
-top =3D> 350,=20
-left =3D> 700,=20
-height =3D> 20,
-width =3D> 110,
-shownone =3D> 1,
);=09
$F->Show();
$W->Show();
#########################
# Event Handler #
#########################
Win32::GUI::Dialog();
################
sub Exit_Click {
################
return -1;
}
#####################
sub Frame_Terminate {
#####################
return -1;
}
|
|
From: Jeremy W. <jez...@ho...> - 2005-11-14 09:56:05
|
>I intend to make this the V1.03 release once I've had a few days to play >with it. She builds fine under ming and basic testing hasn't shown anything odd. I'll try and build under VC6 and test her hard over the next couple of days. Good work, Cheers, jez, |
|
From: Robert M. <rm...@po...> - 2005-11-13 20:25:11
|
I just committed a number of bug fixes: - Makefile.PL added code to remove Test::More dependence from PPD - GUI_MessageLoops.cpp, Window.xs change all mouse related handlers to use GET_X_LPARAM and GET_Y_LPARAM rather than HIWORD and LOWORD (Tracker: 1262098) - GUI.xs added INTERNAL function GetWindowObject to get the perl window object from a window handle - GUI.pm, t\05_Timer*.t, docs\GUI\Tutorial\Part4.pod - re-wrote Win32::GUI::Timer implementation and updated docs to make it all consistent, and to make destruction happen correctly. Added full tests for the package. - GUI.xs fixed GetAsyncKeyState(), which was checking the wrong bit of window's return value. Updated documentation. - MANIFEST updated with new samples and new tests - GUI.pm upped version to 1.02_03 I've put PPM for perl 5.6 and 5.8 at http://www.robmay.me.uk/win32gui/ I intend to make this the V1.03 release once I've had a few days to play with it. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-11-13 20:17:51
|
Proposed API: > new(PARENT, NAME, ELAPSE). Underneath it maps name to an ID, stores the > parameters in a perl Win32::GUI::Timer object and adds a reference to > the object to its window(parent) object. It then calls SetTimer, if > ELAPSE is greater than 0. > > INTERVAL(ELAPSE). Retrieves the parameters from the object, and calls > SetTimer if ELAPSE > 0, or KillTimer if ELAPSE=0. > > Kill(REMOVE). Retrieves the parameters from the object and calls > KillTimer. Removes the reference from its window(parent) object if > REMOVE evaluates true. > > DESTROY(). Called when the reference count to the timer object goes to > zero. Calls KillTimer. > > So you can consider it like this: > new - calls SettTimer > Interval(n) - calls SetTimer > Interval(0) - calls KillTimer > Kill() - calls KillTimer, leaving the mapping between NAME and ID so > that Interval(n) still has the parameters to call SetTimer again. > Kill(1) - calls KillTimer and removes the NAME to ID mapping. > I'm going to go ahead and re-work it and update the documentation and > tests. Updated implementation, documentation, and tests are now in CVS. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
|
From: Robert M. <rm...@po...> - 2005-11-12 16:07:34
|
Glenn W Munroe wrote:
> Rob,
>
> Your enhancements sound good. In principal, I'm a little wary of straying
> from MS's underlying interface, but I think that in the case of this
> control, the precedent was set in the early days of the module (from what I
> understand of the MS documentation, the SetTimer function creates the timer
> and sets its interval in one call). Your proposed new 'Kill' behaviour again
> strays a little from the MS standard, but it will achieve the goal of not
> breaking old programs.
The MS api has only 2 calls:
SetTimer(HWND, ID, INTERVAL)
KillTimer(HWND, ID)
If programming directly using this api the user chooses an ID, and then
calls SetTimer to start the timer, or KillTimer to stop (and free) the
timer.
The Win32::GUI::Timer class has the following api (as proposed by me below):
new(PARENT, NAME, ELAPSE). Underneath it maps name to an ID, stores the
parameters in a perl Win32::GUI::Timer object and adds a reference to
the object to its window(parent) object. It then calls SetTimer, if
ELAPSE is greater than 0.
INTERVAL(ELAPSE). Retrieves the parameters from the object, and calls
SetTimer if ELAPSE > 0, or KillTimer if ELAPSE=0.
Kill(REMOVE). Retrieves the parameters from the object and calls
KillTimer. Removes the reference from its window(parent) object if
REMOVE evaluates true.
DESTROY(). Called when the reference count to the timer object goes to
zero. Calls KillTimer.
So you can consider it like this:
new - calls SettTimer
Interval(n) - calls SetTimer
Interval(0) - calls KillTimer
Kill() - calls KillTimer, leaving the mapping between NAME and ID so
that Interval(n) still has the parameters to call SetTimer again.
Kill(1) - calls KillTimer and removes the NAME to ID mapping.
It doesn't feel too far from the MS api to me.
> The only problem I can think of is if anybody were to
> repeatedly create and destroy a lot of timers, assuming standard MS
> behaviour, then memory usage (which seems to be a hot topic of late) might
> increase, as the timers would be simply disabled and not destroyed. But
> that's unlikely, and as long as the changes are documented, there shouldn't
> be a problem.
I don't see that's how it works. KillTimer is always called. The
problem with the current implementation is that if you repeatedly call
new(), then a new perl object is created, and as there is a reference
from the parent to it, it cannot get DESTROYed until the parent object
is destroyed, so perl memory usage increases. Under the proposed
implementation this is fixed by (1) allowing re-use of the same perl
object (with Interval(0) and Kill() killing the underlying windows
timer, and Interval(n) re-starting it) or (2) Kill(1) freeing all the
perl resources.
I'm going to go ahead and re-work it and update the documentation and tests.
Regards,
Rob.
>
> So, in general, though I'm more of a user than a developer, I agree with
> your suggestions.
>
> Glenn
>
> -----Original Message-----
> From: Robert May [mailto:rm...@po...]
> Sent: Friday, 11 November, 2005 18:46
> To: per...@li...
> Cc: Glenn W Munroe
> Subject: Win32::GUI::Timer [Was: Next Release soon on the users list]
>
> I've had reason to look in more detail at the changes that Reini made
> some months ago. I propose that I'm going to make another round of
> changes to the timer class:
>
> (1) I want to get rid of the circular reference. I think this is possible.
> (2) I'd like to not break existing implementations.
>
> I propose the following interface:
>
> new(PARENT, [NAME, [ELAPSE=0]])
>
> creates a Win32::GUI::Timer object, adds it to the PARENT window's hash
> etc. as today. I'll add the capability of creating the object with
> ELAPSE=0, which will create the object, but not start the timer.
>
> Interval([ELAPSE])
>
> get or set the timer interval, as today. I will modify it so that when
> setting it returns the previous interval. Setting the interval to 0
> will suspend the timer.
>
> Kill([REMOVE=0])
>
> Calling Kill with no parameters (or any parameter that evaluates to
> false) will suspend the timer exactly like Interval(0).
>
> Calling Kill with a parameter that evaluates to True will remove all
> traces of the timer from the parent hash, although true destruction will
> still only happen when the object's ref-count goes to zero. In most
> case this will happen after a Kill(1).
>
> Additionally, by removing the circular reference, I believe that regular
> destruction when the (parent) window object goes out of scope will
> happen, rather than the current implementation where if you have not
> called Kill explicitly, object destruction doe not happen until the
> final garbage collection sweep when the program terminates.
>
> If we can agree on this, then I will make the changes, update the
> documentation and update the tests.
>
> Your comments welcome, as always.
>
> Regards,
> Rob.
>
> Robert May wrote:
>
>>Hi Glenn,
>>
>>Thanks for the investigation. The changes were made by Reini, to try to
>>bring the behaviour in line with what part 4 of the tutorial says about
>>timers. Having looked at this text myself, I'm not sure that what he
>>has done matches what the tutorial says, although I think his
>>implementation is good.
>>
>>Under the current implementation kill() destroys the timer completely
>>(including, as you say, removing it's reference from the parent window).
>> To disable the timer temporarily you need to set the interval to 0.
>>
>>If we all agree that the new implementation is good, then I'll update
>>the Timer documentation and part 4 of the tutorial to reflect this. I'll
>>also make sure that this behavioural change gets mentioned in the
>>release notes.
>>
>>Regards,
>>Rob.
>>
>>Glenn W Munroe wrote:
>>
>>
>>>I had been building the new version using MinGW, but I just
>>>reinstalled it
>>>from Rob's PPM. This installed the new documentation correctly and I
>>>now see
>>>that there is some Timer documentation.
>>>Apologies for flooding the list with replies to myself...
>>>
>>>-----Original Message-----
>>>From: per...@li...
>>>[mailto:per...@li...] On Behalf Of
>>>Glenn
>>>W Munroe
>>>Sent: Friday, 28 October, 2005 12:27
>>>To: rm...@po...
>>>Cc: per...@li...
>>>Subject: RE: [perl-win32-gui-users] Next Release soon
>>>
>>>
>>>I spent a little time to dig into this more. As I suspected, this isn't a
>>>bug, but a change in implementation. Under version 1.01_01, the Kill()
>>>method simply made a call to the system function KillTimer. Version
>>>1.02_02
>>>explicitly destroys the timer, which includes removing its definition
>>>from
>>>the window hash. Hence, my "nothing strange" code below was defining each
>>>timer then destroying it in the next step!
>>>
>>>In practice, there was a more subtle difference. The effect of the old
>>>Kill() method was simply to disable the timer; it could then be
>>>resurrected
>>>with a new Interval(). I'm not sure that this behaviour was correct or
>>>desired, but I was using it in my program. I can't just remember why I
>>>did
>>>it that way, but it was probably a "safe" way of ensuring the timer
>>>didn't
>>>fire until I was ready for it (the alternative being either to make the
>>>Interval() very large--for some arbitrary value of "very large"--or to
>>>repeatedly kill and redefine the timer). It could also have been to
>>>cover a
>>>deeper problem in the implementation, but time will tell.
>>>
>>>The Win32::GUI documentation for Timers is bare, but the MSDN
>>>documentation
>>>does suggest that the new behaviour is correct. However, version 1.02_02
>>>will break any program using the old behaviour. The addition of a simple
>>>definition to the method documentation would help.
>>>
>>>Glenn
>>>
>>>-----Original Message-----
>>>From: gw...@se... [mailto:gw...@se...] Sent: Friday, 21
>>>October, 2005 16:44
>>>To: rm...@po...
>>>Cc: gw...@se...; per...@li...
>>>Subject: RE: [perl-win32-gui-users] Next Release soon
>>>
>>>
>>>Sorry for the delay, but it's been hectic at work this week.
>>>
>>>I've attached (an image of) the error message. Sure enough, a 'dump'
>>>of the
>>>main window object shows that the timers don't get registered for some
>>>reason:
>>>
>>>bless({
>>> # tied Win32::GUI::Window
>>> "-accel" => 41_681_429,
>>> "-font" => -334_885_755,
>>> "-handle" => 2_032_212,
>>> "-minheight" => 595,
>>> "-minwidth" => 850,
>>> "-name" => "mw",
>>> "-timers" => {},
>>> "-type" => 0,
>>>
>>>etc.
>>>
>>>There's nothing strange about the declaration of the timers:
>>>
>>>$mw->AddTimer("tmList",100000);
>>>$mw->tmList->Kill();
>>>$mw->AddTimer("tmLoop",100000);
>>>$mw->tmLoop->Kill();
>>>
>>>etc.
>>>
>>>The same script runs with no problem on 1.01_01. There, the dump shows:
>>>
>>>bless({
>>> # tied Win32::GUI::Window
>>> "-accel" => 25_036_785,
>>> "-font" => "-1626733967",
>>> "-handle" => 6_358_280,
>>> "-minheight" => 595,
>>> "-minwidth" => 850,
>>> "-name" => "mw",
>>> "-timers" => {
>>> 1 => "tmList",
>>> 2 => "tmLoop",
>>> 3 => "tmStatus",
>>> 4 => "tmYearVerify",
>>> 5 => "tmTrackVerify",
>>> 6 => "tmGenreVerify",
>>> },
>>> "-type" => 0,
>>>
>>>etc.
>>>
>>>I'll keep trying to narrow it down and will post back if I do.
>>>
>>>Glenn
>>>
>>>------------------- reply ---------------
>>>
>>>
>>>>From: rm...@po...
>>>>To: gw...@se...
>>>>Cc: per...@li...
>>>>Subject: RE: [perl-win32-gui-users] Next Release soon
>>>>Date: 2005-10-19 15:40:09
>>>>----------------------------------
>>>>gw...@se... wrote:
>>>>
>>>>
>>>>>hit another more worrying problem: I have a large-ish program, which
>>>>>uses a number of timers. With 1.02_02 I get an error whenever any one
>>>>>of the timers tries to fire (Can't locate auto/tmList.al in @INC...).
>>>>>I tried to replicate this in a smaller program, but was unable to; a
>>>>>simple program with a timer works fine. It's quite possible that my
>>>>>program has a flaw, of which 1.01_01 is more tolerant, but there may
>>>>>be a problem in the new GUI code.
>>>>
>>>>
>>>>That is indeed worrying. There have been some minor changes to the
>>>>timer code that Reini made when he put his tests together, but I
>>>>can't immediately see anything that would cause this.
>>>>
>>>>Typically when I see errors like that it turns out to be a
>>>>mis-spelled method call or window name, but if that was the case I
>>>>would expect it to fail in 1.01_01 too.
>>>>
>>>>If you can't get a short example to exhibit this problem, can you
>>>>post the exact error message that you're getting.
>>>>
>>>>Rob.
>>>>--
>>>>Robert May
>>>>Win32::GUI, a perl extension for native Win32 applications
>>>>http://perl-win32-gui.sourceforge.net/
>>>>
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by the JBoss Inc.
>>>Get Certified Today * Register for a JBoss Training Course
>>>Free Certification Exam for All Training Attendees Through End of 2005
>>>Visit http://www.jboss.com/services/certification for more information
>>>_______________________________________________
>>>Perl-Win32-GUI-Users mailing list
>>>Per...@li...
>>>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>>>http://perl-win32-gui.sourceforge.net/
>>>
>>>
>>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by the JBoss Inc.
>>Get Certified Today * Register for a JBoss Training Course
>>Free Certification Exam for All Training Attendees Through End of 2005
>>Visit http://www.jboss.com/services/certification for more information
>>_______________________________________________
>>Perl-Win32-GUI-Users mailing list
>>Per...@li...
>>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>>http://perl-win32-gui.sourceforge.net/
>>
>
>
>
>
|
|
From: Glenn W M. <gw...@se...> - 2005-11-12 14:30:00
|
Rob,
I wasn't aware of the circular reference, but I don't think anybody can
argue with the two goals.
Your enhancements sound good. In principal, I'm a little wary of straying
from MS's underlying interface, but I think that in the case of this
control, the precedent was set in the early days of the module (from what I
understand of the MS documentation, the SetTimer function creates the timer
and sets its interval in one call). Your proposed new 'Kill' behaviour again
strays a little from the MS standard, but it will achieve the goal of not
breaking old programs. The only problem I can think of is if anybody were to
repeatedly create and destroy a lot of timers, assuming standard MS
behaviour, then memory usage (which seems to be a hot topic of late) might
increase, as the timers would be simply disabled and not destroyed. But
that's unlikely, and as long as the changes are documented, there shouldn't
be a problem.
So, in general, though I'm more of a user than a developer, I agree with
your suggestions.
Glenn
-----Original Message-----
From: Robert May [mailto:rm...@po...]
Sent: Friday, 11 November, 2005 18:46
To: per...@li...
Cc: Glenn W Munroe
Subject: Win32::GUI::Timer [Was: Next Release soon on the users list]
I've had reason to look in more detail at the changes that Reini made
some months ago. I propose that I'm going to make another round of
changes to the timer class:
(1) I want to get rid of the circular reference. I think this is possible.
(2) I'd like to not break existing implementations.
I propose the following interface:
new(PARENT, [NAME, [ELAPSE=0]])
creates a Win32::GUI::Timer object, adds it to the PARENT window's hash
etc. as today. I'll add the capability of creating the object with
ELAPSE=0, which will create the object, but not start the timer.
Interval([ELAPSE])
get or set the timer interval, as today. I will modify it so that when
setting it returns the previous interval. Setting the interval to 0
will suspend the timer.
Kill([REMOVE=0])
Calling Kill with no parameters (or any parameter that evaluates to
false) will suspend the timer exactly like Interval(0).
Calling Kill with a parameter that evaluates to True will remove all
traces of the timer from the parent hash, although true destruction will
still only happen when the object's ref-count goes to zero. In most
case this will happen after a Kill(1).
Additionally, by removing the circular reference, I believe that regular
destruction when the (parent) window object goes out of scope will
happen, rather than the current implementation where if you have not
called Kill explicitly, object destruction doe not happen until the
final garbage collection sweep when the program terminates.
If we can agree on this, then I will make the changes, update the
documentation and update the tests.
Your comments welcome, as always.
Regards,
Rob.
Robert May wrote:
> Hi Glenn,
>
> Thanks for the investigation. The changes were made by Reini, to try to
> bring the behaviour in line with what part 4 of the tutorial says about
> timers. Having looked at this text myself, I'm not sure that what he
> has done matches what the tutorial says, although I think his
> implementation is good.
>
> Under the current implementation kill() destroys the timer completely
> (including, as you say, removing it's reference from the parent window).
> To disable the timer temporarily you need to set the interval to 0.
>
> If we all agree that the new implementation is good, then I'll update
> the Timer documentation and part 4 of the tutorial to reflect this. I'll
> also make sure that this behavioural change gets mentioned in the
> release notes.
>
> Regards,
> Rob.
>
> Glenn W Munroe wrote:
>
>> I had been building the new version using MinGW, but I just
>> reinstalled it
>> from Rob's PPM. This installed the new documentation correctly and I
>> now see
>> that there is some Timer documentation.
>> Apologies for flooding the list with replies to myself...
>>
>> -----Original Message-----
>> From: per...@li...
>> [mailto:per...@li...] On Behalf Of
>> Glenn
>> W Munroe
>> Sent: Friday, 28 October, 2005 12:27
>> To: rm...@po...
>> Cc: per...@li...
>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>
>>
>> I spent a little time to dig into this more. As I suspected, this isn't a
>> bug, but a change in implementation. Under version 1.01_01, the Kill()
>> method simply made a call to the system function KillTimer. Version
>> 1.02_02
>> explicitly destroys the timer, which includes removing its definition
>> from
>> the window hash. Hence, my "nothing strange" code below was defining each
>> timer then destroying it in the next step!
>>
>> In practice, there was a more subtle difference. The effect of the old
>> Kill() method was simply to disable the timer; it could then be
>> resurrected
>> with a new Interval(). I'm not sure that this behaviour was correct or
>> desired, but I was using it in my program. I can't just remember why I
>> did
>> it that way, but it was probably a "safe" way of ensuring the timer
>> didn't
>> fire until I was ready for it (the alternative being either to make the
>> Interval() very large--for some arbitrary value of "very large"--or to
>> repeatedly kill and redefine the timer). It could also have been to
>> cover a
>> deeper problem in the implementation, but time will tell.
>>
>> The Win32::GUI documentation for Timers is bare, but the MSDN
>> documentation
>> does suggest that the new behaviour is correct. However, version 1.02_02
>> will break any program using the old behaviour. The addition of a simple
>> definition to the method documentation would help.
>>
>> Glenn
>>
>> -----Original Message-----
>> From: gw...@se... [mailto:gw...@se...] Sent: Friday, 21
>> October, 2005 16:44
>> To: rm...@po...
>> Cc: gw...@se...; per...@li...
>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>
>>
>> Sorry for the delay, but it's been hectic at work this week.
>>
>> I've attached (an image of) the error message. Sure enough, a 'dump'
>> of the
>> main window object shows that the timers don't get registered for some
>> reason:
>>
>> bless({
>> # tied Win32::GUI::Window
>> "-accel" => 41_681_429,
>> "-font" => -334_885_755,
>> "-handle" => 2_032_212,
>> "-minheight" => 595,
>> "-minwidth" => 850,
>> "-name" => "mw",
>> "-timers" => {},
>> "-type" => 0,
>>
>> etc.
>>
>> There's nothing strange about the declaration of the timers:
>>
>> $mw->AddTimer("tmList",100000);
>> $mw->tmList->Kill();
>> $mw->AddTimer("tmLoop",100000);
>> $mw->tmLoop->Kill();
>>
>> etc.
>>
>> The same script runs with no problem on 1.01_01. There, the dump shows:
>>
>> bless({
>> # tied Win32::GUI::Window
>> "-accel" => 25_036_785,
>> "-font" => "-1626733967",
>> "-handle" => 6_358_280,
>> "-minheight" => 595,
>> "-minwidth" => 850,
>> "-name" => "mw",
>> "-timers" => {
>> 1 => "tmList",
>> 2 => "tmLoop",
>> 3 => "tmStatus",
>> 4 => "tmYearVerify",
>> 5 => "tmTrackVerify",
>> 6 => "tmGenreVerify",
>> },
>> "-type" => 0,
>>
>> etc.
>>
>> I'll keep trying to narrow it down and will post back if I do.
>>
>> Glenn
>>
>> ------------------- reply ---------------
>>
>>> From: rm...@po...
>>> To: gw...@se...
>>> Cc: per...@li...
>>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>> Date: 2005-10-19 15:40:09
>>> ----------------------------------
>>> gw...@se... wrote:
>>>
>>>> hit another more worrying problem: I have a large-ish program, which
>>>> uses a number of timers. With 1.02_02 I get an error whenever any one
>>>> of the timers tries to fire (Can't locate auto/tmList.al in @INC...).
>>>> I tried to replicate this in a smaller program, but was unable to; a
>>>> simple program with a timer works fine. It's quite possible that my
>>>> program has a flaw, of which 1.01_01 is more tolerant, but there may
>>>> be a problem in the new GUI code.
>>>
>>>
>>> That is indeed worrying. There have been some minor changes to the
>>> timer code that Reini made when he put his tests together, but I
>>> can't immediately see anything that would cause this.
>>>
>>> Typically when I see errors like that it turns out to be a
>>> mis-spelled method call or window name, but if that was the case I
>>> would expect it to fail in 1.01_01 too.
>>>
>>> If you can't get a short example to exhibit this problem, can you
>>> post the exact error message that you're getting.
>>>
>>> Rob.
>>> --
>>> Robert May
>>> Win32::GUI, a perl extension for native Win32 applications
>>> http://perl-win32-gui.sourceforge.net/
>>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.
>> Get Certified Today * Register for a JBoss Training Course
>> Free Certification Exam for All Training Attendees Through End of 2005
>> Visit http://www.jboss.com/services/certification for more information
>> _______________________________________________
>> Perl-Win32-GUI-Users mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>> http://perl-win32-gui.sourceforge.net/
>>
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>
|
|
From: Robert M. <rm...@po...> - 2005-11-11 21:45:51
|
I've had reason to look in more detail at the changes that Reini made
some months ago. I propose that I'm going to make another round of
changes to the timer class:
(1) I want to get rid of the circular reference. I think this is possible.
(2) I'd like to not break existing implementations.
I propose the following interface:
new(PARENT, [NAME, [ELAPSE=0]])
creates a Win32::GUI::Timer object, adds it to the PARENT window's hash
etc. as today. I'll add the capability of creating the object with
ELAPSE=0, which will create the object, but not start the timer.
Interval([ELAPSE])
get or set the timer interval, as today. I will modify it so that when
setting it returns the previous interval. Setting the interval to 0
will suspend the timer.
Kill([REMOVE=0])
Calling Kill with no parameters (or any parameter that evaluates to
false) will suspend the timer exactly like Interval(0).
Calling Kill with a parameter that evaluates to True will remove all
traces of the timer from the parent hash, although true destruction will
still only happen when the object's ref-count goes to zero. In most
case this will happen after a Kill(1).
Additionally, by removing the circular reference, I believe that regular
destruction when the (parent) window object goes out of scope will
happen, rather than the current implementation where if you have not
called Kill explicitly, object destruction doe not happen until the
final garbage collection sweep when the program terminates.
If we can agree on this, then I will make the changes, update the
documentation and update the tests.
Your comments welcome, as always.
Regards,
Rob.
Robert May wrote:
> Hi Glenn,
>
> Thanks for the investigation. The changes were made by Reini, to try to
> bring the behaviour in line with what part 4 of the tutorial says about
> timers. Having looked at this text myself, I'm not sure that what he
> has done matches what the tutorial says, although I think his
> implementation is good.
>
> Under the current implementation kill() destroys the timer completely
> (including, as you say, removing it's reference from the parent window).
> To disable the timer temporarily you need to set the interval to 0.
>
> If we all agree that the new implementation is good, then I'll update
> the Timer documentation and part 4 of the tutorial to reflect this. I'll
> also make sure that this behavioural change gets mentioned in the
> release notes.
>
> Regards,
> Rob.
>
> Glenn W Munroe wrote:
>
>> I had been building the new version using MinGW, but I just
>> reinstalled it
>> from Rob's PPM. This installed the new documentation correctly and I
>> now see
>> that there is some Timer documentation.
>> Apologies for flooding the list with replies to myself...
>>
>> -----Original Message-----
>> From: per...@li...
>> [mailto:per...@li...] On Behalf Of
>> Glenn
>> W Munroe
>> Sent: Friday, 28 October, 2005 12:27
>> To: rm...@po...
>> Cc: per...@li...
>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>
>>
>> I spent a little time to dig into this more. As I suspected, this isn't a
>> bug, but a change in implementation. Under version 1.01_01, the Kill()
>> method simply made a call to the system function KillTimer. Version
>> 1.02_02
>> explicitly destroys the timer, which includes removing its definition
>> from
>> the window hash. Hence, my "nothing strange" code below was defining each
>> timer then destroying it in the next step!
>>
>> In practice, there was a more subtle difference. The effect of the old
>> Kill() method was simply to disable the timer; it could then be
>> resurrected
>> with a new Interval(). I'm not sure that this behaviour was correct or
>> desired, but I was using it in my program. I can't just remember why I
>> did
>> it that way, but it was probably a "safe" way of ensuring the timer
>> didn't
>> fire until I was ready for it (the alternative being either to make the
>> Interval() very large--for some arbitrary value of "very large"--or to
>> repeatedly kill and redefine the timer). It could also have been to
>> cover a
>> deeper problem in the implementation, but time will tell.
>>
>> The Win32::GUI documentation for Timers is bare, but the MSDN
>> documentation
>> does suggest that the new behaviour is correct. However, version 1.02_02
>> will break any program using the old behaviour. The addition of a simple
>> definition to the method documentation would help.
>>
>> Glenn
>>
>> -----Original Message-----
>> From: gw...@se... [mailto:gw...@se...] Sent: Friday, 21
>> October, 2005 16:44
>> To: rm...@po...
>> Cc: gw...@se...; per...@li...
>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>
>>
>> Sorry for the delay, but it's been hectic at work this week.
>>
>> I've attached (an image of) the error message. Sure enough, a 'dump'
>> of the
>> main window object shows that the timers don't get registered for some
>> reason:
>>
>> bless({
>> # tied Win32::GUI::Window
>> "-accel" => 41_681_429,
>> "-font" => -334_885_755,
>> "-handle" => 2_032_212,
>> "-minheight" => 595,
>> "-minwidth" => 850,
>> "-name" => "mw",
>> "-timers" => {},
>> "-type" => 0,
>>
>> etc.
>>
>> There's nothing strange about the declaration of the timers:
>>
>> $mw->AddTimer("tmList",100000);
>> $mw->tmList->Kill();
>> $mw->AddTimer("tmLoop",100000);
>> $mw->tmLoop->Kill();
>>
>> etc.
>>
>> The same script runs with no problem on 1.01_01. There, the dump shows:
>>
>> bless({
>> # tied Win32::GUI::Window
>> "-accel" => 25_036_785,
>> "-font" => "-1626733967",
>> "-handle" => 6_358_280,
>> "-minheight" => 595,
>> "-minwidth" => 850,
>> "-name" => "mw",
>> "-timers" => {
>> 1 => "tmList",
>> 2 => "tmLoop",
>> 3 => "tmStatus",
>> 4 => "tmYearVerify",
>> 5 => "tmTrackVerify",
>> 6 => "tmGenreVerify",
>> },
>> "-type" => 0,
>>
>> etc.
>>
>> I'll keep trying to narrow it down and will post back if I do.
>>
>> Glenn
>>
>> ------------------- reply ---------------
>>
>>> From: rm...@po...
>>> To: gw...@se...
>>> Cc: per...@li...
>>> Subject: RE: [perl-win32-gui-users] Next Release soon
>>> Date: 2005-10-19 15:40:09
>>> ----------------------------------
>>> gw...@se... wrote:
>>>
>>>> hit another more worrying problem: I have a large-ish program, which
>>>> uses a number of timers. With 1.02_02 I get an error whenever any one
>>>> of the timers tries to fire (Can't locate auto/tmList.al in @INC...).
>>>> I tried to replicate this in a smaller program, but was unable to; a
>>>> simple program with a timer works fine. It's quite possible that my
>>>> program has a flaw, of which 1.01_01 is more tolerant, but there may
>>>> be a problem in the new GUI code.
>>>
>>>
>>> That is indeed worrying. There have been some minor changes to the
>>> timer code that Reini made when he put his tests together, but I
>>> can't immediately see anything that would cause this.
>>>
>>> Typically when I see errors like that it turns out to be a
>>> mis-spelled method call or window name, but if that was the case I
>>> would expect it to fail in 1.01_01 too.
>>>
>>> If you can't get a short example to exhibit this problem, can you
>>> post the exact error message that you're getting.
>>>
>>> Rob.
>>> --
>>> Robert May
>>> Win32::GUI, a perl extension for native Win32 applications
>>> http://perl-win32-gui.sourceforge.net/
>>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the JBoss Inc.
>> Get Certified Today * Register for a JBoss Training Course
>> Free Certification Exam for All Training Attendees Through End of 2005
>> Visit http://www.jboss.com/services/certification for more information
>> _______________________________________________
>> Perl-Win32-GUI-Users mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>> http://perl-win32-gui.sourceforge.net/
>>
>>
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>
|
|
From: Robert M. <rm...@po...> - 2005-11-10 18:30:47
|
Glenn Linderman wrote: > On approximately 11/9/2005 1:26 PM, came the following characters from > the keyboard of Robert May: > >> Please find attached what I hope is a final beta of a >> Win32::GUI::Constants package - v0.00_03. >> > Constants.PL contains stuff like: > > BDR_OUTER 0x0003 # (BDR_RAISEDOUTER | BDR_SUNKENOUTER) > BDR_INNER 0x000C # (BDR_RAISEDINNER | BDR_SUNKENINNER) > BDR_RAISED 0x0005 # (BDR_RAISEDOUTER | BDR_RAISEDINNER) > > Perhaps it would be a nice addition to the TODO file to "enhance > Constants.PL to interpret constant C expressions expressed in terms of > previously defined constants within the Constants.PL file". In the > fullness of time, then, cutting and pasting would be easier from the > header files. > > An encompassing TODO addition would be to change the syntax for the > __DATA__ section to be the subset of C that includes comments, and > #define. That would make the cutting and pasting even easier! > > Of course, that leads in to the also missing TODO of parsing the Windows > header files themselves, looking only for #define that consist only of > constant numbers and expression syntax and already seen constant > operands, which would also be encompassing! These are items that I > could be interested in whacking at, if I ever complete my long-delayed > top-priority project. But listing them might inspire someone else to > beat me to it, which would be OK too. I'll add something to the TODO file about making it easier to extract the constant definitions, but the though of writing a C-preprocessor (even a partial one) just for this one job doesn't appeal to me much - I haven't tried CPAN to see what's available off the shelf though. From what I've read h2xs may have some functionality, but I couldn't get the header parsing functionality to work on windows - perhaps I should give it another go in a cygwin environment. > I guess you can tell that I'm quite happy with the functionality, since > I can only think of long-term TODO items :) I'll count that as a thumbs-up. I'll try to find time to package it all up properly this weekend. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-11-09 21:27:15
|
Please find attached what I hope is a final beta of a Win32::GUI::Constants package - v0.00_03. I'd appreciate a (final?) once over before I up the version to 0.01 and make it available to a wider audience. I hope to be able to fold it into Win32::GUI v1.04, but haven't looked at how difficult this might be yet. Assuming that it passes muster, then I will make it available (both as source, as attached here, and as a PPM) - probably both on my site and at CPAN. Now back to finalising a V1.03 release. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-11-08 19:33:40
|
Robert May wrote:
>> Hmm. With 350 names in :compatibility_win32_gui, more files might be
>> needed. Maybe change Tags.pm
[snip]
> eval "require Win32::GUI::Constants::Tags_$spec";
> if($@) {
> warnings::warnif qq(Failed to load definition for tag ':$spec': $@)
> }
> else {
> $TAG_SPEC{$spec} = \@{"Win32::GUI::Constants::Tags_$spec::C"};
> }
>
> Although I'll not head down this route just yet - I'll add a comment to
> the Tags.pm file.
A day to think about it and all becomes clear. This is exactly what the
AutoLoader module is for. The definition for each tag becomes a
subroutine, which the build process splits into separate files, and
AUTOLOADs only the ones that actually get used.
In fact such is this solution that the whole lot could be folded back
into Constants.pm - although that would make Constants.pm's AUTOLOAD sub
significantly more complex (especially as we can export it to other
namespaces), so I'll be keeping Tags.pm for now.
Seems like we have the full solution.
Regards.
Rob.
|
|
From: Robert M. <rm...@po...> - 2005-11-07 23:05:55
|
I thought I'd share a couple of test that I've done today with you.
(1) speed increases for inlining:
I was interested to know how much time was saved by inline constants.
The following script gives an answer:
#!perl -w
use strict;
use warnings;
use Benchmark qw( :hireswallclock timethese cmpthese );
sub a() {1001}; # will be inlined
sub b {1001}; # won't be inlined
my $r = timethese( 100_000_000 , {
a => sub {a},
b => sub {b},
} );
cmpthese $r;
It takes a couple of minutes to run (w98SE, perl 5.8.7, 700MHz PII), and
when it works it gives results like below, although it also produces
non-sensical results (with -ve times) on some runs.
C:\WINDOWS\Desktop>perl benchmark.pl
Benchmark: timing 100000000 iterations of a, b...
a: 19.4211 wallclock secs (19.39 usr + 0.00 sys = 19.39 CPU) @ 5157297
.58/s (n=100000000)
b: 145.188 wallclock secs (145.22 usr + 0.00 sys = 145.22 CPU) @ 68861
0.38/s (n=100000000)
Rate b a
b 688610/s -- -87%
a 5157298/s 649% --
If this can be believed, then inlining is about 6-7 times faster than a
subroutine call (that's certainly possible). Of course, the times
involved are minuscule, so you'd have to be doing a *lot* of references
to constants before this really made a difference, but interesting, none
the less.
(2) memory usage of Win32::GUI::Constants
This is, perhaps, more relevant, although I'm much less sure of what
interpretation I can make of the results.
I ran the following command lines from the cmd.exe shell on a w2k box.
I used sysinternals' 'Process Monitor' (verified by comparison with
numbers from the MS performance counters) to get the memory figures. The
varying and maximum figure were always within a few 10's of KBytes of
each other, so I am only quoting the max(peak) values. All number in
KBytes.
Commands:
1= perl -Iblib/lib -e "sleep 100"
2= perl -Iblib/lib -e "use strict; use warnings; use warnings::register;
sleep 100"
3= perl -Iblib/lib -e "use Win32::GUI::Constants (); sleep 100"
4= perl -Iblib/lib -e "use Win32::GUI::Constants qw(:common); sleep 100"
5= perl -Iblib/lib -e "use Win32::GUI::Constants qw(:common -inline);
sleep 100"
6= perl -Iblib/lib -e "use Win32::GUI::Constants qw(:all); sleep 100"
7= perl -Iblib/lib -e "use Win32::GUI::Constants qw(:all -inline); sleep
100"
Test 2 is, I think, the best baseline figure to use, and differences
below are calculated from this figure.
Raw results:
Test 1 2 3 4 5 6 7
Perl 5.6.1
Private Bytes 884 1412 1420 3448 3468 3486 11668
Working Set 1596 1912 1964 2448 2436 3704 4688
Perl 5.8.7
Private Bytes 504 744 808 1220 1212 2824 2888
Working Set 1720 2088 2152 2580 2588 4200 4268
From this description (http://www.itwriting.com/dotnetmem.php) I think
that the private bytes is the number of interest.
Differences between baseline (test 2) and tests 3-7, for Private bytes:
Test 3 4 5 6 7
delta 5.6.1 8 2056 2056 2056 10256
delta 5.8.7 64 476 468 2080 2144
So, on the face of it Win32::GUI::Constants costs us no more than 2MB of
memory for all constants exported and compiled under perl 5.8.7, but
costs about 10MB for the same scenario on perl 5.6.1. As I said, I'm
not sure how much you can really read into this, but make of it what you
want.
Regards,
Rob.
|
|
From: Robert M. <rm...@po...> - 2005-11-07 21:41:46
|
Glenn Linderman wrote:
>>
>> use Win32::GUI ();
>>
>> will not export anything, as you'd expect, and as happens today. I
>> think this is what Jez is already doing.
>
> I'm doing that. But I don't know about Jez. On the other hand, use
> Win32::GUI(); also turns off exporting of (non-constant) functions,
> which may not be desirable.
I am not aware that Win32::GUI exports any non-constant functions. Some
of the sub-classes appear to AUTOLOAD some functions (although I'm not
sure they actually do), but this should not be affected. Am I missing
something?
>>>>>> (4) What other groups of constants should we have?
>
> Hmm. With 350 names in :compatibility_win32_gui, more files might be
> needed. Maybe change Tags.pm
>
> sub tag {
> my $spec = shift;
>
> if(defined $TAG_SPECS{$spec}) {
> my @names = ();
> my @syms = keys(%$C);
> foreach my $patn (@{$TAG_SPECS{$spec}}) {
> push @names, grep(/$patn/, @syms);
> }
> return \@names;
> }
> + else {
> + $TAG_SPECS($spec) = <read-the-file-named-after-the-tag>;
> + my @syms = keys(%$C);
> + foreach my $patn (@{$TAG_SPECS{$spec}}) {
> + push @names, grep(/$patn/, @syms);
> + }
> + return \@names;
> + }
> return undef;
> }
>
> Sorry for the pseudo-code above, maybe it should be
>
> + require Win32::GUI::Constants::Tags::$spec;
> + $TAG_SPECS($spec) = $Win32::GUI::Constants::Tags::$spec::C;
>
Probably something like
eval "require Win32::GUI::Constants::Tags_$spec";
if($@) {
warnings::warnif qq(Failed to load definition for tag ':$spec': $@)
}
else {
$TAG_SPEC{$spec} = \@{"Win32::GUI::Constants::Tags_$spec::C"};
}
Although I'll not head down this route just yet - I'll add a comment to
the Tags.pm file.
Thanks for the feedback.
Regards,
Rob.
|
|
From: Robert M. <rm...@po...> - 2005-11-07 20:48:37
|
Glenn Linderman wrote: > from the keyboard of Robert May: >> Glenn Linderman: >>> Robert May: >>>> Glenn Linderman wrote: >> My intention is: >> - Win32::GUI::Constants will export nothing by default. >> - there will be a tag for the current set of symbols. Any suggestions >> for a name? > > :compatibility_set I've gone for :compatibility_win32_gui >> - When we move Win32::GUI to use this, for the first release it will >> continue to export the current set of symbols, but will raise a >> 'deprecated' warning. Future releases will export nothing. Release >> notes will document the changes. > > OK, but for Jez (and for migration/planning) we should add an option > that allows one to turn off the export of the current set of symbols, in > the first release of GUI that uses Constants. use Win32::GUI (); will not export anything, as you'd expect, and as happens today. I think this is what Jez is already doing. >>>> (4) What other groups of constants should we have? >> >> I think there is a need for some tags, as it's not always possible to >> do simple regexs for all the constants related to a topic. For >> example all toolbar related constants requires: >> >> ^BTNS_ >> ^TBSTATE_ >> ^TBSTYLE_ >> ^I_ > > Right, so that's an appropriate grouping. Your example leads to the > following idea: maybe each Win32::GUI::widget class should be examined > for the sets of constants that are relevant to the widget, and if there > is more than a single pattern required to get the set of constants, then > a tag with the widget name could be created. Even if there is only a single pattern (which I suspect is unlikely, given messages, styles, notifications etc.) then I think that we should have a :tag for each class to make life easy for quick prototyping. Of course, production code will probably want the constants listed explicitly, so that Tags.pm is not loaded, and for minimal overhead. > By defining %TAG_SPECS to be a hash of a list of patterns, you've kept > the definition size to a minimum, and the full list of names is only > generated if the tag is used. This is clever. So clever that I'm not > sure it needed to be an extra module, in the end, but having it is not a > problem either. Where there are patterns it works really well, but there are some tags that are not going to be small like this. For example :compatibility_win32_gui is 350 odd constants, and must be an exact match, even if more constants get added to this module in the future, as otherwise we'll start invoking re-definition errors on people's code where they have a 'sub' or 'use constants' definition for something that wasn't there before. Also the 'stock objects' for GetStockObject() can't be matched by a nice pattern. > And it is clever enough that I won't suggest folding the code that is in > Tags.pm back into Constants.pm and having a separate module for each > individual tag, so that only the tag lists that are actually used need > to be loaded, because the patterns, and even sets of patterns, are > extremely small. Additional modules for each (or some of) the tags may be something to consider, once we see how big Tags.pm gets. > Tags.pm line 24: "use use" should be "for use" > Constants.pm line 91: "implemenation" is missing a "t" > Constants.ps line 107: "pargmata" should be "pragmata" > Constants.ps line 131: "like" should be "likely" > Constants.ps line 198: "and" should be "an" Thanks, got that. I'll work on a few more tags, then up the version to 0.01, and release it as experimental from my site. I'll try to fold it into Win32::GUI 1.04, assuming that I'll get 1.03 out soon. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-11-06 22:09:26
|
Glenn Linderman wrote: > from the keyboard of Robert May: >> Glenn Linderman wrote: > > An alternate would be Win32::Constant I think I'll stick with the Win32::GUI namespace for now. But I agree there is room for expanding the scope. >>>> My current prototype has about 1500 constants (and I think that's >>>> about a third of them from the main header files), and weighs in at >>>> 32KB. I've not made much effort at compression yet, but do have it >>>> down from the 75kb that it was at this morning. It's nearly all >>>> constant names and values, there's less than 100 lines of code. Find attached a second version (v0.00_02). I've split it into 3 modules: Win32::GUI::Constants - the main code Win32::GUI::C - a helper package that sets up the hash with the constants, autogenerated during the build process from Constants.pl Win32::GUI::Tags - a helper package where we can define the :tag import symbols. This package only gets loaded if you use a :tag symbol, removing the size overhead, although the way I'm currently specifying the tags it may be that the overhead is not large. >> (1) Are there too many pragma, and will anyone understand them? >> (2) Does in intuitively do what you want? I.e. can you quickly and >> easily get access to the constants in a style that you like. > > Looks like you've supported my preferences, as well as others. Excellent. I guess my real question was do we think the default usage is easy enough for the average user? I don't see anything difficult or unexpected with use Win32::GUI::Constants qw( ...list of symbols... ); >> (3) What constants should be in the default set? I've put one in >> currently (CW_USEDEFAULT - which I find myself using in virtually >> every script I write). > > One school of thought would probably claim that for backwards > compatibility, all the constants currently defined in Win32::GUI should > be in the default set... but actually, that should be Win32::GUI's > responsibility to define and import that set (unless we choose to break > backwards compatibility, which I wouldn't mind, and Jez probably > wouldn't mind, given the size issue that results from all those > constants--but if we do, we should document it loudly, and provide an > easy way to include that original set of constants (or a slight superset)). My intention is: - Win32::GUI::Constants will export nothing by default. - there will be a tag for the current set of symbols. Any suggestions for a name? - When we move Win32::GUI to use this, for the first release it will continue to export the current set of symbols, but will raise a 'deprecated' warning. Future releases will export nothing. Release notes will document the changes. >> (4) What other groups of constants should we have? > > Because of the regularity MS has used to name their groups of constants > with fixed prefixes, the pattern matching may suffice. One should > probably point out that it is better to > > use Win32::GUI::Constants ( '/^TPM_*/' ); > than > use Win32::GUI::Constants ( '/^TPM*/' ); > or > use Win32::GUI::Constants ( '/TPM*/' ); I think you mean to have '.*' on the end of each of these, although it is not necessary. use Win32::GUI::Constants qw( /^TPM_ ); is sufficient. I've put something about this in the docs. I think there is a need for some tags, as it's not always possible to do simple regexs for all the constants related to a topic. For example all toolbar related constants requires: ^BTNS_ ^TBSTATE_ ^TBSTYLE_ ^I_ See Tags.pm for how I've done this specific example > Do %C and %EXPORT_TAGS each need to be "our" for some reason, or would > "my" work, to help hide them? %EXPORT_TAGS no longer exists. %C has become $C (a hash ref now), and I have made it a my variable. It had been our, as I hadn't determined if it was needed by an inheriting module. > Constants.pm lines 149 and > 150, and similar lines that would be needed to define any other tag > classe, result in another (potentially) large array of names being > generated. These particular lines at least share the ASCII names of the > keys, but still have the overhead of a second array pointing at those > names. This could possibly be avoided, by expanding the block at lines > 65-67 to be larger, and contain module-specific explicit code for > initializing @names for each particular :tagname supported. [Such > couldn't be done in the more general Exporter.] This would even > eliminate the need for %EXPORT_TAGS altogether... unless it just turns > out to be the best way to define some of the tags. [Line 76 could be > rewritten as keys(%C).] Nice ideas - led me to the separate module approach, that only gets loaded if a :tag symbol is found. > Constants.pl could contain, or could read in, Constants.pm, and then > emit the "minimum space constant list" directly at the end of the code, > rather than requiring a manual paste. Yes, that wasn't complete. Constants.pl now generates Win32::GUI::Constants::C module as a part of the build process. > In Constants.pm line 46 (at least, maybe also line 45) might should be > moved to right after line 42, so that the sequence -exportpkg => > -inline => 'Win32::GUI' isn't improperly interpreted vs -exportpkg => > -autoload => 'Win32::GUI' It had been my intention that the namespace had to immediately follow the -exportpkg pragma. I've moved the logic around to enforce this, and documented it. So -exportpkg => -autoload => 'Win32::GUI' is not legal, and would try to export to the '-autoload' namespace, except that 'Win32::GUI' is not a defined symbol, so will throw an error. > I guess because the module is named Win32::GUI::Constants rather than > Win32::Constants, that it is not inappropriate to find within the module > the constants that match /^WIN32__GUI__*/ These are there because they are in the current GUI_Constants.cpp, and we will need then in GUI.pm once that is removed. Perhaps they shouldn't be exportable? Regards, Rob. |
|
From: Jeremy W. <jez...@ho...> - 2005-11-06 20:47:21
|
>>Can anyone point me at modules/tools that let me look at how much memory >>my module is using? > >The only easy thing I can mention is the total process size as reported in >the "Mem Usage" column of the Processes tab in Windows Task Manager. It is >kind of a rough measure, but one could certainly distinguish Jez's issue at >that level of granularity. Yeah, I use Windows Task Manager - it's fine for tracking basic memory usage and other tasks such as spotting resource leaks etc. Out of curiosity, will this be included in version 1.03? Or in 1.04? Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-11-03 22:48:41
|
Glenn Linderman wrote:
> On approximately 11/1/2005 8:51 AM, came the following characters from
> the keyboard of Jeremy White:
>>
>>>> If the Win32::GUI::Constant package is a XS/C code we'll be able to
>>>> come up with various algorithms that compress the text strings
>>>> meaning the resulting dll could be relatively small.
The more I think about it the more I like a pure perl solution. Most of
the techniques for space saving can be applied to pure perl too.
Perhaps most attractive to me about a pure perl approach is the ability
to use a perl hash for fast lookup, rather than having to (re)invent our
own in C. Having looked at how the Exporter module works, we should be
able to have our own implementation that would use less memory than the
current implementation before adding the GUI_Constants.cpp overhead.
I'm most of the way to a proof of concept implementation that I'll share
as soon as I have something stable.
>>> But that imports the name into the current package, which is true
>>> namespace clutter, and using bare-name constants from the current
>>> package don't reflect the origin of the constant, and using the
>>> fully-qualified name anyway to reflectt the origin of the constant is
>>> extremely long.
>>
>> I think that's what Win32::GUI does now, it pollutes each name space
>> if Win32::GUI () is used - hence I was loosing around 100k per package.
>
> Hmm. I thought that "use Win32::GUI ();" avoided the exports that are
> done by "use Win32::GUI;"
Current implementation:
use Win32::GUI;
Imports *all* the currently defined constants into the calling
namespace: i.e. the symbol table (stash) gets an entry for each constant
containing a reference to the corresponding symbol table entry in the
Win32::GUI package. So, as well as cluttering the namespace of the
calling package it also clutters the namespace of Win32::GUI *AND* uses
lots of symbol table entries, taking up memory. AUTOLOADing is used to
save compile time (and memory: only constants that are actually used get
subroutine bodies), at the expense of some run time (compiling must
happen the first time any constant is used), and the inability to allow
the compiler to inline the constants, requiring a subroutine call each
time a constant is referenced.
In this case you can use bareword constants (either plain ES_WANTRETURN
or Win32::GUI::ES_WANTRETURN)
use Win32::GUI ();
Imports nothing into the calling namespace, saving symbol table entries
in both the calling and Win32::GUI namespaces. AUTOLOADing has the same
advantages and disadvantages, but fully qualified constants must be used
with parenthesis to allow the compiler to know that it is a subroutine
call (otherwise it will be treated as a bareword: i.e. treated as an
error under strict pragma, or as a string if not. So in the calling
package you write Win32::GUI::ES_WANTRETURN();
You can, or course, do
use Win32::GUI qw( ES_WANTRETURN );
to import just ES_WANTRETURN into both calling and Win32::GUI symbol
tables, affording reduced namespace clutter and reduced memory usage,
whilst adding the advantages (if you see them that way) of being able to
use barewords for constants listed this way.
> I'm not 100% sure how all this mechanism works either, I'm glad Rob
> clearly understands it better, and it does sound like there are some
> issues, and although he doesn't currently believe we can have our cake
> and eat it too, I'm willing to keep some somewhat educated and somewhat
> uneducated discussion going to see if it helps him discover a different
> flavor of cake that perhaps we could both have and eat :)
I've done some background. If you want to get into this I thoroughly
recommend the Exporter module docs, the 'Constant Subroutines' and
'AutoLoading' sections from perlsub.
I've also had a good trawl through Exporter.pm and Exporter/Heavy.pm.
I'm sure I don't understand it all yet, but definitely understand more
than I did 24 hours ago.
Flavours of cake, and eating it all:
There's really no right way to do everything that I wanted to achieve,
and it all comes down to a trade-off between speed at compile time vs.
speed at run time. Memory usage doesn't really come into it (except for
controlling how many entries get into the various symbol tables) as
memory usage for the autoloaded subroutines is always used (assuming you
use a constant) - it's just a question of when the memory gets used.
So, I'm working on the following:
(1) A separate module (currently Win32::GUI::Constants, but I'm open to
suggestions). I like this for 2 reasons: (1) If you don't want it you
don't use it, removing some bloat from your distributable. (2) From a
maintenance point of view it's easier to have the functionality
separated. (I'll address Glenn's issue with longer namespace in a moment)
(2) An import syntax that follows the Exporter module's syntax. Everyone
should be at least somewhat familiar with this - If you've never read
about it's capabilities then read the docs - I didn't know about the
regex and negation options to select which symbols to import.
I'll think about classes (e.g. :toolbar :all), as I don't think most
people will want to list each constant individually - it's only an issue
if you really want to tune for memory usage.
Following precedent that I've seen in the CGI module there will be some
import tokens that act as pragmata:
-inline - will sacrifice compile time speed to create the constant
functions at compile time (when the use statement is issued). This
allows the compiler to see the subroutine body and inline the constants,
increasing runtime speed by avoiding subroutine calls at runtime.
-noexport - will similarly sacrifice compile time speed, autoloading the
subroutines for inlining, but without exporting the constants. This
will reduce caller namespace clutter (and symbol table entries) and
allow bareword usage of Win32::GUI::Constants::SYMBOL_NAME, while also
allowing inlining of the constants.
(3) I see no reason why we couldn't subsequently use/require
Win32::GUI::Constants from within Win32::GUI and allow Win32::GUI to
have the same use statement semantics, although there will be some
symbol table overhead. In fact I see this as a necessary migration
step, so we don't break existing scripts. (we probably need a
':original' import class that exports the current set of symbols that is
used by default when/if we change Win32::GUI)
>> The advantage of having a separate package/dll is that if you dont
>> want to use it, you dont have to - this could become an important
>> issue if the constant code becomes large (especally if it's generated
>> automatically via the headers).
Right. My current prototype has about 1500 constants (and I think
that's about a third of them from the main header files), and weighs in
at 32KB. I've not made much effort at compression yet, but do have it
down from the 75kb that it was at this morning. It's nearly all
constant names and values, there's less than 100 lines of code.
> If the groups of constants are separately importable via the imports
> list in the use statement, then the only size cost would be the DLL
> size, correct? (except for constants you actually want to import and
> use, and pay the extra space for) And I suspect with a good algorithm,
> that wouldn't be large compared to the size of Win32::GUI itself.
> Measurements will tell the tale. I'd be pretty disappointed to have to
> use really long names like
> Win32::GUI::Constant::Windows_Names_Are_Long_Enough_Already but maybe
> there would be the possibility that Win32::GUI::Constant could actually
> export the names into the Win32::GUI namespace? As an option, of course.
Indeed, I had independently though of this. There is an overhead for
this though (as both Win32::GUI and Win32::GUI::Constants will have
symbol table entries. If you're happy will the current subroutine call
per constant reference at runtime, then it would be possible to get
Win32::GUI's AUTOLOAD to delegate directly to Win32::GUI::Constants, but
there's a (small) speed penalty for this. In this case a true trade-off
between speed and memory usage.
>>> Importing exactly the constants used (per your first example) into
>>> the local namespace would (I guess) allow the performance speedup of
>>> inlined constants, which May may like.
Inlining has little to do with which namespace holds the symbol
reference. To inline the subroutine must have an empty prototype (i.e.
be defined as sub SYMBOL_NAME() { ... } ), and the subroutine body must
have been seen by the compiler as suitable for inlining before the
compiler sees the subroutine call. See perldoc perlsub.
Watch this space.
Regards,
Rob.
|
|
From: Jeremy W. <jez...@ho...> - 2005-11-02 08:43:19
|
Hi, All these modules are now in the Win32-GUI source repository: http://cvs.sourceforge.net/viewcvs.py/perl-win32-gui/ Cheers, jez. |
|
From: Jeremy W. <jez...@ho...> - 2005-11-01 16:51:34
|
>>If the Win32::GUI::Constant package is a XS/C code we'll be able to come >>up with various algorithms that compress the text strings meaning the >>resulting dll could be relatively small. > >But that imports the name into the current package, which is true namespace >clutter, and using bare-name constants from the current package don't >reflect the origin of the constant, and using the fully-qualified name >anyway to reflectt the origin of the constant is extremely long. I think that's what Win32::GUI does now, it pollutes each name space if Win32::GUI () is used - hence I was loosing around 100k per package. >So if all this could be achieved with Win32::GUI::Constant, why could it >not be achieved with Win32::GUI directly? The advantage of having a separate package/dll is that if you dont want to use it, you dont have to - this could become an important issue if the constant code becomes large (especally if it's generated automatically via the headers). >Importing exactly the constants used (per your first example) into the >local namespace would (I guess) allow the performance speedup of inlined >constants, which May may like. I think so too - but I'm not 100% sure:) Cheers, jez. |
|
From: Jeremy W. <jez...@ho...> - 2005-11-01 10:19:23
|
>We wouldn't _need_ to change the algorithm, but if we do generate from >(say) a flat file of constants (or something more sophisticated, like the >Windows header files), the potential for using more constants in a program >is larger, and a better algorithm, while it won't change the run time of >the program, will improve startup times (rather than making it worse when >adding large numbers of constants). It should be changed, but the focus shouldn't be on it persay, but on the bigger picture so to speak. If a solution to constants is to be found, it'll be a compromise on performance, memory and ease of use - and the devil will be in the details:) In my case, my main app comes in a 5.32 MB as the final exe, and once it's started it uses 50 meg - before it's even done anything! Increasing the size of the GUI.dll, or adding some constant dll of say 200K would be nothing for this application. Would it still be the case for a simple script? Even if we're talking about increasing the size by a much larger number does it really matter if the solution is efficient and works well? Personally, I would always sacrifice memory for a tangible increase in performance - but I know other people who say otherwise:) Cheers, jez. |
|
From: Jeremy W. <jez...@ho...> - 2005-11-01 09:41:31
|
I assume you would end up with something like: use Win32::GUI::Constant qw (ES_WANTRETURN with a big list of other constants that you want); With the Constant package creating the passed list of constants in the callers namespace? You could also have: use Win32::GUI::Constant qw (all); #all the constants! use Win32::GUI::Constant qw (common); #just the common ones use Win32::GUI::Constant qw (toolbar); #constants associated with the toolbar control If the Win32::GUI::Constant package is a XS/C code we'll be able to come up with various algorithms that compress the text strings meaning the resulting dll could be relatively small. Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-10-31 19:22:24
|
Jeremy White wrote: >>> There are two main reasons to use SetEvent: >>> >>> 1) To add NEM events to windows/controls after they have been created >>> - perhaps by a 3rd party tool (such as Loft) which isn't NEM aware. >>> 2) To change the event handlers during runtime. >>> >>> In both cases, the expectation should be that the control is now >>> running under NEM only - just as if the control was created with NEM >>> event handlers in the first place. >> >> I don't follow this logical step. If a tool that is not NEM aware >> generates code, that presumably relies on OEM events being fired, and >> then I add so code that uses SetEvent(), your proposal would stop any >> existing OEM event handlers from being fired, even if for a different >> event. > > My poor explanation. The tool wouldn't be responsible for generating the > event handlers, just creating the window. For example, if you wanted to > use Loft (or any GUI builder) and NEM, then you would use Loft to create > the window and add the events later. Basically, I would have thought it > would be valid to separate the step of creating a window, and > associating events to it? OK, I'm with you now. >>> If these assumptions are correct - and I could be wrong - shouldn't >>> the approach be to simply turn off the OEM for a control that uses >>> SetEvent? Even if the object was created with -eventmodel => 'both' ? >> I can't see that that is the right approach. If the object is created >> to use OEM, then SetEvent can have no idea whether there are actually >> OEM event handlers that need to be called. It does, however, know >> that after it is called there is at least one NEM handler to call. So >> all it can do is turn on the NEM flag. If you don't want OEM events >> fired, then ensure they are turned off when the object is created by >> setting at least one NEM handle, or by using the -eventmodel option. > > Ok - if this is correct, then adding an event with SetEvent, shouldn't > first call the NEM handler and still call the OEM handler for a single > event. This is a bug. Returning 1 from the added NEM handler to stop > this happening would be none standard. > >> I guess I'm arguing that what's there is correct. Comments? > > I can understand your point of view - and to some extent I agree with > it. The issue is how to control the event model of a object post it's > creation - there is no way to do this at the moment. I would have > thought that using SetEvent would have explicitly changed event modes. > As a compromise how about this: > > * SetEvent logic stays the same OK > * The bug where 2 events are called for the same event when using > SetEvent is fixed I don't know how to fix this. Within the event handler we don't know whether the OEM and NEM flags have been set explicitly or not. Are you suggesting that we shouldn't be testing the return value from the NEM handler before looking for the OEM handler? > * A new method is added, which when called forces the object into NEM mode (untried) Doesn't $window->Change( -eventmodel => 'byref' ); already do this? Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-10-31 19:21:42
|
Jeremy White wrote: > My 2 cents. > >>> SW_* constants are not defined in GUI_constants.cpp (nor exported in >>> GUI.pm). In general there are many constants missing. > > Constant handling is, and will be a pain to get right. See below. > Personally, I > don't like the way Win32::GUI exports all it's constants by default - > it's a huge waste of memory. I create separate packages for each window, > and I used to have "use Win32::GUI" at the top of each package to get > access to the constants. From memory, this added around 100K per package > where Win32::GUI was used. When using constants I now use the full name, > i.e., Win32::GUI::WS_CLIPCHILDREN. I'm with you on this one. Glenn is correct that the way it is currently done using AutoLoad saves on compile time, as the subs are only created (eval'ed) on first use, however, he misses the point that every exported variable creates an entry in the exporting namespace's stash. As you say this is a huge waste of memory. > Using autoload to bring in the constants dynamically, is an alternative > solution but all the constant strings will have to be in the dll - and > if we're talking about adding *all* the constants, the dll could become > quite large... And it's already too big! I am personally convinced that a separate module is the way to go. I have not decided yet if a pure perl implementation would do, or whether an XS implementation is necessary for speed. > I'm not sure what the best solution is. Personally, I would prefer if no > more constants where exported as a default (unless they are commonly > used), but adding them to GUI_constants.cpp is fine by me. I'd personally prefer neither at the moment (except, as you say, for common ones). > I also like the idea of generating GUI_constants.cpp automatically from > (say) a flat file of constants - it would certainly make adding > constants easier! Even if we end up having thousands of autoloaded > constants, I don't think we would need to change the current algorithm > (even though it's far from optimal) as autoloader only needs to do the > look up once for each constant used. I actually started looking at something like this a couple of weeks ago when there were a large number of constants that I wanted to use that were not available. I have some prototype code, but there are still problems that I want to see if I can address: Primarily I want constants to be inlined for speed. In order for this to happen the subroutine must have been seen by the compiler before it sees the constant in your code, so that it knows that it can be inlined; however, if we are autoloading the subroutines, then they are not compiled until the eval happens at run time - so they are not inlined. A possible way around this is to not use Exporter, but to write our own import() function that does the eval on the constants being exported - the downside of this is compile time overhead for each exported constant, regardless of whether it is used or not. Additionally, using the constants as Win32::GUI::Constant::ES_WANTRETURN (i.e. not exporting them) would never be inlined. There are also differences between perl 5.6.1 and 5.8.x that I haven't managed to work around yet. It seems we can't have our case and eat it in this case. I will look further into this at a future date. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-10-31 19:04:28
|
Jeremy White wrote:
>> Jeremy White wrote:
>>
>>> Just done some performance testing with this type map:
>>>
>>> if(SvROK($arg)) {
>>> SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
>>> if(out != NULL)
>>> $var = ($type) SvIV(*out);
>>> else
>>> $var = NULL;
>>> } else
>>> $var = ($type) SvIV($arg);
>>>
>>> Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap...
>>> NewTypeMap: 29 wallclock secs (29.64 usr + 0.06 sys = 29.70 CPU) @
>>> 33666.63/s (
>>> n=1000000)
>>> OldTypeMap: 38 wallclock secs (38.22 usr + 0.02 sys = 38.23 CPU) @
>>> 26154.05/s (
>>> n=1000000)
>>
>> I'm no typemap expert, but don't see anything wrong with that.
>> Indeed, only doing the hv_fetch once seems like an obvious
>> improvement. If you can hold onto the code until after the next
>> release, then we can get it into CVS for the following release?
>
> No problem - there may be one issue. This code was compiled via Mingw,
> and as I'm declaring SV** out within a block of code, VC will complain.
> This may have been the reason that two hash reads were needed. I've a
> copy of VC now, so once the current build is out of the way, I'll do
> more testing.
I'm no C expert either, but I think it was always OK (C89 spec) to
declare variables at the start of a block. (I think it was the C99 spec
that allowed you to declare a variable anywhere). I think if it
compiles with your somewhat old version of MinGW we'll be OK with VC98.
We'll try it once the next release is out of the way.
Regards,
Rob.
|
18 messages has been excluded from this view by a project administrator.
