thr3ads.net - wxruby development - [wxruby-development] pre-2.0 testing [Jan 2009]

If this information is useful, please help other people find it:
Share via:

Alex Fenton

2009-Jan-08 09:25 UTC

[wxruby-development] pre-2.0 testing

I had a burst of inspiration and went through the tracker fixing many 
items, including several very longstanding ones. I also added a few 
missed classes: Toolbook, Treebook, PropertySheetDialog and 
RichTextFormattingDialog.

There are two bugs left that are definitely wxRuby bugs that I think we 
should fix before 2.0 (Clipboard Text on GTK, TextCtrl#set_selection on 
Windows). So I''m hoping we can put out 2.0 shortly - perhaps next week.

So, I''d be really grateful for any time you can put in over the next 
week or so building from the latest SVN HEAD and seeing if there''s 
anything awry. I''ve been working mainly on OS X and Linux, so testing
on
Windows is particularly helpful.

If it''s useful I can make a Windows pre-release binary gem available - 
let me know.

On a side note, Mario and I are pleased to announce that Chauk-Mean has 
agreed to join the wxRuby development team. His contributions across the 
project have been really valuable to improving wxRuby''s quality.

cheers
alex

Chauk-Mean P

2009-Jan-08 10:43 UTC

head link

[wxruby-development] pre-2.0 testing

Hi all,

2009/1/8 Alex Fenton <alex at pressure.to>:> So, I''d be really grateful for any time you can put in over the
next week or
> so building from the latest SVN HEAD and seeing if there''s
anything awry.
> I''ve been working mainly on OS X and Linux, so testing on Windows
is
> particularly helpful.
I can test on Windows (mingw and VC2003/VC7.1) for both ruby-1.8.7 and
ruby-1.9.1-rc1.

Cheers.

Chauk-Mean.

Mario Steele

2009-Jan-08 11:34 UTC

head link

[wxruby-development] pre-2.0 testing

When attempting to build wxRuby on Xubuntu 8.10, everything runs fine, up to
when I get to the wxTreebook.  Specifically with wxTreebookEvent.h  (Which I
think needs to be wxTreeBookEvent, not sure though), here is the error:

rake aborted!
Don''t know how to build task
''/home/eumario/src/wxruby/swig/classes/include/wxTreebookEvent.h''


On Thu, Jan 8, 2009 at 4:43 AM, Chauk-Mean P <chauk.mean at gmail.com>
wrote:
> Hi all,
>
> 2009/1/8 Alex Fenton <alex at pressure.to>:
> > So, I''d be really grateful for any time you can put in over
the next week
> or
> > so building from the latest SVN HEAD and seeing if there''s
anything awry.
> > I''ve been working mainly on OS X and Linux, so testing on
Windows is
> > particularly helpful.
>
> I can test on Windows (mingw and VC2003/VC7.1) for both ruby-1.8.7 and
> ruby-1.9.1-rc1.
>
> Cheers.
>
> Chauk-Mean.
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090108/45b5adc8/attachment.html>

Alex Fenton

2009-Jan-08 13:25 UTC

head link

[wxruby-development] pre-2.0 testing

Mario Steele wrote:> When attempting to build wxRuby on Xubuntu 8.10, everything runs fine, 
> up to when I get to the wxTreebook.  Specifically with 
> wxTreebookEvent.h  (Which I think needs to be wxTreeBookEvent, not 
> sure though), here is the error:
>
> rake aborted!
> Don''t know how to build task 
>
''/home/eumario/src/wxruby/swig/classes/include/wxTreebookEvent.h''
The correct file name is wxTreebookEvent but it''s currently called 
wxTree*Book*Event. OS X doesn''t mind, and Windows can''t tell
the
difference. I''ll do an SVN move later today

thanks
alex

Alex Fenton

2009-Jan-08 13:30 UTC

head link

[wxruby-development] pre-2.0 testing

Chauk-Mean P wrote:> I can test on Windows (mingw and VC2003/VC7.1) for both ruby-1.8.7 and
> ruby-1.9.1-rc1.
Thanks - one environment I don''t have is VC7.1 + Ruby 1.9, and
haven''t
used VC7.1 + Ruby 1.8 for a while, so they would be good ones to test.

Just fixed a compile error on MingW with BookCtrlBase in SVN so you 
might want to update.

cheers
alex

Mario Steele

2009-Jan-08 16:32 UTC

head link

[wxruby-development] pre-2.0 testing

That''s what I figured, let me know when you have done it, and
I''ll update my
stuff.

On Thu, Jan 8, 2009 at 7:25 AM, Alex Fenton <alex at pressure.to> wrote:
> Mario Steele wrote:
>
>> When attempting to build wxRuby on Xubuntu 8.10, everything runs fine,
up
>> to when I get to the wxTreebook.  Specifically with wxTreebookEvent.h
>>  (Which I think needs to be wxTreeBookEvent, not sure though), here is
the
>> error:
>>
>> rake aborted!
>> Don''t know how to build task
>>
''/home/eumario/src/wxruby/swig/classes/include/wxTreebookEvent.h''
>>
>
> The correct file name is wxTreebookEvent but it''s currently called
> wxTree*Book*Event. OS X doesn''t mind, and Windows can''t
tell the difference.
> I''ll do an SVN move later today
>
> thanks
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090108/fd6bd5a3/attachment.html>

Alex Fenton

2009-Jan-08 20:09 UTC

head link

[wxruby-development] pre-2.0 testing

Mario Steele wrote:> That''s what I figured, let me know when you have done it, and
I''ll
> update my stuff.
Done. You might find you need to do something like "rm 
swig/classes/include/wxTree*" before "svn up", as Subversion
doesn''t
seem to like checking out the similarly named new file on top of the old one

a

Mario Steele

2009-Jan-08 20:19 UTC

head link

[wxruby-development] pre-2.0 testing

Not a problem, I will join #wxruby, and talk to you there, if your there.

On Thu, Jan 8, 2009 at 2:09 PM, Alex Fenton <alex at pressure.to> wrote:
> Mario Steele wrote:
>
>> That''s what I figured, let me know when you have done it, and
I''ll update
>> my stuff.
>>
>
> Done. You might find you need to do something like "rm
> swig/classes/include/wxTree*" before "svn up", as Subversion
doesn''t seem to
> like checking out the similarly named new file on top of the old one
>
>
> a
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090108/e2258438/attachment.html>

Chauk-Mean P

2009-Jan-09 23:19 UTC

head link

[wxruby-development] pre-2.0 testing

Hi,

Here are some feedbacks from building wxRuby-r1963 with VC7.1 :
* with ruby-1.8.7-p72 : the build and the produced gem work fine.

* with ruby-1.9.1-rc1 : I have the same problems as when I tried to
build with VC9.
So these problems are related with ruby-1.9.1 and not with the compiler version.

1/ Direct build with ruby-1.9.1-rc1 => the generation of source files
from SWIG cannot be done.

C:\Home\wxruby2>ruby -v
ruby 1.9.1 (2008-12-30 patchlevel-0 revision 21203) [i386-mswin32_71]

