' C:\>ruby -v ruby 1.9.3p0 (2011-10-30) [i386-mingw32] C:\>gem list *** LOCAL GEMS *** bigdecimal (1.1.0) ffi (1.0.11) io-console (0.3) json (1.5.4) minitest (2.5.1) rake (0.9.2.2) rdoc (3.9.4) rubygems-update (1.8.15) This is on Windows XP Pro. Regards, Dan From djberg96 at gmail.com Sun Jan 15 10:32:12 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 15 Jan 2012 08:32:12 -0700 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: On Sun, Jan 15, 2012 at 8:06 AM, Daniel Berger wrote: > On Sun, Jan 15, 2012 at 1:59 AM, Heesob Park wrote: >> Hi, >> >> 2012/1/15 Daniel Berger : >>> On Fri, Jan 13, 2012 at 9:42 PM, Heesob Park wrote: >>>> Hi, >>>> >>>> 2012/1/14 Daniel Berger : >>>>> Is it odd that calling _mktemp more than once in the same process doesn't work? >>>>> >>>>> require 'ffi' >>>>> >>>>> class Win >>>>> ?extend FFI::Library >>>>> >>>>> ?ffi_lib 'msvcrt' >>>>> ?attach_function :_mktemp, [:string], :string >>>>> >>>>> ?def self.mktemp >>>>> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >>>>> ?end >>>>> end >>>>> >>>>> Win.mktemp >>>>> >>>>> # Output >>>>> "rb_file_temp_a03680" >>>>> nil >>>>> nil >>>>> nil >>>>> nil >>>> >>>> According to MSDN, _mktemp is deprecated; consider using _mktemp_s instead. >>>> >>>> Refer to http://msdn.microsoft.com/en-us/library/34wc6k1f(v=vs.80).aspx >>> >>> True. I guess they were really serious about it this time. ;) >>> >>> Unfortunately I'm not sure how to get at _mktemp_s with FFI using >>> mingw, since that function doesn't seem to be exported. Suggestions? >>> >>> Regards, >>> >>> Dan >> >> Well, I can use _mktemp_s with ffi using migw. >> May be it depends on the version of msvcrt.dll. >> C:\work>ruby -v mt.rb >> ruby 1.9.3p0 (2011-10-30) [i386-mingw32] >> "rb_file_temp_a07024" >> >> ======================= >> require 'ffi' >> >> class Win >> ?extend FFI::Library >> >> ?ffi_lib 'msvcrt' >> ?attach_function :_mktemp_s, [:string,:int], :string >> >> ?def self.mktemp >> ? str = "rb_file_temp_XXXXXX" >> ? _mktemp_s(str,21) >> ? p str >> ?end >> end >> >> Win.mktemp >> ====================== > > How? > > C:\>ruby test.rb > c:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/library.rb:249:in > `attach_function': Function '_mktemp_s' not found in [msvcrt] (FFI: > :NotFoundError) > ? ? ? ?from test.rb:7:in `' > ? ? ? ?from test.rb:3:in `

