wxruby users - Aug 2005 - patch for Icon

I just checked out a fresh copy and had to tweak wxIcon.h to get it to
compile on Mac OS X and windows. The problem is with:

      wxIcon(const wxString& filename, 
             wxBitmapType type = wxBITMAP_TYPE_XPM,
             int desiredWidth=-1, int desiredHeight=-1);

that signature is only used on GTK on other systems it is:

      wxIcon(const wxString& name,
             long type = wxBITMAP_TYPE_ICO_RESOURCE,
             int desiredWidth = -1, int desiredHeight = -1); 

So I wrapped this in a #ifdef __WXGTK__ #else #endif

I also had to change:

 wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));

I don''t know about other systems but on Windows wxLogWarning and
wxLogStatus only take const char *formatString and that is what the
docs show also.

Kevin the refactored install works great also.

I will be out of town for 5 days starting tomorrow so if you need any
clarification email me back quick.


Sean


_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users

This one needs more work. I have not applied it yet.

The icon changes won''t compile on my box at all. I''ll try to
figure out why.

These log changes appear to be reverting changes that I checked in just 
a day or two ago that Jani said were necessary. I haven''t looked
closely
enough to see what is going on, so can either of you (or anyone else) 
clarify?

Thanks,

Kevin


Sean Long wrote:
> I just checked out a fresh copy and had to tweak wxIcon.h to get it to
> compile on Mac OS X and windows. The problem is with:
> 
>       wxIcon(const wxString& filename, 
>              wxBitmapType type = wxBITMAP_TYPE_XPM,
>              int desiredWidth=-1, int desiredHeight=-1);
> 
> that signature is only used on GTK on other systems it is:
> 
>       wxIcon(const wxString& name,
>              long type = wxBITMAP_TYPE_ICO_RESOURCE,
>              int desiredWidth = -1, int desiredHeight = -1); 
> 
> So I wrapped this in a #ifdef __WXGTK__ #else #endif
> 
> I also had to change:
> 
>  wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));
> 
> I don''t know about other systems but on Windows wxLogWarning and
> wxLogStatus only take const char *formatString and that is what the
> docs show also.
> 
> Kevin the refactored install works great also.
> 
> I will be out of town for 5 days starting tomorrow so if you need any
> clarification email me back quick.
> 
> 
> Sean
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users

I can''t speak to the icon changes.  The log file changes appear to be a
different take on the same thing I tried.  The changes you checked in 
will not compile on Windows at all so I can''t imagine we want to go
that
route.  Is there a different declaration under older/different versions 
of wxWindows?

Kevin Smith wrote:
> This one needs more work. I have not applied it yet.
>
> The icon changes won''t compile on my box at all. I''ll try
to figure
> out why.
>
> These log changes appear to be reverting changes that I checked in 
> just a day or two ago that Jani said were necessary. I haven''t
looked
> closely enough to see what is going on, so can either of you (or 
> anyone else) clarify?
>
> Thanks,
>
> Kevin
>
>
> Sean Long wrote:
>
>> I just checked out a fresh copy and had to tweak wxIcon.h to get it to
>> compile on Mac OS X and windows. The problem is with:
>>
>>       wxIcon(const wxString& filename,              wxBitmapType
type
>> = wxBITMAP_TYPE_XPM,
>>              int desiredWidth=-1, int desiredHeight=-1);
>>
>> that signature is only used on GTK on other systems it is:
>>
>>       wxIcon(const wxString& name,
>>              long type = wxBITMAP_TYPE_ICO_RESOURCE,
>>              int desiredWidth = -1, int desiredHeight = -1);
>> So I wrapped this in a #ifdef __WXGTK__ #else #endif
>>
>> I also had to change:
>>
>>  wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));
>>
>> I don''t know about other systems but on Windows wxLogWarning
and
>> wxLogStatus only take const char *formatString and that is what the
>> docs show also.
>>
>> Kevin the refactored install works great also.
>>
>> I will be out of town for 5 days starting tomorrow so if you need any
>> clarification email me back quick.
>>
>>
>> Sean
>>
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> wxruby-users mailing list
>> wxruby-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>

