fxruby users - Apr 2007 - Support for Ruby 1.9?

I''m trying to compile FXRuby under Ruby 1.9.0.  After applying the
below
patch, I get the error:

FXRbApp.cpp: In member function ''long int 
FXRbApp::onChoreThreads(FX::FXObject*, FX::FXSelector, void*)'':
FXRbApp.cpp:98: error: ''CHECK_INTS'' was not declared in this
scope

I would fix this, but I''m not familiar with what this code is doing.

Any estimate on support for 1.9 in FXRuby?  I only ask because I''m 
trying to add support for 1.9 to my extensions, and I end up building 
FXRuby in the process.

Thanks,

Kevin

Index: pre-config.rb
==================================================================---
pre-config.rb    (revision 921)
+++ pre-config.rb    (working copy)
@@ -20,7 +20,7 @@
 def fox_include_files_found?
   search_directories.each do |path|
     filename = File.join(path, "fxver.h")
-    return true if FileTest.exists?(filename)
+    return true if FileTest.exist?(filename)
   end
   false
 end
@@ -44,7 +44,7 @@
 def installed_fox_version
   search_directories.each do |path|
     filename = File.join(path, "fxver.h")
-    if FileTest.exists?(filename)
+    if FileTest.exist?(filename)
       foxMajor, foxMinor, foxLevel = read_fox_version(filename)
       return [foxMajor, foxMinor, foxLevel].join(''.'')
     end
Index: ext/fox16/extconf.rb
==================================================================---
ext/fox16/extconf.rb    (revision 921)
+++ ext/fox16/extconf.rb    (working copy)
@@ -20,7 +20,7 @@
  
   incdirs.each do |incdir|
     filename = File.join(incdir, "fxver.h")
-    if FileTest.exists?(filename)
+    if FileTest.exist?(filename)
       idircflag = "-I" + incdir
       $CPPFLAGS += " " + idircflag unless 
$CPPFLAGS.split.include?(idircflag)
       return
@@ -50,7 +50,7 @@
  
   incdirs.each do |incdir|
     filename = File.join(incdir, "FXScintilla.h")
-    if FileTest.exists?(filename)
+    if FileTest.exist?(filename)
       $autodetected_fxscintilla = true
       idircflag = "-I" + incdir
       $CPPFLAGS += " " + idircflag unless 
$CPPFLAGS.split.include?(idircflag)
@@ -87,11 +87,11 @@
   $libs = append_library($libs, "FOX-1.6")
   $CFLAGS = $CFLAGS + " -fpermissive -DWIN32 -Iinclude"
   if is_fxscintilla_build?
-    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exists?(''scintilla_wrap.cpp.bak'')
+    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exist?(''scintilla_wrap.cpp.bak'')
     $CFLAGS = $CFLAGS + " -DWITH_FXSCINTILLA -DHAVE_FOX_1_6"
     $libs = append_library($libs, "fxscintilla")
   else
-    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exists?(''scintilla_wrap.cpp'')
+    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exist?(''scintilla_wrap.cpp'')
   end
 end
 
@@ -113,11 +113,11 @@
   $CFLAGS = $CFLAGS + " /DWIN32 /DUNICODE /GR /GX /Iinclude"
   $LOCAL_LIBS = $LOCAL_LIBS + "FOX-1.6.lib"
   if is_fxscintilla_build?
-    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exists?(''scintilla_wrap.cpp.bak'')
+    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exist?(''scintilla_wrap.cpp.bak'')
     $CFLAGS = $CFLAGS + " /DWITH_FXSCINTILLA /DHAVE_FOX_1_6"
     $libs = append_library($libs, "fxscintilla")
   else
-    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exists?(''scintilla_wrap.cpp'')
+    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exist?(''scintilla_wrap.cpp'')
   end
 end
 
@@ -139,11 +139,11 @@
   $libs = append_library($libs, "FOX-1.6")
   $CFLAGS = $CFLAGS + " -O0 -Iinclude"
   if is_fxscintilla_build?