C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
(in C:/Home/wxruby2)
Enabling STATIC build
Enabling UNICODE build
** Invoke gem (first_time)
** Invoke default (first_time)
** Invoke lib/wxruby2.so (first_time)
** Invoke obj/AboutDialogInfo.obj (first_time)
** Invoke src/AboutDialogInfo.cpp (first_time)
** Invoke swig/classes/AboutDialogInfo.i (first_time, not_needed)
** Invoke C:/Home/wxruby2/swig/common.i (first_time, not_needed)
** Invoke C:/Home/wxruby2/swig/classes/include/wxAboutDialogInfo.h (first_time,
not_needed)
** Execute src/AboutDialogInfo.cpp
swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__ -IC:/Home/wxWidgets-2.8.9/lib
/vc_lib/mswu -D_UNICODE -DUNICODE -Iswig/custom -w401 -w801 -w515 -c++ -ruby -o
src/AboutDialogInfo.cpp swig/classes/AboutDialogInfo.i
Syntaxe du nom de fichier, de r?pertoire ou de volume incorrecte.
rake aborted!
Command failed with status (1): [swig -IC:/Home/wxWidgets-2.8.9/include -D_...]
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:968:in `block in sh''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `call''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `sh''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1069:in `sh''
C:/Home/wxruby2/rake/rakewx.rb:84:in `do_swig''
C:/Home/wxruby2/rake/rakewx.rb:139:in `block (2 levels) in <top
(required)>''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `call''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `block in execute''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `execute''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:574:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:560:in `invoke''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2016:in `invoke_task''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block (2 levels) in top_lev
el''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block in
top_level''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in `standard_exception_handling
''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1988:in `top_level''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1967:in `block in run''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in `standard_exception_handling
''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1964:in `run''
C:/opt/ruby19-msvc71/bin/rake.bat:39:in `<main>''

C:\Home\wxruby2>

=> "Syntaxe du nom de fichier, de r?pertoire ou de volume
incorrecte." means
Syntax of filename, directory or volume incorrect".


2/ The generation of source files from SWIG has been done with ruby-1.8.7-p72.
The build of wxRuby with ruby-1.9.1-rc1 produces :

C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
(in C:/Home/wxruby2)
Enabling STATIC build
Enabling UNICODE build
** Invoke gem (first_time)
** Invoke default (first_time)
** Invoke lib/wxruby2.so (first_time)
** Invoke obj/AboutDialogInfo.obj (first_time)
** Invoke src/AboutDialogInfo.cpp (first_time, not_needed)
** Invoke swig/classes/AboutDialogInfo.i (first_time, not_needed)
** Invoke C:/Home/wxruby2/swig/common.i (first_time, not_needed)
** Invoke C:/Home/wxruby2/swig/classes/include/wxAboutDialogInfo.h (first_time,
not_needed)
** Execute obj/AboutDialogInfo.obj
cl.exe -c  -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__ -IC:/Home/wxWidgets-2.8
.9/lib/vc_lib/mswu -D_UNICODE -DUNICODE -MD -Zi  -O2b2xg- -G6 -Zm200 -DNDEBUG  /
GR /EHsc -DSTRICT -DWIN32 -D__WIN32__ -DWINVER=0x0400 -D_WINDOWS /D__WINDOWS__ /
D__WIN95__  -I. -I C:/opt/ruby19-msvc71/include/ruby-1.9.1 -I C:/opt/ruby19-msvc
71/include/ruby-1.9.1/site_ruby -I C:/opt/ruby19-msvc71/include/ruby-1.9.1/vendo
r_ruby -I C:/opt/ruby19-msvc71/include/ruby-1.9.1/i386-mswin32_71 /Foobj/AboutDi
alogInfo.obj src/AboutDialogInfo.cpp
La ligne entr?e est trop longue.
rake aborted!
Command failed with status (1): [cl.exe -c  -IC:/Home/wxWidgets-2.8.9/inclu...]
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:968:in `block in sh''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `call''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `sh''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1069:in `sh''
C:/Home/wxruby2/rake/rakewx.rb:152:in `block in <top (required)>''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `call''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `block in execute''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `execute''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:574:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in invoke_prerequisite
s''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in invoke_with_call_ch
ain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:560:in `invoke''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2016:in `invoke_task''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block (2 levels) in top_lev
el''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `each''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block in
top_level''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in `standard_exception_handling
''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1988:in `top_level''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1967:in `block in run''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in `standard_exception_handling
''
C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1964:in `run''
C:/opt/ruby19-msvc71/bin/rake.bat:39:in `<main>''

C:\Home\wxruby2>

=> "La ligne entr?e est trop longue." means "Entered line is
too long".


Last thing, the treectrl sample (not the one in the BigDemo) does not
work well on both MinGW and VC7.1.
A scroll window seems to be displayed over the root item.
I cannot expand the root item by clicking on the + icon. The only way
I found to expand the tree is from the menu Tree \ Make the last item
visible.
On Linux, this sample works fine.

Cheers.

Chauk-Mean.

Mario Steele

2009-Jan-09 23:59 UTC

head link

[wxruby-development] pre-2.0 testing

My tests on Linux, and Windows has gone pretty good.  My biggest surprise,
is that BigDemo runs without crashing, after going through all of the
samples.  In previous versions I found trouble trying to get through half
the samples before BigDemo would crash.

A couple of minor notes that I have found going through the sample, and
compile process:

Samples:
  gridtablebase.rb
    Class MyMutableGridTable:
      @val not defined, succ called on Nil:NilClass

Compile:
  On Xubuntu, and more then likely on Kubuntu, and any other Linux distro
that doesn''t include the GTK Runtime by default, you need to ensure
that
there are symbolic links to most of the gtk, gdkpixbuff, gdk, and pango
libraries, so that the compiler can find it.  On Xubuntu atleast, after
installing stuff needed for GTK stuff, I needed to create symbolic links to
the installed version of each library, in order for the compiler to
recognize it being there.  Once the symbolic link was created, everything
compiled just fine.  It may be suggested that we ensure to let people know
about this, for the custom building.


I also updated the Wiki to correct formatting, and update the location of
GDIplus zip library we host.  There''s a missing file, that needs to be
added, which I will add later, it''s libgdiplus.def.  That is needed in
order
to compile properly.

Other then that, things are looking real good for the 2.0 release.


On Fri, Jan 9, 2009 at 5:19 PM, Chauk-Mean P <chauk.mean at gmail.com>
wrote:
> Hi,
>
> Here are some feedbacks from building wxRuby-r1963 with VC7.1 :
> * with ruby-1.8.7-p72 : the build and the produced gem work fine.
>
> * with ruby-1.9.1-rc1 : I have the same problems as when I tried to
> build with VC9.
> So these problems are related with ruby-1.9.1 and not with the compiler
> version.
>
> 1/ Direct build with ruby-1.9.1-rc1 => the generation of source files
> from SWIG cannot be done.
>
> C:\Home\wxruby2>ruby -v
> ruby 1.9.1 (2008-12-30 patchlevel-0 revision 21203) [i386-mswin32_71]
>
> C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
> (in C:/Home/wxruby2)
> Enabling STATIC build
> Enabling UNICODE build
> ** Invoke gem (first_time)
> ** Invoke default (first_time)
> ** Invoke lib/wxruby2.so (first_time)
> ** Invoke obj/AboutDialogInfo.obj (first_time)
> ** Invoke src/AboutDialogInfo.cpp (first_time)
> ** Invoke swig/classes/AboutDialogInfo.i (first_time, not_needed)
> ** Invoke C:/Home/wxruby2/swig/common.i (first_time, not_needed)
> ** Invoke C:/Home/wxruby2/swig/classes/include/wxAboutDialogInfo.h
> (first_time,
> not_needed)
> ** Execute src/AboutDialogInfo.cpp
> swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
> -IC:/Home/wxWidgets-2.8.9/lib
> /vc_lib/mswu -D_UNICODE -DUNICODE -Iswig/custom -w401 -w801 -w515 -c++
> -ruby -o
> src/AboutDialogInfo.cpp swig/classes/AboutDialogInfo.i
> Syntaxe du nom de fichier, de r?pertoire ou de volume incorrecte.
> rake aborted!
> Command failed with status (1): [swig -IC:/Home/wxWidgets-2.8.9/include
> -D_...]
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:968:in `block in sh''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `call''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `sh''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1069:in `sh''
> C:/Home/wxruby2/rake/rakewx.rb:84:in `do_swig''
> C:/Home/wxruby2/rake/rakewx.rb:139:in `block (2 levels) in <top
> (required)>''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `call''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `block in
execute''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `execute''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:574:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:560:in `invoke''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2016:in `invoke_task''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block (2 levels) in
> top_lev
> el''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block in
top_level''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in
> `standard_exception_handling
> ''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1988:in `top_level''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1967:in `block in run''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in
> `standard_exception_handling
> ''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1964:in `run''
> C:/opt/ruby19-msvc71/bin/rake.bat:39:in `<main>''
>
> C:\Home\wxruby2>
>
> => "Syntaxe du nom de fichier, de r?pertoire ou de volume
incorrecte."
> means
> Syntax of filename, directory or volume incorrect".
>
>
> 2/ The generation of source files from SWIG has been done with
> ruby-1.8.7-p72.
> The build of wxRuby with ruby-1.9.1-rc1 produces :
>
> C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
> (in C:/Home/wxruby2)
> Enabling STATIC build
> Enabling UNICODE build
> ** Invoke gem (first_time)
> ** Invoke default (first_time)
> ** Invoke lib/wxruby2.so (first_time)
> ** Invoke obj/AboutDialogInfo.obj (first_time)
> ** Invoke src/AboutDialogInfo.cpp (first_time, not_needed)
> ** Invoke swig/classes/AboutDialogInfo.i (first_time, not_needed)
> ** Invoke C:/Home/wxruby2/swig/common.i (first_time, not_needed)
> ** Invoke C:/Home/wxruby2/swig/classes/include/wxAboutDialogInfo.h
> (first_time,
> not_needed)
> ** Execute obj/AboutDialogInfo.obj
> cl.exe -c  -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
> -IC:/Home/wxWidgets-2.8
> .9/lib/vc_lib/mswu -D_UNICODE -DUNICODE -MD -Zi  -O2b2xg- -G6 -Zm200
> -DNDEBUG  /
> GR /EHsc -DSTRICT -DWIN32 -D__WIN32__ -DWINVER=0x0400 -D_WINDOWS
> /D__WINDOWS__ /
> D__WIN95__  -I. -I C:/opt/ruby19-msvc71/include/ruby-1.9.1 -I
> C:/opt/ruby19-msvc
> 71/include/ruby-1.9.1/site_ruby -I
> C:/opt/ruby19-msvc71/include/ruby-1.9.1/vendo
> r_ruby -I C:/opt/ruby19-msvc71/include/ruby-1.9.1/i386-mswin32_71
> /Foobj/AboutDi
> alogInfo.obj src/AboutDialogInfo.cpp
> La ligne entr?e est trop longue.
> rake aborted!
> Command failed with status (1): [cl.exe -c
>  -IC:/Home/wxWidgets-2.8.9/inclu...]
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:968:in `block in sh''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `call''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:981:in `sh''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1069:in `sh''
> C:/Home/wxruby2/rake/rakewx.rb:152:in `block in <top
(required)>''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `call''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:611:in `block in
execute''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:608:in `execute''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:574:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:584:in `block in
> invoke_prerequisite
> s''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:581:in
`invoke_prerequisites''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:573:in `block in
> invoke_with_call_ch
> ain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/monitor.rb:190:in
`mon_synchronize''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:567:in
`invoke_with_call_chain''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:560:in `invoke''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2016:in `invoke_task''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block (2 levels) in
> top_lev
> el''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `each''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1994:in `block in
top_level''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in
> `standard_exception_handling
> ''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1988:in `top_level''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1967:in `block in run''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:2033:in
> `standard_exception_handling
> ''
> C:/opt/ruby19-msvc71/lib/ruby/1.9.1/rake.rb:1964:in `run''
> C:/opt/ruby19-msvc71/bin/rake.bat:39:in `<main>''
>
> C:\Home\wxruby2>
>
> => "La ligne entr?e est trop longue." means "Entered line
is too long".
>
>
> Last thing, the treectrl sample (not the one in the BigDemo) does not
> work well on both MinGW and VC7.1.
> A scroll window seems to be displayed over the root item.
> I cannot expand the root item by clicking on the + icon. The only way
> I found to expand the tree is from the menu Tree \ Make the last item
> visible.
> On Linux, this sample works fine.
>
> Cheers.
>
> Chauk-Mean.
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090109/de260785/attachment.html>

