[26543] in Perl-Users-Digest
Perl-Users Digest, Issue: 8687 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 19 09:05:29 2005
Date: Sat, 19 Nov 2005 06:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 19 Nov 2005 Volume: 10 Number: 8687
Today's topics:
Apparent bug in 5.8 wrt tied scalars <sdn.girths00869@zoemail.net>
Re: Win32::GUI: Issues, Accessibility, Clipboard (part <rm@nospam.popeslane.clara.co.uk>
Re: Win32::GUI: Documentation, Layout and accessability <rm@nospam.popeslane.clara.co.uk>
Re: Win32::GUI: Documentation, Layout and accessability <vtatila@mail.student.oulu.fi>
Re: Win32::GUI: Documentation, Layout and accessability <rm@nospam.popeslane.clara.co.uk>
XML Parsing too slow with XML::Simple (jabby)
XML Parsing too slow with XML::Simple (jabby)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 19 Nov 2005 07:15:27 -0600
From: "Eric J. Roode" <sdn.girths00869@zoemail.net>
Subject: Apparent bug in 5.8 wrt tied scalars
Message-Id: <Xns9713542B3A43Bsdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Good morning, (well, it's morning in the USA)
In the past month, three bugs have been reported in my Readonly
module, except that they turned out not to be bugs in the module, but
(sadly) bugs in Perl 5.8. The pure-perl version of Readonly relies
on tied variables, which appear to have various colorful and
intermittent bugs.
I have not reported these via the usual way (perlbug), because at
the current time, I do not have access to a machine that can send
mail to the outside world. So I'm posting it here in the hopes that
a) someone who maintains perl will see it, or b) someone will perlbug
it.
Here is a short program that illustrates bug #1:
sub foo::TIESCALAR { bless {value => $_[1]}, $_[0] }
sub foo::FETCH { $_[0]->{value} }
tie my $test, 'foo', 'test';
print "$test$test\n";
This prints "testp\cX\c@" or other similar garbage. The first
interpolation prints fine; the second is reminiscent of a
non-NUL-terminated C string.
Oddly, with a longer string:
sub foo::TIESCALAR { bless {value => $_[1]}, $_[0] }
sub foo::FETCH { $_[0]->{value} }
tie my $test, 'foo', 'I snort the nose, Lucifer!';
print "$test$test\n";
it prints "I snort the nose, Lucifer!I snort the nose, Lucifer!" as
you'd expect. Also, if there is a space, or any other character,
between the two variables in the interpolation:
print "$test $test\n";
there is no buggy behavior.
Here is a short program that illustrates bug #2:
use warnings;
sub foo::TIESCALAR { bless {}, shift }
sub foo::FETCH { return 2 }
tie my $test, 'foo';
my $bits = 3 & ~$test;
This gives the warning
Use of uninitialized value in 1's complement (~) at....
Finally, the mysterious Bug #3:
sub foo::TIESCALAR { bless {value => $_[1]}, $_[0] }
sub foo::FETCH { $_[0]->{value} }
tie my $VAR, 'foo', 'SEARCH';
foreach my $var ($VAR)
{
print +($var eq $VAR) ? 'yes' : 'no';
}
This prints "no".
Amusingly, change the "print" line to:
print +(lc $var eq lc $VAR) ? 'yes' : 'no';
and it prints "yes".
I had several friends try out the code I posted above for "bug
#1". Two people had perl 5.6.1, and that did not exhibit the buggy
behavior. All others had various forms of 5.8.x (where x ranged from
0 to 7), on various platforms (Windows, linux, FreeBSD, MacOSX,
cygwin/2000, cygwin/XP). All 5.8.x users exhibited the buggy
behavior.
Any insight the users of this group can shed on this problem
would be greatly appreciated.
Thank you,
- --
Eric
`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32) - WinPT 0.7.96rc1
iD8DBQFDfyWUY96i4h5M0egRAmqUAJ4gk+BG2pBjEIJiN1/MTW2rdmxlMwCgpkF8
i0fyS60LX6NVzOCU0ceHzLw=
=0xYi
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 19 Nov 2005 02:14:39 +0000
From: Rob <rm@nospam.popeslane.clara.co.uk>
Subject: Re: Win32::GUI: Issues, Accessibility, Clipboard (partially OT)
Message-Id: <EPKdndEgRvUPF-PeRVnytg@pipex.net>
A. Sinan Unur wrote:
>>Rob wrote:
>>>That documentation is very old. Updated (official) docs can be found
>>>at: http://perl-win32-gui.sourceforge.net/docs/
>
> I got a 404 when I tried that page.
>
> http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi
>
> seems to work.
Sinan,
Thanks for the heads up. Both urls now work.
I must also apologise to you and Sisyphus for mis-quoting you as him
up-thread. No offence to either of you intended.
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
------------------------------
Date: Sat, 19 Nov 2005 02:04:11 +0000
From: Rob <rm@nospam.popeslane.clara.co.uk>
Subject: Re: Win32::GUI: Documentation, Layout and accessability
Message-Id: <ZcmdnY-EJ9KDFePeRVnyrA@pipex.net>
Veli-Pekka Tätilä wrote:
> Rob wrote:
>>Updated (official) docs can be found at:
>>http://perl-win32-gui.sourceforge.net/docs/
As Syphius points out later in the thread
http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi
is the correct link. I'd got ahead of myself, and was on the TODO list
to get /docs to return those pages. Both now work equally well.
> Hey, you saved my day by pointing this out. I mean, I don't know hhow I've
> managed to miss them but for a long long time I thought my WIn32::GUI
> installation carried out with PPM didn't come with the docs.
There have certainly been some PPM releases in the past that didn't
include any html docs (or for that matter most of the POD docs). I hope
that I've fixed the build process so that doesn't happen again. It is
also my intention to keep the on-line docs up to date with the latest
release.
[Talking about Layout managers]
>>There's the (very) basic Win32::GUI::GridLayout.
>
> Thanks, I'll check the docs. But I'll also be lazy and fire up a quick
> question asking if it is similar to Java's Grid layout? That is a
> rectangular grid of equal-sized controls.
It's a rectangular grid. You can set column and row width/height,
although IIRC the default is for equal-sized columns and rows (window
width/height divided by number of columns/rows). There have been some
recent additions that allow for percentage widths/heights to be set, but
I'm not am my regular PC right now, and can't check if that got into the
latest release, or whether it's due for the next one (V1.03 should be
released this weekend, hopefully).
>>>you don't seem to be able to pull in dialogs from resource files
>>
>>No, you can't do this, although if you want to raise a feature request
>><snip>
>
> I think I might. That support with event handling would rock. Though I
> haven't used the mouse too much and need to design with heavy full-screen
> magnification, which is slow, I still prefer dragging and dropping
> conponents in a dialog graphically. That is at least if it is a static
> dialog.
I've never experimented with it, but there's a Win32::GUI graphical
design environment (written in Win32::GUI as far as I know) called the
GUI Loft: See http://user.bahnhof.se/~johanl/perl/Loft/
Although I don't think it allows for drag/drop.
>>>where to get the exact font metrics that can be used to write
>>>resolution, font and DPI independent code avoid it.
>>
>>Me too.
>
> Ah. again glad to hear this is a recognized problem. Petzold seems to use
> functions like
> GetSystemMetrics and GetTextMetrics. Maybe these two and the related
> functions could be used possibly by importing them using Win32::API.
Both these functions are already available
http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-methods#getsystemmetrics
- the 1.04 release should have the full set of SM_* constants available,
for now you'll need to find them from elsewhere.
http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=font#getmetrics
- I'll not vouch for the correctness of the values though: I've not
looked at the Win32::GUI::Font code yet, and recall that there are some
outstanding bug reports in this area.
[Moving onto threads]
>>I can't comment in Win32::OLE.
> Well, I've noticed that if you load OLE and try to create two or more
> threads the whole of Perl will crash. I asked in the Win32 list and it is a
> known problem with no Perl-only solution.
As I said, I can't comment on Win32::OLE, but for Win32::GUI if you know
how many threads you are going to need, and spawn them all early (before
creating any Win32::GUI objects, or delay loading Win32::GUI using an
eval "use Win32::GUI" statement after spawning the threads), then
Win32::GUI can be used in a single thread to run your gui, with other
threads doing the work. If you fail to do this, then windows crashes
when threads terminate (presumably due to destruction on the Win32::GUI
objects that have been copied to the other thread, although
investigation of this is another TODO).
I found the following article very enlightening:
http://www.perlmonks.org/?node_id=288022
>>try to address some of the accessibility issues that you raised with
>>Win32::GUI - in particular with Win32::GUI::Grid IIRC.
>
> Hmm I don't exactly recall this instance. I think I've mostly been
> complaining about TK.
My mistake. I do have some of your accessibility mails filed, but they
are all about Tk. I have some other reports of dialog navigation
(particularly 'tab' navigation) not working as expected with
Win32::GUI::GridLayout - although not a core module we've recently taken
ownership of the source for this, so I hope to resolve the issue (time
permitting).
> If you can point me to sample code or real world apps that use the most of
> WIn32::GUI I could evaluate the keyboard and screen reader usability if
> you'd like. I've done similar things before, reporting bits and pieces that
> are inaccessible and giving a list of possible work-arounds.
I can't share most of the application code that I have currently, but
hope to be extending the sample code that gets distributed with the
module. If you'd be happy for me to contact you then I'd appreciate
accessibility feedback. It may be some time before I have anything in a
state that's worth you spending time on though. In the meantime, if you
do come across any accessibility issues with Win32::GUI, please raise
bug reports through either the perl-win32-gui@users.sourceforge.net list
or the sourceforge tracker system.
>>To get back on topic, the OP may find the Win32::Clipboard package
>>useful
>
> I've used that module succesfully. I'm not sure about the unicode support,
> either. But I've never really gotten the WaitForChange function to work as
> expected so I've been manually polling for changes. Maybe I'm missing
> something in the docs. Here's a simple test app:
>
> use strict; use warnings;
> use Win32::Clipboard;
> my $clip = Win32::Clipboard->new();
> for(;;)
> { # Infinite loop for testing purposes.
> $clip->WaitForChange();
> print 'Got: ', $clip->GetText(), "\n";
> } # for
>
> When I run this, it prints the previous clipboard contents on the screen
> even if the contents have not changed since the beginning of the program.
> not only that but it seems to freeze in the WaitForChange method the second
> time even if I copy more text in the clipboard.
It will always print the current contents of the clipboard on start-up.
It seems to work OK for me, printing new clipboard contents as I copy
test from my editor to the clipboard (AS Perl 5.8.7(build 813),
Win32::Clipboard v0.5101, Win98SE)
Regards,
Rob.
------------------------------
Date: Sat, 19 Nov 2005 14:55:22 +0200
From: "Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi>
Subject: Re: Win32::GUI: Documentation, Layout and accessability
Message-Id: <dln7c5$ock$1@news.oulu.fi>
Rob wrote:
> Veli-Pekka Tätilä wrote:
> There have certainly been some PPM releases in the past that didn't
> include any html docs
Yep, I recall reading something to that effect. Well, I've just updated all
PPM packages lately and now I have all the GUI docs I need. Really speeds up
navigation when you've got the HTML content locally. At least the old,
out-dated docs were very slow to access even on broadband (VDSL).
> [Talking about Layout managers]
> It's a rectangular grid. You can set column and row width/height,
> although IIRC the default is for equal-sized columns and rows
Ah, good to know the dimensions can be changed. Java's GridLayout also let's
you specify the number of rows and columns as well as the horizontal and
vertical grid gaps but that's about it. I've always thought a grid layout
would be cool for making a calculator.
>> still prefer dragging and dropping conponents in a dialog graphically.
> I've never experimented with it, but there's a Win32::GUI graphical
> design environment (written in Win32::GUI <sip>
> http://user.bahnhof.se/~johanl/perl/Loft/
I'll give it a shot. I've also seen some XML based design tool for
Win32::GUI but the name escapes me. I do have VC6 here, so I thought of
using its resource editor for the dialogs and possibly menus, too. That's
why I'd be interested in loading resource files and attaching Win32::GUI
event handlers to the loaded controls.
>> GetSystemMetrics and GetTextMetrics. Maybe these two and the related
>> functions could be used possibly by importing them using Win32::API.
> Both these functions are already available
> http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-methods#getsystemmetrics
> for now you'll need to find them from elsewhere.
Oh ok. I do have the headers so that's not an issue. I think I might be able
to create font-independent code then. But I'll keep your warnings about
remaining bugs in mind.
> [Moving onto threads]
> As I said, I can't comment on Win32::OLE <sip>
> Win32::GUI can be used in a single thread to run your gui, with other
> threads doing the work.
Again this is good news to me. Too bad I'm using OLE heavily and it won't
work with threads currently. Well, that's just how it is.
> I found the following article very enlightening:
> http://www.perlmonks.org/?node_id=288022
Thanks for pointing this out. I haven't realized interpreter based threads
are this heavy. Also, it says that forking is fast but I think it is fast
only in Unix. I recall reading somewhere that the behavior is emulated in
Win32 which may be slow. This is just a gut feeling, I' not a thread guru
nor hav I run the benchmarks.
[speaking of accessibility]
> have some other reports of dialog navigation (particularly 'tab'
> navigation) not working
In addition to any bugs in Win32::GUI, one reason might be that the person
doing the code has not specified the WS_TABSTOP style for the controls.
Without this style they won't be part of the tab order in the dialog, at
least in the Win32 API. That is you cannot set the keybord focus to such
controls by using [shift+] tab.
While being excluded from the tab order may be desirable for some types of
controls such as group boxes, generally you should always include say
enabled check boxes, radio buttons, lists and trees in the tab order
(disabled controls are automagically excluded). If you don't, and there's no
shortcut, the keyboard user canot access that control without using a screen
reader specific mouse emulation mode. Even if a control is not in the tab
order, however, it can still receive keyboard messages provided that it has
the focus somehow.
Maybe the Win32::GUI could add certain controls in the tab order
automatically. My rationale is that these controls ought to be in the tab
order in the first place and the user wouldn't have to memorize putting them
there. Not being in the tab order, for something like buttons, is the
exception rather than the rule.
Another thing that often goes awry is enter not being equivalent to ok and
esc to cancel. But at least in the Win32::API this is a result of correct
message handling and setting default buttons etc... The equivalent actions
are wel documented in Win32::GUI so we've got just the lib users to blame, I
guess. I cannot think of a good way to specify a default button
automatically. MAybe the first inserted button in the dialog, if none is
specified. And cancel should be the second because most dialogs start with
OK and Cancel in the very bottom in this order. YOu can also layout buttons
on the right, in which case ok is the top-most and has the cancel button
below it. Or this style is expected by most users, at least.
How's the default tab order for Win32::GUI is it the insertion order? I
think many graphical tools use the insertion order and thus you often get an
illogical tab sequence if the designer has tweaked the controls afterwords,
removing some and adding others. Programmatically, going through the
controls from top to bottom, left to right and respecting group boxes could
be a sufficient default.
> If you'd be happy for me to contact you then I'd appreciate
> accessibility feedback.
I'd be glad to, as soon as you have something to test. My e-mail address is
the same as in the signature that is:
vtatila@mail.student.oulu.fi
Probably not an issue but please don't post in HTMl as I've got
spam_Assassin set real strict.
> do come across any accessibility issues with Win32::GUI, please raise
> bug reports through either the perl-win32-gui@users.sourceforge.net list
> or the sourceforge tracker system.
Will do. I'll be lazy and ask what the subscription address is for the
former?
[clipbord bugs?]
>> use strict; use warnings;
>> use Win32::Clipboard;
>> my $clip = Win32::Clipboard->new();
>> for(;;)
>> { # Infinite loop for testing purposes.
>> $clip->WaitForChange();
>> print 'Got: ', $clip->GetText(), "\n";
>> } # for
>> prints the previous clipboard contents on the screen even if the
>> contents have not changed since the beginning <snip> seems to freeze in
>> the WaitForChange method the second time even if
>> I copy more text in the clipboard.
> It will always print the current contents of the clipboard on start-up.
Ok, seems I need to check it initially, as I wouldn't want to destroy the
user's current clipboard contents, either.
> It seems to work OK for me <snip> Perl 5.8.7(build 813),
> Win32::Clipboard v0.5101, Win98SE)
It would appear not to work for me but I've got a different setup:
-Win32::Clipboard V0.5101
-Perl 5.8.6
-Win XP SP2 Pro English
--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/
------------------------------
Date: Sat, 19 Nov 2005 13:29:36 +0000
From: Rob <rm@nospam.popeslane.clara.co.uk>
To: =?ISO-8859-1?Q?Veli-Pekka_T=E4til=E4?= <vtatila@mail.student.oulu.fi>
Subject: Re: Win32::GUI: Documentation, Layout and accessability
Message-Id: <437F28C0.50208@nospam.popeslane.clara.co.uk>
Veli-Pekka Tätilä wrote:
> Rob wrote:
>>Veli-Pekka Tätilä wrote:
[Win32 design environments]
>>I've never experimented with it, but there's a Win32::GUI graphical
>>design environment (written in Win32::GUI <sip>
>>http://user.bahnhof.se/~johanl/perl/Loft/
>
> I'll give it a shot. I've also seen some XML based design tool for
> Win32::GUI but the name escapes me.
WGX - http://www.numeninest.com/Perl/WGX/
>>[Moving onto threads]
>
>>I found the following article very enlightening:
>>http://www.perlmonks.org/?node_id=288022
>
> Thanks for pointing this out. I haven't realized interpreter based threads
> are this heavy. Also, it says that forking is fast but I think it is fast
> only in Unix.
Correct. Forking in windows is emulated using ithreads.
> [speaking of accessibility]
>
>>have some other reports of dialog navigation (particularly 'tab'
>>navigation) not working
>
> In addition to any bugs in Win32::GUI, one reason might be that the person
> doing the code has not specified the WS_TABSTOP style for the controls.
I had a quick look at this one myself when the report was raised. It
appears that either the Win32::GUI wrapper or the underlying control
that is used is not honouring the WS_TABSTOP style correctly.
> Maybe the Win32::GUI could add certain controls in the tab order
> automatically. My rationale is that these controls ought to be in the tab
> order in the first place and the user wouldn't have to memorize putting them
> there. Not being in the tab order, for something like buttons, is the
> exception rather than the rule.
I'll add this to my list of things to think about. My immediate
reaction would be that designing an algorithm that *always* does
something sensible would be hard. Such an algorithm should be looking
at adding WS_TABSTOP and WS_GROUP styles.
> Another thing that often goes awry is enter not being equivalent to ok and
> esc to cancel. But at least in the Win32::API this is a result of correct
> message handling and setting default buttons etc... The equivalent actions
> are wel documented in Win32::GUI so we've got just the lib users to blame, I
> guess. I cannot think of a good way to specify a default button
> automatically. MAybe the first inserted button in the dialog, if none is
> specified. And cancel should be the second because most dialogs start with
> OK and Cancel in the very bottom in this order. YOu can also layout buttons
> on the right, in which case ok is the top-most and has the cancel button
> below it. Or this style is expected by most users, at least.
Again, getting it right automatically would be hard, but there are some
interesting ideas there.
> How's the default tab order for Win32::GUI is it the insertion order? I
> think many graphical tools use the insertion order and thus you often get an
> illogical tab sequence if the designer has tweaked the controls afterwords,
> removing some and adding others. Programmatically, going through the
> controls from top to bottom, left to right and respecting group boxes could
> be a sufficient default.
The order is defined by the win32 api as the control creation order,
which in Win32::GUI is the object creation order.
>>do come across any accessibility issues with Win32::GUI, please raise
>>bug reports through either the perl-win32-gui@users.sourceforge.net list
>>or the sourceforge tracker system.
>
> Will do. I'll be lazy and ask what the subscription address is for the
> former?
http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
Regards,
Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/
------------------------------
Date: Sat, 19 Nov 2005 07:26:42 -0600
From: krising@gmail-dot-com.no-spam.invalid (jabby)
Subject: XML Parsing too slow with XML::Simple
Message-Id: <SdadnTQ6M66PteLeRVn-hg@giganews.com>
I have some files ranging from 6 meg to 15 meg that I need to process
to input into a database. I'm inheriting some old code using
XML::Simple and this process is taking forever (an hour or more). I
have eliminated the database as the time hog in this equation.
is there an alternative XML module I should be using?
Sent via Archivaty.com
------------------------------
Date: Sat, 19 Nov 2005 07:26:43 -0600
From: krising@gmail-dot-com.no-spam.invalid (jabby)
Subject: XML Parsing too slow with XML::Simple
Message-Id: <SdadnTc6M66OteLeRVn-hg@giganews.com>
I have some files ranging from 6 meg to 15 meg that I need to process
to input into a database. I'm inheriting some old code using
XML::Simple and this process is taking forever (an hour or more). I
have eliminated the database as the time hog in this equation.
is there an alternative XML module I should be using?
Sent via Archivaty.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8687
***************************************