' > > C:\>ruby -v > ruby 1.9.3p0 (2011-10-30) [i386-mingw32] > > C:\>gem list > > *** LOCAL GEMS *** > > bigdecimal (1.1.0) > ffi (1.0.11) > io-console (0.3) > json (1.5.4) > minitest (2.5.1) > rake (0.9.2.2) > rdoc (3.9.4) > rubygems-update (1.8.15) > > This is on Windows XP Pro. I tried it again on Windows 7 and it worked. I guess it's not exported on XP. Regards, Dan From phasis at gmail.com Sun Jan 15 22:44:41 2012 From: phasis at gmail.com (Heesob Park) Date: Mon, 16 Jan 2012 12:44:41 +0900 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References: Message-ID: Hi, 2012/1/14 Daniel Berger : > Is it odd that calling _mktemp more than once in the same process doesn't work? > > require 'ffi' > > class Win > ?extend FFI::Library > > ?ffi_lib 'msvcrt' > ?attach_function :_mktemp, [:string], :string > > ?def self.mktemp > ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } > ?end > end > > Win.mktemp > > # Output > "rb_file_temp_a03680" > nil > nil > nil > nil It is odd indeed. _mktemp not working in the loop. require 'ffi' class Win extend FFI::Library ffi_lib 'msvcrt' attach_function :_mktemp, [:string], :string def self.mktemp p _mktemp("rb_file_temp_XXXXXX") p _mktemp("rb_file_temp_XXXXXX") p _mktemp("rb_file_temp_XXXXXX") p _mktemp("rb_file_temp_XXXXXX") p _mktemp("rb_file_temp_XXXXXX") 5.times { p _mktemp("rb_loop_temp_XXXXXX") } end end Win.mktemp # Output "rb_file_temp_a05972" "rb_file_temp_a05972" "rb_file_temp_a05972" "rb_file_temp_a05972" "rb_file_temp_a05972" "rb_loop_temp_a05972" nil nil nil nil Regards, Park Heesob From djberg96 at gmail.com Mon Jan 16 09:00:50 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Mon, 16 Jan 2012 07:00:50 -0700 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: On Sun, Jan 15, 2012 at 8:44 PM, Heesob Park wrote: > Hi, > > 2012/1/14 Daniel Berger : >> Is it odd that calling _mktemp more than once in the same process doesn't work? >> >> require 'ffi' >> >> class Win >> ?extend FFI::Library >> >> ?ffi_lib 'msvcrt' >> ?attach_function :_mktemp, [:string], :string >> >> ?def self.mktemp >> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >> ?end >> end >> >> Win.mktemp >> >> # Output >> "rb_file_temp_a03680" >> nil >> nil >> nil >> nil > It is odd indeed. > _mktemp not working in the loop. > > require 'ffi' > > class Win > ?extend FFI::Library > > ?ffi_lib 'msvcrt' > ?attach_function :_mktemp, [:string], :string > > ?def self.mktemp > ? p _mktemp("rb_file_temp_XXXXXX") > ? p _mktemp("rb_file_temp_XXXXXX") > ? p _mktemp("rb_file_temp_XXXXXX") > ? p _mktemp("rb_file_temp_XXXXXX") > ? p _mktemp("rb_file_temp_XXXXXX") > ?5.times { > ? p _mktemp("rb_loop_temp_XXXXXX") > ?} > ?end > end > > Win.mktemp > > ?# Output > "rb_file_temp_a05972" > "rb_file_temp_a05972" > "rb_file_temp_a05972" > "rb_file_temp_a05972" > "rb_file_temp_a05972" > "rb_loop_temp_a05972" > nil > nil > nil > nil I noticed that in the example of the bottom of the _mktemp documentation that they don't use the char* string directly, but instead strcpy it to an array of chars and use that. I guess there's a limit of 26 names. Regards, Dan From phasis at gmail.com Mon Jan 16 09:36:59 2012 From: phasis at gmail.com (Heesob Park) Date: Mon, 16 Jan 2012 23:36:59 +0900 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: Hi, 2012/1/16 Daniel Berger : > On Sun, Jan 15, 2012 at 8:44 PM, Heesob Park wrote: >> Hi, >> >> 2012/1/14 Daniel Berger : >>> Is it odd that calling _mktemp more than once in the same process doesn't work? >>> >>> require 'ffi' >>> >>> class Win >>> ?extend FFI::Library >>> >>> ?ffi_lib 'msvcrt' >>> ?attach_function :_mktemp, [:string], :string >>> >>> ?def self.mktemp >>> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >>> ?end >>> end >>> >>> Win.mktemp >>> >>> # Output >>> "rb_file_temp_a03680" >>> nil >>> nil >>> nil >>> nil >> It is odd indeed. >> _mktemp not working in the loop. >> >> require 'ffi' >> >> class Win >> ?extend FFI::Library >> >> ?ffi_lib 'msvcrt' >> ?attach_function :_mktemp, [:string], :string >> >> ?def self.mktemp >> ? p _mktemp("rb_file_temp_XXXXXX") >> ? p _mktemp("rb_file_temp_XXXXXX") >> ? p _mktemp("rb_file_temp_XXXXXX") >> ? p _mktemp("rb_file_temp_XXXXXX") >> ? p _mktemp("rb_file_temp_XXXXXX") >> ?5.times { >> ? p _mktemp("rb_loop_temp_XXXXXX") >> ?} >> ?end >> end >> >> Win.mktemp >> >> ?# Output >> "rb_file_temp_a05972" >> "rb_file_temp_a05972" >> "rb_file_temp_a05972" >> "rb_file_temp_a05972" >> "rb_file_temp_a05972" >> "rb_loop_temp_a05972" >> nil >> nil >> nil >> nil > > I noticed that in the example of the bottom of the _mktemp > documentation that they don't use the char* string directly, but > instead strcpy it to an array of chars and use that. I guess there's a > limit of 26 names. > I want to know why sequence of _mktemp works and _mktemp in the loop not works after first call. More over _mktemp_s segfaults in the loop after first call. #code require 'ffi' class Win extend FFI::Library ffi_lib 'msvcrt' ffi_convention :stdcall attach_function :_mktemp_s, [:string,:int], :string def self.mktemp 3.times { str = "rb_file_temp_XXXXXX" _mktemp_s(str,21) p str } end end Win.mktemp #output "rb_file_temp_a03212" mt.rb:13: [BUG] Segmentation fault ruby 1.9.3p0 (2011-10-30) [i386-mingw32] -- Control frame information ----------------------------------------------- c:0008 p:---- s:0022 b:0022 l:000021 d:000021 CFUNC :_mktemp_s c:0007 p:0027 s:0017 b:0017 l:000008 d:000016 BLOCK mt.rb:13 c:0006 p:---- s:0014 b:0014 l:000013 d:000013 FINISH c:0005 p:---- s:0012 b:0012 l:000011 d:000011 CFUNC :times c:0004 p:0012 s:0009 b:0009 l:000008 d:000008 METHOD mt.rb:11 c:0003 p:0037 s:0006 b:0006 l:001d0c d:00150c EVAL mt.rb:19 c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH c:0001 p:0000 s:0002 b:0002 l:001d0c d:001d0c TOP -- Ruby level backtrace information ---------------------------------------- mt.rb:19:in `