Chauk-Mean P

2009-Jan-10 09:27 UTC

head link

[wxruby-development] pre-2.0 testing

Hi,

2009/1/10 Chauk-Mean P <chauk.mean at gmail.com>:>
> Last thing, the treectrl sample (not the one in the BigDemo) does not
> work well on both MinGW and VC7.1.
> A scroll window seems to be displayed over the root item.
> I cannot expand the root item by clicking on the + icon. The only way
> I found to expand the tree is from the menu Tree \ Make the last item
> visible.
> On Linux, this sample works fine.
The treectrl window was overlapped by the log window on Windows.
On Linux, it works a bit better but not completely fine (it''s the log
window that is overlapped by the treectrl window).
I''ve added a splitter window to fix this overlapping issue.
I''ve tested on both Windows and Linux and have just committed into SVN.

Cheers.

Chauk-Mean.

Alex Fenton

2009-Jan-12 18:05 UTC

head link

[wxruby-development] pre-2.0 testing

Hi Chauk-Mean

Thanks for trying out these buidls.

Chauk-Mean P wrote:> Here are some feedbacks from building wxRuby-r1963 with VC7.1 :
> * with ruby-1.8.7-p72 : the build and the produced gem work fine.
>
> * with ruby-1.9.1-rc1 : I have the same problems as when I tried to
> build with VC9.
> So these problems are related with ruby-1.9.1 and not with the compiler
version.
>
> 1/ Direct build with ruby-1.9.1-rc1 => the generation of source files
> from SWIG cannot be done.
>
> C:\Home\wxruby2>ruby -v
> ruby 1.9.1 (2008-12-30 patchlevel-0 revision 21203) [i386-mswin32_71]
>
> C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
>   
...> swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
-IC:/Home/wxWidgets-2.8.9/lib
> /vc_lib/mswu -D_UNICODE -DUNICODE -Iswig/custom -w401 -w801 -w515 -c++
-ruby -o
> src/AboutDialogInfo.cpp swig/classes/AboutDialogInfo.i
> Syntaxe du nom de fichier, de r?pertoire ou de volume incorrecte.
>   
Strange, I can''t see anything wrong with the swig invocation here ...
> 2/ The generation of source files from SWIG has been done with
ruby-1.8.7-p72.
> The build of wxRuby with ruby-1.9.1-rc1 produces :
>
> C:\Home\wxruby2>rake --trace gem WXRUBY_VERSION=1.9.10
>   
...> cl.exe -c  -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
-IC:/Home/wxWidgets-2.8
> .9/lib/vc_lib/mswu -D_UNICODE -DUNICODE -MD -Zi  -O2b2xg- -G6 -Zm200
-DNDEBUG  /
> GR /EHsc -DSTRICT -DWIN32 -D__WIN32__ -DWINVER=0x0400 -D_WINDOWS
/D__WINDOWS__ /
> D__WIN95__  -I. -I C:/opt/ruby19-msvc71/include/ruby-1.9.1 -I
C:/opt/ruby19-msvc
> 71/include/ruby-1.9.1/site_ruby -I
C:/opt/ruby19-msvc71/include/ruby-1.9.1/vendo
> r_ruby -I C:/opt/ruby19-msvc71/include/ruby-1.9.1/i386-mswin32_71
/Foobj/AboutDi
> alogInfo.obj src/AboutDialogInfo.cpp
> La ligne entr?e est trop longue.
>   
I find this also a bit strange because the final line of the whole 
compile sequence, the linker instruction is enormous because it 
references the object file for every class. So I don''t understand why
it
doesn''t error there.

It may be the options rather than the arguments that are bothering it. 
In which case we could reduce the length of the line by removing two 
includes which are probably unneeded. Could you try commenting out lines 
41 and 42 of rake/rakeconfigure.rb (the ones with ''sitehdrdir''
and
''vendorhdrdir'') and see if then compiles please?

Overall I''m minded to offer only MingW build for 1.9 on Windows. I
don''t
really have the resources at the moment to work on another a VC build.

MingW builds without problems (well apart from a ruby bug with rake) and 
if it''s like 1.8, the MingW wxRuby build will work with a VC ruby
build,
if installed with gem --force. We can try that out if you like.
> Last thing, the treectrl sample (not the one in the BigDemo) does not
> work well on both MinGW and VC7.1.
Thank you for your patch addressing this; it also improved things on OS X.

alex

Chauk-Mean P

2009-Jan-12 23:34 UTC

head link

[wxruby-development] pre-2.0 testing

Hi Alex,

2009/1/12 Alex Fenton <alex at pressure.to>:>> 1/ Direct build with ruby-1.9.1-rc1 => the generation of source
files
>> from SWIG cannot be done.
> ...
>>
>> swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
>> -IC:/Home/wxWidgets-2.8.9/lib
>> /vc_lib/mswu -D_UNICODE -DUNICODE -Iswig/custom -w401 -w801 -w515 -c++
>> -ruby -o
>> src/AboutDialogInfo.cpp swig/classes/AboutDialogInfo.i
>> Syntaxe du nom de fichier, de r?pertoire ou de volume incorrecte.
>>
>
> Strange, I can''t see anything wrong with the swig invocation here
...
>
Indeed, there is nothing wrong with the swig invocation ...
I just copy the command line into a text file/remove line breaks/paste
into the windows shell and it works ...

C:\Home\wxruby2>swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
-IC:/Home/wxWidgets-2.8.9/lib/vc_lib/mswu -D_UNICODE -DUNICODE
-Iswig/custom -w401 -w801 -w515 -c++ -ruby -o src/AboutDialogInfo.cpp
swig/classes/AboutDialogInfo.i

