From mario at ruby-im.net  Tue Apr  1 04:19:24 2008
From: mario at ruby-im.net (Mario Steele)
Date: Tue, 1 Apr 2008 03:19:24 -0500
Subject: [wxruby-development] MingW
In-Reply-To: <a4439dea0803312009n5b4823fdidda8e02298a5c251@mail.gmail.com>
References: <47ECD64A.4080600@pressure.to>
	<c2cd0d1d0803280936l39596e38mbc6e94a8f81e3c9@mail.gmail.com>
	<a4439dea0803281018l121543e7td79f9549250bd715@mail.gmail.com>
	<47ED300F.5010909@pressure.to>
	<a4439dea0803281103h75902f3dudaa952ed1bff4ecf@mail.gmail.com>
	<a4439dea0803300656s4b9ce9a0we9b7830dd0ec345f@mail.gmail.com>
	<47F0BC65.8090605@pressure.to>
	<a4439dea0803312009n5b4823fdidda8e02298a5c251@mail.gmail.com>
Message-ID: <a4439dea0804010119y1712a9e0veeaa34d24a147629@mail.gmail.com>

Hey Alex,

I've just committed revision 1648, which in rakemingw.rb will detect to see
if the user compiled from the build directory, by checking for
$WXDIR/lib/wx/include/msw-unicode-release-static-2.8/wx/setup.h, and if it
is not there, it'll check
$WXDIR/build/lib/wx/include/msw-unicode-release-static-2.8/wx/setup.h and
adjust $WXLIBDIR and $WXSETUPINCDIR accordingly.  I've been able to get STC
compiled in with wxRuby perfectly fine this way, and with the mods you did
as well.  I've just found some instructions on the web, for how to get
GDIPlus setup, and have ran through the instructions.  I'm now trying to
compile against wxWidgets with --enable-graphics_ctx, to see if that will
work.  If it does, I'll update NotesOnMingW with the new instructions on how
to enable ContextGraphics.

L8ers,
Mario Steele

On Mon, Mar 31, 2008 at 10:09 PM, Mario Steele <mario at ruby-im.net> wrote:

> Hey Alex,
>
> The modifications I did to rakemingw, isn't that much at all.  So it
> wouldn't be that complicated.  I've made it to the point, where your linking
> the object files together into the single lib, but it's erroring out, and I
> know why now, cause of the lib_mswu_stc.a not being created, I will look at
> fixing that, and add that to the rakemingw.rb, I don't see that this will
> be that big of a change, so I will get everything together, and see about
> committing it tonight/morning time.
>
> I'll let ya know.
> Mario
>
>
> On 3/31/08, Alex Fenton <alex at pressure.to> wrote:
> >
> > Mario Steele wrote:
> > > Also, I made some slight changes to rakemingw.rb, as I use the linux
> > > method of compiling wxWidgets, under the build directory, instead of
> > > the top level directory.  I have the mods, and will be committing them
> > > today when I get home, around 4:30 to 5:00 pm CST.
> > I found using the Windows method of compiling wxWidgets using
> > ./configure in the base directory of the install creates the stc library
> > file (lib_mswu_stc.a on my system) in the right place to start with. The
> > only error I had to work around is because the header file isn't found.
> >
> > I've just committed a patch to rake/rakemingw which should fix this and
> > STC now compiles cleanly. It assumes the Windows-style compile; if you
> > want to support Linux-style builds with mingw and it can be done without
> > making the rakefile too messy or breaking the other one, please do so.
> >
> > I updated the notes page a bit as well:
> > http://wxruby.rubyforge.org/wiki/wiki.pl?NotesOnMingW
> >
> > cheers
> > alex
> > _______________________________________________
> > wxruby-development mailing list
> > wxruby-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-development
> >
>
>
>
> --
> Mario Steele
> http://www.trilake.net
> http://www.ruby-im.net
> http://rubyforge.org/projects/wxruby/
> http://rubyforge.org/projects/wxride/
> http://rubyforge.org/projects/vwmc/
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080401/1058c813/attachment.html 

From alex at pressure.to  Tue Apr  1 05:08:36 2008
From: alex at pressure.to (Alex Fenton)
Date: Tue, 01 Apr 2008 10:08:36 +0100
Subject: [wxruby-development] MingW
In-Reply-To: <a4439dea0804010119y1712a9e0veeaa34d24a147629@mail.gmail.com>
References: <47ECD64A.4080600@pressure.to>	<c2cd0d1d0803280936l39596e38mbc6e94a8f81e3c9@mail.gmail.com>	<a4439dea0803281018l121543e7td79f9549250bd715@mail.gmail.com>	<47ED300F.5010909@pressure.to>	<a4439dea0803281103h75902f3dudaa952ed1bff4ecf@mail.gmail.com>	<a4439dea0803300656s4b9ce9a0we9b7830dd0ec345f@mail.gmail.com>	<47F0BC65.8090605@pressure.to>	<a4439dea0803312009n5b4823fdidda8e02298a5c251@mail.gmail.com>
	<a4439dea0804010119y1712a9e0veeaa34d24a147629@mail.gmail.com>
Message-ID: <47F1FB94.6050809@pressure.to>

Mario Steele wrote:
> I've just committed revision 1648, which in rakemingw.rb will detect 
> to see if the user compiled from the build directory, by checking for 
> $WXDIR/lib/wx/include/msw-unicode-release-static-2.8/wx/setup.h, and 
> if it is not there, it'll check
> $WXDIR/build/lib/wx/include/msw-unicode-release-static-2.8/wx/setup.h 
> and adjust $WXLIBDIR and $WXSETUPINCDIR accordingly.  I've been able 
> to get STC compiled in with wxRuby perfectly fine this way, and with 
> the mods you did as well.  I've just found some instructions on the 
> web, for how to get GDIPlus setup, and have ran through the 
> instructions.  I'm now trying to compile against wxWidgets with 
> --enable-graphics_ctx, to see if that will work.  If it does, I'll 
> update NotesOnMingW with the new instructions on how to enable 
> ContextGraphics.
Good stuff, thanks. Sorry to nag about this again, but please can you 
set your editor to indent with two real spaces when committing to 
existing files so the indentation doesn't get messed up.

alex



From mario at ruby-im.net  Wed Apr  2 02:13:08 2008
From: mario at ruby-im.net (Mario Steele)
Date: Wed, 2 Apr 2008 01:13:08 -0500
Subject: [wxruby-development] MingW
In-Reply-To: <47F1FB94.6050809@pressure.to>
References: <47ECD64A.4080600@pressure.to>
	<c2cd0d1d0803280936l39596e38mbc6e94a8f81e3c9@mail.gmail.com>
	<a4439dea0803281018l121543e7td79f9549250bd715@mail.gmail.com>
	<47ED300F.5010909@pressure.to>
	<a4439dea0803281103h75902f3dudaa952ed1bff4ecf@mail.gmail.com>
	<a4439dea0803300656s4b9ce9a0we9b7830dd0ec345f@mail.gmail.com>
	<47F0BC65.8090605@pressure.to>
	<a4439dea0803312009n5b4823fdidda8e02298a5c251@mail.gmail.com>
	<a4439dea0804010119y1712a9e0veeaa34d24a147629@mail.gmail.com>
	<47F1FB94.6050809@pressure.to>
Message-ID: <a4439dea0804012313x7ee11e2ay94ec68e2b3ccf413@mail.gmail.com>

Hey Alex,

On Tue, Apr 1, 2008 at 4:08 AM, Alex Fenton <alex at pressure.to> wrote:

> Good stuff, thanks. Sorry to nag about this again, but please can you
> set your editor to indent with two real spaces when committing to
> existing files so the indentation doesn't get messed up.
>
> alex
>

Yeah, sorry, I was using SciTE when editing it, and I have several
installations everywhere, I forget which ones have tabs fixed, and tabs
not.  I'll keep them fixed one way or another.  BTW, I have a bead on
GraphicsContext, and GDI+, however, it means some modifications to the
wxWidgets graphics.cpp file, in order to work with the modified headers for
GDI+ that are setup for MinGW Environment.  What is your opinion on this?
They are very minor patches, and just ensure that the work with the new
headers.  Oviously this will need to be noted on MinGW, but I'm not finished
yet testing, to see if the new patch will work with Compiling wxWidgets.

Let me know what you think about modifying wxWidgets source to work with the
MinGW'ized GDI+ Library.

L8ers,

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080402/d6c04f31/attachment.html 

From alex at pressure.to  Wed Apr  2 05:29:47 2008
From: alex at pressure.to (Alex Fenton)
Date: Wed, 02 Apr 2008 10:29:47 +0100
Subject: [wxruby-development] MingW
In-Reply-To: <a4439dea0804012313x7ee11e2ay94ec68e2b3ccf413@mail.gmail.com>
References: <47ECD64A.4080600@pressure.to>	<c2cd0d1d0803280936l39596e38mbc6e94a8f81e3c9@mail.gmail.com>	<a4439dea0803281018l121543e7td79f9549250bd715@mail.gmail.com>	<47ED300F.5010909@pressure.to>	<a4439dea0803281103h75902f3dudaa952ed1bff4ecf@mail.gmail.com>	<a4439dea0803300656s4b9ce9a0we9b7830dd0ec345f@mail.gmail.com>	<47F0BC65.8090605@pressure.to>	<a4439dea0803312009n5b4823fdidda8e02298a5c251@mail.gmail.com>	<a4439dea0804010119y1712a9e0veeaa34d24a147629@mail.gmail.com>	<47F1FB94.6050809@pressure.to>
	<a4439dea0804012313x7ee11e2ay94ec68e2b3ccf413@mail.gmail.com>