' mt.rb:11:in `mktemp' mt.rb:11:in `times' mt.rb:13:in `block in mktemp' mt.rb:13:in `_mktemp_s' -- C level backtrace information ------------------------------------------- C:\Windows\SysWOW64\ntdll.dll(ZwWaitForSingleObject+0x15) [0x7756f8b1] C:\Windows\syswow64\kernel32.dll(WaitForSingleObjectEx+0x43) [0x75151194] C:\Windows\syswow64\kernel32.dll(WaitForSingleObject+0x12) [0x75151148] C:\Ruby193\bin\msvcrt-ruby191.dll(rb_vm_bugreport+0xf9) [0x62e5acc9] C:\Ruby193\bin\msvcrt-ruby191.dll(rb_name_err_mesg_new+0x17a) [0x62d3a68e] C:\Ruby193\bin\msvcrt-ruby191.dll(rb_bug+0x2f) [0x62d3b3ef] C:\Ruby193\bin\msvcrt-ruby191.dll(rb_check_safe_str+0x1a4) [0x62ded27c] [0x004011e6] C:\Windows\syswow64\kernel32.dll(GetProfileStringW+0x12aa3) [0x7519003f] C:\Windows\SysWOW64\ntdll.dll(RtlKnownExceptionFilter+0xb7) [0x775c74df] -- Other runtime information ----------------------------------------------- * Loaded script: mt.rb * Loaded features: 0 enumerator.so 1 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/encdb.so 2 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/cp949.so 3 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/trans/transdb.so 4 C:/Ruby193/lib/ruby/1.9.1/rubygems/defaults.rb 5 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/rbconfig.rb 6 C:/Ruby193/lib/ruby/1.9.1/rubygems/deprecate.rb 7 C:/Ruby193/lib/ruby/1.9.1/rubygems/exceptions.rb 8 C:/Ruby193/lib/ruby/1.9.1/rubygems/defaults/operating_system.rb 9 C:/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb 10 C:/Ruby193/lib/ruby/1.9.1/rubygems.rb 11 C:/Ruby193/lib/ruby/1.9.1/rubygems/version.rb 12 C:/Ruby193/lib/ruby/1.9.1/rubygems/requirement.rb 13 C:/Ruby193/lib/ruby/1.9.1/rubygems/platform.rb 14 C:/Ruby193/lib/ruby/1.9.1/rubygems/specification.rb 15 C:/Ruby193/lib/ruby/1.9.1/rubygems/path_support.rb 16 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi_c.so 17 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/platform.rb 18 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/types.rb 19 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/library.rb 20 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/errno.rb 21 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/pointer.rb 22 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/memorypointer.rb 23 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/struct_layout_build er.rb 24 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/struct.rb 25 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/union.rb 26 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/managedstruct.rb 27 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/callback.rb 28 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/io.rb 29 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/autopointer.rb 30 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/variadic.rb 31 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/enum.rb 32 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi/ffi.rb 33 C:/Ruby193/lib/ruby/gems/1.9.1/gems/ffi-1.0.11/lib/ffi.rb 34 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/utf_16le.so 35 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/trans/korean.so 36 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/trans/utf_16_32.so 37 C:/Ruby193/lib/ruby/1.9.1/i386-mingw32/enc/trans/single_byte.so [NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. But, calling without loop block works. require 'ffi' class Win extend FFI::Library ffi_lib 'msvcrt' ffi_convention :stdcall attach_function :_mktemp_s, [:string,:int], :string def self.mktemp str = "rb_file_temp_XXXXXX" _mktemp_s(str,21) p str str = "rb_file_temp_XXXXXX" _mktemp_s(str,21) p str str = "rb_file_temp_XXXXXX" _mktemp_s(str,21) p str end end Win.mktemp #output "rb_file_temp_a03940" "rb_file_temp_a03940" "rb_file_temp_a03940" Regards, Park Heesob From phasis at gmail.com Tue Jan 17 05:00:18 2012 From: phasis at gmail.com (Heesob Park) Date: Tue, 17 Jan 2012 19:00:18 +0900 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References: Message-ID: Hi, 2012/1/14 Daniel Berger : > Is it odd that calling _mktemp more than once in the same process doesn't work? > > require 'ffi' > > class Win > ?extend FFI::Library > > ?ffi_lib 'msvcrt' > ?attach_function :_mktemp, [:string], :string > > ?def self.mktemp > ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } > ?end > end > > Win.mktemp > > # Output > "rb_file_temp_a03680" > nil > nil > nil > nil Here is a proper working version: require 'ffi' class Win extend FFI::Library ffi_lib 'msvcrt' attach_function :_mktemp, [:pointer], :string def self.mktemp 5.times { buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") p _mktemp(buf) } end end Win.mktemp Regards, Park Heesob From djberg96 at gmail.com Tue Jan 17 13:36:16 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 17 Jan 2012 13:36:16 -0500 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: On Tue, Jan 17, 2012 at 5:00 AM, Heesob Park wrote: > Hi, > > 2012/1/14 Daniel Berger : >> Is it odd that calling _mktemp more than once in the same process doesn't work? >> >> require 'ffi' >> >> class Win >> ?extend FFI::Library >> >> ?ffi_lib 'msvcrt' >> ?attach_function :_mktemp, [:string], :string >> >> ?def self.mktemp >> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >> ?end >> end >> >> Win.mktemp >> >> # Output >> "rb_file_temp_a03680" >> nil >> nil >> nil >> nil > > Here is a proper working version: > > > require 'ffi' > > class Win > ?extend FFI::Library > > ?ffi_lib 'msvcrt' > ?attach_function :_mktemp, [:pointer], :string > > ?def self.mktemp > ?5.times { > ? buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") > ? p _mktemp(buf) > ?} > ?end > end > > Win.mktemp That's better, though it seems to return the same string each time instead of providing a new one. I get: "rb_file_temp_a03200" "rb_file_temp_a03200" "rb_file_temp_a03200" "rb_file_temp_a03200" "rb_file_temp_a03200" Regards, Dan From djberg96 at gmail.com Tue Jan 17 14:23:58 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 17 Jan 2012 12:23:58 -0700 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: On Tue, Jan 17, 2012 at 11:36 AM, Daniel Berger wrote: > On Tue, Jan 17, 2012 at 5:00 AM, Heesob Park wrote: >> Hi, >> >> 2012/1/14 Daniel Berger : >>> Is it odd that calling _mktemp more than once in the same process doesn't work? >>> >>> require 'ffi' >>> >>> class Win >>> ?extend FFI::Library >>> >>> ?ffi_lib 'msvcrt' >>> ?attach_function :_mktemp, [:string], :string >>> >>> ?def self.mktemp >>> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >>> ?end >>> end >>> >>> Win.mktemp >>> >>> # Output >>> "rb_file_temp_a03680" >>> nil >>> nil >>> nil >>> nil >> >> Here is a proper working version: >> >> >> require 'ffi' >> >> class Win >> ?extend FFI::Library >> >> ?ffi_lib 'msvcrt' >> ?attach_function :_mktemp, [:pointer], :string >> >> ?def self.mktemp >> ?5.times { >> ? buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") >> ? p _mktemp(buf) >> ?} >> ?end >> end >> >> Win.mktemp > > That's better, though it seems to return the same string each time > instead of providing a new one. I get: > > "rb_file_temp_a03200" > "rb_file_temp_a03200" > "rb_file_temp_a03200" > "rb_file_temp_a03200" > "rb_file_temp_a03200" Actually, I get the same result with the C code that MS provides, too. I think I might be better off writing a custom mktemp method in pure Ruby. Regards, Dan From phasis at gmail.com Tue Jan 17 19:47:57 2012 From: phasis at gmail.com (Heesob Park) Date: Wed, 18 Jan 2012 09:47:57 +0900 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: Hi, 2012/1/18 Daniel Berger : > On Tue, Jan 17, 2012 at 11:36 AM, Daniel Berger wrote: >> On Tue, Jan 17, 2012 at 5:00 AM, Heesob Park wrote: >>> Hi, >>> >>> 2012/1/14 Daniel Berger : >>>> Is it odd that calling _mktemp more than once in the same process doesn't work? >>>> >>>> require 'ffi' >>>> >>>> class Win >>>> ?extend FFI::Library >>>> >>>> ?ffi_lib 'msvcrt' >>>> ?attach_function :_mktemp, [:string], :string >>>> >>>> ?def self.mktemp >>>> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >>>> ?end >>>> end >>>> >>>> Win.mktemp >>>> >>>> # Output >>>> "rb_file_temp_a03680" >>>> nil >>>> nil >>>> nil >>>> nil >>> >>> Here is a proper working version: >>> >>> >>> require 'ffi' >>> >>> class Win >>> ?extend FFI::Library >>> >>> ?ffi_lib 'msvcrt' >>> ?attach_function :_mktemp, [:pointer], :string >>> >>> ?def self.mktemp >>> ?5.times { >>> ? buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") >>> ? p _mktemp(buf) >>> ?} >>> ?end >>> end >>> >>> Win.mktemp >> >> That's better, though it seems to return the same string each time >> instead of providing a new one. I get: >> >> "rb_file_temp_a03200" >> "rb_file_temp_a03200" >> "rb_file_temp_a03200" >> "rb_file_temp_a03200" >> "rb_file_temp_a03200" > > Actually, I get the same result with the C code that MS provides, too. > > I think I might be better off writing a custom mktemp method in pure Ruby. > I guess you overlooked the C code that MS provides, it created file with temp names. If you want the same result with the C code, here is a modified version: require 'ffi' class Win extend FFI::Library ffi_lib 'msvcrt' attach_function :_mktemp, [:pointer], :string def self.mktemp 5.times { buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") p res = _mktemp(buf) File.open(res,"w") } end end Win.mktemp #output "rb_file_temp_a03144" "rb_file_temp_b03144" "rb_file_temp_c03144" "rb_file_temp_d03144" "rb_file_temp_e03144" Regards, Park Heesob From djberg96 at gmail.com Tue Jan 17 21:30:41 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 17 Jan 2012 19:30:41 -0700 Subject: [Win32utils-devel] _mktemp on Windows In-Reply-To: References:

Message-ID: On Tue, Jan 17, 2012 at 5:47 PM, Heesob Park wrote: > Hi, > > 2012/1/18 Daniel Berger : >> On Tue, Jan 17, 2012 at 11:36 AM, Daniel Berger wrote: >>> On Tue, Jan 17, 2012 at 5:00 AM, Heesob Park wrote: >>>> Hi, >>>> >>>> 2012/1/14 Daniel Berger : >>>>> Is it odd that calling _mktemp more than once in the same process doesn't work? >>>>> >>>>> require 'ffi' >>>>> >>>>> class Win >>>>> ?extend FFI::Library >>>>> >>>>> ?ffi_lib 'msvcrt' >>>>> ?attach_function :_mktemp, [:string], :string >>>>> >>>>> ?def self.mktemp >>>>> ? ?5.times{ p _mktemp("rb_file_temp_XXXXXX") } >>>>> ?end >>>>> end >>>>> >>>>> Win.mktemp >>>>> >>>>> # Output >>>>> "rb_file_temp_a03680" >>>>> nil >>>>> nil >>>>> nil >>>>> nil >>>> >>>> Here is a proper working version: >>>> >>>> >>>> require 'ffi' >>>> >>>> class Win >>>> ?extend FFI::Library >>>> >>>> ?ffi_lib 'msvcrt' >>>> ?attach_function :_mktemp, [:pointer], :string >>>> >>>> ?def self.mktemp >>>> ?5.times { >>>> ? buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") >>>> ? p _mktemp(buf) >>>> ?} >>>> ?end >>>> end >>>> >>>> Win.mktemp >>> >>> That's better, though it seems to return the same string each time >>> instead of providing a new one. I get: >>> >>> "rb_file_temp_a03200" >>> "rb_file_temp_a03200" >>> "rb_file_temp_a03200" >>> "rb_file_temp_a03200" >>> "rb_file_temp_a03200" >> >> Actually, I get the same result with the C code that MS provides, too. >> >> I think I might be better off writing a custom mktemp method in pure Ruby. >> > I guess you overlooked the C code that MS provides, it created file > with temp names. > If you want the same result with the C code, here is a modified version: > > require 'ffi' > > class Win > ?extend FFI::Library > > ?ffi_lib 'msvcrt' > ?attach_function :_mktemp, [:pointer], :string > > ?def self.mktemp > ?5.times { > ? buf = FFI::MemoryPointer.from_string("rb_file_temp_XXXXXX") > ? p res = _mktemp(buf) > ? File.open(res,"w") > ?} > ?end > end > > Win.mktemp > > #output > "rb_file_temp_a03144" > "rb_file_temp_b03144" > "rb_file_temp_c03144" > "rb_file_temp_d03144" > "rb_file_temp_e03144" Oh, I see. It doesn't actually create a unique name unless the file is actually created. It doesn't just automatically bump the name. Thanks, Dan From djberg96 at gmail.com Fri Jan 20 01:47:05 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 19 Jan 2012 23:47:05 -0700 Subject: [Win32utils-devel] MSVC and FFI build warnings Message-ID: <003501ccd73f$54869780$fd93c680$@com> Hi, I noticed a couple warnings with FFI on Windows Vista with VC++ 9: .\src\x86\win32.asm(842) : warning A6004:procedure argument or local not referenced : FORCEFRAME .\src\x86\win32.asm(995) : warning A6004:procedure argument or local not referenced : FORCEFRAME Thread.c Thread.c(224) : warning C4101: 'res' : unreferenced local variable Thread.c(255) : warning C4101: 'res' : unreferenced local variable Thread.c(254) : warning C4101: 'state' : unreferenced local variable I also seem to be having trouble with 1.8.7. It builds fine, but won't load: irb(main):001:0> require 'ffi' LoadError: 127: The specified procedure could not be found. - Init_ffi c:/rubyvc9/lib/ruby/site_ruby/1.8/i386-msvcr90/ffi.so from c:/rubyvc9/lib/ruby/site_ruby/1.8/i386-msvcr90/ffi.so from (irb):1 from :0 I tried both the manual approach and the "gem install" approach. Seems to be ok on my 1.9.2 built with VC9, though. Regards, Dan From phasis at gmail.com Fri Jan 20 09:57:39 2012 From: phasis at gmail.com (Heesob Park) Date: Fri, 20 Jan 2012 23:57:39 +0900 Subject: [Win32utils-devel] MSVC and FFI build warnings In-Reply-To: <003501ccd73f$54869780$fd93c680$@com> References: <003501ccd73f$54869780$fd93c680$@com> Message-ID: Hi, 2012/1/20 Daniel Berger : > Hi, > > I noticed a couple warnings with FFI on Windows Vista with VC++ 9: > > .\src\x86\win32.asm(842) : warning A6004:procedure argument or local not > referenced : FORCEFRAME > .\src\x86\win32.asm(995) : warning A6004:procedure argument or local not > referenced : FORCEFRAME > > Thread.c > Thread.c(224) : warning C4101: 'res' : unreferenced local variable > Thread.c(255) : warning C4101: 'res' : unreferenced local variable > Thread.c(254) : warning C4101: 'state' : unreferenced local variable > > I also seem to be having trouble with 1.8.7. It builds fine, but won't load: > > irb(main):001:0> require 'ffi' > LoadError: 127: The specified procedure could not be found. ? - Init_ffi > c:/rubyvc9/lib/ruby/site_ruby/1.8/i386-msvcr90/ffi.so > ? ? ? ?from c:/rubyvc9/lib/ruby/site_ruby/1.8/i386-msvcr90/ffi.so > ? ? ? ?from (irb):1 > ? ? ? ?from :0 > > I tried both the manual approach and the "gem install" approach. Seems to be > ok on my 1.9.2 built with VC9, though. > I think the warnings are ignorable. require 'ffi' is actulally require 'ffi.rb'. And in ffi.rb, you can see require 'ffi_c'. I cannot understand why "ffi.so" is created. /ext/ffi_c/extconf.rb creates Makefile for ffi_c.so. Could you show me the generated Makefile? Regards, Park Heesob From djberg96 at gmail.com Fri Jan 20 11:33:19 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 20 Jan 2012 09:33:19 -0700 Subject: [Win32utils-devel] MSVC and FFI build warnings In-Reply-To: References: <003501ccd73f$54869780$fd93c680$@com> Message-ID: <004a01ccd791$39fb6bf0$adf243d0$@com> Hi > require 'ffi' is actulally require 'ffi.rb'. > And in ffi.rb, you can see require 'ffi_c'. > > I cannot understand why "ffi.so" is created. > /ext/ffi_c/extconf.rb creates Makefile for ffi_c.so. > Could you show me the generated Makefile? VC++ 9 on Windows Vista ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mswin32_90] I ran ruby extconf.rb using the latest from your repo: >ruby extconf.rb checking for ffi.h... no checking for ffi.h in /usr/local/include... no checking for rb_thread_blocking_region()... no checking for ruby_thread_has_gvl_p()... no checking for ruby_native_thread_p()... no checking for rb_thread_call_with_gvl()... no creating extconf.h creating Makefile Here's the Makefile: SHELL = /bin/sh #### Start of system configuration section. #### srcdir = . topdir = c:/rubyvc9/lib/ruby/1.8/i386-mswin32_90 hdrdir = $(topdir) VPATH = $(srcdir);$(topdir);$(hdrdir) DESTDIR = c: exec_prefix = $(prefix) prefix = $(DESTDIR)/rubyvc9 sharedstatedir = $(DESTDIR)/etc mandir = $(prefix)/man oldincludedir = $(DESTDIR)/usr/include bindir = $(exec_prefix)/bin libexecdir = $(exec_prefix)/libexec sitedir = $(prefix)/lib/ruby/site_ruby vendorarchdir = $(vendorlibdir)/$(sitearch) includedir = $(prefix)/include infodir = $(prefix)/info vendorlibdir = $(vendordir)/$(ruby_version) sysconfdir = $(prefix)/etc libdir = $(exec_prefix)/lib sbindir = $(exec_prefix)/sbin rubylibdir = $(libdir)/ruby/$(ruby_version) vendordir = $(prefix)/lib/ruby/vendor_ruby archdir = $(rubylibdir)/$(arch) sitearchdir = $(sitelibdir)/$(sitearch) datadir = $(prefix)/share localstatedir = $(DESTDIR)/var sitelibdir = $(sitedir)/$(ruby_version) CC = cl -W3 -nologo LIBRUBY = $(RUBY_SO_NAME).lib LIBRUBY_A = $(RUBY_SO_NAME)-static.lib LIBRUBYARG_SHARED = $(LIBRUBY) LIBRUBYARG_STATIC = $(LIBRUBY_A) RUBY_EXTCONF_H = extconf.h CFLAGS = -MD -O2b2xty- INCFLAGS = -I. -I. -Ic:/rubyvc9/lib/ruby/1.8/i386-mswin32_90 -I. DEFS = CPPFLAGS = -DRUBY_EXTCONF_H=\"$(RUBY_EXTCONF_H)\" -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE CXXFLAGS = $(CFLAGS) ldflags = dldflags = -link -incremental:no -debug -opt:ref -opt:icf -dll $(LIBPATH) archflag = DLDFLAGS = $(ldflags) $(dldflags) $(archflag) LDSHARED = cl -W3 -nologo -LD AR = lib -nologo EXEEXT = .exe RUBY_INSTALL_NAME = ruby RUBY_SO_NAME = msvcr90-ruby18 arch = i386-mswin32_90 sitearch = i386-msvcr90 ruby_version = 1.8 ruby = c:/rubyvc9/bin/ruby RUBY = $(ruby:/=\) RM = $(RUBY) -run -e rm -- -f MAKEDIRS = @$(RUBY) -run -e mkdir -- -p INSTALL = @$(RUBY) -run -e install -- -vp INSTALL_PROG = $(INSTALL) -m 0755 INSTALL_DATA = $(INSTALL) -m 0644 COPY = copy > nul #### End of system configuration section. #### preload = libpath = . $(libdir) LIBPATH = -libpath:"." -libpath:"$(libdir)" DEFFILE = $(TARGET)-$(arch).def CLEANFILES = mkmf.log DISTCLEANFILES = vc*.pdb $(DEFFILE) extout = extout_prefix = target_prefix = LOCAL_LIBS = ./libffi/.libs/libffi_convenience.lib LIBS = $(LIBRUBYARG_SHARED) oldnames.lib user32.lib advapi32.lib shell32.lib wsock32.lib SRCS = AbstractMemory.c ArrayType.c Buffer.c Call.c ClosurePool.c DataConverter.c DynamicLibrary.c ffi.c Function.c FunctionInfo.c LastError.c MappedType.c MemoryPointer.c MethodHandle.c Platform.c Pointer.c Struct.c StructByReference.c StructByValue.c StructLayout.c Thread.c Type.c Types.c Variadic.c OBJS = AbstractMemory.obj ArrayType.obj Buffer.obj Call.obj ClosurePool.obj DataConverter.obj DynamicLibrary.obj ffi.obj Function.obj FunctionInfo.obj LastError.obj MappedType.obj MemoryPointer.obj MethodHandle.obj Platform.obj Pointer.obj Struct.obj StructByReference.obj StructByValue.obj StructLayout.obj Thread.obj Type.obj Types.obj Variadic.obj TARGET = ffi_c DLLIB = $(TARGET).so EXTSTATIC = STATIC_LIB = BINDIR = $(bindir) RUBYCOMMONDIR = $(sitedir)$(target_prefix) RUBYLIBDIR = $(sitelibdir)$(target_prefix) RUBYARCHDIR = $(sitearchdir)$(target_prefix) TARGET_SO = $(DLLIB) CLEANLIBS = $(TARGET).so $(TARGET).il? $(TARGET).tds $(TARGET).map CLEANOBJS = *.obj *.lib *.s[ol] *.pdb *.exp *.bak all: $(DLLIB) static: $(STATIC_LIB) clean: @-$(RM) $(CLEANLIBS:/=\) $(CLEANOBJS:/=\) $(CLEANFILES:/=\) distclean: clean @-$(RM) Makefile $(RUBY_EXTCONF_H) conftest.* mkmf.log @-$(RM) core ruby$(EXEEXT) *~ $(DISTCLEANFILES:/=\) realclean: distclean install: install-so install-rb install-so: $(RUBYARCHDIR) install-so: $(RUBYARCHDIR)/$(DLLIB) $(RUBYARCHDIR)/$(DLLIB): $(DLLIB) $(INSTALL_PROG) $(DLLIB:/=\) $(RUBYARCHDIR:/=\) install-rb: pre-install-rb install-rb-default install-rb-default: pre-install-rb-default pre-install-rb: Makefile pre-install-rb-default: Makefile $(RUBYARCHDIR): $(MAKEDIRS) $@ site-install: site-install-so site-install-rb site-install-so: install-so site-install-rb: install-rb .SUFFIXES: .c .m .cc .cxx .cpp .obj {$(hdrdir)}.cc{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(topdir)}.cc{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(srcdir)}.cc{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) .cc.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(hdrdir)}.cxx{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(topdir)}.cxx{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(srcdir)}.cxx{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) .cxx.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(hdrdir)}.cpp{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(topdir)}.cpp{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(srcdir)}.cpp{}.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) .cpp.obj: $(CXX) $(INCFLAGS) $(CXXFLAGS) $(CPPFLAGS) -c -Tp$(<:\=/) {$(hdrdir)}.c{}.obj: $(CC) $(INCFLAGS) $(CFLAGS) $(CPPFLAGS) -c -Tc$(<:\=/) {$(topdir)}.c{}.obj: $(CC) $(INCFLAGS) $(CFLAGS) $(CPPFLAGS) -c -Tc$(<:\=/) {$(srcdir)}.c{}.obj: $(CC) $(INCFLAGS) $(CFLAGS) $(CPPFLAGS) -c -Tc$(<:\=/) .c.obj: $(CC) $(INCFLAGS) $(CFLAGS) $(CPPFLAGS) -c -Tc$(<:\=/) $(DLLIB): $(DEFFILE) $(OBJS) Makefile @-$(RM) $@ $(LDSHARED) -Fe$(@) $(OBJS) $(LIBS) $(LOCAL_LIBS) $(DLDFLAGS) -implib:$(*F:.so=)-$(arch).lib -pdb:$(*F:.so=)-$(arch).pdb -def:$(DEFFILE) @if exist $(@).manifest mt -nologo -manifest $(@).manifest -outputresource:$(@);2 @if exist $(@).manifest $(RM) $(@:/=\).manifest $(DEFFILE): $(RUBY) -e "puts 'EXPORTS', 'Init_$(TARGET)'" > $@ $(OBJS): {.;$(VPATH)}ruby.h {.;$(VPATH)}defines.h $(RUBY_EXTCONF_H) LIBFFI_HOST=--host=i686-mswin32_90 !include $(srcdir)/libffi.vc.mk From phasis at gmail.com Fri Jan 20 20:03:32 2012 From: phasis at gmail.com (Heesob Park) Date: Sat, 21 Jan 2012 10:03:32 +0900 Subject: [Win32utils-devel] MSVC and FFI build warnings In-Reply-To: <004a01ccd791$39fb6bf0$adf243d0$@com> References: <003501ccd73f$54869780$fd93c680$@com> <004a01ccd791$39fb6bf0$adf243d0$@com> Message-ID: 2012/1/21 Daniel Berger : > Hi > > > >> require 'ffi' is actulally require 'ffi.rb'. >> And in ffi.rb, you can see require 'ffi_c'. >> >> I cannot understand why "ffi.so" is created. >> /ext/ffi_c/extconf.rb creates Makefile for ffi_c.so. >> Could you show me the generated Makefile? > > VC++ 9 on Windows Vista > ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mswin32_90] > > I ran ruby extconf.rb using the latest from your repo: > >>ruby extconf.rb > checking for ffi.h... no > checking for ffi.h in /usr/local/include... no > checking for rb_thread_blocking_region()... no > checking for ruby_thread_has_gvl_p()... no > checking for ruby_native_thread_p()... no > checking for rb_thread_call_with_gvl()... no > creating extconf.h > creating Makefile > > Here's the Makefile: ... > Your Makefile looks OK. In Makefile, TARGET and DLLIB defined as like this: TARGET = ffi_c DLLIB = $(TARGET).so So, after runng Makefile, the result so file is not "ffi.so" but "ffi_c.so", isn't it? What's the output of "nmake install"? In my environment, C:\work\ffi-ffi-a48ba61\ext\ffi_c>nmake install Microsoft(R) Program Maintenance Utility Version 9.00.30729.01 Copyright (c) Microsoft Corporation. All rights reserved. install -c -p -m 0755 ffi_c.so c:\lib\ruby\site_ruby\1.8\i386-msvcr90 Regards, Park Heesob From djberg96 at gmail.com Sat Jan 21 11:12:28 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 21 Jan 2012 09:12:28 -0700 Subject: [Win32utils-devel] MSVC and FFI build warnings In-Reply-To: References: <003501ccd73f$54869780$fd93c680$@com> <004a01ccd791$39fb6bf0$adf243d0$@com> Message-ID: <006d01ccd857$7a43f490$6ecbddb0$@com> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org [mailto:win32utils-devel- > bounces at rubyforge.org] On Behalf Of Heesob Park > Sent: Friday, January 20, 2012 6:04 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] MSVC and FFI build warnings > > 2012/1/21 Daniel Berger : > > Hi > > > > > > > >> require 'ffi' is actulally require 'ffi.rb'. > >> And in ffi.rb, you can see require 'ffi_c'. > >> > >> I cannot understand why "ffi.so" is created. > >> /ext/ffi_c/extconf.rb creates Makefile for ffi_c.so. > >> Could you show me the generated Makefile? > > > > VC++ 9 on Windows Vista > > ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mswin32_90] > > > > I ran ruby extconf.rb using the latest from your repo: > > > >>ruby extconf.rb > > checking for ffi.h... no > > checking for ffi.h in /usr/local/include... no > > checking for rb_thread_blocking_region()... no > > checking for ruby_thread_has_gvl_p()... no > > checking for ruby_native_thread_p()... no > > checking for rb_thread_call_with_gvl()... no > > creating extconf.h > > creating Makefile > > > > Here's the Makefile: > ... > > > > Your Makefile looks OK. > > In Makefile, TARGET and DLLIB defined as like this: > TARGET = ffi_c > DLLIB = $(TARGET).so > > So, after runng Makefile, the result so file is not "ffi.so" but > "ffi_c.so", isn't it? > What's the output of "nmake install"? > > In my environment, > C:\work\ffi-ffi-a48ba61\ext\ffi_c>nmake install > > Microsoft(R) Program Maintenance Utility Version 9.00.30729.01 > Copyright (c) Microsoft Corporation. All rights reserved. > > install -c -p -m 0755 ffi_c.so c:\lib\ruby\site_ruby\1.8\i386-msvcr90 I must have been screwing around with an earlier version and renamed a file manually. It's working fine now. Sorry for the confusion. Regards, Dan From djberg96 at gmail.com Sat Jan 28 10:56:37 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 28 Jan 2012 08:56:37 -0700 Subject: [Win32utils-devel] windows data types for ffi Message-ID: <01a801ccddd5$6c7bb180$45731480$@com> Hi, With FFI now building with MSVC++ I've been converting the windows-pr stuff to use FFI. One thing that's a bit of a hassle is having to remember the Windows data types, e.g. DWORD, etc. Do you think it would be worth it to add a few of them? I don't want to add them all necessarily because I know there are a lot, but if I could pick just one it would be ":dword". Regards, Dan From phasis at gmail.com Sun Jan 29 00:39:20 2012 From: phasis at gmail.com (Heesob Park) Date: Sun, 29 Jan 2012 14:39:20 +0900 Subject: [Win32utils-devel] windows data types for ffi In-Reply-To: <01a801ccddd5$6c7bb180$45731480$@com> References: <01a801ccddd5$6c7bb180$45731480$@com> Message-ID: Hi, 2012/1/29 Daniel Berger : > Hi, > > With FFI now building with MSVC++ I've been converting the windows-pr stuff > to use FFI. One thing that's a bit of a hassle is having to remember the > Windows data types, e.g. DWORD, etc. > > Do you think it would be worth it to add a few of them? I don't want to add > them all necessarily because I know there are a lot, but if I could pick > just one it would be ":dword". > > I think it would be better to define a separate common Windows data and structure type module like python's ctypes.wintypes. Refer to http://fossies.org/dox/Python-3.2.2/namespacectypes_1_1wintypes.html http://fossies.org/dox/Python-3.2.2/wintypes_8py_source.html > Regards, > > Dan Regards, Park Heesob From djberg96 at gmail.com Sun Jan 29 15:43:51 2012 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 29 Jan 2012 13:43:51 -0700 Subject: [Win32utils-devel] windows data types for ffi In-Reply-To: References: <01a801ccddd5$6c7bb180$45731480$@com> Message-ID: <020501ccdec6$b6e28090$24a781b0$@com> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org [mailto:win32utils-devel- > bounces at rubyforge.org] On Behalf Of Heesob Park > Sent: Saturday, January 28, 2012 10:39 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] windows data types for ffi > > Hi, > > 2012/1/29 Daniel Berger : > > Hi, > > > > With FFI now building with MSVC++ I've been converting the windows-pr > stuff > > to use FFI. One thing that's a bit of a hassle is having to remember > the > > Windows data types, e.g. DWORD, etc. > > > > Do you think it would be worth it to add a few of them? I don't want > to add > > them all necessarily because I know there are a lot, but if I could > pick > > just one it would be ":dword". > > > > > I think it would be better to define a separate common Windows data > and structure type module like python's ctypes.wintypes. > > Refer to > http://fossies.org/dox/Python-3.2.2/namespacectypes_1_1wintypes.html > http://fossies.org/dox/Python-3.2.2/wintypes_8py_source.html Ok. I guess it's easy enough to wrap these use ffi's typedef feature: https://github.com/ffi/ffi/wiki/Examples (bottom) Dan