C:\Home\wxruby2>

Ruby 1.9 string management differs slightly from 1.8.
Maybe, this affects the command output from rake.
I tried to find where the command is executed in the different
rakefiles but I''m a bit lost at the moment.
>> 2/ The generation of source files from SWIG has been done with
>> ruby-1.8.7-p72.
>> The build of wxRuby with ruby-1.9.1-rc1 produces :
> ...
>> cl.exe -c  -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
>> -IC:/Home/wxWidgets-2.8
>> .9/lib/vc_lib/mswu -D_UNICODE -DUNICODE -MD -Zi  -O2b2xg- -G6 -Zm200
>> -DNDEBUG  /
>> GR /EHsc -DSTRICT -DWIN32 -D__WIN32__ -DWINVER=0x0400 -D_WINDOWS
>> /D__WINDOWS__ /
>> D__WIN95__  -I. -I C:/opt/ruby19-msvc71/include/ruby-1.9.1 -I
>> C:/opt/ruby19-msvc
>> 71/include/ruby-1.9.1/site_ruby -I
>> C:/opt/ruby19-msvc71/include/ruby-1.9.1/vendo
>> r_ruby -I C:/opt/ruby19-msvc71/include/ruby-1.9.1/i386-mswin32_71
>> /Foobj/AboutDi
>> alogInfo.obj src/AboutDialogInfo.cpp
>> La ligne entr?e est trop longue.
>>
>
> I find this also a bit strange because the final line of the whole compile
> sequence, the linker instruction is enormous because it references the
> object file for every class. So I don''t understand why it
doesn''t error
> there.
>
> It may be the options rather than the arguments that are bothering it. In
> which case we could reduce the length of the line by removing two includes
> which are probably unneeded. Could you try commenting out lines 41 and 42
of
> rake/rakeconfigure.rb (the ones with ''sitehdrdir'' and
''vendorhdrdir'') and
> see if then compiles please?
This doesn''t help.
But again, copy/remove line breaks/paste the command line fixes the
"line too long" error.

C:\Home\wxruby2>cl.exe -c  -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
-IC:/Ho
me/wxWidgets-2.8.9/lib/vc_lib/mswu -D_UNICODE -DUNICODE -MD -Zi  -O2b2xg- -G6 -Z
m200 -DNDEBUG  /GR /EHsc -DSTRICT -DWIN32 -D__WIN32__ -DWINVER=0x0400 -D_WINDOWS
 /D__WINDOWS__ /D__WIN95__  -I. -IC:/opt/ruby19-msvc71/include/ruby-1.9.1 -IC:/o
pt/ruby19-msvc71/include/ruby-1.9.1/site_ruby -IC:/opt/ruby19-msvc71/include/rub
y-1.9.1/vendor_ruby -IC:/opt/ruby19-msvc71/include/ruby-1.9.1/i386-mswin32_71 /F
oobj/AboutDialogInfo.obj src/AboutDialogInfo.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

AboutDialogInfo.cpp
C:/Home\wxWidgets-2.8.9\include\wx\filefn.h(110) : error C2628:
''_off_t'' followe
d by ''__int64'' is illegal (did you forget a
'';''?)

C:\Home\wxruby2>

Now, there is a more understandable error ...

> Overall I''m minded to offer only MingW build for 1.9 on Windows. I
don''t
> really have the resources at the moment to work on another a VC build.
Given my finding, can you please have a look in the rakefiles ?
> MingW builds without problems (well apart from a ruby bug with rake) and if
> it''s like 1.8, the MingW wxRuby build will work with a VC ruby
build, if
> installed with gem --force. We can try that out if you like.
Until now, wxRuby builds and works fine on MinGW.
The problem I have is that I can''t build the C++ richtextctrl sample.
The linker complains about some undefined GDI+ references.
(I''m looking forward the removal of the GDI+ requirements for building
wxRuby -
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221).
Hopefully, this doesn''t prevent the wxRuby richtextctrl to work.
I hope that we will not have problems later with MinGW.

>> Last thing, the treectrl sample (not the one in the BigDemo) does not
>> work well on both MinGW and VC7.1.
>
> Thank you for your patch addressing this; it also improved things on OS X.
Cool.

Cheers,

Chauk-Mean

Mario Steele

2009-Jan-13 01:57 UTC

head link

[wxruby-development] pre-2.0 testing

Hey Chauk,

On Mon, Jan 12, 2009 at 5:34 PM, Chauk-Mean P <chauk.mean at gmail.com>
wrote:
> Until now, wxRuby builds and works fine on MinGW.
> The problem I have is that I can''t build the C++ richtextctrl
sample.
> The linker complains about some undefined GDI+ references.
> (I''m looking forward the removal of the GDI+ requirements for
building
> wxRuby -
>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221
> ).
> Hopefully, this doesn''t prevent the wxRuby richtextctrl to work.
> I hope that we will not have problems later with MinGW.
>
This requires the Special GDI+ library, which I''ve updated the Zip
library
for it, you can find it here:
http://wxruby.rubyforge.org/wiki/wiki.pl?NotesOnMingW  It''s under the
Enabling Graphics Context.  There were some missing files, but the
instructions on how to do it will be simple to follow.  Try unziping the
GDI+ Archive, and copying over the files to their associated ones for MinGW,
then try giving the C++ RichText example a compile, see if it works.

> >> Last thing, the treectrl sample (not the one in the BigDemo) does
not
> >> work well on both MinGW and VC7.1.
> >
> > Thank you for your patch addressing this; it also improved things on
OS
> X.
>
> Cool.
>
> Cheers,
>
> Chauk-Mean
> _______________________________________________
> wxruby-development mailing list
> wxruby-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-development
>
Also, as for the problems with GTK that I experienced, I''ve tested on
another Debian based distro, that doesn''t use Gnome exclusively, and it
results in the same problem, that the Symbolic links from the .so to the
.so.0.xxxx.xx aren''t there.  Therefore, I''m committing a tool
called
fix_libraries.rb to the subversion, under the root, where the main Rakefile
is.  This should be included in with the source package that we release, and
subversion, along with a Readme, that I will also commit, explaining
it''s
usage.  The script only runs through, and verifies that there are symbolic
links going to where they need to be going.

Also, I''ve done a test compile on PuppyLinux (Man was that a trip), and
everything seems to be working, except for the Font Selection Dialog, it
segfaults on it, with the following backtrace:

# gdb --args ruby bigdemo.rb
GNU gdb 6.7
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-t2-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/ruby bigdemo.rb

(wxruby:30740): GLib-GObject-WARNING **: invalid cast from
`GtkScrolledWindow'' to `GtkWindow''

Program received signal SIGSEGV, Segmentation fault.
0xb687601f in g_signal_connect_data () from /usr/lib/libgobject-2.0.so.0
(gdb) whe
#0 0xb687601f in g_signal_connect_data () from /usr/lib/libgobject-2.0.so.0
#1 0xb6aec509 in gtk_window_set_screen () from /usr/lib/libgtk-x11-2.0.so.0
#2 0xb6aef4b0 in gtk_window_set_transient_for () from
/usr/lib/libgtk-x11-2.0.so.0
#3 0xb76eabb6 in wxFontDialog::DoCreate () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#4 0xb727b8c2 in SwigDirector_wxFontDialog (this=0x837c400, self=3056711380,
parent=0x8325208, data=@0x839e6f0)
  at /usr/include/wx-2.8/wx/fontdlg.h:36
#5 0xb727c131 in _wrap_new_wxFontDialog (nargs=2, args=0xbf9ccc00,
self=3056711380) at src/FontDialog.cpp:2330
#6 0x0805621c in call_cfunc (func=0xb727bf60 <_wrap_new_wxFontDialog>,
recv=3056711380, len=30740, argc=2, argv=0x0)
  at eval.c:5749
#7 0x0805f8a7 in rb_call0 (klass=3084036380, recv=3056711380, id=2961,
oid=2961, argc=2, argv=0xbf9ccc00, body=0xb7d2a8b8,
  flags=<value optimized out>) at eval.c:5904