Message-ID: <47F3520B.9050903@pressure.to>

Mario Steele wrote:
> I have a bead on GraphicsContext, and GDI+, however, it means some 
> modifications to the wxWidgets graphics.cpp file, in order to work 
> with the modified headers for GDI+ that are setup for MinGW 
> Environment.  What is your opinion on this?  They are very minor 
> patches, and just ensure that the work with the new headers.  Oviously 
> this will need to be noted on MinGW, but I'm not finished yet testing, 
> to see if the new patch will work with Compiling wxWidgets.
Not a problem as far as I'm concerned. It's mainly for our purposes 
providing binary builds. The default build (without --graphics_ctx and 
without the modifications) should still work fine, yes?

It would be good to see if the patches are in WxWidget's tracker so it 
gets fixed in a later release.

thanks
alex


From dirk.traulsen at lypso.de  Sun Apr  6 11:18:09 2008
From: dirk.traulsen at lypso.de (Dirk Traulsen)
Date: Sun, 06 Apr 2008 17:18:09 +0200
Subject: [wxruby-development] minimal.rb
Message-ID: <47F905D1.19841.74485D2@dirk.traulsen.lypso.de>

Hi!

After updating to Ruby 1.8.6 Patchlevel 111 and WxRuby 1.9.5 on WinXP 
the minimal.rb sample stopped working.

It doesn't find wx:

