RE: [wxperl-users] wxPerl and Perl 5.8 threads

[Marc M. A. <mm...@Do...>]

Build notes:

> > I was unable to link the XRC module for some reason.  I suspect some
> > inconsistency in the build process for wxWindows, but haven't
> sorted it out
> > yet.  Don't really care so much about it, just mentioning in passing.
> It'd be nice to discover why, how did you compile wxWIndows/wxPerl?
> What if you follow the updated build instructions at
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wxperl/wxPerl/docs/install.tx
t?rev=1.12&content-type=text/vnd.viewcvs-markup

Ah, well, that makes a BIG difference.  The install.txt file that comes with
the wxPerl 0.10 source archive doesn't have quite so much detail in it and I
didn't think to double-check online.  I was building via the IDE as well,
not using the command line (occasionally that is dangerous, as the makefile
isn't automatically generated).

So, OK, I loaded a fresh copy of Wx-0.10 source and started from scratch to
catch all my notes (which I had collected earlier and then lost):

When running Makefile.PL there are some GetOptions() variables that need to
be initialized in build/wxConfig.pm to get rid of some warnings:
	$extra_libs   = '';
	$extra_cflags = '';
Probably others as well, but these are the ones that made noise for me.
Obviously this isn't crucial.  There is also a warning:
	Subroutine MY::post_initialize redefined
		at C:/TEMP/Wx0.10/build/wxConfig.pm line 114.
which probably isn't going away.

I get an error regarding wxGetFontFromUser not being available.  In
XS/FontDialog.xs it is wrapped with #if WXPERL_W_VERSION_GE( 2, 3, 2 ).  I
have wxWindows 2.3.2 (from a development snapshot, not from CVS) but it
doesn't have wxGetFontFromUser, so I change the conditional to check for
2.3.3 and move on (I suppose I'll get around to downloading another snapshot
at some point).

Similarly for IsFixedWidth in GDI.C.  Changed 2.3.2 to 2.3.3 and moved on.

When I run the nmake test I get:

Failed Test       Stat Wstat Total Fail  Failed  List of Failed
---------------------------------------------------------------
t\1_load.t           2   512     1    1 100.00%  1
t\2_inheritance.t    2   512    ??   ??       %  ??
t\3_attr.t           2   512     1    1 100.00%  1

The error appears to be that it can't locate Wx/Grid.pm.  The Grid DLL is
built, but Grid.pm isn't in the path during the test.  Haven't dug any
deeper yet.

> > So all (or most) of the sample programs run.  The demo runs except for
> > whatever I had to comment out because XRC isn't there (I
> think).  All good.
> You should not need to comment anything out, BTW

Actually, I went back and re-ran this and there are a number of things not
connecting right now.  Wx::Help.pm and Wx::Html.pm aren't available for some
reason (didn't install?  depend on XRC?).  So I had to comment out a bunch
of stuff to get the demo to run at all.  Again, I haven't taken the time to
track this down.  I'm using WxPerl 0.10 (from a source download, not from
CVS).

I'm guessing this is similar to the issue with Grid.pm, as I can find
HTML.dll in the installed tree but not HTML.pm.

-----------------------------------------------------------------------

Usage (threading) notes:

> The problem here is that wxWindows expects threads to be worker threads;
> they should not create windows; they should communicate with the
> main thread
> via Wx::PostMessage (see the threads sample in the demo).

Well, this is what I figured...

> > Which naturally leads to the idea of posting  windows events
> > that are commands to create windows and so forth.  Which ends up looking
> > like an event-driven program and not a multi-threaded program.

...but that leaves me frustrated.  Not necessarily at WxPerl.  I think I'm
frustrated with the Perl 5.8 threading model (which is apparently the one
that is being implemented in Parrot for Perl 6).  It doesn't provide shared
data by default.  It may actually be implemented using threads, but it has
the user experience of using processes.  But that's a personal problem. ;)

I have to admit, it's been a while since I did any low-level GUI
programming.  I'm thinking that these problems may in fact be characteristic
of some of the environments I've had to use.  Seems to me I've had to do
exactly what you say...

> Well, if you have a long computation to run in the background, threads
> are a much better solution than a Wx::Timer or idle events...

...putting just the computations in the background and having all the actual
window-related stuff happen in the foreground.  Then again, I've used at
least one system where all window-related code could occur in any thread
(with suitable locking of code where necessary).

> I know Vadim Zeitlin (one of the core wxWindows developers) has a
wxGUIThread
> (a thread that can create windows and dispatch messages to them) in his
TODO
> since (at least) 2 years. Of course making it work in at least
> wxGTK (variuos UNIX flavours), wxMSW (Win32) and wxMac (OS9 hasn't
> preemptive thread, but OSX, AFAIK has), requires a lot of work.

You betcha.  I don't think that this applies to Perl, though, unless you're
going to write a wxPerl overlay that starts a wxGUIThread and then
instantiates a Perl interpreter within it.  Which I guess would be
possible...but you would still need to make all the window objects shared (I
think).

Ah, well, none of this is critical.  Just curious (as usual) as to what will
work and what won't.  The Perl 5.8 dev group wanted feedback on how the
release candidates were working and I thought that this might be an
interesting experiment.  I have not, as yet, sent them any feedback on this.

marc