#8 0x0805fbb0 in rb_call (klass=3084036380, recv=3056711380, mid=2961,
argc=2, argv=0xbf9ccc00, scope=1, self=6) at eval.c:6151
#9 0x0805fdcf in rb_obj_call_init (obj=3056711380, argc=2, argv=0xbf9ccc00)
at eval.c:7770
#10 0x08086053 in rb_class_new_instance (argc=2, argv=0xbf9ccc00,
klass=3084036380) at object.c:1644
#11 0x0805621c in call_cfunc (func=0x8086030 <rb_class_new_instance>,
recv=3084036380, len=30740, argc=2, argv=0x0) at eval.c:5749
#12 0x0805f8a7 in rb_call0 (klass=3085344000, recv=3084036380, id=3361,
oid=3361, argc=2, argv=0xbf9ccc00, body=0xb7e68a7c,
  flags=<value optimized out>) at eval.c:5904
#13 0x0805fbb0 in rb_call (klass=3085344000, recv=3084036380, mid=3361,
argc=2, argv=0xbf9ccc00, scope=0, self=3056992680)
  at eval.c:6151
#14 0x0805b93c in rb_eval (self=3056992680, n=<value optimized out>) at
eval.c:3492
#15 0x0805c9cc in rb_eval (self=3056992680, n=<value optimized out>) at
eval.c:3677
#16 0x0805f7fe in rb_call0 (klass=3056993600, recv=3056992680, id=84937,
oid=84937, argc=1, argv=0xbf9cd2b0, body=0xb6366954,
  flags=<value optimized out>) at eval.c:6055
#17 0x0805fbb0 in rb_call (klass=3056993600, recv=3056992680, mid=84937,
argc=1, argv=0xbf9cd2b0, scope=1, self=3056992680)
  at eval.c:6151
#18 0x0805ba53 in rb_eval (self=3056992680, n=<value optimized out>) at
eval.c:3507
#19 0x0805ab99 in rb_yield_0 (val=3056711520, self=3056992680, klass=<value
optimized out>, flags=<value optimized out>, avalue=0)
  at eval.c:5077
#20 0x0806435a in proc_invoke (proc=3056991680, args=3056711520, self=6,
klass=0) at eval.c:8840
#21 0x0805f8a7 in rb_call0 (klass=3085277120, recv=3056991680, id=5521,
oid=5521, argc=1, argv=0xbf9cd990, body=0xb7e5970c,
  flags=<value optimized out>) at eval.c:5904
#22 0x0805fbb0 in rb_call (klass=3085277120, recv=3056991680, mid=5521,
argc=1, argv=0xbf9cd990, scope=1, self=6) at eval.c:6151
#23 0x08060003 in vafuncall (recv=3056991680, mid=5521, n=1, ar=0xbf9cd9f4)
at eval.c:6228
#24 0x0806014e in rb_funcall (recv=3056991680, mid=5521, n=1) at eval.c:6245
#25 0xb7266396 in wxRbCallback::EventThunker (this=0x8325208,
event=@0xbf9ce0d8) at src/EvtHandler.cpp:1803
#26 0xb767f38f in wxEvtHandler::ProcessEventIfMatches () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
---Type <return> to continue, or q <return> to quit---
#27 0xb767f457 in wxEvtHandler::SearchDynamicEventTable () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#28 0xb7680962 in wxEvtHandler::ProcessEvent () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#29 0xb7265a5f in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0xbf9cdce0,
self=3056992680) at src/EvtHandler.cpp:2680
#30 0x0805621c in call_cfunc (func=0xb72659d0
<_wrap_wxEvtHandler_ProcessEvent>, recv=3056992680, len=30740, argc=1,
argv=0x0)
  at eval.c:5749
#31 0x0805f8a7 in rb_call0 (klass=3084099980, recv=3056992680, id=25401,
oid=25401, argc=1, argv=0xbf9cdce0, body=0xb7d3a010,
  flags=<value optimized out>) at eval.c:5904
#32 0x0805fbb0 in rb_call (klass=3084099980, recv=3056992680, mid=25401,
argc=1, argv=0xbf9cdce0, scope=1, self=6) at eval.c:6151
#33 0x08060003 in vafuncall (recv=3056992680, mid=25401, n=1, ar=0xbf9cdd44)
at eval.c:6228
#34 0x0806014e in rb_funcall (recv=3056992680, mid=25401, n=1) at
eval.c:6245
#35 0xb73909d6 in SwigDirector_wxPanel::ProcessEvent (this=0x8325208,
event=@0xbf9ce0d8) at src/Panel.cpp:2342
#36 0xb776fc38 in wxWindowBase::TryParent () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#37 0xb7680928 in wxEvtHandler::ProcessEvent () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#38 0xb7265a5f in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0xbf9ce010,
self=3056992140) at src/EvtHandler.cpp:2680
#39 0x0805621c in call_cfunc (func=0xb72659d0
<_wrap_wxEvtHandler_ProcessEvent>, recv=3056992140, len=30740, argc=1,
argv=0x0)
  at eval.c:5749
#40 0x0805f8a7 in rb_call0 (klass=3084099980, recv=3056992140, id=25401,
oid=25401, argc=1, argv=0xbf9ce010, body=0xb7d3a010,
  flags=<value optimized out>) at eval.c:5904
#41 0x0805fbb0 in rb_call (klass=3084099980, recv=3056992140, mid=25401,
argc=1, argv=0xbf9ce010, scope=1, self=6) at eval.c:6151
#42 0x08060003 in vafuncall (recv=3056992140, mid=25401, n=1, ar=0xbf9ce074)
at eval.c:6228
#43 0x0806014e in rb_funcall (recv=3056992140, mid=25401, n=1) at
eval.c:6245
#44 0xb71e3946 in SwigDirector_wxButton::ProcessEvent (this=0x8326690,
event=@0xbf9ce0d8) at src/Button.cpp:2343
#45 0xb76db383 in gtk_button_clicked_callback () from
/usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
#46 0xb68725c6 in g_cclosure_marshal_VOID__VOID () from
/usr/lib/libgobject-2.0.so.0
#47 0xb686b3c4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#48 0xb68743d5 in ?? () from /usr/lib/libgobject-2.0.so.0
#49 0x0834a6b0 in ?? ()
#50 0x00000000 in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
#


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

Mario Steele

2009-Jan-13 07:48 UTC

head link

[wxruby-development] pre-2.0 testing

This may be a problem with GTK itself, I found that the version that comes
with this copy of PuppyLinux that I''m using, is 2.12.1, I''m
compiling 2.14.7
right now, to see if that will sovle the problem.