-    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exists?(''scintilla_wrap.cpp.bak'')
+    File.move(''scintilla_wrap.cpp.bak'',
''scintilla_wrap.cpp'') if
FileTest.exist?(''scintilla_wrap.cpp.bak'')
     $CFLAGS = $CFLAGS + " -DWITH_FXSCINTILLA -DHAVE_FOX_1_6"
     $libs = append_library($libs, "fxscintilla")
   else
-    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exists?(''scintilla_wrap.cpp'')
+    File.move(''scintilla_wrap.cpp'',
''scintilla_wrap.cpp.bak'') if
FileTest.exist?(''scintilla_wrap.cpp'')
   end
 end
 
Index: install.rb
==================================================================--- install.rb
(revision 921)
+++ install.rb    (working copy)
@@ -237,7 +237,6 @@
       @table[k] = default
     end
   end
-  private :init
 
   def save
     File.open(SAVE_FILE, ''w'') {|f|




http://www.systemware.com/

On 4/17/07, Kevin Burge <kevin.burge at systemware.com> wrote:
> Any estimate on support for 1.9 in FXRuby?  I only ask because I''m
> trying to add support for 1.9 to my extensions, and I end up building
> FXRuby in the process.
Yikes, Ruby 1.9 wasn''t even on my radar screen yet. Since
you''ve
actually done some stuff with it -- Is it stable enough to even try
out yet? I know the official release won''t be until the end of the
year (or whatever), but is it kinda working at this point?

I will file a bug report about adding Ruby 1.9 support and see what I can do.

Lyle Johnson wrote:
> On 4/17/07, Kevin Burge <kevin.burge at systemware.com> wrote:
> 
>> Any estimate on support for 1.9 in FXRuby?  I only ask because
I''m
>> trying to add support for 1.9 to my extensions, and I end up building
>> FXRuby in the process.
> 
> Yikes, Ruby 1.9 wasn''t even on my radar screen yet. Since
you''ve
> actually done some stuff with it -- Is it stable enough to even try
> out yet? I know the official release won''t be until the end of the
> year (or whatever), but is it kinda working at this point?
As far as I can tell, ruby1.9 has always been functional.  It has
remained more or less stable since the YARV merge last December.
There are relatively minor changes to the C api, but nothing earth
shattering for .so writers.
The only big gotcha is that ruby1.9 does away with continuations and
that yarv is a little bit more multithread aware (not quite, really, but
you need to prepare for it), so some of the internal stuff in eval.c is
quite different.
SWIG should already be 1.9 aware, as far as I can tell.

PS.  Talking about SWIG.  As a result of me wrapping FLTK and the Maya
API library under it, I''ve submitted 4 patches to the latest SWIG for
ruby.  Two are for relatively serious bugs in it (that could potentially
crash it on some rare ocassions).  I''m not sure if Fox could benefit
from those (Fox mainly uses its own classes and relatively little of the
features swig).

-- 
Gonzalo Garramu?o
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

On 4/17/07, gga <ggarra at advancedsl.com.ar> wrote:
> As far as I can tell, ruby1.9 has always been functional.  It has
> remained more or less stable since the YARV merge last December.
> There are relatively minor changes to the C api, but nothing earth
> shattering for .so writers.
OK.
> PS.  Talking about SWIG.  As a result of me wrapping FLTK and the Maya
> API library under it, I''ve submitted 4 patches to the latest SWIG
for
> ruby.  Two are for relatively serious bugs in it (that could potentially
> crash it on some rare ocassions).  I''m not sure if Fox could
benefit
> from those (Fox mainly uses its own classes and relatively little of the
> features swig).
Yes, the hard parts of FXRuby were completed before SWIG got some of
its more recent useful features (like the director classes support),
and there was some breakage for multiple modules for several releases.
I will probably upgrade to a more recent SWIG at some point, but right
now I''m using a modified version of SWIG 1.3.22.

As an extension developer myself, I wanted to try to use 1.9 on a 
day-to-day basis before it''s released, to make sure that I
don''t write
any new incompatible code, and to possibly contribute by reporting bugs 
to various projects that don''t seem to be 1.9 compatible sooner rather 
than later.  IMO, it would be nice if, when 1.9 is finally released, 
there are actually libraries that work with it beyond the standard stuff. :)