C:\minimal>minimal.rb
C:/minimal/minimal.rb:10:in `load': no such file to load -- wx 
(LoadError)
        from C:/minimal/minimal.rb:10

The problem occures because of the use of 'load' instead of 'require' 
in the rescue clause. With 'require' it works.

As the one-click-installer on windows now also does no longer require 
rubygems automatically, why not simplify the beginning to:

============================================
--- minimal.rb  2008-04-06 10:23:48.859375000 +0200
+++ minimal_new.rb      2008-04-06 10:25:29.437500000 +0200
@@ -2,16 +2,8 @@
 # wxRuby2 Sample Code. Copyright (c) 2004-2006 Kevin B. Smith
 # Freely reusable code: see SAMPLES-LICENSE.TXT for details

-begin
-  require 'wx'
-rescue LoadError => no_wx_err
-  begin
-    require 'rubygems'
-    load 'wx'
-  rescue
-    raise no_wx_err
-  end
-end
+require 'rubygems'
+require 'wx'

 # This sample shows a fairly minimal Wx::App using a Frame, with a
 # MenuBar and StatusBar but no controls. For the absolute minimum app,
============================================

Oh and by the way:
Thank you for your effort to support the use of MingW. This is really 
good news! Especially if the result is even faster than with VisualC.

Regards,
Dirk

From mario at ruby-im.net  Sun Apr  6 15:43:36 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 6 Apr 2008 14:43:36 -0500
Subject: [wxruby-development] minimal.rb
In-Reply-To: <47F905D1.19841.74485D2@dirk.traulsen.lypso.de>
References: <47F905D1.19841.74485D2@dirk.traulsen.lypso.de>
Message-ID: <a4439dea0804061243x11ec3480kac5dd2113ebe469e@mail.gmail.com>

Hey Dirk,

On Sun, Apr 6, 2008 at 10:18 AM, Dirk Traulsen <dirk.traulsen at lypso.de>
wrote:

> Hi!
>
> After updating to Ruby 1.8.6 Patchlevel 111 and WxRuby 1.9.5 on WinXP
> the minimal.rb sample stopped working.


You will find that more then just minimal.rb is broken, there are several
examples where this bug crops up.  They will be fixed in time for the next
release.

As the one-click-installer on windows now also does no longer require
> rubygems automatically, why not simplify the beginning to:
>
> ============================================
> --- minimal.rb  2008-04-06 10:23:48.859375000 +0200
> +++ minimal_new.rb      2008-04-06 10:25:29.437500000 +0200
> @@ -2,16 +2,8 @@
>  # wxRuby2 Sample Code. Copyright (c) 2004-2006 Kevin B. Smith
>  # Freely reusable code: see SAMPLES-LICENSE.TXT for details
>
> -begin
> -  require 'wx'
> -rescue LoadError => no_wx_err
> -  begin
> -    require 'rubygems'
> -    load 'wx'
> -  rescue
> -    raise no_wx_err
> -  end
> -end
> +require 'rubygems'
> +require 'wx'


This would not work, cause if a person doesn't have rubygems installed, it
will throw an LoadError just as it would if wx was not found.  I prefer this
method of inclusion, simply cause you can have a newer version of wxRuby
installed to the site_ruby directory, then what is installed to the gems
directory (If your a compiler like us), and you may want to test the version
you just compiled, compared to the version that comes with ruby gems.
Unless someone else objects to this, I will opt to do something like:

begin
  requier 'rubygems'
rescue LoadError
end
require 'wx'

Oh and by the way:
> Thank you for your effort to support the use of MingW. This is really
> good news! Especially if the result is even faster than with VisualC.


It has been proven to be faster by about 20 to 30 percent.  I've been
talking with Luis as well to help get wxRuby going.  So far, we have
StyledTextCtrl, and GraphicsContext compiled in, we are pausing on getting
OpenGL and MediaCtrl at the moment, as a bug has cropped up, due to
Patchlevel 114 of Ruby and the GC Collection methods.  We want to nail this
down before moving any further.  Once we have that, then we'll continue
adding the other two classes to wxRuby.


Thanks for your continued support, and hopefully soon, we'll have a MinGW
based release out for people to use.

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080406/faf733fd/attachment.html 

From alex at pressure.to  Sun Apr  6 16:00:52 2008
From: alex at pressure.to (Alex Fenton)
Date: Sun, 06 Apr 2008 21:00:52 +0100
Subject: [wxruby-development] minimal.rb
In-Reply-To: <a4439dea0804061243x11ec3480kac5dd2113ebe469e@mail.gmail.com>
References: <47F905D1.19841.74485D2@dirk.traulsen.lypso.de>
	<a4439dea0804061243x11ec3480kac5dd2113ebe469e@mail.gmail.com>
Message-ID: <47F92BF4.6040500@pressure.to>

Hi Dirk, Mario

Mario Steele wrote:
>  Unless someone else objects to this, I will opt to do something like:
>
> begin
>   requier 'rubygems'
> rescue LoadError
> end
> require 'wx'
+1

cheers
alex

From dirk.traulsen at lypso.de  Tue Apr  8 00:57:13 2008
From: dirk.traulsen at lypso.de (Dirk Traulsen)
Date: Tue, 08 Apr 2008 06:57:13 +0200
Subject: [wxruby-development] minimal.rb
In-Reply-To: <a4439dea0804061243x11ec3480kac5dd2113ebe469e@mail.gmail.com>
References: <47F905D1.19841.74485D2@dirk.traulsen.lypso.de>,
	<a4439dea0804061243x11ec3480kac5dd2113ebe469e@mail.gmail.com>
Message-ID: <47FB1749.14063.F58C37D@dirk.traulsen.lypso.de>

Am 6 Apr 2008 um 14:43 hat Mario Steele geschrieben:

 > You will find that more then just minimal.rb is broken, there are
> several examples where this bug crops up.  They will be fixed in time
> for the next release. 

Excellent.

> This would not work, cause if a person doesn't have rubygems installed,
> it will throw an LoadError just as it would if wx was not found.  I
> prefer this method of inclusion, simply cause you can have a newer
> version of wxRuby installed to the site_ruby directory, then what is
> installed to the gems directory (If your a compiler like us), and you
> may want to test the version you just compiled, compared to the version
> that comes with ruby gems.  

So, there is obviously no need for rubygems in this case, right.

> Unless someone else objects to this, I will opt to do something
> like:
> 
> begin
>   requier 'rubygems'
> rescue LoadError
> end
> require 'wx'

I like it, It works and is still simpler than the original.
Just please don't copy and paste it directely from here: 
requier/require  :)

Regards,
Dirk


From mario at ruby-im.net  Thu Apr 10 05:39:54 2008
From: mario at ruby-im.net (Mario Steele)
Date: Thu, 10 Apr 2008 04:39:54 -0500
Subject: [wxruby-development] wxRuby
Message-ID: <a4439dea0804100239s537e56c3v1d5dc95f43db5304@mail.gmail.com>

Hey Alex, Sean and all the others,

I know we're looking towards doing a possible 1.9.6 release, and as me and
Alex discussed with the work towards using MinGW, that I personally would
like to hold off on doing a 1.9.6 release, till we get the current issue
with the Garbage Collection mark and sweep cleared out, as well as see about
possibly getting OpenGL and MediaCtrl working, to keep it on Par with the
MSVC version of wxRuby.

I also know that Alex said that he was looking to hopefully move to a 2.0
release by the end of releasing 1.9.6, but I see that with the option of
using MinGW opening up to us, that we may want to hold off on doing a 2.0
release for a while, till we can be sure that the MinGW version will work.
We can still go beyond 1.9.6 release, as we have pleanty of numbers to go
through past 1.9.9 (Look at Fox toolkit, with it's 1.6.18 scheme to see what
I mean).  The only reason why I bring this up, is the fact that with the
very strong possibility of the OCI going from MSVC to MinGW, people may end
up getting the latest OCI, with it being MinGW, and find that wxRuby doesn't
work.  I'd rather the Fox Toolkit run into that, then wxRuby.

Just my two cents, plus I'm still looking at possibly adding back wxSocket
classes, to wxRuby, since I'm becoming more comfortable with the Swig stuff,
and I want to add Sockets into wxRuby very very strongly.  Don't get me
wrong, I like the Ruby sockets, and they have gone a long way to keeping
things going on all three platforms.  At the same time, wxWidgets has the
same operability, with the bonus addition of it being Event Driven, instead
of Thread/Polling driven.  To all honesty of the fact, trying to
re-implement in Ruby, what's already available in wxWidgets, seems a bit
much like overkill.  I've not seen many posts online, concerning the
possible attacks against wxWidgets's socket implementation being bugged and
such, if you still have reservations about that Alex, could you point me to
them, so that I can look and see what is going on?  And weither it might
warrent the same problems on our side or not.

Again, these are just my feelings, and I'm not the only developer on the
team, so I wanted to see what you guys think about this as well.

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080410/1e45fd17/attachment.html 

From alex at pressure.to  Thu Apr 10 17:01:10 2008
From: alex at pressure.to (Alex Fenton)
Date: Thu, 10 Apr 2008 22:01:10 +0100
Subject: [wxruby-development] wxRuby
In-Reply-To: <a4439dea0804100239s537e56c3v1d5dc95f43db5304@mail.gmail.com>
References: <a4439dea0804100239s537e56c3v1d5dc95f43db5304@mail.gmail.com>
Message-ID: <47FE8016.6030008@pressure.to>

Hi Mario

Thanks for bringing this up. Overall, my view is that the greatest need 
is for a production version of wxRuby 2.0 with a guarantee of API and 
feature set, so that developers can develop against it with confidence. 
I think we've reached a level of stability that that's possible now, and 
I'd like to push for it asap.

Mario Steele wrote:
> I know we're looking towards doing a possible 1.9.6 release, and as me 
> and Alex discussed with the work towards using MinGW, that I 
> personally would like to hold off on doing a 1.9.6 release, till we 
> get the current issue with the Garbage Collection mark and sweep 
> cleared out,
Yep, we must fix the problem with mark_wxEvent. I can reproduce the 
crash with the sample you sent (only in MingW, not OS X, haven't tried 
VC) but currently cannot understand why it's happening.
> as well as see about possibly getting OpenGL and MediaCtrl working, to 
> keep it on Par with the MSVC version of wxRuby.
I agree these would be good to have, but I don't see these as blockers 
for the next release. Current stable wxPython doesn't support MediaCtrl 
with MingW, so it may not be so easy. However, it's likely that fixes 
here will be in the build system rather than the core library, so could 
be applied after 2.0.
> I also know that Alex said that he was looking to hopefully move to a 
> 2.0 release by the end of releasing 1.9.6, but I see that with the 
> option of using MinGW opening up to us, that we may want to hold off 
> on doing a 2.0 release for a while, till we can be sure that the MinGW 
> version will work. 
I think it's likely that the OCI will move to MingW, but I also think we 
can be pretty confident from our recent experiments that wxRuby will 
work. It's just combines a platfrom (Windows) and a compiler (gcc) which 
we've well tested already.
> Just my two cents, plus I'm still looking at possibly adding back 
> wxSocket classes, to wxRuby, since I'm becoming more comfortable with 
> the Swig stuff, and I want to add Sockets into wxRuby very very 
> strongly.  
OK, I think they would be nice to have, but not a vital feature for 2.0. 
It seems possible to build a range of socket-using apps already using 
ruby sockets and threads. I would prefer to spend time on polishing 
what's there - tidying and commenting the samples so they serve more 
like tutorials, writing more overviews in the docs, ensuring samples 
cover new-ish classes - than adding features that may be marginal for 
most apps. But of course it's not for me to tell anyone what to work on, 
and all contributions are welcome.

I'd like to see Sockets added to a 2.1.x or 2.9.x next development 
series which was more modular in design, and shared the SWIG runtime 
code. Then it would have no impact on library size.

I'm open to the views of other contributors and users on these topics.

alex



From mario at ruby-im.net  Mon Apr 14 22:25:55 2008
From: mario at ruby-im.net (Mario Steele)
Date: Mon, 14 Apr 2008 21:25:55 -0500
Subject: [wxruby-development] Swig 1.3.35
Message-ID: <a4439dea0804141925pefbe814lea33cd7878df5c46@mail.gmail.com>

Hey guys,

I just checked out Swig 1.3.35, and it works just fine with wxRuby.  Safely
can assume that we can upgrade to that.

L8ers,

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080414/4a90b23f/attachment-0001.html 

From alex at pressure.to  Tue Apr 15 18:07:00 2008
From: alex at pressure.to (Alex Fenton)
Date: Tue, 15 Apr 2008 23:07:00 +0100
Subject: [wxruby-development] Swig 1.3.35
In-Reply-To: <a4439dea0804141925pefbe814lea33cd7878df5c46@mail.gmail.com>
References: <a4439dea0804141925pefbe814lea33cd7878df5c46@mail.gmail.com>
Message-ID: <48052704.4050804@pressure.to>

Mario Steele wrote:
> I just checked out Swig 1.3.35, and it works just fine with wxRuby.  
> Safely can assume that we can upgrade to that.
Thanks for checking this out. Looks like there's no ruby-related changes 
in the SWIG changelog for that version. I'll update the rakefiles etc.

alex


From alex at pressure.to  Tue Apr 15 18:10:21 2008
From: alex at pressure.to (Alex Fenton)
Date: Tue, 15 Apr 2008 23:10:21 +0100
Subject: [wxruby-development] wxSugar 0.1.20
Message-ID: <480527CD.3050000@pressure.to>

Hi

Just to say I released a new version of wxSugar. This was mainly to have 
a release with a bugfix the layout.rb library.

There's some experimental code in there to convert XRC files to pure 
ruby which might be of interest. I hope in the next release we can get 
this integrated into the standard xrcise tool

cheers
alex

From noreply at rubyforge.org  Wed Apr 16 04:37:42 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 16 Apr 2008 04:37:42 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Bugs-19578 ] Potential memory leak
	with wxEvtHandler
Message-ID: <20080416083742.ECA92185862D@rubyforge.org>

Bugs item #19578, was opened at 2008-04-16 08:37
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19578&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: Potential memory leak with wxEvtHandler

Initial Comment:
When event handlers are defined, the Procs that are associated with the handler must be preserved from ruby's GC.

At the moment this is done in EvtHandler.i by adding the Proc to a global variable call rb_callbacks.

This means that the handler Procs are never destroyed, even when the associated EvtHandler object is gone. 

It would be better to preserve the Procs by associating them with an instance variable of the EvtHandler.

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

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19578&group_id=35

From noreply at rubyforge.org  Wed Apr 16 15:43:10 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 16 Apr 2008 15:43:10 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Bugs-19590 ] Shouldn't have to call
	XmlResource.init_all_handlers
Message-ID: <20080416194310.6D4561858656@rubyforge.org>

Bugs item #19590, was opened at 2008-04-16 19:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19590&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: Shouldn't have to call XmlResource.init_all_handlers

Initial Comment:
Let this be done automatically by wxRUby, as with images

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

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19590&group_id=35

From alex at pressure.to  Thu Apr 17 20:49:41 2008
From: alex at pressure.to (Alex Fenton)
Date: Fri, 18 Apr 2008 01:49:41 +0100
Subject: [wxruby-development] Proposal for an improved API for
 Sizer	(and ToolBar)
In-Reply-To: <ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>
References: <ca0724b20803180621i787fc3b3nc517730b4c6a9ec5@mail.gmail.com>	<47E15C0B.80408@pressure.to>	<ca0724b20803191322v786d03c9y1312e0806794181b@mail.gmail.com>
	<ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>
Message-ID: <4807F025.6040700@pressure.to>

Hi Chauk-Mean

Chauk-Mean P wrote:
> 2008/3/19, Chauk-Mean P <chauk.mean at gmail.com>:
>   
>> I will post a proposal for ToolBar tomorrow morning.
>>     
>
> First, I improved further the args_as_list method by checking that the
> keyword arguments supplied are valid ones.
>
> Regarding the new method ToolBar#add_item :

Just to mention that I added the ToolBarTool class to wxRuby so it's 
consistent with MenuItem and SizerItem. It makes the API easier in that 
you can say:

tool = tool_bar.add_tool(...)
evt_tool tool, :on_tool_action

I think the bulk of your proposal still stands, except no generate_id 
method is needed, and I think it should now return the ToolBarTool 
object. So I will still look to merge for the next release.

cheers
alex

alex





From noreply at rubyforge.org  Sat Apr 19 04:42:42 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 19 Apr 2008 04:42:42 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Bugs-19646 ] BusyCursor.busy doesn't
	restore cursor if leave block via rescue
Message-ID: <20080419084242.B8042185868A@rubyforge.org>

Bugs item #19646, was opened at 2008-04-19 08:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19646&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: BusyCursor.busy doesn't restore cursor if leave block via rescue

Initial Comment:
The normal cursor won't be restored if an exception is thrown and the block exits via rescue:

begin
BusyCursor.busy do

...
end
rescue

end

It would be better to add the static functions wxBeginBusyCursor and wxEndBusyCursor, and rewrite BusyCursor in pure ruby using these. Seems silly anyway to have a whole object file for this one function.

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

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19646&group_id=35

From noreply at rubyforge.org  Sun Apr 20 06:40:29 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 20 Apr 2008 06:40:29 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Feature Requests-19661 ] Make the
	constructor for AcceleratorTable a bit nicer
Message-ID: <20080420104029.796EB18585EF@rubyforge.org>

Feature Requests item #19661, was opened at 2008-04-20 10:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=221&aid=19661&group_id=35

Category: API improvement
Group: None
Status: Open
Priority: 3
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: Make the constructor for AcceleratorTable a bit nicer

Initial Comment:
Currently a lot of AcceleratorEntry objects have to be created by hand - let them be specified using a three-element array. Also perhaps allow unlimited list length of individual items?



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

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=221&aid=19661&group_id=35

From alex at pressure.to  Sun Apr 20 13:42:13 2008
From: alex at pressure.to (Alex Fenton)
Date: Sun, 20 Apr 2008 18:42:13 +0100
Subject: [wxruby-development] wxRuby and ruby 1.8.7
Message-ID: <480B8075.1040800@pressure.to>

Hi

Mario has been working on the MingW build and has been encountering a 
lot of crashes. It turns out it's not specific to MingW but rather to 
the new versions of Ruby, 1.8.7. With 1.8.7-preview2 on Linux too the 
whole thing becomes very unstable.

It seems that the ruby core developers have made some major changes to 
the way that GC is handled, and this has broken the GC marking stuff in 
wxRuby. I'm not sure at the moment whether the problem is in our code, 
or perhaps a problem with SWIG.

Anyway, my plan is to proceed with releasing wxRuby 1.9.6 in the next 
few weeks, but warn that it's not yet usable with 1.8.7.

alex

From mario at ruby-im.net  Sun Apr 20 14:24:03 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 20 Apr 2008 13:24:03 -0500
Subject: [wxruby-development] wxRuby and ruby 1.8.7
In-Reply-To: <480B8075.1040800@pressure.to>
References: <480B8075.1040800@pressure.to>
Message-ID: <a4439dea0804201124o56ca66f0t247795ec82541397@mail.gmail.com>

On Sun, Apr 20, 2008 at 12:42 PM, Alex Fenton <alex at pressure.to> wrote:

> Hi
>
> Mario has been working on the MingW build and has been encountering a
> lot of crashes. It turns out it's not specific to MingW but rather to
> the new versions of Ruby, 1.8.7. With 1.8.7-preview2 on Linux too the
> whole thing becomes very unstable.
>
> It seems that the ruby core developers have made some major changes to
> the way that GC is handled, and this has broken the GC marking stuff in
> wxRuby. I'm not sure at the moment whether the problem is in our code,
> or perhaps a problem with SWIG.
>
> Anyway, my plan is to proceed with releasing wxRuby 1.9.6 in the next
> few weeks, but warn that it's not yet usable with 1.8.7.
>
> alex


It's also worth noting, that wxRuby isn't the only project having problems
with 1.8.6 to 1.8.7 changes.  A lot of other projects are having similar
problems.  Notably Rubinius' rubyspecs furballed under the new 1.8.7
release.  So keep this in mind, hold off on the 1.8.7 release for a while.


-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080420/47a22620/attachment.html 

From alex at pressure.to  Sun Apr 20 15:23:16 2008
From: alex at pressure.to (Alex Fenton)
Date: Sun, 20 Apr 2008 20:23:16 +0100
Subject: [wxruby-development] wxRuby and ruby 1.8.7
In-Reply-To: <a4439dea0804201124o56ca66f0t247795ec82541397@mail.gmail.com>
References: <480B8075.1040800@pressure.to>
	<a4439dea0804201124o56ca66f0t247795ec82541397@mail.gmail.com>
Message-ID: <480B9824.3060002@pressure.to>

Mario Steele wrote:
> It's also worth noting, that wxRuby isn't the only project having 
> problems with 1.8.6 to 1.8.7 changes.  A lot of other projects are 
> having similar problems.  Notably Rubinius' rubyspecs furballed under 
> the new 1.8.7 release.  So keep this in mind, hold off on the 1.8.7 
> release for a while.
That's reassuring if depressing.

It's taken myself and others a huge amount of time to get the GC / 
memory management sorted to the level of stability we have today in 
wxRuby + ruby 1.8.6. The compile... wait... wait... run.. click... 
crash... gdb...wait.. wait... tweak... compile... cycle that it takes to 
get there is about the least fun thing I know.

Given that 1.8.7 is a dead-end release, with 2.0 in the works, I don't 
intend to spend any more time on it. Mario, if you or someone else can 
figure it out in a way that's backward compatible at least to 1.8.6 not 
p114 (as this is the standard version on OS X), great.

alex




From mario at ruby-im.net  Sun Apr 20 15:55:48 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 20 Apr 2008 14:55:48 -0500
Subject: [wxruby-development] wxRuby and ruby 1.8.7
In-Reply-To: <480B9824.3060002@pressure.to>
References: <480B8075.1040800@pressure.to>
	<a4439dea0804201124o56ca66f0t247795ec82541397@mail.gmail.com>
	<480B9824.3060002@pressure.to>
Message-ID: <a4439dea0804201255o5df61c82ncdb8c9152ee8912f@mail.gmail.com>

As much as I hate to say it, and as depressing as this is going to be.... it
may very well be that 2.0 will have the same thing in it, as far as the
rb_bug() which originally started this quest to fix it.  With as much as
they back ported from 2.0, to 1.8, it may be something that is 2.0 related,
and we'll end up being in the same boat as we are now.

Do realize Alex, I'm not trying to get you down.  Just a sad, but very
possible truth of the matter.

On Sun, Apr 20, 2008 at 2:23 PM, Alex Fenton <alex at pressure.to> wrote:

> Mario Steele wrote:
> > It's also worth noting, that wxRuby isn't the only project having
> > problems with 1.8.6 to 1.8.7 changes.  A lot of other projects are
> > having similar problems.  Notably Rubinius' rubyspecs furballed under
> > the new 1.8.7 release.  So keep this in mind, hold off on the 1.8.7
> > release for a while.
> That's reassuring if depressing.
>
> It's taken myself and others a huge amount of time to get the GC /
> memory management sorted to the level of stability we have today in
> wxRuby + ruby 1.8.6. The compile... wait... wait... run.. click...
> crash... gdb...wait.. wait... tweak... compile... cycle that it takes to
> get there is about the least fun thing I know.
>
> Given that 1.8.7 is a dead-end release, with 2.0 in the works, I don't
> intend to spend any more time on it. Mario, if you or someone else can
> figure it out in a way that's backward compatible at least to 1.8.6 not
> p114 (as this is the standard version on OS X), great.
>
> alex
>
>
>
> _______________________________________________
> wxruby-development mailing list
> wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080420/7fd61f32/attachment-0001.html 

From alex at pressure.to  Sun Apr 20 16:38:26 2008
From: alex at pressure.to (Alex Fenton)
Date: Sun, 20 Apr 2008 21:38:26 +0100
Subject: [wxruby-development] wxRuby and ruby 1.8.7
In-Reply-To: <a4439dea0804201255o5df61c82ncdb8c9152ee8912f@mail.gmail.com>
References: <480B8075.1040800@pressure.to>	<a4439dea0804201124o56ca66f0t247795ec82541397@mail.gmail.com>	<480B9824.3060002@pressure.to>
	<a4439dea0804201255o5df61c82ncdb8c9152ee8912f@mail.gmail.com>
Message-ID: <480BA9C2.5070407@pressure.to>

Mario Steele wrote:
> As much as I hate to say it, and as depressing as this is going to 
> be.... it may very well be that 2.0 will have the same thing in it, as 
> far as the rb_bug() which originally started this quest to fix it.  
> With as much as they back ported from 2.0, to 1.8, it may be something 
> that is 2.0 related, and we'll end up being in the same boat as we are 
> now.
>
> Do realize Alex, I'm not trying to get you down.  Just a sad, but very 
> possible truth of the matter.
Hehe, I'm less gloomy and more grumpy. You're probably right, although 
at first glance it worked OK with 1.9.0. But at least with a version 2.0 
you expect some pain, and get a bit more than Enumerable#minmax_by in 
return.

Given the big internal changes, 1.8.7 won't necessarily be a good guide 
to problems we might hit with 2.0. With some luck someone will take an 
interest in improving SWIG/Ruby and much of it will be taken from there.

cheers
alex

From chauk.mean at gmail.com  Mon Apr 21 08:49:20 2008
From: chauk.mean at gmail.com (Chauk-Mean P)
Date: Mon, 21 Apr 2008 14:49:20 +0200
Subject: [wxruby-development] Proposal for an improved API for Sizer
	(and ToolBar)
In-Reply-To: <4807F025.6040700@pressure.to>
References: <ca0724b20803180621i787fc3b3nc517730b4c6a9ec5@mail.gmail.com>
	<47E15C0B.80408@pressure.to>
	<ca0724b20803191322v786d03c9y1312e0806794181b@mail.gmail.com>
	<ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>
	<4807F025.6040700@pressure.to>
Message-ID: <ca0724b20804210549g4996a7fek583ad96b45b64593@mail.gmail.com>

Hi Alex,

2008/4/18, Alex Fenton <alex at pressure.to>:
> Just to mention that I added the ToolBarTool class to wxRuby so it's
> consistent with MenuItem and SizerItem.
>
> I think the bulk of your proposal still stands, except no generate_id
> method is needed, and I think it should now return the ToolBarTool
> object. So I will still look to merge for the next release.

That's fine. I'm looking forward the next release.

Cheers,

Chauk-Mean.

From alex at pressure.to  Mon Apr 21 08:52:35 2008
From: alex at pressure.to (Alex Fenton)
Date: Mon, 21 Apr 2008 13:52:35 +0100
Subject: [wxruby-development] Proposal for an improved API for
 Sizer	(and ToolBar)
In-Reply-To: <ca0724b20804210549g4996a7fek583ad96b45b64593@mail.gmail.com>
References: <ca0724b20803180621i787fc3b3nc517730b4c6a9ec5@mail.gmail.com>	<47E15C0B.80408@pressure.to>	<ca0724b20803191322v786d03c9y1312e0806794181b@mail.gmail.com>	<ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>	<4807F025.6040700@pressure.to>
	<ca0724b20804210549g4996a7fek583ad96b45b64593@mail.gmail.com>
Message-ID: <480C8E13.9020905@pressure.to>

Chauk-Mean P wrote:
>> I think the bulk of your proposal still stands, except no generate_id
>> method is needed, and I think it should now return the ToolBarTool
>> object. So I will still look to merge for the next release.
>>     
>
> That's fine. I'm looking forward the next release.
Cool - I meant to say, could you also submit a patch to fix the 
documentation please? These kind of enhancements are little use unless 
they are in the API docs.

thanks
alex

From chauk.mean at gmail.com  Mon Apr 21 09:22:41 2008
From: chauk.mean at gmail.com (Chauk-Mean P)
Date: Mon, 21 Apr 2008 15:22:41 +0200
Subject: [wxruby-development] Proposal for an improved API for Sizer
	(and ToolBar)
In-Reply-To: <480C8E13.9020905@pressure.to>
References: <ca0724b20803180621i787fc3b3nc517730b4c6a9ec5@mail.gmail.com>
	<47E15C0B.80408@pressure.to>
	<ca0724b20803191322v786d03c9y1312e0806794181b@mail.gmail.com>
	<ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>
	<4807F025.6040700@pressure.to>
	<ca0724b20804210549g4996a7fek583ad96b45b64593@mail.gmail.com>
	<480C8E13.9020905@pressure.to>
Message-ID: <ca0724b20804210622t18a103a6k8a5ffa6b8a642bf1@mail.gmail.com>

2008/4/21, Alex Fenton <alex at pressure.to>:
> > That's fine. I'm looking forward the next release.
> Cool - I meant to say, could you also submit a patch to fix the
> documentation please? These kind of enhancements are little use unless
> they are in the API docs.

Alex,

I can do it but I will not be available for the next 2 weeks for family reasons.
If wxRuby 1.9.6 is not expected to be released during these 2 weeks,
then it is OK for me.

Chauk-Mean.

From alex at pressure.to  Tue Apr 22 07:49:12 2008
From: alex at pressure.to (Alex Fenton)
Date: Tue, 22 Apr 2008 12:49:12 +0100
Subject: [wxruby-development] Proposal for an improved API for
 Sizer	(and ToolBar)
In-Reply-To: <ca0724b20804210622t18a103a6k8a5ffa6b8a642bf1@mail.gmail.com>
References: <ca0724b20803180621i787fc3b3nc517730b4c6a9ec5@mail.gmail.com>	<47E15C0B.80408@pressure.to>	<ca0724b20803191322v786d03c9y1312e0806794181b@mail.gmail.com>	<ca0724b20803200319s51e13240j760e3bb5077bbbfa@mail.gmail.com>	<4807F025.6040700@pressure.to>	<ca0724b20804210549g4996a7fek583ad96b45b64593@mail.gmail.com>	<480C8E13.9020905@pressure.to>
	<ca0724b20804210622t18a103a6k8a5ffa6b8a642bf1@mail.gmail.com>
Message-ID: <480DD0B8.60709@pressure.to>

Chauk-Mean P wrote:
> I can do it but I will not be available for the next 2 weeks for family reasons.
> If wxRuby 1.9.6 is not expected to be released during these 2 weeks,
> then it is OK for me.

No problems - given that ruby changes have introduced a big crasher bug 
with the latest stable version 1.8.6-114, we may release a little bit 
earlier. I would be very happy to integerate your patch at any time 
afterwards though, anyway.

best
alex

From alex at pressure.to  Tue Apr 22 18:26:14 2008
From: alex at pressure.to (Alex Fenton)
Date: Tue, 22 Apr 2008 23:26:14 +0100
Subject: [wxruby-development] 1.9.6
Message-ID: <480E6606.8030305@pressure.to>

Hi

I'd like to see if we can release 1.9.6 in the next week or so. I'm 
concerned that 1.9.5 and the current stable ruby don't get on well. What 
we have left on the bug list is either trivial or things we can't fix in 
wxRuby.

Sean/Mario - how are you fixed at the moment re Windows builds on MSVC 
and MingW?

Anyone - any testing time you can give to the samples on SVN HEAD would 
be great

thanks
alex

From mario at ruby-im.net  Wed Apr 23 01:18:29 2008
From: mario at ruby-im.net (Mario Steele)
Date: Wed, 23 Apr 2008 00:18:29 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <480E6606.8030305@pressure.to>
References: <480E6606.8030305@pressure.to>
Message-ID: <a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>

Hey Alex,

On Tue, Apr 22, 2008 at 5:26 PM, Alex Fenton <alex at pressure.to> wrote:

> Sean/Mario - how are you fixed at the moment re Windows builds on MSVC
> and MingW?


 If you give me the week, I'll try going with patchlevel 114, since I've
been working SVN Versions of Ruby Core with our builds.  If 114 turns out to
be a drop in the wrong direction, I'll down to 111, and see if I can get it
to work there.  I should hopefully have something for you by weeks end.  And
I'll do a fresh checkout of SVN, to ensure that I'm using the latest HEAD,
without any modifications.

Anyone - any testing time you can give to the samples on SVN HEAD would
> be great


I also will be running through these to, and fixing them up as I go, as far
as the problems that were discussed before in regards to the begin, require,
rescue, begin, require, load, end, end stuff that we have at the top of the
examples.

L8ers,

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080423/c11cbe56/attachment.html 

From alex at pressure.to  Wed Apr 23 02:57:25 2008
From: alex at pressure.to (Alex Fenton)
Date: Wed, 23 Apr 2008 07:57:25 +0100
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
Message-ID: <480EDDD5.4000405@pressure.to>

Hi Mario

Mario Steele wrote:
>
>  If you give me the week, I'll try going with patchlevel 114, since 
> I've been working SVN Versions of Ruby Core with our builds.  If 114 
> turns out to be a drop in the wrong direction, I'll down to 111, and 
> see if I can get it to work there. 
After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114. 
WxRuby on it seems very stable.
>
>     Anyone - any testing time you can give to the samples on SVN HEAD
>     would
>     be great
>
>
> I also will be running through these to, and fixing them up as I go, 
> as far as the problems that were discussed before in regards to the 
> begin, require, rescue, begin, require, load, end, end stuff that we 
> have at the top of the examples.
I already fixed all the require lines. In one case my updater script 
broke a script, so still good to check em over.

thanks
alex

From mario at ruby-im.net  Thu Apr 24 05:16:31 2008
From: mario at ruby-im.net (Mario Steele)
Date: Thu, 24 Apr 2008 04:16:31 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <480EDDD5.4000405@pressure.to>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
	<480EDDD5.4000405@pressure.to>
Message-ID: <a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>

Hey Alex,

On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote:

> After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114.
> WxRuby on it seems very stable.


Unfortunately, this doesn't seem to be the case on MinGW.  I am still
getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar
crashes with a rb_gc_mark() unknown data type, for which I can only trace
back to ProcessEvent() as the last part in wxRuby before it goes to Ruby's
GC Mark and Sweep stuff.

Again, we're looking at major bugs, all concerning the same problem.  GC
mark scan, is causing objects to not be properly referenced some how.

>
> >     Anyone - any testing time you can give to the samples on SVN HEAD
> >     would
> >     be great
> >
> >
> > I also will be running through these to, and fixing them up as I go,
> > as far as the problems that were discussed before in regards to the
> > begin, require, rescue, begin, require, load, end, end stuff that we
> > have at the top of the examples.
> I already fixed all the require lines. In one case my updater script
> broke a script, so still good to check em over.


We may not have a 1.9.6 MinGW Release, unless we can somehow figure out a
way to see why we're getting bad pointers.  If we could somehow utilize
"puts value.inspect" to inspect the object we get from st_foreach, and "puts
rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that
we're getting what we actually want.....  *sighs*

How do you want to proceed?

-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080424/7b3a30c7/attachment-0001.html 

From mario at ruby-im.net  Sat Apr 26 17:33:27 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sat, 26 Apr 2008 16:33:27 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
	<480EDDD5.4000405@pressure.to>
	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
Message-ID: <a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>

Hey Alex,

Okay, I have been able to verify that we are getting the correct
information, including the Object ID, and the actual Ruby class reference
during the GC_markIterate() on wxRubyApp.  Now there's been several crashes,
at different points.  First one, is the GC_mark_wxWindow().  It is failing
on dialogs, specifically FontDialog, when it tries to do the
wx_win->GetDropTarget().  Don't ask me why, I have no idea.

The second error, which I think traces back to general destruction under
wxFont, wxColour, and Ultimately with wxTextDateAttribute or whatever it may
be, it's crashing at the MSVCRT level, not at the Ruby or wxRuby level.
It's either with UnRef() function, or with New allocator, and it comes from
the iostream, or something similar, that is in MinGW.

Both of these have me confuzelled, and I have no idea where to go from
here.  But I definately think there is something wrong here, specifically in
the MinGW Build, which is the weirdest thing in the world.  Any ideas?

L8ers,

On Thu, Apr 24, 2008 at 4:16 AM, Mario Steele <mario at ruby-im.net> wrote:

> Hey Alex,
>
> On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote:
>
> > After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114.
> > WxRuby on it seems very stable.
>
>
> Unfortunately, this doesn't seem to be the case on MinGW.  I am still
> getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar
> crashes with a rb_gc_mark() unknown data type, for which I can only trace
> back to ProcessEvent() as the last part in wxRuby before it goes to Ruby's
> GC Mark and Sweep stuff.
>
> Again, we're looking at major bugs, all concerning the same problem.  GC
> mark scan, is causing objects to not be properly referenced some how.
>
> >
> > >     Anyone - any testing time you can give to the samples on SVN HEAD
> > >     would
> > >     be great
> > >
> > >
> > > I also will be running through these to, and fixing them up as I go,
> > > as far as the problems that were discussed before in regards to the
> > > begin, require, rescue, begin, require, load, end, end stuff that we
> > > have at the top of the examples.
> > I already fixed all the require lines. In one case my updater script
> > broke a script, so still good to check em over.
>
>
> We may not have a 1.9.6 MinGW Release, unless we can somehow figure out a
> way to see why we're getting bad pointers.  If we could somehow utilize
> "puts value.inspect" to inspect the object we get from st_foreach, and "puts
> rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that
> we're getting what we actually want.....  *sighs*
>
> How do you want to proceed?
>
>
> --
> Mario Steele
> http://www.trilake.net
> http://www.ruby-im.net
> http://rubyforge.org/projects/wxruby/
> http://rubyforge.org/projects/wxride/
> http://rubyforge.org/projects/vwmc/
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080426/f6b579ec/attachment.html>

From mario at ruby-im.net  Sun Apr 27 01:58:43 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 27 Apr 2008 00:58:43 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
	<480EDDD5.4000405@pressure.to>
	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
Message-ID: <a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>

Further testing, with a little throw in of manual debug information (Since
GDB isn't being nice), using the methods of GetClassInfo(), specifically
GetSize(), GetClassName(), GetBaseClass1() and GetBaseClass2().  I did this
so I could see if we are getting correct memory pointers, cause if we're
getting correct memory pointers, GetClassName, GetBaseClass1 and 2 all
return wxStrings, for GetClassName() I'm getting just 'w', GetBaseClass1()
returns a bunch of binary bytes, GetBaseClass2() is returning null on every
instance called when GC_mark_wxWindow() is called.

Now, this tells me we are getting an invalid pointer.  And the reason why I
know this, is cause of the way memory allocation occurs, I've dealt with in
another programming language that had the low level memory allocation
routines available to you.  All you have to do, is take the base address
returned by the memory allocator, use math to add a number to it, for
example 10, and it would offset the memory address by 10 bytes.  Example:
0xF3EABC + 10 == Memory Address now 0xF3EACB.  Add that to trying to read a
structure, and passing the new pointer to the functions that read the
information back out, and you litterally get jibberish back, since none of
the offsets for the fields in the structure are correct anymore to get the
data in the structure.

So we are getting invalid pointers back, most likely from the
SWIG_NewObject() function, or possibly the true Ruby object, and not the
actual Wrapped Pointer to the wx Object.  Which would explain the wxEvent
bug having strange, crazy ass id's with them, and the
wxFont/Colour/DateTextAttr errors we are getting with the new allocator and
the UnRef(), as memory is being unref'ed, and it's not the correct address,
causing a SegFault to occur.  Amazing what you can learn about C/C++, from
using an interpreted langauge that gives you access to those low level
memory routines.  Now the question remains, what is it, we're actually
getting back, a Pointer to the Swig wrapped object, a pointer to the Ruby
Object, or a offsetted pointer to the wx object, that Swig has messed up.

On Sat, Apr 26, 2008 at 4:33 PM, Mario Steele <mario at ruby-im.net> wrote:

> Hey Alex,
>
> Okay, I have been able to verify that we are getting the correct
> information, including the Object ID, and the actual Ruby class reference
> during the GC_markIterate() on wxRubyApp.  Now there's been several crashes,
> at different points.  First one, is the GC_mark_wxWindow().  It is failing
> on dialogs, specifically FontDialog, when it tries to do the
> wx_win->GetDropTarget().  Don't ask me why, I have no idea.
>
> The second error, which I think traces back to general destruction under
> wxFont, wxColour, and Ultimately with wxTextDateAttribute or whatever it may
> be, it's crashing at the MSVCRT level, not at the Ruby or wxRuby level.
> It's either with UnRef() function, or with New allocator, and it comes from
> the iostream, or something similar, that is in MinGW.
>
> Both of these have me confuzelled, and I have no idea where to go from
> here.  But I definately think there is something wrong here, specifically in
> the MinGW Build, which is the weirdest thing in the world.  Any ideas?
>
> L8ers,
>
>
> On Thu, Apr 24, 2008 at 4:16 AM, Mario Steele <mario at ruby-im.net> wrote:
>
> > Hey Alex,
> >
> > On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote:
> >
> > > After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114.
> > > WxRuby on it seems very stable.
> >
> >
> > Unfortunately, this doesn't seem to be the case on MinGW.  I am still
> > getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar
> > crashes with a rb_gc_mark() unknown data type, for which I can only trace
> > back to ProcessEvent() as the last part in wxRuby before it goes to Ruby's
> > GC Mark and Sweep stuff.
> >
> > Again, we're looking at major bugs, all concerning the same problem.  GC
> > mark scan, is causing objects to not be properly referenced some how.
> >
> > >
> > > >     Anyone - any testing time you can give to the samples on SVN
> > > HEAD
> > > >     would
> > > >     be great
> > > >
> > > >
> > > > I also will be running through these to, and fixing them up as I go,
> > > > as far as the problems that were discussed before in regards to the
> > > > begin, require, rescue, begin, require, load, end, end stuff that we
> > > > have at the top of the examples.
> > > I already fixed all the require lines. In one case my updater script
> > > broke a script, so still good to check em over.
> >
> >
> > We may not have a 1.9.6 MinGW Release, unless we can somehow figure out
> > a way to see why we're getting bad pointers.  If we could somehow utilize
> > "puts value.inspect" to inspect the object we get from st_foreach, and "puts
> > rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that
> > we're getting what we actually want.....  *sighs*
> >
> > How do you want to proceed?
> >
> >
> > --
> > Mario Steele
> > http://www.trilake.net
> > http://www.ruby-im.net
> > http://rubyforge.org/projects/wxruby/
> > http://rubyforge.org/projects/wxride/
> > http://rubyforge.org/projects/vwmc/
> >
>
>
>
> --
> Mario Steele
> http://www.trilake.net
> http://www.ruby-im.net
> http://rubyforge.org/projects/wxruby/
> http://rubyforge.org/projects/wxride/
> http://rubyforge.org/projects/vwmc/
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080427/7cb0ddf8/attachment.html>

From alex at pressure.to  Sun Apr 27 04:00:04 2008
From: alex at pressure.to (Alex Fenton)
Date: Sun, 27 Apr 2008 09:00:04 +0100
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>
References: <480E6606.8030305@pressure.to>	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>	<480EDDD5.4000405@pressure.to>	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>
Message-ID: <48143284.4030109@pressure.to>

Hi Mario

Thanks for your investigations. I've been looking at the MSVC build 
which has similar problems, and the MS debugger suggests that indeed the 
Event mark routine is getting an invalid pointer. When we've hit these 
sort of problems before, it's shown up much worse on Windows, I think 
perhaps b/c of different memory allocation strategies.

wxWidgets creates Event objects on the stack, not the heap, so rt of the 
problem is I don't know of a way to know when they are finished with 
(unlike the way we use WindowDestroyEvent). One strange thing is that 
the two routes of C++ Event objects to Ruby Objects 
(EvtHandler#EventThunker and App#FilterEvent) neither specify a mark 
routine in the Data_Wrap_Struct call. So I don't quite understand why 
the mark routine is getting called - they should be "unowned" by ruby 
except if Event.new is called on the ruby side, which is only in custom 
event handling.

I guess the solution is either to 1) fix the mark routine 2) find out 
why the mark routine is getting called on Event objects that it 
shouldn't or 3) find a different way to preserve ruby client data 
associated with event objects, which is why we have to have the mark 
routine in the first place.

alex



From mario at ruby-im.net  Sun Apr 27 12:47:50 2008
From: mario at ruby-im.net (Mario Steele)
Date: Sun, 27 Apr 2008 11:47:50 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <48143284.4030109@pressure.to>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
	<480EDDD5.4000405@pressure.to>
	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>
	<48143284.4030109@pressure.to>
Message-ID: <a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>

That would indeed answer the problem with wxEvents, and make sense.  But
what of wxWindow / wxFontDialog.  I would suggest testing to see what we are
exactly getting, but the question becomes, how do we do such a thing.  And
should it even matter if we check or not.  This was oviously working in the
past, why is it now that we are getting these problems?

Aside from it being a MinGW Build, I have yet to try this set, with Swig
1.3.34 instead of 1.3.35, but you said there were no changes as far as the
Ruby side is concern.  I'm going to look into that a bit more further.

L8ers,

On Sun, Apr 27, 2008 at 3:00 AM, Alex Fenton <alex at pressure.to> wrote:

> Hi Mario
>
> Thanks for your investigations. I've been looking at the MSVC build which
> has similar problems, and the MS debugger suggests that indeed the Event
> mark routine is getting an invalid pointer. When we've hit these sort of
> problems before, it's shown up much worse on Windows, I think perhaps b/c of
> different memory allocation strategies.
>
> wxWidgets creates Event objects on the stack, not the heap, so rt of the
> problem is I don't know of a way to know when they are finished with (unlike
> the way we use WindowDestroyEvent). One strange thing is that the two routes
> of C++ Event objects to Ruby Objects (EvtHandler#EventThunker and
> App#FilterEvent) neither specify a mark routine in the Data_Wrap_Struct
> call. So I don't quite understand why the mark routine is getting called -
> they should be "unowned" by ruby except if Event.new is called on the ruby
> side, which is only in custom event handling.
>
> I guess the solution is either to 1) fix the mark routine 2) find out why
> the mark routine is getting called on Event objects that it shouldn't or 3)
> find a different way to preserve ruby client data associated with event
> objects, which is why we have to have the mark routine in the first place.
>
>
> alex
>
>
> _______________________________________________
> wxruby-development mailing list
> wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080427/e164232d/attachment-0001.html>

From alex at pressure.to  Mon Apr 28 16:28:57 2008
From: alex at pressure.to (Alex Fenton)
Date: Mon, 28 Apr 2008 21:28:57 +0100
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>
References: <480E6606.8030305@pressure.to>	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>	<480EDDD5.4000405@pressure.to>	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>	<48143284.4030109@pressure.to>
	<a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>
Message-ID: <48163389.2050808@pressure.to>

Hi Mario

I've just committed a substantial set of changes to the way that events 
are managed between the C++ and Ruby side of the library.

Seems we were running into one of the causes of hard-to-track bugs in 
the API. This is that SWIG will create "director" methods for any C++ 
method declared virtual in any ancestor class (including wxEvtHandler, 
for all wxWindow classes). These director methods will create a ruby 
wrapper for the C++ object then attempt to pass that object into ruby in 
a method call. Which is great, except if you weren't expecting a ruby 
object to be created at that point.

In this case, before normal event handlers were called, wxWidgets calls 
ProcessEvent, which SWIG passes to Ruby, including wrapping a 
short-lived (stack-based) C++ event object. The GC mark routines were 
getting called on these objects causing the crashes. I've fixed this 
with a directorin typemap to catch the times that the C++ API is passing 
the event object into a ruby method eg process_event.

Anyway, could you svn up and see how it goes. bigdemo.rb seems much more 
stable, but I'd like to identify any errors that remain.

cheers
alex


Mario Steele wrote:
> That would indeed answer the problem with wxEvents, and make sense.  
> But what of wxWindow / wxFontDialog.  I would suggest testing to see 
> what we are exactly getting, but the question becomes, how do we do 
> such a thing.  And should it even matter if we check or not.  This was 
> oviously working in the past, why is it now that we are getting these 
> problems?
>
> Aside from it being a MinGW Build, I have yet to try this set, with 
> Swig 1.3.34 instead of 1.3.35, but you said there were no changes as 
> far as the Ruby side is concern.  I'm going to look into that a bit 
> more further.



From noreply at rubyforge.org  Tue Apr 29 16:21:33 2008
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 29 Apr 2008 16:21:33 -0400 (EDT)
Subject: [wxruby-development] [ wxruby-Bugs-19857 ] Using Image.write
	doesn't seem to work with TIFF format
Message-ID: <20080429202133.430B8185863B@rubyforge.org>

Bugs item #19857, was opened at 2008-04-29 20:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19857&group_id=35

Category: Incorrect behavior
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Alex Fenton (brokentoy)
Assigned to: Alex Fenton (brokentoy)
Summary: Using Image.write doesn't seem to work with TIFF format

Initial Comment:
An error seems to be thrown in the wxWidgets API when it checks the header has been written correctly (in src/tif/tif_open.c line 303).

The commoner image formats (PNG, JPEG, BMP) all work correctly.

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

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=218&aid=19857&group_id=35

From mario at ruby-im.net  Wed Apr 30 04:14:19 2008
From: mario at ruby-im.net (Mario Steele)
Date: Wed, 30 Apr 2008 03:14:19 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <48163389.2050808@pressure.to>
References: <480E6606.8030305@pressure.to>
	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>
	<480EDDD5.4000405@pressure.to>
	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>
	<48143284.4030109@pressure.to>
	<a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>
	<48163389.2050808@pressure.to>
Message-ID: <a4439dea0804300114mcb6e354n115602981019ef27@mail.gmail.com>

Hey Alex,

On Mon, Apr 28, 2008 at 3:28 PM, Alex Fenton <alex at pressure.to> wrote:

> Hi Mario
>
> I've just committed a substantial set of changes to the way that events
> are managed between the C++ and Ruby side of the library.
>
> Seems we were running into one of the causes of hard-to-track bugs in the
> API. This is that SWIG will create "director" methods for any C++ method
> declared virtual in any ancestor class (including wxEvtHandler, for all
> wxWindow classes). These director methods will create a ruby wrapper for the
> C++ object then attempt to pass that object into ruby in a method call.
> Which is great, except if you weren't expecting a ruby object to be created
> at that point.
>
> In this case, before normal event handlers were called, wxWidgets calls
> ProcessEvent, which SWIG passes to Ruby, including wrapping a short-lived
> (stack-based) C++ event object. The GC mark routines were getting called on
> these objects causing the crashes. I've fixed this with a directorin typemap
> to catch the times that the C++ API is passing the event object into a ruby
> method eg process_event.
>
> Anyway, could you svn up and see how it goes. bigdemo.rb seems much more
> stable, but I'd like to identify any errors that remain.


Well, looks like for now, as far as I can tell, Events are being handled
properly.  I can't say for certain, as I still have wxWindow bugging out due
to the failure to get a Drop Target from the wxFontDialog demo example.

Debug:
Program received signal SIGSEGV, Segmentation fault.
0x00220528 in ?? ()
(gdb) whe
#0  0x00220528 in ?? ()
#1  0x6806a0c2 in GC_mark_wxWindow (ptr=0x2ccd1b8) at src/wx.cpp:2485
#2  0x66baea59 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll
#3  0x686a9435 in wxRubyApp::markIterate (key=93954929, value=104909377,
    lev=0) at src/App.cpp:2317
#4  0x66bf634c in st_foreach () from E:\system\ruby\bin\msvcrt-ruby18.dll
#5  0x686a9476 in wxRubyApp::mark_wxRubyApp (ptr=0x2cd55a0)
    at src/App.cpp:2346
#6  0x66baea59 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll
#7  0x66baeb60 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll
#8  0x66baf2a4 in rb_gc_mark_frame ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#9  0x66bafac5 in rb_newobj () from E:\system\ruby\bin\msvcrt-ruby18.dll
#10 0x66b9c442 in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#11 0x66b9d77b in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#12 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll
#13 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll
#14 0x680690fe in wxRuby_WrapWxEventInRuby (wx_event=0x246eff0)
    at src/wx.cpp:2363
#15 0x67ceda97 in SwigDirector_wxFrame::ProcessEvent (this=0x2da8458,
    event=@0x246eff0) at src/Frame.cpp:2418
#16 0x680a74cb in wxWindowBase::TryParent ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.
5/ext/new_allocator.h:69
#17 0x680b722e in wxEvtHandler::ProcessEvent ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.
5/ext/new_allocator.h:69
#18 0x67cc1a29 in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0x246dec0,
    self=52207632) at src/EvtHandler.cpp:2718
#19 0x66b9d3a0 in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#20 0x66b9d77b in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#21 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll
#22 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll
#23 0x67f3f24b in SwigDirector_wxSplitterWindow::ProcessEvent (
    this=0x2dad3e8, event=@0x246eff0) at src/SplitterWindow.cpp:2133
#24 0x680a74cb in wxWindowBase::TryParent ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.
5/ext/new_allocator.h:69
#25 0x680b722e in wxEvtHandler::ProcessEvent ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.
5/ext/new_allocator.h:69
#26 0x67cc1a29 in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0x246e2a0,
    self=52207584) at src/EvtHandler.cpp:2718
#27 0x66b9d3a0 in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#28 0x66b9d77b in rb_thread_schedule ()
   from E:\system\ruby\bin\msvcrt-ruby18.dll
#29 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll

The lines are off, cause I added #ifdef's for __WXDEBUG__ for the routines I
devised for trying to print out the GetClassInfo() information, which still
remains to show that there is some kind of pointer offset going on.

Also Calendar.rb demo is still bugging out, with an UnRef segfault on
wxObject.

Debug:

0x6806b781 in wxObject::UnRef ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
69            ~new_allocator() throw() { }
Current language:  auto; currently c++
(gdb) whe
#0  0x6806b781 in wxObject::UnRef ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#1  0x680c7d67 in wxFontBase::~wxFontBase ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#2  0x680c1147 in wxFont::~wxFont ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#3  0x67c2dd89 in free_wxCalendarDateAttr (arg1=0x2e5b220) at
F:/wxWidgets-2.8.7/include/wx/generic/calctrl.h:136
#4  0x66baf62a in rb_gc_mark_frame () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#5  0x66bafac5 in rb_newobj () from E:\system\ruby\bin\msvcrt-ruby18.dll
#6  0x66b9c442 in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#7  0x66b9d77b in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#8  0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll
#9  0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll
#10 0x680690fe in wxRuby_WrapWxEventInRuby (wx_event=0x246f140) at
src/wx.cpp:2363
#11 0x67ceda97 in SwigDirector_wxFrame::ProcessEvent (this=0x2e4a498,
event=@0x246f140) at src/Frame.cpp:2418
#12 0x680ab041 in wxWindowBase::UpdateWindowUI ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#13 0x6802b4dc in _wrap_wxWindow_UpdateWindowUI (argc=1, argv=0x246f3f0,
self=51793968) at src/Window.cpp:11002
#14 0x66b9d3a0 in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#15 0x66b9d77b in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#16 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll
#17 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll
#18 0x67ce6d52 in SwigDirector_wxFrame::UpdateWindowUI (this=0x2e4a498,
flags=2) at src/Frame.cpp:2133
#19 0x68092bf3 in wxWindow::OnInternalIdle ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#20 0x680b9bc1 in wxAppBase::SendIdleEvents ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#21 0x680b9f35 in wxAppBase::ProcessIdle ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#22 0x6836c1cf in wxEventLoopManual::Run ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#23 0x680b969e in wxAppBase::MainLoop ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#24 0x6836fbc7 in wxEntryReal ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#25 0x680bef57 in wxEntry ()
    at
E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69
#26 0x67bd5d57 in _wrap_App_main_loop (argc=0, argv=0x0, self=51795456) at
src/App.cpp:2374
#27 0x66b9d3a0 in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#28 0x66b9d77b in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#29 0x66b98de8 in rb_thread_schedule () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#30 0x66ba53e5 in rb_eval_string () from
E:\system\ruby\bin\msvcrt-ruby18.dll
#31 0x66ba5416 in ruby_exec () from E:\system\ruby\bin\msvcrt-ruby18.dll
#32 0x66ba6450 in ruby_run () from E:\system\ruby\bin\msvcrt-ruby18.dll
#33 0x00401341 in main (argc=2, argv=0x223ef0, envp=0x222b18) at
../ruby_1_8/main.c:48
(gdb)

If you want to see the jibberish it's spewing out from the GetClassInfo()
stuff, here's the code:

In order to make it show, you need to comment out, or remove the #ifdef
__WXDEBUG__.

Index: mark_free_impl.i
===================================================================
--- mark_free_impl.i    (revision 1700)
+++ mark_free_impl.i    (working copy)
@@ -113,6 +113,13 @@
          rb_gc_mark(rb_caret);
        }

+#ifdef __WXDEBUG__
+  printf("wxwinDEBUG> wx_win->GetClassInfo()\n");
+  printf("            GetClassName() =
%s\n",wx_win->GetClassInfo()->GetClassName());
+  printf("            GetBaseClass1() =
%s\n",wx_win->GetClassInfo()->GetBaseClass1());
+  printf("            GetBaseClass2() =
%s\n",wx_win->GetClassInfo()->GetBaseClass2());
+  printf("            GetSize() = %d\n",wx_win->GetClassInfo()->GetSize());
+#endif
   wxDropTarget* wx_droptarget = wx_win->GetDropTarget();
   if ( wx_droptarget )
        {


Index: App.i
===================================================================
--- App.i       (revision 1700)
+++ App.i       (working copy)
@@ -86,6 +86,9 @@
   static int markIterate(VALUE key, VALUE value, int lev)
   {
        VALUE rb_obj = SWIG_RubyReferenceToObject(value);
+#ifdef __WXDEBUG__
+  printf(" rubyDEBUG> rb_obj.inspect = %s\n",STR2CSTR(rb_inspect(rb_obj)));
+#endif
        // Check if it's a valid object (sometimes SWIG doesn't return what
we're
        // expecting), a descendant of Wx::Window, and if it has not yet
been
        // deleted by WxWidgets; if so, mark it.





-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080430/68e07967/attachment-0001.html>

From alex at pressure.to  Wed Apr 30 04:55:42 2008
From: alex at pressure.to (Alex Fenton)
Date: Wed, 30 Apr 2008 09:55:42 +0100
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804300114mcb6e354n115602981019ef27@mail.gmail.com>
References: <480E6606.8030305@pressure.to>	<a4439dea0804222218n54976b69x724e640e2bd126ff@mail.gmail.com>	<480EDDD5.4000405@pressure.to>	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>	<48143284.4030109@pressure.to>	<a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>	<48163389.2050808@pressure.to>
	<a4439dea0804300114mcb6e354n115602981019ef27@mail.gmail.com>
Message-ID: <4818340E.9020302@pressure.to>

Mario Steele wrote:
>
> Well, looks like for now, as far as I can tell, Events are being 
> handled properly.
Cool. This was the really difficult problem.

> I can't say for certain, as I still have wxWindow bugging out due to 
> the failure to get a Drop Target from the wxFontDialog demo example.

Good news is I can reproduce those bugs on OS X. I guess I've never 
kicked those samples hard enough. They look like simple DISOWN fixes are 
needed. I'll try and apply these later and wrap the build.

thanks
alex

From mario at ruby-im.net  Wed Apr 30 05:32:19 2008
From: mario at ruby-im.net (Mario Steele)
Date: Wed, 30 Apr 2008 04:32:19 -0500
Subject: [wxruby-development] 1.9.6
In-Reply-To: <4818340E.9020302@pressure.to>
References: <480E6606.8030305@pressure.to> <480EDDD5.4000405@pressure.to>
	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>
	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>
	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>
	<48143284.4030109@pressure.to>
	<a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>
	<48163389.2050808@pressure.to>
	<a4439dea0804300114mcb6e354n115602981019ef27@mail.gmail.com>
	<4818340E.9020302@pressure.to>
Message-ID: <a4439dea0804300232r6b206b65t69c873d3876ba049@mail.gmail.com>

On Wed, Apr 30, 2008 at 3:55 AM, Alex Fenton <alex at pressure.to> wrote:

> Good news is I can reproduce those bugs on OS X. I guess I've never kicked
> those samples hard enough. They look like simple DISOWN fixes are needed.
> I'll try and apply these later and wrap the build.


I consider that more then good news, means I'm not going crazy over here in
Windows land. LOL  I'll await your commit, to test it out over here.  Also,
I found a way to get MediaCtrl enabled, just as I did for GraphicsContext.
Evidently the wxPython team never really looked to deeply into the problem /
solution for it, and it's very similar to the way we had to make GDI
Compliant with MinGW for it to work with wxWidgets.

Also, what I thought was Pointer corruption, wasn't at all, just me either
not utitlizing the correct methods, or me not utilizing a conversion method
to turn it from Unicode to ASCII UTF8 format.

Here's the update components, it might be a smart idea to keep these around,
just incase we need to do further debugging in the future  (Hence why I
threw them in under __WXDEBUG__ defines):

Index: mark_free_impl.i
===================================================================
--- mark_free_impl.i    (revision 1700)
+++ mark_free_impl.i    (working copy)
@@ -113,6 +113,14 @@
          rb_gc_mark(rb_caret);
        }

+#ifdef __WXDEBUG__
+  wxClassInfo* wx_classinfo = wx_win->GetClassInfo();
+  printf("wxwinDEBUG> wx_win->GetClassInfo()\n");
+  printf("            GetClassName() = %s\n",(const char*)(
wxString(wx_classinfo->GetClassName()).mb_str( wxConvUTF8 ) ) );
+  printf("            GetBaseClass1() = %s\n",(const char*)(
wxString(wx_classinfo->GetBaseClassName1()).mb_str( wxConvUTF8 ) ) );
+  printf("            GetBaseClass2() = %s\n",(const char*)(
wxString(wx_classinfo->GetBaseClassName2()).mb_str( wxConvUTF8 ) ) );
+  printf("            GetSize() = %d\n",wx_classinfo->GetSize());
+#endif
   wxDropTarget* wx_droptarget = wx_win->GetDropTarget();
   if ( wx_droptarget )
        {



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080430/21ffe994/attachment.html>

From alex at pressure.to  Wed Apr 30 20:37:27 2008
From: alex at pressure.to (Alex Fenton)
Date: Thu, 01 May 2008 01:37:27 +0100
Subject: [wxruby-development] 1.9.6
In-Reply-To: <a4439dea0804300232r6b206b65t69c873d3876ba049@mail.gmail.com>
References: <480E6606.8030305@pressure.to>
	<480EDDD5.4000405@pressure.to>	<a4439dea0804240216oa4405c7yc8cd57a194a8263d@mail.gmail.com>	<a4439dea0804261433r16d919caped55590c7aaf0638@mail.gmail.com>	<a4439dea0804262258k71598751u8a33c360c464d028@mail.gmail.com>	<48143284.4030109@pressure.to>	<a4439dea0804270947v1645c562wed53a2f1db789266@mail.gmail.com>	<48163389.2050808@pressure.to>	<a4439dea0804300114mcb6e354n115602981019ef27@mail.gmail.com>	<4818340E.9020302@pressure.to>
	<a4439dea0804300232r6b206b65t69c873d3876ba049@mail.gmail.com>
Message-ID: <481910C7.6000006@pressure.to>

I've tagged 1.9.6 in the repo and uploaded the builds for the three 
"core" platforms.

Mario, if you'd like to do a RELEASE-based build for mingw, that'd be great.

My demo licence for VMWare which I used to build the linux-x86_64 build 
has run out and I don't really feel like buying one ($70) cos I don't 
have any other use for it. If anyone is keen and able to offer the gem 
on this platform get in touch.

alex