Re: wxTimer problem

2014-10-20 Thread Steve Cookson

Hi Eric,

On 20-10-2014 06:37, Erik Colson wrote:

I checked the archives and at first sight your prob is Windows
related. Am I correct in this, or did you try Linux too ?

The crash started a long time ago, but it was a compile problem on Kubuntu.

I can try again to see if it is still there.

Regards

Steve.


Re: wxperl: svn to git

2014-10-20 Thread Steve Cookson
You see, if the wxTimer problem has gone away and Mark has upgraded svn 
to 3.0.1, then the only one we need is 3.0.2.


Even here, the patch file contains two updates, one to fix the 
validation in Build.PL and the other for a null data/patch file. Maybe 
even that is not required, in which case we only have the validation of 
the Build.PL file.


A much smaller task and less prone to error.

What do you think?

Regards

Steve.


On 19-10-2014 23:21, Erik Colson wrote:

Steve Cookson steve.cook...@sca-uk.com writes:


3.0.1 - Does this conflict with Mark has applied?

Did you look at Mark's most recent svn patch for 3.0.1?  Is it any
different from mine?  I'll look when I get a chance: this is going to
be a busy couple of weeks.

nope I didn't check both. However I corrected a small bug in the bugfix
branch.


3.0.2 - No problem.

Nothing more to say.

:)


- wxTimer wrapping changes.  Without the changes, I get a crash, with
them I get a run-time warning. I prefer the warning, but it is still
not perfect.

I recall you also had an issue here.  Did you get it all working
without any errors?  What did you do?

Can't remember I had an issue. I do have code using timers and that
works nicely. Do you have a small script which shows your prob ?

best




Re: Install Script Feedback

2014-10-20 Thread Steve Cookson - gmail

Hi James,

Thanks for putting it out there.  And great response.

My comments follow.

Steve.

On 20-10-2014 18:20, James Lynes wrote:



I got the following feedback from posting the install script on Perl 
Monks.


Any thoughts? Willing to keep it updated as needed.

I see 3.0.2 is available. Is it in the svn repository?

At the time of writing it is not there.  Look here to check:

http://sourceforge.net/p/wxperl/code/HEAD/tree/

If you look at my earlier emails, you can find a script which points to 
my own github repo with 3.0.2 in it.


James



I think that a couple of improvements can be made there.

First of all,

find /usr | grep -i wx | grep -v -i python | grep -v -i soffice 
rm_w+x.sh # | Collect wx files. Exclude wxpython, and soffice
files sed -i -e 's/\/usr\//rm -rf \/usr\//g' rm_wx.sh
[download]

http://perlmonks.org/?abspart=1;displaytype=displaycode;node_id=1104254;part=1

This looks scary and will break the packages installed in the system. 
For example, wxmaxima, a frontend to a symbolic calculation system 
written in LISP, will be deleted (but the package will be still marked 
installed). MCabber, a jabber client not related to Perl or Wx in any 
way, is going to get damaged, too.
It's true, it is dangerous.  When I'm running and re-running it, it is 
more important to me that I don't have to do a total rebuild each time, 
but we should try to refine this part of the script to make it safer for 
users.  If your Perl Monk has any ideas we could incorporate them.

Manual cleanups should be done only in /usr/local;

I don't know about this, if that is true we could make it:

find /usr/local

instead.
other parts of /usr belong to dpkg. Perhaps feeding the output of the 
command to dpkg -S and removing the packages it finds is a better 
idea, but you still need a way to filter the package names which 
should not be deleted (perhaps removing only packages with names 
matching 'lib*' will help for a start?).


Also, you can save on the child processes by using find expressions 
instead of grep: find /usr -iwholename '*wx*' \! \( -iwholename 
'*python*' -o -iwholename '*soffice' \) should produce the same output 
(and you can also use -iname instead of -iwholename to filter file 
names only).



It takes a few seconds out of 45 minutes, I don't think it is significant.


Another two relatively unimportant things are that you ask the users 
to create a Perl directory in their ~, but don't use it much and 
download wxPerl and Alien-wxWidgets in the ~ instead