The main things that have affected me are:

in Ruby code:
String is not Enumerable (i.e. no each)
arity changes for blocks
send vs. funcall
Thread.critical not supported
using "case/when" with a colon, instead of "then" or
";", i.e. "when 7:
true"

in Extension code:
rb_cvar_set takes 1 less arg
RB_STRING doesn''t allow direct access anymore (I''ve been
converting to
RB_STRING_LEN and RB_STRING_PTR (not sure if this is the right thing yet).

Also, YARV only supports native threads at this point, as far as I can tell.

Lyle Johnson wrote:
> On 4/17/07, Kevin Burge <kevin.burge at systemware.com> wrote:
>
>   
>> Any estimate on support for 1.9 in FXRuby?  I only ask because
I''m
>> trying to add support for 1.9 to my extensions, and I end up building
>> FXRuby in the process.
>>     
>
> Yikes, Ruby 1.9 wasn''t even on my radar screen yet. Since
you''ve
> actually done some stuff with it -- Is it stable enough to even try
> out yet? I know the official release won''t be until the end of the
> year (or whatever), but is it kinda working at this point?
>
> I will file a bug report about adding Ruby 1.9 support and see what I can
do.
> _______________________________________________
> fxruby-users mailing list
> fxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/fxruby-users
>
>   
http://www.systemware.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20070418/222038c4/attachment.html

On 4/18/07, Kevin Burge <kevin.burge at systemware.com> wrote:
> As an extension developer myself, I wanted to try to use 1.9 on a
> day-to-day basis before it''s released, to make sure that I
don''t write any
> new incompatible code, and to possibly contribute by reporting bugs to
> various projects that don''t seem to be 1.9 compatible sooner
rather than
> later.  IMO, it would be nice if, when 1.9 is finally released, there are
> actually libraries that work with it beyond the standard stuff. :)
>
Sure. ;)

Also, YARV only supports native threads at this point, as far as I can
tell.
>
Native threads, as in operating system threads? Or just the user-space
threads that Ruby 1.8 provides?

Just an update: I checked out the trunk for Ruby 1.9 last night and built
that, but I''m having trouble getting some critical stuff (namely,
RubyGems)
to even install. I''m sure this is just a temporary breakage, but it
looks
like it''s going to be awhile before I can say that FXRuby
"works" on Ruby
1.9. Nevertheless, I''ll go ahead and apply the patches that you sent
(for
FileText.exists?) and so my best to get other things fixed in due time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20070418/5a822355/attachment.html

Thank you.

I found a possible error in the patch I sent you: It looks like you can 
call "funcall", rather than removing "private :init" from
install.rb.  I
have not verified this.  And, "funcall" is not in 1.8, so I put in:

if RUBY_VERSION < "1.9"
  module Kernel
    alias_method :funcall, :send
  end
end

Haven''t quite figured out the difference between funcall, send, and 
__send__.

Lyle Johnson wrote:
> On 4/18/07, *Kevin Burge* <kevin.burge at systemware.com 
> <mailto:kevin.burge at systemware.com>> wrote:
>
>     As an extension developer myself, I wanted to try to use 1.9 on a
>     day-to-day basis before it''s released, to make sure that I
don''t
>     write any new incompatible code, and to possibly contribute by
>     reporting bugs to various projects that don''t seem to be 1.9
>     compatible sooner rather than later.  IMO, it would be nice if,
>     when 1.9 is finally released, there are actually libraries that
>     work with it beyond the standard stuff. :)
>
>
> Sure. ;)
>
>     Also, YARV only supports native threads at this point, as far as I
>     can tell.
>
>
> Native threads, as in operating system threads? Or just the user-space 
> threads that Ruby 1.8 provides?
>
> Just an update: I checked out the trunk for Ruby 1.9 last night and 
> built that, but I''m having trouble getting some critical stuff 
> (namely, RubyGems) to even install. I''m sure this is just a
temporary
> breakage, but it looks like it''s going to be awhile before I can
say
> that FXRuby "works" on Ruby 1.9. Nevertheless, I''ll go
ahead and apply
> the patches that you sent (for FileText.exists?) and so my best to get 
> other things fixed in due time.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fxruby-users mailing list
> fxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/fxruby-users
http://www.systemware.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/fxruby-users/attachments/20070418/82dbb7ef/attachment.html