On Mon, Jan 12, 2009 at 7:57 PM, Mario Steele <mario at ruby-im.net>
wrote:
> Hey Chauk,
>
> On Mon, Jan 12, 2009 at 5:34 PM, Chauk-Mean P <chauk.mean at
gmail.com>wrote:
>
>> Until now, wxRuby builds and works fine on MinGW.
>> The problem I have is that I can''t build the C++ richtextctrl
sample.
>> The linker complains about some undefined GDI+ references.
>> (I''m looking forward the removal of the GDI+ requirements for
building
>> wxRuby -
>>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221
>> ).
>> Hopefully, this doesn''t prevent the wxRuby richtextctrl to
work.
>> I hope that we will not have problems later with MinGW.
>>
>
> This requires the Special GDI+ library, which I''ve updated the Zip
library
> for it, you can find it here:
> http://wxruby.rubyforge.org/wiki/wiki.pl?NotesOnMingW  It''s under
the
> Enabling Graphics Context.  There were some missing files, but the
> instructions on how to do it will be simple to follow.  Try unziping the
> GDI+ Archive, and copying over the files to their associated ones for
MinGW,
> then try giving the C++ RichText example a compile, see if it works.
>
>
>> >> Last thing, the treectrl sample (not the one in the BigDemo)
does not
>> >> work well on both MinGW and VC7.1.
>> >
>> > Thank you for your patch addressing this; it also improved things
on OS
>> X.
>>
>> Cool.
>>
>> Cheers,
>>
>> Chauk-Mean
>> _______________________________________________
>> wxruby-development mailing list
>> wxruby-development at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/wxruby-development
>>
>
> Also, as for the problems with GTK that I experienced, I''ve tested
on
> another Debian based distro, that doesn''t use Gnome exclusively,
and it
> results in the same problem, that the Symbolic links from the .so to the
> .so.0.xxxx.xx aren''t there.  Therefore, I''m committing a
tool called
> fix_libraries.rb to the subversion, under the root, where the main Rakefile
> is.  This should be included in with the source package that we release,
and
> subversion, along with a Readme, that I will also commit, explaining
it''s
> usage.  The script only runs through, and verifies that there are symbolic
> links going to where they need to be going.
>
> Also, I''ve done a test compile on PuppyLinux (Man was that a
trip), and
> everything seems to be working, except for the Font Selection Dialog, it
> segfaults on it, with the following backtrace:
>
> # gdb --args ruby bigdemo.rb
> GNU gdb 6.7
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
> and "show warranty" for details.
> This GDB was configured as "i486-t2-linux-gnu"...
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) run
> Starting program: /usr/bin/ruby bigdemo.rb
>
> (wxruby:30740): GLib-GObject-WARNING **: invalid cast from
> `GtkScrolledWindow'' to `GtkWindow''
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb687601f in g_signal_connect_data () from /usr/lib/libgobject-2.0.so.0
> (gdb) whe
> #0 0xb687601f in g_signal_connect_data () from /usr/lib/libgobject-2.0.so.0
> #1 0xb6aec509 in gtk_window_set_screen () from /usr/lib/libgtk-x11-2.0.so.0
> #2 0xb6aef4b0 in gtk_window_set_transient_for () from
> /usr/lib/libgtk-x11-2.0.so.0
> #3 0xb76eabb6 in wxFontDialog::DoCreate () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #4 0xb727b8c2 in SwigDirector_wxFontDialog (this=0x837c400,
> self=3056711380, parent=0x8325208, data=@0x839e6f0)
>   at /usr/include/wx-2.8/wx/fontdlg.h:36
> #5 0xb727c131 in _wrap_new_wxFontDialog (nargs=2, args=0xbf9ccc00,
> self=3056711380) at src/FontDialog.cpp:2330
> #6 0x0805621c in call_cfunc (func=0xb727bf60
<_wrap_new_wxFontDialog>,
> recv=3056711380, len=30740, argc=2, argv=0x0)
>   at eval.c:5749
> #7 0x0805f8a7 in rb_call0 (klass=3084036380, recv=3056711380, id=2961,
> oid=2961, argc=2, argv=0xbf9ccc00, body=0xb7d2a8b8,
>   flags=<value optimized out>) at eval.c:5904
> #8 0x0805fbb0 in rb_call (klass=3084036380, recv=3056711380, mid=2961,
> argc=2, argv=0xbf9ccc00, scope=1, self=6) at eval.c:6151
> #9 0x0805fdcf in rb_obj_call_init (obj=3056711380, argc=2, argv=0xbf9ccc00)
> at eval.c:7770
> #10 0x08086053 in rb_class_new_instance (argc=2, argv=0xbf9ccc00,
> klass=3084036380) at object.c:1644
> #11 0x0805621c in call_cfunc (func=0x8086030 <rb_class_new_instance>,
> recv=3084036380, len=30740, argc=2, argv=0x0) at eval.c:5749
> #12 0x0805f8a7 in rb_call0 (klass=3085344000, recv=3084036380, id=3361,
> oid=3361, argc=2, argv=0xbf9ccc00, body=0xb7e68a7c,
>   flags=<value optimized out>) at eval.c:5904
> #13 0x0805fbb0 in rb_call (klass=3085344000, recv=3084036380, mid=3361,
> argc=2, argv=0xbf9ccc00, scope=0, self=3056992680)
>   at eval.c:6151
> #14 0x0805b93c in rb_eval (self=3056992680, n=<value optimized out>)
at
> eval.c:3492
> #15 0x0805c9cc in rb_eval (self=3056992680, n=<value optimized out>)
at
> eval.c:3677
> #16 0x0805f7fe in rb_call0 (klass=3056993600, recv=3056992680, id=84937,
> oid=84937, argc=1, argv=0xbf9cd2b0, body=0xb6366954,
>   flags=<value optimized out>) at eval.c:6055
> #17 0x0805fbb0 in rb_call (klass=3056993600, recv=3056992680, mid=84937,
> argc=1, argv=0xbf9cd2b0, scope=1, self=3056992680)
>   at eval.c:6151
> #18 0x0805ba53 in rb_eval (self=3056992680, n=<value optimized out>)
at
> eval.c:3507
> #19 0x0805ab99 in rb_yield_0 (val=3056711520, self=3056992680,
klass=<value
> optimized out>, flags=<value optimized out>, avalue=0)
>   at eval.c:5077
> #20 0x0806435a in proc_invoke (proc=3056991680, args=3056711520, self=6,
> klass=0) at eval.c:8840
> #21 0x0805f8a7 in rb_call0 (klass=3085277120, recv=3056991680, id=5521,
> oid=5521, argc=1, argv=0xbf9cd990, body=0xb7e5970c,
>   flags=<value optimized out>) at eval.c:5904
> #22 0x0805fbb0 in rb_call (klass=3085277120, recv=3056991680, mid=5521,
> argc=1, argv=0xbf9cd990, scope=1, self=6) at eval.c:6151
> #23 0x08060003 in vafuncall (recv=3056991680, mid=5521, n=1, ar=0xbf9cd9f4)
> at eval.c:6228
> #24 0x0806014e in rb_funcall (recv=3056991680, mid=5521, n=1) at
> eval.c:6245
> #25 0xb7266396 in wxRbCallback::EventThunker (this=0x8325208,
> event=@0xbf9ce0d8) at src/EvtHandler.cpp:1803
> #26 0xb767f38f in wxEvtHandler::ProcessEventIfMatches () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> ---Type <return> to continue, or q <return> to quit---
> #27 0xb767f457 in wxEvtHandler::SearchDynamicEventTable () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #28 0xb7680962 in wxEvtHandler::ProcessEvent () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #29 0xb7265a5f in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0xbf9cdce0,
> self=3056992680) at src/EvtHandler.cpp:2680
> #30 0x0805621c in call_cfunc (func=0xb72659d0
> <_wrap_wxEvtHandler_ProcessEvent>, recv=3056992680, len=30740,
argc=1,
> argv=0x0)
>   at eval.c:5749
> #31 0x0805f8a7 in rb_call0 (klass=3084099980, recv=3056992680, id=25401,
> oid=25401, argc=1, argv=0xbf9cdce0, body=0xb7d3a010,
>   flags=<value optimized out>) at eval.c:5904
> #32 0x0805fbb0 in rb_call (klass=3084099980, recv=3056992680, mid=25401,
> argc=1, argv=0xbf9cdce0, scope=1, self=6) at eval.c:6151
> #33 0x08060003 in vafuncall (recv=3056992680, mid=25401, n=1,
> ar=0xbf9cdd44) at eval.c:6228
> #34 0x0806014e in rb_funcall (recv=3056992680, mid=25401, n=1) at
> eval.c:6245
> #35 0xb73909d6 in SwigDirector_wxPanel::ProcessEvent (this=0x8325208,
> event=@0xbf9ce0d8) at src/Panel.cpp:2342
> #36 0xb776fc38 in wxWindowBase::TryParent () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #37 0xb7680928 in wxEvtHandler::ProcessEvent () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #38 0xb7265a5f in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0xbf9ce010,
> self=3056992140) at src/EvtHandler.cpp:2680
> #39 0x0805621c in call_cfunc (func=0xb72659d0
> <_wrap_wxEvtHandler_ProcessEvent>, recv=3056992140, len=30740,
argc=1,
> argv=0x0)
>   at eval.c:5749
> #40 0x0805f8a7 in rb_call0 (klass=3084099980, recv=3056992140, id=25401,
> oid=25401, argc=1, argv=0xbf9ce010, body=0xb7d3a010,
>   flags=<value optimized out>) at eval.c:5904
> #41 0x0805fbb0 in rb_call (klass=3084099980, recv=3056992140, mid=25401,
> argc=1, argv=0xbf9ce010, scope=1, self=6) at eval.c:6151
> #42 0x08060003 in vafuncall (recv=3056992140, mid=25401, n=1,
> ar=0xbf9ce074) at eval.c:6228
> #43 0x0806014e in rb_funcall (recv=3056992140, mid=25401, n=1) at
> eval.c:6245
> #44 0xb71e3946 in SwigDirector_wxButton::ProcessEvent (this=0x8326690,
> event=@0xbf9ce0d8) at src/Button.cpp:2343
> #45 0xb76db383 in gtk_button_clicked_callback () from
> /usr/lib/ruby/site_ruby/1.8/i686-linux/wxruby2.so
> #46 0xb68725c6 in g_cclosure_marshal_VOID__VOID () from
> /usr/lib/libgobject-2.0.so.0
> #47 0xb686b3c4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #48 0xb68743d5 in ?? () from /usr/lib/libgobject-2.0.so.0
> #49 0x0834a6b0 in ?? ()
> #50 0x00000000 in ?? ()
> (gdb) q
> The program is running. Exit anyway? (y or n) y
> #
>
>
>
> --
> Mario Steele
> http://www.trilake.net
> http://www.ruby-im.net
> http://rubyforge.org/projects/wxruby/
> http://rubyforge.org/projects/wxride/
>


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