You can update the wxPerl and Alien-wxWidgets directories to 
~/Perl/wxPerl and ~/Perl/wxPerlAlien-wxWidgets if you think is neater.


and that you can save a lot of time on apt-get startup if you merge 
all apt-get install commands into one.


I agree.  It's a trade-off between readability and execution.  Your 
format is more readable, but the merged format is easier to manipulate. 
Again, I'm not sure that the total execution time is much faster.  I 
don't mind which course we take.





My response:

aitap:

Thank you for your reply. I'll get back to the original author and see 
if we can improve the find section. The rm_wx.sh script is saved, so I 
will take a look and see what was deleted unintentionally. The cleanup 
commands would not be needed for a new install. For me, it was 
visually easier to keep the apt-get commands separate as I was merging 
several scripts and cross checking between them to make sure I didn't 
miss anything. The Perl directory is where I put the install script 
and other install files. The user is free to customize to their 
installation.


James





Re: Install Script Feedback

2014-10-20 Thread James Lynes
Steve:

I need to read-up on find before I can make an intelligent comment. And
also need to look at the rm_wx.sh script in detail.

I'll add add a reference to http://sourceforge.net/p/wxperl/code/HEAD/tree/;
to the notes for checking on the current version of things. I did see the
3.0.2 reference to your github repo.

I like moving to ~/Perl/wxPerl and ~/Perl/wxPerlAlien-wxWidgets as opposed
to creating home level directories. Will make that change. The rm script
should go there too.

I like readability over execution on the apt-gets. This whole process is
quick enough for me.

James


On Mon, Oct 20, 2014 at 1:55 PM, Steve Cookson - gmail 
steveco.1...@gmail.com wrote:

  Hi James,

 Thanks for putting it out there.  And great response.

 My comments follow.

 Steve.

 On 20-10-2014 18:20, James Lynes wrote:



  I got the following feedback from posting the install script on Perl
 Monks.

  Any thoughts? Willing to keep it updated as needed.

  I see 3.0.2 is available. Is it in the svn repository?

 At the time of writing it is not there.  Look here to check:

 http://sourceforge.net/p/wxperl/code/HEAD/tree/

 If you look at my earlier emails, you can find a script which points to my
 own github repo with 3.0.2 in it.


  James


 

 I think that a couple of improvements can be made there.

 First of all,

 find /usr | grep -i wx | grep -v -i python | grep -v -i soffice  rm_w+x.sh   
  # | Collect wx files. Exclude wxpython, and soffice files
 sed -i -e 's/\/usr\//rm -rf \/usr\//g' rm_wx.sh
 [download] 
 http://perlmonks.org/?abspart=1;displaytype=displaycode;node_id=1104254;part=1

  This looks scary and will break the packages installed in the system. For
 example, wxmaxima, a frontend to a symbolic calculation system written in
 LISP, will be deleted (but the package will be still marked installed).
 MCabber, a jabber client not related to Perl or Wx in any way, is going to
 get damaged, too.

 It's true, it is dangerous.  When I'm running and re-running it, it is
 more important to me that I don't have to do a total rebuild each time, but
 we should try to refine this part of the script to make it safer for
 users.  If your Perl Monk has any ideas we could incorporate them.

   Manual cleanups should be done only in /usr/local;

 I don't know about this, if that is true we could make it:

 find /usr/local

 instead.

   other parts of /usr belong to dpkg. Perhaps feeding the output of the
 command to dpkg -S and removing the packages it finds is a better idea,
 but you still need a way to filter the package names which should not be
 deleted (perhaps removing only packages with names matching 'lib*' will
 help for a start?).

 Also, you can save on the child processes by using find expressions
 instead of grep: find /usr -iwholename '*wx*' \! \( -iwholename
 '*python*' -o -iwholename '*soffice' \) should produce the same output
 (and you can also use -iname instead of -iwholename to filter file names
 only).

 It takes a few seconds out of 45 minutes, I don't think it is significant.

   Another two relatively unimportant things are that you ask the users to
 create a Perl directory in their ~, but don't use it much and download
 wxPerl and Alien-wxWidgets in the ~ instead

 You can update the wxPerl and Alien-wxWidgets directories to ~/Perl/wxPerl
 and ~/Perl/wxPerlAlien-wxWidgets if you think is neater.

   and that you can save a lot of time on apt-get startup if you merge all
 apt-get install commands into one.

 I agree.  It's a trade-off between readability and execution.  Your format
 is more readable, but the merged format is easier to manipulate. Again, I'm
 not sure that the total execution time is much faster.  I don't mind which
 course we take.



 

 My response:

 aitap:

 Thank you for your reply. I'll get back to the original author and see if
 we can improve the find section. The rm_wx.sh script is saved, so I will
 take a look and see what was deleted unintentionally. The cleanup commands
 would not be needed for a new install. For me, it was visually easier to
 keep the apt-get commands separate as I was merging several scripts and
 cross checking between them to make sure I didn't miss anything. The Perl
 directory is where I put the install script and other install files. The
 user is free to customize to their installation.

 James