Kevin Burge wrote:
> 
> The main things that have affected me are:
> 
What crazy version of 1.9 are you testing?  Half of the stuff you
mentioned works fine for me.  Latest SVN.

Examples:
> irb1.9
>> puts RUBY_VERSION
1.9.0

----
> in Ruby code:
> String is not Enumerable (i.e. no each)
Huh?
>> ''asdsd''.each { |x| puts x }
asdsd
=> "asdsd"
>> ''asdsd''.each_byte { |x| puts x }
97
115
100
115
100

No Unicode, yet, thou.
> arity changes for blocks
Like?
> send vs. funcall
>> ''5''.send(:to_i)
=> 5

(or do you mean how this resolved in inheritance - a subtle change --
see comp.lang.ruby.  Basically send was broken since it could call
private methods before)
> Thread.critical not supported
True.
> using "case/when" with a colon, instead of "then" or
";", i.e. "when 7:
> true"
Huh?  Colons?  You must have gotten python on your mind.
>> a = 20
=> 20
>> case a
>>   when 20
>>     puts ''x''
>>   else
>>     puts ''y''
>>   end
=> ''x''

> 
> in Extension code:
> rb_cvar_set takes 1 less arg
Yes, that''s what it should have been all along.  Some crazy guy put a
4th warning argument somewhere in the 1.8 branch and matz removed it.
> RB_STRING doesn''t allow direct access anymore (I''ve been
converting to
> RB_STRING_LEN and RB_STRING_PTR (not sure if this is the right thing yet).
AFAIK, they are RSTRING_LEN and RSTRING_PTR.  For array you have
RARRAY_LEN and RARRAY_PTR.  The PTR version of string is hardly ever
used due to StringValuePtr() and StringValueCStr() -- pickaxe recommended.
> 
> Also, YARV only supports native threads at this point, as far as I can
tell.
> 
Yep.  The code for ruby''s 1.8 green threads is there but koichi turned
it off at some point (some bug, probably).


-- 
Gonzalo Garramu?o
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

(built this morning from trunk)

==String.each

% ruby -v
ruby 1.9.0 (2007-04-18 patchlevel 0) [i686-linux]
% ruby -e ''"a\nb\n".each { |l| puts l }''
-e:1:in `<main>'': undefined method `each'' for
"a\nb\n":String
(NoMethodError)

each_byte works though.
==arity:

class A
  def self.meth_with_block(a, &block)
    puts block.arity
  end
end

A.meth_with_block do |arg1|
end

Ruby 1.9 => -2
Ruby 1.8.6 => 1

(I don''t know if this is a bug in 1.9 or not.  I don''t
understand the
logic behind -2 - you''d think it''d be 1).  From what
I''ve seen on the
mailing lists, -2 should be |a,*b|.

== From activesupport:

        def self.included(klass) #:nodoc:
          klass.funcall(:alias_method, :to_default_s, :to_s)
          klass.funcall(:alias_method, :to_s, :to_formatted_s)
        end

works, but:

        def self.included(klass) #:nodoc:
          klass.send(:alias_method, :to_default_s, :to_s)
          klass.send(:alias_method, :to_s, :to_formatted_s)
        end

doesn''t.
==about "when" clause, a couple libraries I use do this:

case somevar
when 1: true
when 2: false
end

This no longer works in 1.9.  You have to do:

when 1; true
when 2; false

or

when 1 then true
when 2 then false

I''ve never done this in my own code.

==You are correct about RB_STRING* also, it is RSTRING*, just misspoke.  
My quick hack was to replace all with the _PTR and _LEN macros.  I''ll 
update my own libraries to use StringValuePtr and StringValueCStr.  Thanks!


Kevin


http://www.systemware.com/