Chauk-Mean P

2009-Jan-13 09:53 UTC

head link

[wxruby-development] pre-2.0 testing

Hi Mario,

2009/1/13 Mario Steele <mario at ruby-im.net>:> Hey Chauk,
>
> On Mon, Jan 12, 2009 at 5:34 PM, Chauk-Mean P <chauk.mean at
gmail.com> wrote:
>>
>> Until now, wxRuby builds and works fine on MinGW.
>> The problem I have is that I can''t build the C++ richtextctrl
sample.
>> The linker complains about some undefined GDI+ references.
>> (I''m looking forward the removal of the GDI+ requirements for
building
>> wxRuby -
>>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221).
>> Hopefully, this doesn''t prevent the wxRuby richtextctrl to
work.
>> I hope that we will not have problems later with MinGW.
>
> This requires the Special GDI+ library, which I''ve updated the Zip
library
> for it, you can find it here:
> http://wxruby.rubyforge.org/wiki/wiki.pl?NotesOnMingW  It''s under
the
> Enabling Graphics Context.  There were some missing files, but the
> instructions on how to do it will be simple to follow.  Try unziping the
> GDI+ Archive, and copying over the files to their associated ones for
MinGW,
> then try giving the C++ RichText example a compile, see if it works.
>
I still have the problem. The richtext and the drawing samples cannot be built.
Conversely, the controls and the dialogs samples have been built successfully.

Chauk-Mean.

Mario Steele

2009-Jan-13 10:59 UTC

head link

[wxruby-development] pre-2.0 testing

Have you tried building wxRuby, and trying the Graphics, and the RichText
controls there, to see if it will work?

On Tue, Jan 13, 2009 at 3:53 AM, Chauk-Mean P <chauk.mean at gmail.com>
wrote:
> Hi Mario,
>
> 2009/1/13 Mario Steele <mario at ruby-im.net>:
> > Hey Chauk,
> >
> > On Mon, Jan 12, 2009 at 5:34 PM, Chauk-Mean P <chauk.mean at
gmail.com>
> wrote:
> >>
> >> Until now, wxRuby builds and works fine on MinGW.
> >> The problem I have is that I can''t build the C++
richtextctrl sample.
> >> The linker complains about some undefined GDI+ references.
> >> (I''m looking forward the removal of the GDI+ requirements
for building
> >> wxRuby -
> >>
>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221
> ).
> >> Hopefully, this doesn''t prevent the wxRuby richtextctrl
to work.
> >> I hope that we will not have problems later with MinGW.
> >
> > This requires the Special GDI+ library, which I''ve updated
the Zip
> library
> > for it, you can find it here:
> > http://wxruby.rubyforge.org/wiki/wiki.pl?NotesOnMingW  It''s
under the
> > Enabling Graphics Context.  There were some missing files, but the
> > instructions on how to do it will be simple to follow.  Try unziping
the
> > GDI+ Archive, and copying over the files to their associated ones for
> MinGW,
> > then try giving the C++ RichText example a compile, see if it works.
> >
>
> I still have the problem. The richtext and the drawing samples cannot be
> built.
> Conversely, the controls and the dialogs samples have been built
> successfully.
>
> Chauk-Mean.
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090113/1d9d4b3f/attachment-0001.html>

Alex Fenton

2009-Jan-13 11:50 UTC

head link

[wxruby-development] pre-2.0 testing

Chauk-Mean P wrote:> Indeed, there is nothing wrong with the swig invocation ...
> I just copy the command line into a text file/remove line breaks/paste
> into the windows shell and it works ...
>
> C:\Home\wxruby2>swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
> -IC:/Home/wxWidgets-2.8.9/lib/vc_lib/mswu -D_UNICODE -DUNICODE
> -Iswig/custom -w401 -w801 -w515 -c++ -ruby -o src/AboutDialogInfo.cpp
> swig/classes/AboutDialogInfo.i
>
> C:\Home\wxruby2>
>
> Ruby 1.9 string management differs slightly from 1.8.
> Maybe, this affects the command output from rake.
> I tried to find where the command is executed in the different
> rakefiles but I''m a bit lost at the moment.
>   
I haven''t run into problems on any other platforms. The command is 
executed in a function called ''do_swig'' which is in
rake/rakewx.rb. And
yes, the rakefiles are like tangled spaghetti..> This doesn''t help.
> But again, copy/remove line breaks/paste the command line fixes the
> "line too long" error.
>   
Sounds like there is something odd going on with rake or system calls in 
mswin32 with 1.9, rather than something wrong in the rakefiles themselves.
> AboutDialogInfo.cpp
> C:/Home\wxWidgets-2.8.9\include\wx\filefn.h(110) : error C2628:
''_off_t'' followe
> d by ''__int64'' is illegal (did you forget a
'';''?)
>
> C:\Home\wxruby2>
>
> Now, there is a more understandable error ...
>   
Hehe ... not a lot more. The error is coming from the wx headerS!
>> Overall I''m minded to offer only MingW build for 1.9 on
Windows. I don''t
>> really have the resources at the moment to work on another a VC build.
>>     
>
> Given my finding, can you please have a look in the rakefiles ?
>   
Well, if the commands work on the command line, but when fired from the 
rakefiles, it''s probably not the rakefiles themselves that are the
problem.

One thing to try might be an innocuous command using rake''s sh, adding 
it to the start of the rakefile, eg

sh "dir C:/Windows/"

>> MingW builds without problems (well apart from a ruby bug with rake)
and if
>> it''s like 1.8, the MingW wxRuby build will work with a VC ruby
build, if
>> installed with gem --force. We can try that out if you like.
>>     
>
> Until now, wxRuby builds and works fine on MinGW.
> The problem I have is that I can''t build the C++ richtextctrl
sample.
> The linker complains about some undefined GDI+ references.
> (I''m looking forward the removal of the GDI+ requirements for
building
> wxRuby -
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221).
>   
I looked again at this and it should already be possible to build 
without all the Graphics* classes. The rakefiles check whether 
wxUSE_GRAPHICS_CONTEXT is set to 0 in wxWidget''s setup.h (see 
rakeconfigure.rb), and if so exclude these files. This certainly used to 
work - could you double-check the setting is right in your build of 
wxWidgets please?> Hopefully, this doesn''t prevent the wxRuby richtextctrl to work.
> I hope that we will not have problems later with MinGW.
>   
I''ve got no problems with building either the C++ samples or running 
your RichTextCtrl with MingW (either version of Ruby) at the moment.

cheers
alex

Mario Steele

2009-Jan-13 12:29 UTC

head link

[wxruby-development] pre-2.0 testing

Alright, you can ignore my email with the gdb backtrace, I''ve finally
finished the compile of GTK, XFCE, wxWidgets and wxRuby, and the
wxFontDialog no longer crashes on me.  So, it looks good now.