Re: Install Script Feedback

2014-10-20 Thread James Lynes
Steve:

I reviewed rm_wx.sh. All the deleted files came from sub-directories of:
   /usr/local/lib
   /usr/local/bin
   /usr/local/share

Specifically sub-directories of:
   usr/local/lib/perl/5.18.2/
   usr/local/lib/perl/5.18.2/Wx/
   usr/local/lib/perl/5.18.2/auto/
   usr/local/lib/perl/5.18.2/auto/Wx/
   usr/local/lib/perl/5.18.2/auto/share/dist/
   usr/local/lib/perl/5.18.2/auto/Alien/
   usr/local/lib/perl/5.18.2/auto/Alien/wxWidgets/
   usr/local/lib/perl/5.18.2/Alien/
   usr/local/lib/perl/5.18.2/Alien/wxWidgets/
   /usr/local/bin/
   /usr/local/share/perl/5.18.2/
   usr/local/share/perl/5.18.2/Wx/
   usr/local/share/man/man3/
   ust/local/share/man/man1/

I don't see where any unrelated packages were effected. It seems that it
would be prudent to begin the find at /usr/local/.

James



On Mon, Oct 20, 2014 at 2:48 PM, James Lynes jmlyne...@gmail.com wrote:

 Steve:

 I need to read-up on find before I can make an intelligent comment. And
 also need to look at the rm_wx.sh script in detail.

 I'll add add a reference to 
 http://sourceforge.net/p/wxperl/code/HEAD/tree/; to the notes for
 checking on the current version of things. I did see the 3.0.2 reference to
 your github repo.

 I like moving to ~/Perl/wxPerl and ~/Perl/wxPerlAlien-wxWidgets as opposed
 to creating home level directories. Will make that change. The rm script
 should go there too.

 I like readability over execution on the apt-gets. This whole process is
 quick enough for me.

 James


 On Mon, Oct 20, 2014 at 1:55 PM, Steve Cookson - gmail 
 steveco.1...@gmail.com wrote:

  Hi James,

 Thanks for putting it out there.  And great response.

 My comments follow.

 Steve.

 On 20-10-2014 18:20, James Lynes wrote:



  I got the following feedback from posting the install script on Perl
 Monks.

  Any thoughts? Willing to keep it updated as needed.

  I see 3.0.2 is available. Is it in the svn repository?

 At the time of writing it is not there.  Look here to check:

 http://sourceforge.net/p/wxperl/code/HEAD/tree/

 If you look at my earlier emails, you can find a script which points to
 my own github repo with 3.0.2 in it.


  James


 

 I think that a couple of improvements can be made there.

 First of all,

 find /usr | grep -i wx | grep -v -i python | grep -v -i soffice  rm_w+x.sh  
   # | Collect wx files. Exclude wxpython, and soffice files
 sed -i -e 's/\/usr\//rm -rf \/usr\//g' rm_wx.sh
 [download] 
 http://perlmonks.org/?abspart=1;displaytype=displaycode;node_id=1104254;part=1

  This looks scary and will break the packages installed in the system.
 For example, wxmaxima, a frontend to a symbolic calculation system written
 in LISP, will be deleted (but the package will be still marked installed).
 MCabber, a jabber client not related to Perl or Wx in any way, is going to
 get damaged, too.

 It's true, it is dangerous.  When I'm running and re-running it, it is
 more important to me that I don't have to do a total rebuild each time, but
 we should try to refine this part of the script to make it safer for
 users.  If your Perl Monk has any ideas we could incorporate them.

   Manual cleanups should be done only in /usr/local;

 I don't know about this, if that is true we could make it:

 find /usr/local

 instead.

   other parts of /usr belong to dpkg. Perhaps feeding the output of the
 command to dpkg -S and removing the packages it finds is a better idea,
 but you still need a way to filter the package names which should not be
 deleted (perhaps removing only packages with names matching 'lib*' will
 help for a start?).

 Also, you can save on the child processes by using find expressions
 instead of grep: find /usr -iwholename '*wx*' \! \( -iwholename
 '*python*' -o -iwholename '*soffice' \) should produce the same output
 (and you can also use -iname instead of -iwholename to filter file names
 only).

 It takes a few seconds out of 45 minutes, I don't think it is significant.

   Another two relatively unimportant things are that you ask the users
 to create a Perl directory in their ~, but don't use it much and
 download wxPerl and Alien-wxWidgets in the ~ instead

 You can update the wxPerl and Alien-wxWidgets directories to
 ~/Perl/wxPerl and ~/Perl/wxPerlAlien-wxWidgets if you think is neater.

   and that you can save a lot of time on apt-get startup if you merge
 all apt-get install commands into one.

 I agree.  It's a trade-off between readability and execution.  Your
 format is more readable, but the merged format is easier to manipulate.
 Again, I'm not sure that the total execution time is much faster.  I don't
 mind which course we take.



 

 My response:

 aitap:

 Thank you for your reply. I'll get back to the original author and see if
 we can improve the find section. The rm_wx.sh script is saved, so I will
 take a look and see 

