 |
Forums |
Admin Discussion Forums: help Start New Thread
By: Daniel Berger
 RE: port to 1.9.1 [ reply ]
2009-11-14 15:29
|
Actually, I just remembered something. Supposedly the open3 library that ships as part of the Ruby standard library should "just work" with 1.9.x on Windows.
Have you tried using open3? Are there problems?
Regards,
Dan
|
By: Daniel Berger
RE: port to 1.9.1 [ reply ]
2009-11-12 02:17
|
I don't think I've tested this against 1.9.1 yet. I'll take a look, but I'm not sure off the top of my head.
Can you file a bug report please?
Regards,
Dan
|
By: Dan Rathbun
RE: Ruby 1.9.1 & WIN32API.so [ reply ]
2009-11-11 23:07
|
FYI: WIN32API filename clash, Ruby ver 1.9.1
I use Ruby in an imbedded environment (Google Sketchup,) in which many of the Ruby 'plugins' require "WIN32API" (with no file extension.) The intent is to load WIN32API.so (the old package that Daniel Berger's Win32::API replaces.)
Everything worked fine, until Ruby 1.9.1 came along. (Some of us Ruby coders have a Full Ruby install, and use some of the full install libs with Sketchup plugins.) Sketchup uses a 1.8 branch version of the interpreter.
Anyhow... what happened is that Ruby ver 1.9.1 added a ruby script called: WIN32API.rb
It appears that "require" will first try to load ".rb" files, whereever they may be, in the search paths, BEFORE it trys to load other file types, ie: ".so", ".dll", etc.
You'd think that Ruby would go thru the $: search paths 1 by 1, and in each directory, try to load any file with 'WIN32API' as the file name, trying each vaild extension in turn, before it went on to the next entry in the $: (aka $LOADPATH) array.
So head's up on that issue of 'Win32API.rb' versus 'WIN32API.so"; personally I believe that not stating the full filename is poor programming practice.
INTERIM:
What we need is to still have the old 'WIN32API.so' valid, as we coders slowly update all the old Sketchup plugin scripts to use Berger's new Win32::API package.
My 1st thot was to create a translator script (interface) perhaps named WIN32API.rb that would translate the old WIN32API parameters and types, to Dan's new Win32::API set.
1) The Ruby people beat me to the use of 'WIN32API.rb' as a file name, however. It also appears they are using it for the same idea; as an interim translator from an old way of doing things, to a new way - which I think is using a DL (Dynamic Loader) module. [BTW, this DL module looks confusing to me, isn't the idea of ruby to be less confusing and more a 'high level' language?]
2) I think somewhere, I have already come across a translator that translates the old 'WIN32API.so' calls into new calls to Berger's Win32::API
3) This translation, is [or should be,] transparent to the scripts still using the 'old' calls
But, I can't remember (or find,) where to find the full ruby file of this translator.
Anyone know where it is, or if it exists?
If not, I guess we can clone the 1.9.1 'Win32API.rb' and modify it for local use under Sketchup; so it translates to Berger's package, rather than full ruby's DL module
|
By: Chuck Emary
RE: port to 1.9.1 [ reply ]
2009-11-11 21:52
|
here is a dump:
irb(main):001:0> require 'win32/open3'
D:/Ruby19/lib/ruby/gems/1.9.1/gems/win32-open3-0.3.1-x86-mswin32-60/lib/win32/open3.so: [BUG] Segmentation fault
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]
-- control frame ----------
c:0025 p:-5029374 s:0088 b:0088 l:000087 d:000087 TOP
c:0024 p:---- s:0086 b:0086 l:000085 d:000085 CFUNC :require
c:0023 p:0011 s:0082 b:0082 l:00010c d:000ed4 EVAL (irb):1
c:0022 p:---- s:0080 b:0080 l:000079 d:000079 FINISH
c:0021 p:---- s:0078 b:0078 l:000077 d:000077 CFUNC :eval
c:0020 p:0027 s:0071 b:0071 l:000070 d:000070 METHOD D:/Ruby19/lib/ruby/1.9.1/irb/workspace.rb:80
c:0019 p:0031 s:0064 b:0063 l:000062 d:000062 METHOD D:/Ruby19/lib/ruby/1.9.1/irb/context.rb:218
c:0018 p:0030 s:0058 b:0058 l:00013c d:000057 BLOCK D:/Ruby19/lib/ruby/1.9.1/irb.rb:149
c:0017 p:0037 s:0050 b:0050 l:000049 d:000049 METHOD D:/Ruby19/lib/ruby/1.9.1/irb.rb:263
c:0016 p:0011 s:0045 b:0045 l:00013c d:000044 BLOCK D:/Ruby19/lib/ruby/1.9.1/irb.rb:146
c:0015 p:0132 s:0041 b:0041 l:000024 d:000040 BLOCK D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:244
c:0014 p:---- s:0038 b:0038 l:000037 d:000037 FINISH
c:0013 p:---- s:0036 b:0036 l:000035 d:000035 CFUNC :loop
c:0012 p:0009 s:0033 b:0033 l:000024 d:000032 BLOCK D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:230
c:0011 p:---- s:0031 b:0031 l:000030 d:000030 FINISH
c:0010 p:---- s:0029 b:0029 l:000028 d:000028 CFUNC :catch
c:0009 p:0023 s:0025 b:0025 l:000024 d:000024 METHOD D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:229
c:0008 p:0042 s:0022 b:0022 l:00013c d:00013c METHOD D:/Ruby19/lib/ruby/1.9.1/irb.rb:145
c:0007 p:0011 s:0019 b:0019 l:001824 d:000018 BLOCK D:/Ruby19/lib/ruby/1.9.1/irb.rb:69
c:0006 p:---- s:0017 b:0017 l:000016 d:000016 FINISH
c:0005 p:---- s:0015 b:0015 l:000014 d:000014 CFUNC :catch
c:0004 p:0172 s:0011 b:0011 l:001824 d:001824 METHOD D:/Ruby19/lib/ruby/1.9.1/irb.rb:68
c:0003 p:0039 s:0006 b:0006 l:0017c4 d:000f0c EVAL D:/Ruby19/bin/irb:12
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0017c4 d:0017c4 TOP
---------------------------
-- Ruby level backtrace information-----------------------------------------
(irb):1:in `require'
(irb):1:in `irb_binding'
D:/Ruby19/lib/ruby/1.9.1/irb/workspace.rb:80:in `eval'
D:/Ruby19/lib/ruby/1.9.1/irb/workspace.rb:80:in `evaluate'
D:/Ruby19/lib/ruby/1.9.1/irb/context.rb:218:in `evaluate'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:149:in `block (2 levels) in eval_input'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:263:in `signal_status'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:146:in `block in eval_input'
D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:244:in `block (2 levels) in each_top_level_statement'
D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:230:in `loop'
D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:230:in `block in each_top_level_statement'
D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `catch'
D:/Ruby19/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in `each_top_level_statement'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:145:in `eval_input'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:69:in `block in start'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:68:in `catch'
D:/Ruby19/lib/ruby/1.9.1/irb.rb:68:in `start'
D:/Ruby19/bin/irb:12:in `<main>'
[NOTE]
You may encounter a bug of Ruby interpreter. Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
|
By: Chuck Emary
port to 1.9.1 [ reply ]
2009-11-11 20:10
|
Hello,
I am testing some code I wrote that uses win32-open3, against ruby 1.9.1. It segfaults, so wondering if this has been ported or whether it's a bug.
TIA
|
|
|