On Tue, Jan 13, 2009 at 5:50 AM, Alex Fenton <alex at pressure.to> wrote:
> Chauk-Mean P wrote:
>
>> Indeed, there is nothing wrong with the swig invocation ...
>> I just copy the command line into a text file/remove line breaks/paste
>> into the windows shell and it works ...
>>
>> C:\Home\wxruby2>swig -IC:/Home/wxWidgets-2.8.9/include -D__WXMSW__
>> -IC:/Home/wxWidgets-2.8.9/lib/vc_lib/mswu -D_UNICODE -DUNICODE
>> -Iswig/custom -w401 -w801 -w515 -c++ -ruby -o src/AboutDialogInfo.cpp
>> swig/classes/AboutDialogInfo.i
>>
>> C:\Home\wxruby2>
>>
>> Ruby 1.9 string management differs slightly from 1.8.
>> Maybe, this affects the command output from rake.
>> I tried to find where the command is executed in the different
>> rakefiles but I''m a bit lost at the moment.
>>
>>
>
> I haven''t run into problems on any other platforms. The command is
executed
> in a function called ''do_swig'' which is in
rake/rakewx.rb. And yes, the
> rakefiles are like tangled spaghetti..
>
>> This doesn''t help.
>> But again, copy/remove line breaks/paste the command line fixes the
>> "line too long" error.
>>
>>
>
> Sounds like there is something odd going on with rake or system calls in
> mswin32 with 1.9, rather than something wrong in the rakefiles themselves.
>
>  AboutDialogInfo.cpp
>> C:/Home\wxWidgets-2.8.9\include\wx\filefn.h(110) : error C2628:
''_off_t''
>> followe
>> d by ''__int64'' is illegal (did you forget a
'';''?)
>>
>> C:\Home\wxruby2>
>>
>> Now, there is a more understandable error ...
>>
>>
>
> Hehe ... not a lot more. The error is coming from the wx headerS!
>
>  Overall I''m minded to offer only MingW build for 1.9 on Windows.
I don''t
>>> really have the resources at the moment to work on another a VC
build.
>>>
>>>
>>
>> Given my finding, can you please have a look in the rakefiles ?
>>
>>
>
> Well, if the commands work on the command line, but when fired from the
> rakefiles, it''s probably not the rakefiles themselves that are the
problem.
>
> One thing to try might be an innocuous command using rake''s sh,
adding it
> to the start of the rakefile, eg
>
> sh "dir C:/Windows/"
>
>
>  MingW builds without problems (well apart from a ruby bug with rake) and
>>> if
>>> it''s like 1.8, the MingW wxRuby build will work with a VC
ruby build, if
>>> installed with gem --force. We can try that out if you like.
>>>
>>>
>>
>> Until now, wxRuby builds and works fine on MinGW.
>> The problem I have is that I can''t build the C++ richtextctrl
sample.
>> The linker complains about some undefined GDI+ references.
>> (I''m looking forward the removal of the GDI+ requirements for
building
>> wxRuby -
>>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221
>> ).
>>
>>
>
> I looked again at this and it should already be possible to build without
> all the Graphics* classes. The rakefiles check whether
> wxUSE_GRAPHICS_CONTEXT is set to 0 in wxWidget''s setup.h (see
> rakeconfigure.rb), and if so exclude these files. This certainly used to
> work - could you double-check the setting is right in your build of
> wxWidgets please?
>
>> Hopefully, this doesn''t prevent the wxRuby richtextctrl to
work.
>> I hope that we will not have problems later with MinGW.
>>
>>
>
> I''ve got no problems with building either the C++ samples or
running your
> RichTextCtrl with MingW (either version of Ruby) at the moment.
>
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090113/85f3c8bc/attachment.html>

Chauk-Mean P

2009-Jan-13 16:46 UTC

head link

[wxruby-development] pre-2.0 testing

Mario,

2009/1/13 Mario Steele <mario at ruby-im.net>:> Have you tried building wxRuby, and trying the Graphics, and the RichText
> controls there, to see if it will work?
Yes, I built successfully the wxRuby mingw gem and the
graphics_drawing.rb and the rich_textctrl.rb samples work.

Chauk-Mean.

Mario Steele

2009-Jan-13 17:24 UTC

head link

[wxruby-development] pre-2.0 testing

There are some modifications that have to be made to the GDI+ library, which
may be causing some problems with the C++ Sample counterparts.  You may want
to look at why they are failing to compile, and see if any of the functions
that they use, have been modified in the headers that are a part of the GDI+
stuff for MinGW that we provide.  That''s about the only thing I can
think
of, that would be causing the problems of the C++ stuff not to work, but the
Ruby side is working fine.

On Tue, Jan 13, 2009 at 10:46 AM, Chauk-Mean P <chauk.mean at gmail.com>
wrote:
> Mario,
>
> 2009/1/13 Mario Steele <mario at ruby-im.net>:
> > Have you tried building wxRuby, and trying the Graphics, and the
RichText
> > controls there, to see if it will work?
>
> Yes, I built successfully the wxRuby mingw gem and the
> graphics_drawing.rb and the rich_textctrl.rb samples work.
>
> Chauk-Mean.
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/wxruby-development/attachments/20090113/eca059aa/attachment.html>

Chauk-Mean P

2009-Jan-14 12:15 UTC

head link

[wxruby-development] pre-2.0 testing

Hi,

2009/1/13 Alex Fenton <alex at pressure.to>:>
> I haven''t run into problems on any other platforms. The command is
executed
> in a function called ''do_swig'' which is in
rake/rakewx.rb. And yes, the
> rakefiles are like tangled spaghetti..
Thanks for the entry point. I''ve been able to find the root cause of
the problem which is ruby-1.9 incompatibility in rake.
I''ve reported the bug and also provided a fix which is very simple
(http://redmine.ruby-lang.org/issues/show/1010)
And yes, the problem affects only ruby 1.9 on Windows !
> Sounds like there is something odd going on with rake or system calls in
> mswin32 with 1.9, rather than something wrong in the rakefiles themselves.
You were right.
>> AboutDialogInfo.cpp
>> C:/Home\wxWidgets-2.8.9\include\wx\filefn.h(110) : error C2628:
''_off_t''
>> followe
>> d by ''__int64'' is illegal (did you forget a
'';''?)
>>
>> C:\Home\wxruby2>
>>
>> Now, there is a more understandable error ...
>
> Hehe ... not a lot more. The error is coming from the wx headerS!
I will try to investigate this issue.
>> Until now, wxRuby builds and works fine on MinGW.
>> The problem I have is that I can''t build the C++ richtextctrl
sample.
>> The linker complains about some undefined GDI+ references.
>> (I''m looking forward the removal of the GDI+ requirements for
building
>> wxRuby -
>>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221).
>
> I looked again at this and it should already be possible to build without
> all the Graphics* classes. The rakefiles check whether
> wxUSE_GRAPHICS_CONTEXT is set to 0 in wxWidget''s setup.h (see
> rakeconfigure.rb), and if so exclude these files. This certainly used to
> work - could you double-check the setting is right in your build of
> wxWidgets please?
To be sure, for MinGW, do I need to edit the file
include/wx/msw/setup.h to define the flags :
define wxUNICODE 1
define wxUSE_GRAPHICS_CONTEXT 1
define wxUSE_GLCANVAS 1
I edit this file only for Visual C++ build.

For MinGW, I just launch configure with the appropriate settings.

I will also try to make a build without graphics context support.

Cheers,

Chauk-Mean.

Alex Fenton

2009-Jan-14 13:14 UTC

head link

[wxruby-development] pre-2.0 testing

Chauk-Mean P wrote:> Thanks for the entry point. I''ve been able to find the root cause
of
> the problem which is ruby-1.9 incompatibility in rake.
> I''ve reported the bug and also provided a fix which is very simple
> (http://redmine.ruby-lang.org/issues/show/1010)
> And yes, the problem affects only ruby 1.9 on Windows !
>   
Good work.
> To be sure, for MinGW, do I need to edit the file
> include/wx/msw/setup.h to define the flags :
> define wxUNICODE 1
> define wxUSE_GRAPHICS_CONTEXT 1
> define wxUSE_GLCANVAS 1
> I edit this file only for Visual C++ build.
>
> For MinGW, I just launch configure with the appropriate settings.
Just ../configure --with-necessary-flags, I believe; only VC requires 
editing the setup.h

cheers
alex

Chauk-Mean P

2009-Jan-15 16:40 UTC

head link

[wxruby-development] pre-2.0 testing

Hi,

2009/1/13 Alex Fenton <alex at pressure.to>:> Chauk-Mean P wrote:
>> (I''m looking forward the removal of the GDI+ requirements for
building
>> wxRuby -
>>
http://rubyforge.org/tracker/index.php?func=detail&aid=22844&group_id=35&atid=221).
>>
>
> I looked again at this and it should already be possible to build without
> all the Graphics* classes. The rakefiles check whether
> wxUSE_GRAPHICS_CONTEXT is set to 0 in wxWidget''s setup.h (see
> rakeconfigure.rb), and if so exclude these files. This certainly used to
> work - could you double-check the setting is right in your build of
> wxWidgets please?
FYI :
On MinGW, after a build of wxWidgets without GRAPHICS_CONTEXT from the
original source tarball, I''ve built successfully the wxRuby gem.
The wxRuby samples work except obviously graphics_drawing.rb.
And now, the C++ richtext sample can also be built without any problem.

Chauk-Mean.

wxruby development - Jan 2009 - pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing

[wxruby-development] pre-2.0 testing