[rt.cpan.org #99607] Issue using wxTextEntryBox

2014-10-20 Thread Patrick via RT
Mon Oct 20 19:52:16 2014: Request 99607 was acted upon.
Transaction: Ticket created by pwnbusiness2...@centurylink.net
   Queue: Wx
 Subject: Issue using wxTextEntryBox
   Broken in: (no value)
Severity: (no value)
   Owner: Nobody
  Requestors: pwnbusiness2...@centurylink.net
  Status: new
 Ticket URL: https://rt.cpan.org/Ticket/Display.html?id=99607 


Hello, 

I was attempting to use a wxTextEntryBox object in my application and I ran 
into a little issue. 

I'm using Wx 0.9923 and Strawberry Perl v. 5.16.3 (built for 
MSWin32-x86-multi-thread) under Windows XP 32-bit SP3. It think the WxWidgets 
install is v. 3.0.0. 

The following is the code: 

#!/usr/bin/env perl 

use warnings; 
use strict; 
use Wx qw(:everything); 


package MyFrame; 

use base 'Wx::Frame'; 

sub new { 

my $ref = shift; 
my $self = $ref-SUPER::new( undef, 
1, 
'Parent Window', 
Wx::wxDefaultPosition, 
[500, 500], 
); 
my $panel = Wx::Panel-new( $self, 
2 
); 
my $dialog = Wx::TextEntryDialog-new( $panel, 
'Please Enter Text', 
'Dialog Header', 
, 
Wx::wxOK|Wx::wxCANCEL, 
Wx::wxDefaultPosition 
); 

return $self; 
} 

package MyApp; 

use base 'Wx::App'; 

sub OnInit { 

my $frame = MyFrame-new; 

$frame-Show( 1 ); 

} 

package main; 

my $app = MyApp-new; 
$app-MainLoop; 

When I launch this code from the command prompt in a command window and then 
exit the program normally (using the red X in the upper right hand side of 
the window), the window closes, but the program does not terminate. I have to 
use Control+C to get the command prompt to return and I get the message 
Terminating on signal SIGINT(2). If I comment out the call to the new 
method of the TextEntryDialog, the program will exit normally and the command 
prompt will be redisplayed with no error message. 

Thanks for your time. 

Patrick Nighswonger