Roy Sutton wrote:
> I can''t speak to the icon changes.  The log file changes appear to
be a
> different take on the same thing I tried.  The changes you checked in 
> will not compile on Windows at all so I can''t imagine we want to
go that
> route.  Is there a different declaration under older/different versions 
> of wxWindows?
Possible, but I''m using wx 2.6.1 here, so I doubt it''s an API
difference
that we are hitting. It is probably a compiler pickiness issue, a 
platform datatype mismatch, or a unicode/non-unicode thing.

Can you try changing this:
   wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));

to something like this:
   wxLogWarning(wxString(StringValuePtr(str), wxConvUTF8));

It looks like a good pattern because it creates a local wxString that 
will get cleaned up on function exit, and it avoids any question of 
char* vs const char* vs wxChar* etc. It seemed to work over in TextCtrl.

I''ll look at this more in a day or two, but any feedback on this would 
be appreciated.

Thanks,

Kevin

I''ve tried that before, although I did use a temporary variable.  It 
does seem to work although I didn''t actually test logging
functionality,
only compilation.  I can try something later to see if it works.

Kevin Smith wrote:
> Roy Sutton wrote:
>
>> I can''t speak to the icon changes.  The log file changes
appear to be
>> a different take on the same thing I tried.  The changes you checked 
>> in will not compile on Windows at all so I can''t imagine we
want to
>> go that route.  Is there a different declaration under 
>> older/different versions of wxWindows?
>
>
> Possible, but I''m using wx 2.6.1 here, so I doubt it''s an
API
> difference that we are hitting. It is probably a compiler pickiness 
> issue, a platform datatype mismatch, or a unicode/non-unicode thing.
>
> Can you try changing this:
>   wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));
>
> to something like this:
>   wxLogWarning(wxString(StringValuePtr(str), wxConvUTF8));
>
> It looks like a good pattern because it creates a local wxString that 
> will get cleaned up on function exit, and it avoids any question of 
> char* vs const char* vs wxChar* etc. It seemed to work over in TextCtrl.
>
> I''ll look at this more in a day or two, but any feedback on this
would
> be appreciated.
>
> Thanks,
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>

I''m getting the same error when compiling the current tree:

src/Functions.cpp: In function `void log_message(int, VALUE*, long unsigned
   int)'':
src/Functions.cpp:583: error: cannot convert `const wxWCharBuffer'' to
`const
   wxChar*'' for argument `1'' to `void wxLogWarning(const
wxChar*, ...)''

Applying your (ad-hoc) suggested fix didn''t work either :(

On a sidenote: Before the update I finally had some samples up n
running, after the update I got a segfault :(
I''m unsure whether it''s related to this issue (I commented out
the
offending lines), but it''s definitely something newly checked-in.
Running the program through gbd doesn''t help either....I still get alot
of mumbo-jumbo

Sorry I couldn''t help you out any further here,

Jonathan

Kevin Smith wrote:
> Roy Sutton wrote:
>
>> I can''t speak to the icon changes.  The log file changes
appear to be
>> a different take on the same thing I tried.  The changes you checked
>> in will not compile on Windows at all so I can''t imagine we
want to
>> go that route.  Is there a different declaration under
>> older/different versions of wxWindows?
>
>
> Possible, but I''m using wx 2.6.1 here, so I doubt it''s an
API
> difference that we are hitting. It is probably a compiler pickiness
> issue, a platform datatype mismatch, or a unicode/non-unicode thing.
>
> Can you try changing this:
>   wxLogWarning(wxConvUTF8.cMB2WC(StringValuePtr(str)));
>
> to something like this:
>   wxLogWarning(wxString(StringValuePtr(str), wxConvUTF8));
>
> It looks like a good pattern because it creates a local wxString that
> will get cleaned up on function exit, and it avoids any question of
> char* vs const char* vs wxChar* etc. It seemed to work over in TextCtrl.
>
> I''ll look at this more in a day or two, but any feedback on this
would
> be appreciated.
>
> Thanks,
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>

Sean Long wrote:
> I just checked out a fresh copy and had to tweak wxIcon.h to get it to
> compile on Mac OS X and windows. The problem is with:
> 
>       wxIcon(const wxString& filename, 
>              wxBitmapType type = wxBITMAP_TYPE_XPM,
>              int desiredWidth=-1, int desiredHeight=-1);
> 
> that signature is only used on GTK on other systems it is:
> 
>       wxIcon(const wxString& name,
>              long type = wxBITMAP_TYPE_ICO_RESOURCE,
>              int desiredWidth = -1, int desiredHeight = -1); 
> 
> So I wrapped this in a #ifdef __WXGTK__ #else #endif
I *FINALLY* figured out why this wasn''t working for me: because 
__WXGTK__ wasn''t defined, even though I''m using wxGTK. Why?
Because we
weren''t passing the wx cppflags to swig. I just changed the rakefile to
do this, and now this kind of #if works in classes/include/wxXxxxx.h files.

So I grabbed a copy of my "official" wx icon.h file and used that as a
starting point for wxIcon.h. I added the one conditional above, and also 
commented out some overloaded operators that don''t make sense for us. A
visual comparison with the patch submitted by Sean looked good. I no 
longer have to %ignore anything, and it compiles and seems to run.

Hopefully it will work on other platforms also, now. If not, it would 
probably be more differences between the GTK API and other platform 
APIs. Another less likely cause would be unicode/non-unicode glitches.

Anyway, let me know whether Icon now works on MS Win and Mac.

Thanks!

Kevin

I had to make a small change to get Icon to compile on Windows the
patch in attached. Will try Mac OS X hopefully tonight.

Sean

On 8/11/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Sean Long wrote:
> > I just checked out a fresh copy and had to tweak wxIcon.h to get it to
> > compile on Mac OS X and windows. The problem is with:
> >
> >       wxIcon(const wxString& filename,
> >              wxBitmapType type = wxBITMAP_TYPE_XPM,
> >              int desiredWidth=-1, int desiredHeight=-1);
> >
> > that signature is only used on GTK on other systems it is:
> >
> >       wxIcon(const wxString& name,
> >              long type = wxBITMAP_TYPE_ICO_RESOURCE,
> >              int desiredWidth = -1, int desiredHeight = -1);
> >
> > So I wrapped this in a #ifdef __WXGTK__ #else #endif
> 
> I *FINALLY* figured out why this wasn''t working for me: because
> __WXGTK__ wasn''t defined, even though I''m using wxGTK.
Why? Because we
> weren''t passing the wx cppflags to swig. I just changed the
rakefile to
> do this, and now this kind of #if works in classes/include/wxXxxxx.h files.
> 
> So I grabbed a copy of my "official" wx icon.h file and used that
as a
> starting point for wxIcon.h. I added the one conditional above, and also
> commented out some overloaded operators that don''t make sense for
us. A
> visual comparison with the patch submitted by Sean looked good. I no
> longer have to %ignore anything, and it compiles and seems to run.
> 
> Hopefully it will work on other platforms also, now. If not, it would
> probably be more differences between the GTK API and other platform
> APIs. Another less likely cause would be unicode/non-unicode glitches.
> 
> Anyway, let me know whether Icon now works on MS Win and Mac.
> 
> Thanks!
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxIcon.patch
Type: application/octet-stream
Size: 958 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050811/ac11fb51/wxIcon.obj

I also had to slightly change rakemswin.rb for the new swig procedure to work.

Sean

On 8/11/05, Sean Long <sean.m.long@gmail.com>
wrote:
> I had to make a small change to get Icon to compile on Windows the
> patch in attached. Will try Mac OS X hopefully tonight.
> 
> Sean
> 
> On 8/11/05, Kevin Smith <wxruby@qualitycode.com> wrote:
> > Sean Long wrote:
> > > I just checked out a fresh copy and had to tweak wxIcon.h to get
it to
> > > compile on Mac OS X and windows. The problem is with:
> > >
> > >       wxIcon(const wxString& filename,
> > >              wxBitmapType type = wxBITMAP_TYPE_XPM,
> > >              int desiredWidth=-1, int desiredHeight=-1);
> > >
> > > that signature is only used on GTK on other systems it is:
> > >
> > >       wxIcon(const wxString& name,
> > >              long type = wxBITMAP_TYPE_ICO_RESOURCE,
> > >              int desiredWidth = -1, int desiredHeight = -1);
> > >
> > > So I wrapped this in a #ifdef __WXGTK__ #else #endif
> >
> > I *FINALLY* figured out why this wasn''t working for me:
because
> > __WXGTK__ wasn''t defined, even though I''m using
wxGTK. Why? Because we
> > weren''t passing the wx cppflags to swig. I just changed the
rakefile to
> > do this, and now this kind of #if works in classes/include/wxXxxxx.h
files.
> >
> > So I grabbed a copy of my "official" wx icon.h file and used
that as a
> > starting point for wxIcon.h. I added the one conditional above, and
also
> > commented out some overloaded operators that don''t make sense
for us. A
> > visual comparison with the patch submitted by Sean looked good. I no
> > longer have to %ignore anything, and it compiles and seems to run.
> >
> > Hopefully it will work on other platforms also, now. If not, it would
> > probably be more differences between the GTK API and other platform
> > APIs. Another less likely cause would be unicode/non-unicode glitches.
> >
> > Anyway, let me know whether Icon now works on MS Win and Mac.
> >
> > Thanks!
> >
> > Kevin
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
> >
> 
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rakemswin.patch
Type: application/octet-stream
Size: 576 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050811/7443e994/rakemswin-0001.obj

After applying both of Sean''s patches I had a clean compile.

I decided to stop playing with the old samples and check out the new 
samples.  I''ll have a patched version of dialogs.rb later. 
Here''s one
quick fix:

Single Choice:   No OK button.  Fix:

        dialog = SingleChoiceDialog.new(self,
                                    "This is a small sample\n" +
                                    "A single-choice convenience
dialog",
                                    "Please select a value",
                                    choices, nil, OK | CANCEL)

I don''t understand why the ''nil'' needs to be there
yet, it was just
trial-and-error and could be wrong.  From the wxWindows documentation 
there shouldn''t be an argument after choices (although before it should
be the could of items, but I''m guessing we''re hiding that
complexity)..

Roy

Sean Long wrote:
>I also had to slightly change rakemswin.rb for the new swig procedure to
work.
>
>Sean
>
>On 8/11/05, Sean Long <sean.m.long@gmail.com> wrote:
>  
>
>>I had to make a small change to get Icon to compile on Windows the
>>patch in attached. Will try Mac OS X hopefully tonight.
>>
>>Sean
>>
>>On 8/11/05, Kevin Smith <wxruby@qualitycode.com> wrote:
>>    
>>
>>>Sean Long wrote:
>>>      
>>>
>>>>I just checked out a fresh copy and had to tweak wxIcon.h to get
it to
>>>>compile on Mac OS X and windows. The problem is with:
>>>>
>>>>      wxIcon(const wxString& filename,
>>>>             wxBitmapType type = wxBITMAP_TYPE_XPM,
>>>>             int desiredWidth=-1, int desiredHeight=-1);
>>>>
>>>>that signature is only used on GTK on other systems it is:
>>>>
>>>>      wxIcon(const wxString& name,
>>>>             long type = wxBITMAP_TYPE_ICO_RESOURCE,
>>>>             int desiredWidth = -1, int desiredHeight = -1);
>>>>
>>>>So I wrapped this in a #ifdef __WXGTK__ #else #endif
>>>>        
>>>>
>>>I *FINALLY* figured out why this wasn''t working for me:
because
>>>__WXGTK__ wasn''t defined, even though I''m using
wxGTK. Why? Because we
>>>weren''t passing the wx cppflags to swig. I just changed the
rakefile to
>>>do this, and now this kind of #if works in classes/include/wxXxxxx.h
files.
>>>
>>>So I grabbed a copy of my "official" wx icon.h file and
used that as a
>>>starting point for wxIcon.h. I added the one conditional above, and
also
>>>commented out some overloaded operators that don''t make
sense for us. A
>>>visual comparison with the patch submitted by Sean looked good. I no
>>>longer have to %ignore anything, and it compiles and seems to run.
>>>
>>>Hopefully it will work on other platforms also, now. If not, it
would
>>>probably be more differences between the GTK API and other platform
>>>APIs. Another less likely cause would be unicode/non-unicode
glitches.
>>>
>>>Anyway, let me know whether Icon now works on MS Win and Mac.
>>>
>>>Thanks!
>>>
>>>Kevin
>>>_______________________________________________
>>>wxruby-users mailing list
>>>wxruby-users@rubyforge.org
>>>http://rubyforge.org/mailman/listinfo/wxruby-users
>>>
>>>      
>>>
>>
>>    
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>wxruby-users mailing list
>>wxruby-users@rubyforge.org
>>http://rubyforge.org/mailman/listinfo/wxruby-users
>>    
>>

Sean Long wrote:
> I had to make a small change to get Icon to compile on Windows the
> patch in attached. Will try Mac OS X hopefully tonight.
Committed.

Kevin

Sean Long wrote:
> I also had to slightly change rakemswin.rb for the new swig procedure to
work.
Committed.

Kevin

> I had to make a small change to get Icon to compile on Windows the
> patch in attached. Will try Mac OS X hopefully tonight.
Works on OS X also. 

I just tried something that I thought should have worked, but didn''t.
I checked out the latest HEAD and just typed rake, usually I type rake
clean_src then rake and wouldn''t you know it, it does not compile. If
I do clean_src first then everything is run through swig and compiles
fine, this is a problem I have been suspecting might exist.

I believe it is because the #ifdef __WXGTK__ preprocessor symbols are
used during the swig process but not actually put in the generated
code. So if Kevin runs SWIG on his Linux machine and uploads that to
CVS all the guys using that platform will not have to use SWIG but all
us Windows and Mac guys will have to have SWIG installed or use a
precompiled version of wxRuby2. Now if the wxWidgets headers were all
exactly the same for each platform this would not be an issue but that
is something out of our control.

Any ideas on how to remedy this? Should we just expect anyone not
using a pre-built binary to have SWIG installed?

I am going to be out of town the next few days (to much traveling this
month) so don''t think I am ignoring any questions or comments on this.

Sean

Roy Sutton wrote:
> I decided to stop playing with the old samples and check out the new 
> samples.  I''ll have a patched version of dialogs.rb later. 
Here''s one
> quick fix:
> 
> Single Choice:   No OK button.  Fix:
> 
>        dialog = SingleChoiceDialog.new(self,
>                                    "This is a small sample\n" +
>                                    "A single-choice convenience
dialog",
>                                    "Please select a value",
>                                    choices, nil, OK | CANCEL)
Committed. Thanks.
> I don''t understand why the ''nil'' needs to be
there yet, it was just
> trial-and-error and could be wrong.  From the wxWindows documentation 
> there shouldn''t be an argument after choices (although before it
should
> be the could of items, but I''m guessing we''re hiding that
complexity)..
My wx docs show this constructor signature:

wxSingleChoiceDialog(wxWindow* parent,
	const wxString& message,
	const wxString& caption,
	int n, const wxString* choices,
	void** clientData = NULL,
	long style = wxOK | wxCANCEL | wxCENTRE,
	const wxPoint& pos = wxDefaultPosition)

You''re right that we (thanks to typemaps) merge n+choices into just an 
array of strings. The nil you pass in is the clientData. I''m not sure 
why the default style wasn''t working properly.

Kevin

hmm, that''s a good question...  I suppose tracking why default values 
aren''t working might be more important than changing the sample.

Kevin Smith wrote:
> You''re right that we (thanks to typemaps) merge n+choices into
just an
> array of strings. The nil you pass in is the clientData. I''m not
sure
> why the default style wasn''t working properly.

Sean Long wrote:
> So if Kevin runs SWIG on his Linux machine and uploads that to
> CVS all the guys using that platform will not have to use SWIG but all
> us Windows and Mac guys will have to have SWIG installed or use a
> precompiled version of wxRuby2. Now if the wxWidgets headers were all
> exactly the same for each platform this would not be an issue but that
> is something out of our control.
Doh! I remember thinking this through a while back...probably when 
deciding whether to go with wx 2.5.3 or 2.6. It is indeed a significant 
problem. I see two options:

1. Require SWIG to build from source. I don''t think that''s too
horrible
of a requirement. We''ll have binaries available soon for MS Win and OS 
X, and Linux folk are pretty used to building from source with weird 
tools. As long as "rake; rake install" works, it shouldn''t
matter. And
hopefully we''ll have .deb and .rpm binaries at some point, too.

2. Fool SWIG into generating both versions of each method that differs 
between versions, and then surround them #if __WXGTK__ etc. with a 
post-processor, so the compiler will do the right thing.

My current inclination is to require swig. Is there anyone building from 
source now who would consider having swig too high of a burden? Will 
that still be true for you after binaries are available?

Not checking in the src/ directory would also speed up CVS, which would 
make my life a bit sweeter.

Thanks,

Kevin

> My current inclination is to require swig. Is there anyone building from
> source now who would consider having swig too high of a burden? Will
> that still be true for you after binaries are available?
I like the advantages of requiring swig but it would be nice if it
wasn''t one specific swig version. Do the swig developers change APIs
that often that a certain codebase of .i files only works with a
specific version, or can the wxruby sources be cleaned up so they work
with a reasonable range of swig versions. I hope it''s the latter :)
Ubuntu will most likely have swig 1.3.24 in the upcoming release so a
packge should build-depend on that

thank you
Jani

Hi.

On Sat, Aug 13, 2005 at 11:22:21AM +0300, Jani Monoses
wrote:
> > My current inclination is to require swig. Is there anyone building
from
> > source now who would consider having swig too high of a burden? Will
> > that still be true for you after binaries are available?
I think requiring swig is not a big problem for most people. The only
thing that is a bit annoying is that a very recent version of swig is
required.
> I like the advantages of requiring swig but it would be nice if it
> wasn''t one specific swig version. Do the swig developers change
APIs
> that often that a certain codebase of .i files only works with a
> specific version, or can the wxruby sources be cleaned up so they work
> with a reasonable range of swig versions. I hope it''s the latter
:)
I think the thing is: swig has improved in 1.3.25 - if you look at
recent patches, many remove workarounds and "%ignore"s for things we
could not handle before (correct me if I''m wrong, that''s the
way I see
it).
> Ubuntu will most likely have swig 1.3.24 in the upcoming release so a
> packge should build-depend on that
I have built experimental packages with uupdate for Debian. There is no
change to the Debian patches and it compiles and works cleanly on my
system: http://portfolio16.de/debian/ - I don''t know if it works on
Ubuntu. Warning: The version number is lower then a regular swig release
but still could clash with a NMU of the new version...

Greetings Tobi

-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20050813/2d0e639e/attachment.bin

> I have built experimental packages with uupdate for Debian. There is no
> change to the Debian patches and it compiles and works cleanly on my
> system: http://portfolio16.de/debian/ - I don''t know if it works
on
> Ubuntu. Warning: The version number is lower then a regular swig release
> but still could clash with a NMU of the new version...
Ubuntu is in freeze so that''s the main reason that swig is unlikely to
get updated in this release, hence other packages cannot build-depend
on it. But for packaging I can still use the 1.3.25 generated .cpp
files so it''s not a problem to require it if indeed the newest swig
makes things easier in wxruby.

Jani

Jani Monoses wrote:
> Ubuntu will most likely have swig 1.3.24 in the upcoming release so a
> packge should build-depend on that
Ok. Since I''m a Unbuntu guy, I will target 1.3.24. The trick is 
detecting the proper version, since I know SWIG 1.3.22 has problems, and 
I don''t trust 1.3.23 without someone testing it first. SWIG 1.3.25
sends
its -version output to stdout, but 1.3.24 sends it to stderr, and there 
is no cross-platform way in ruby (without third-party libraries) to 
catch stderr output.

So I wrote a clever(?) hack that will figure out what version of SWIG 
you have, if it''s pre-1.3.25. I reverted my system to SWIG 1.3.24,
fixed
the one post-processor script that didn''t work, and was able to build 
wxruby2 and run a couple samples. There is a chance that my fix might 
fail with SWIG 1.3.25, and there is a chance that my hack won''t work 
properly on MS Windows. I''m optimistic on both of those, though.

I also removed the entire src/ directory from CVS, meaning that you must 
have SWIG to build from source. As was pointed out earlier, that was 
really a requirement anyway, unless you happened to be on wxGTK.

Please try out the new CVS head and let me know how it works for you.

Thanks,

Kevin

> On Sat, Aug 13, 2005 at 11:22:21AM +0300, Jani Monoses wrote:
> 
>>I like the advantages of requiring swig but it would be nice if it
>>wasn''t one specific swig version. Do the swig developers change
APIs
>>that often that a certain codebase of .i files only works with a
>>specific version, or can the wxruby sources be cleaned up so they work
>>with a reasonable range of swig versions. I hope it''s the
latter :)
I meant to reply to this in my other message.

Our post-process steps rely on certain internal SWIG generated code 
patterns, so they are more likely to break between SWIG versions than a 
simple wrapped app would be.

One of the things I dislike about SWIG is that a minor revision bump 
(such as 1.3.22 to 1.3.23) might contain some major changes that could 
break compatibility. It really means that you won''t know if something 
works with a different SWIG version until you try it.

Kevin

Swigging now.  Fails immediately because src directory doesn''t exist.  
Easy patch for that I''m sure.

Works fine with 1.3.25 on Windows.

Roy

P.S.  I added:

force_mkdir($src_dir)

As the first line in do_swig and it ensure the src directory exists.


Kevin Smith wrote:
> Jani Monoses wrote:
>
>> Ubuntu will most likely have swig 1.3.24 in the upcoming release so a
>> packge should build-depend on that
>
>
> Ok. Since I''m a Unbuntu guy, I will target 1.3.24. The trick is 
> detecting the proper version, since I know SWIG 1.3.22 has problems, 
> and I don''t trust 1.3.23 without someone testing it first. SWIG
1.3.25
> sends its -version output to stdout, but 1.3.24 sends it to stderr, 
> and there is no cross-platform way in ruby (without third-party 
> libraries) to catch stderr output.
>
> So I wrote a clever(?) hack that will figure out what version of SWIG 
> you have, if it''s pre-1.3.25. I reverted my system to SWIG 1.3.24,
> fixed the one post-processor script that didn''t work, and was able
to
> build wxruby2 and run a couple samples. There is a chance that my fix 
> might fail with SWIG 1.3.25, and there is a chance that my hack
won''t
> work properly on MS Windows. I''m optimistic on both of those,
though.
>
> I also removed the entire src/ directory from CVS, meaning that you 
> must have SWIG to build from source. As was pointed out earlier, that 
> was really a requirement anyway, unless you happened to be on wxGTK.
>
> Please try out the new CVS head and let me know how it works for you.
>
> Thanks,
>
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>

Roy Sutton wrote:
> Swigging now.  Fails immediately because src directory doesn''t
exist.
Strange. I did a completely-from-scratch CVS checkout and didn''t have 
that problem.
> P.S.  I added:
> 
> force_mkdir($src_dir)
> 
> As the first line in do_swig and it ensure the src directory exists.
I added this anyway, for safety. It has been committed. Thanks.
> Works fine with 1.3.25 on Windows.
Excellent. I have tagged the new head as 0.0.24. I wonder if this could 
become a release candidate for the "wxruby2 preview release"???

Kevin

Checked out HEAD and compiled and ran just fine on OS X. Doing a check
out is so much nicer now that src/ is empty.

using SWIG 1.3.25

Sean

On 8/14/05, Kevin Smith <wxruby@qualitycode.com>
wrote:
> Roy Sutton wrote:
> > Swigging now.  Fails immediately because src directory
doesn''t exist.
> 
> Strange. I did a completely-from-scratch CVS checkout and didn''t
have
> that problem.
> 
> > P.S.  I added:
> >
> > force_mkdir($src_dir)
> >
> > As the first line in do_swig and it ensure the src directory exists.
> 
> I added this anyway, for safety. It has been committed. Thanks.
> 
> > Works fine with 1.3.25 on Windows.
> 
> Excellent. I have tagged the new head as 0.0.24. I wonder if this could
> become a release candidate for the "wxruby2 preview release"???
> 
> Kevin
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Sean Long wrote:
> Checked out HEAD and compiled and ran just fine on OS X. Doing a check
> out is so much nicer now that src/ is empty.
> 
> using SWIG 1.3.25
Excellent. So it builds on Linux, Windows, and Mac. It works with SWIG 
1.3.24 and 1.3.25. As far as I know, all the samples run.

But we do have some pretty serious memory problems, since most of the 
samples will segfault on exit, and SpaceMonkeys segfaults pretty 
quickly. My guess is that the first garbage collection sweep crashes. 
Someone could confirm that by experimenting with GC.start calls in the 
samples.

I would like to fix those crashes before the preview release, even if it 
means leaking memory wildly by preventing things from being deleted. It 
would be better to (eventually) run out of memory than to immediately 
crash, for now. We''ll get all the problems fixed for real before the 
true 1.0 release.

I won''t have a lot of time this week, but hopefully I can put in a few 
hours to try to figure it out. Meanwhile, I think the other two highest 
priority tasks should be:

1. Adding the classes that were in wxruby 0.6 but aren''t yet in wxruby2
2. Adding/improving the samples

Kevin