From noreply at rubyforge.org Sat Jan 10 06:27:13 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 10 Jan 2009 06:27:13 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Feature Requests-23514 ] Possibility to get exitstatus from app ran by open3 Message-ID: <20090110112713.B710518581B8@rubyforge.org> Feature Requests item #23514, was opened at 2009-01-10 12:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=414&aid=23514&group_id=85 Category: win32-open3 Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roman Zawada (zwadar) Assigned to: Nobody (None) Summary: Possibility to get exitstatus from app ran by open3 Initial Comment: Hi, because bug [#23356] http://rubyforge.org/tracker/index.php?func=detail&aid=23356&group_id=85&atid=411 is rather unsolvable, maybe would be possible to introduce some other way to catch proper existatus on Windows machines with Open3 library? I wrote this to bug [#23356] comments, but I pressume no one has read it :-) Saddly lack of exitstatus is reason wy I can't use open3 for now. I'm using http://groups.google.com/group/comp.lang.ruby/msg/c0e7fc74641b9a50 for getting stderr and exitstatus (little bit modyfied, because this script catshes exitstatus of executed ruby script, not from executed app from it), but i think this is realy ugly solution of the problem. Thanks ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=414&aid=23514&group_id=85 From Daniel.Berger at qwest.com Mon Jan 12 09:35:43 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 12 Jan 2009 08:35:43 -0600 Subject: [Win32utils-devel] [ win32utils-Feature Requests-23514 ]Possibility to get exitstatus from app ran by open3 In-Reply-To: <20090110112713.B710518581B8@rubyforge.org> References: <20090110112713.B710518581B8@rubyforge.org> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514F6B@ITOMAE2KM01.AD.QINTRA.COM> Quick followup... > Hi, > because bug [#23356] > http://rubyforge.org/tracker/index.php?func=detail&aid=23356&g > roup_id=85&atid=411 > is rather unsolvable, maybe would be possible to introduce > some other way to catch proper existatus on Windows machines > with Open3 library? > I wrote this to bug [#23356] comments, but I pressume no one > has read it :-) Saddly lack of exitstatus is reason wy I > can't use open3 for now. > I'm using > http://groups.google.com/group/comp.lang.ruby/msg/c0e7fc74641b9a50 > for getting stderr and exitstatus (little bit modyfied, > because this script catshes exitstatus of executed ruby > script, not from executed app from it), but i think this is > realy ugly solution of the problem. This was resolved in win32-open3-0.2.7, which is now available. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From joe.swatosh at gmail.com Wed Jan 14 00:20:42 2009 From: joe.swatosh at gmail.com (Joe Swatosh) Date: Tue, 13 Jan 2009 21:20:42 -0800 Subject: [Win32utils-devel] Fwd: BUG? Win32::Service.create calling CreateServiceW In-Reply-To: References: Message-ID: Hi Dan, When we upgraded win32-process to 0.6.0, we had to upgrade some dependencies. Now we are getting failures when invoking Win32::Service.create in code that used to work. After looking in the registry and futzing around with the code, it appears that when Win32::Service.create calls CreateService, ultimately CreateServiceW is being called. I added this to the file before we invoke anything in Win32::Service, and our app seems to be working again: class Win32::Service def CreateService(*a) CreateServiceA(*a) end def self.OpenService(*a) OpenServiceA(*a) end end But is obviously not a real solution. As an aside, we seem to be having failures when calling Process.create, but need to do more research (some calls fail while others work). This is a Rails app, so maybe ActiveSupport require magic could be changing the order of the requires? I think these are the relevant gem versions: win32-service-0.6.1-x86-mswin32-60 windows-pr-0.9.8 windows-api-0.2.4 win32-api-1.3.0-x86-mswin32-60 win32-process-0.6.0 Thanks -- Joe From djberg96 at gmail.com Wed Jan 14 08:02:35 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 14 Jan 2009 06:02:35 -0700 Subject: [Win32utils-devel] Fwd: BUG? Win32::Service.create calling CreateServiceW In-Reply-To: References: Message-ID: <496DE26B.2020505@gmail.com> Joe Swatosh wrote: > Hi Dan, > > When we upgraded win32-process to 0.6.0, we had to upgrade some dependencies. > > Now we are getting failures when invoking Win32::Service.create in code that > used to work. After looking in the registry and futzing around with the code, > it appears that when Win32::Service.create calls CreateService, ultimately > CreateServiceW is being called. > > I added this to the file before we invoke anything in Win32::Service, and our > app seems to be working again: > > class Win32::Service > def CreateService(*a) > CreateServiceA(*a) > end > def self.OpenService(*a) > OpenServiceA(*a) > end > end > > But is obviously not a real solution. Thanks for the report. If you're calling the 'W' methods it means you're running with $KCODE set to UTF8. > As an aside, we seem to be having failures when calling Process.create, but > need to do more research (some calls fail while others work). This is a Rails > app, so maybe ActiveSupport require magic could be changing the order of the > requires? > > I think these are the relevant gem versions: > win32-service-0.6.1-x86-mswin32-60 > windows-pr-0.9.8 > windows-api-0.2.4 > win32-api-1.3.0-x86-mswin32-60 > win32-process-0.6.0 Probably caused by $KCODE being set to UTF8. What do people think. Should I remove that logic from win32-api altogether? It seems to cause more trouble than it's worth. Regards, Dan From joe.swatosh at gmail.com Wed Jan 14 20:39:30 2009 From: joe.swatosh at gmail.com (Joe Swatosh) Date: Wed, 14 Jan 2009 17:39:30 -0800 Subject: [Win32utils-devel] Fwd: BUG? Win32::Service.create calling CreateServiceW In-Reply-To: <496DE26B.2020505@gmail.com> References: <496DE26B.2020505@gmail.com> Message-ID: On Wed, Jan 14, 2009 at 5:02 AM, Daniel Berger wrote: > Joe Swatosh wrote: >> >> Hi Dan, >> >> When we upgraded win32-process to 0.6.0, we had to upgrade some >> dependencies. >> >> Now we are getting failures when invoking Win32::Service.create in code >> that >> used to work. After looking in the registry and futzing around with the >> code, >> it appears that when Win32::Service.create calls CreateService, ultimately >> CreateServiceW is being called. >> >> I added this to the file before we invoke anything in Win32::Service, and >> our >> app seems to be working again: >> >> class Win32::Service >> def CreateService(*a) >> CreateServiceA(*a) >> end >> def self.OpenService(*a) >> OpenServiceA(*a) >> end >> end >> >> But is obviously not a real solution. > > Thanks for the report. If you're calling the 'W' methods it means you're > running with $KCODE set to UTF8. > >> As an aside, we seem to be having failures when calling Process.create, >> but >> need to do more research (some calls fail while others work). This is a >> Rails >> app, so maybe ActiveSupport require magic could be changing the order of >> the >> requires? >> >> I think these are the relevant gem versions: >> win32-service-0.6.1-x86-mswin32-60 >> windows-pr-0.9.8 >> windows-api-0.2.4 >> win32-api-1.3.0-x86-mswin32-60 >> win32-process-0.6.0 > > Probably caused by $KCODE being set to UTF8. > > What do people think. Should I remove that logic from win32-api altogether? > It seems to cause more trouble than it's worth. > Thanks for your prompt reply. Your explanation makes a lot of sense to me (Rails sets $KCODE). In what version of win32-api did this change? At any rate, we seem to have things working again (with a similar patch for Windows::Process.CreateProcess). I can't really answer your question. If you'd asked before I'd run into this issue, I think I'd've supported the way it is now. On the other hand, we *had* working code, and now after the upgrade not so much. Thanks again! -- Joe From phasis at gmail.com Thu Jan 22 22:09:59 2009 From: phasis at gmail.com (Heesob Park) Date: Fri, 23 Jan 2009 12:09:59 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: Hi, 2008/11/5 Berger, Daniel : > > >> > >> > Another thing to consider, now that Jruby's FFI is now bundled with >> > Jruby itself and supports callbacks, is whether or not we want to >> > declare Jruby as the preferred platform for creating Ruby >> services since >> > it supports native threads. >> > >> > Of course, this means finishing the port of win32-api. :) >> > >> I consider that there are three ways to go to support of the >> Windows native >> threads. >> >> 1. Use Jruby >> 2. Use Ruby 1.9.x >> 3. Implement the Sapphire :) >> >> If you dislike Ruby's dl library, using >> libffi(http://sourceware.org/libffi/) is also possible. > > Well, FFI is supposed to be universal now, though I can't get it to > build on Windows at the moment. So it would be the same code for MRI > (1.8 and 1.9) and Jruby. > In my thought, the current ruby ffi implementation don't care of the Windows support. As far as I know, the ffi developers have no definite plan about releasing of Windows binary. If it were built to binary with mingw compiler, It cannot work with Windows API. It uses dlopen,dlsym and dlclose instead of LoadLibrary,GetProcAddress and FreeLibrary. I managed to build MSVC version of ruby ffi-0.2.0 using win32 libffi source ported by the Python's ctypes library. You can download ctypes at sourceforge [1]. What's your thought about implementing ruby-ffi windows version? Is it worthwhile or meaningless? At now the callback function support is not working but the others work fine. I succeeded following test code: require 'ffi' module Foo extend FFI::Library ffi_lib("advapi32.dll") attach_function("GetUserName", "GetUserNameA", [:string, :pointer], :int) end buf = 0.chr * 256 size = [256].pack('L') p Foo.GetUserName(buf,size) len = size.unpack('L').first puts buf[0,len] [1] http://sourceforge.net/project/showfiles.php?group_id=71702&package_id=71318 Regards, Park Heesob From Daniel.Berger at qwest.com Fri Jan 23 11:00:33 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 23 Jan 2009 10:00:33 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Thursday, January 22, 2009 8:10 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > Well, FFI is supposed to be universal now, though I can't get it to > > build on Windows at the moment. So it would be the same code for MRI > > (1.8 and 1.9) and Jruby. > > > In my thought, the current ruby ffi implementation don't care > of the Windows support. As far as I know, the ffi developers > have no definite plan about releasing of Windows binary. If > it were built to binary with mingw compiler, It cannot work > with Windows API. It uses dlopen,dlsym and dlclose instead of > LoadLibrary,GetProcAddress and FreeLibrary. That's unfortunate. > I managed to build MSVC version of ruby ffi-0.2.0 using win32 > libffi source ported by the Python's ctypes library. You can > download ctypes at sourceforge [1]. > What's your thought about implementing ruby-ffi windows > version? Is it worthwhile or meaningless? It's only worthwhile if the other implementations can run it. Otherwise, I don't see a practical advantage over win32-api. Do you? Also, do you mean that your version requires Python's ctypes library? Or do you mean you've ported it to Ruby? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jftucker at gmail.com Fri Jan 23 12:38:40 2009 From: jftucker at gmail.com (James Tucker) Date: Fri, 23 Jan 2009 17:38:40 +0000 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <6C600A6D-ED00-4C8E-89F6-9A7B47F027E2@gmail.com> On 23 Jan 2009, at 03:09, Heesob Park wrote: > Hi, > > 2008/11/5 Berger, Daniel : >> >> >>>> >>>> Another thing to consider, now that Jruby's FFI is now bundled with >>>> Jruby itself and supports callbacks, is whether or not we want to >>>> declare Jruby as the preferred platform for creating Ruby >>> services since >>>> it supports native threads. >>>> >>>> Of course, this means finishing the port of win32-api. :) >>>> >>> I consider that there are three ways to go to support of the >>> Windows native >>> threads. >>> >>> 1. Use Jruby >>> 2. Use Ruby 1.9.x >>> 3. Implement the Sapphire :) >>> >>> If you dislike Ruby's dl library, using >>> libffi(http://sourceware.org/libffi/) is also possible. >> >> Well, FFI is supposed to be universal now, though I can't get it to >> build on Windows at the moment. So it would be the same code for MRI >> (1.8 and 1.9) and Jruby. >> > In my thought, the current ruby ffi implementation don't care of the > Windows support. As far as I know, the ffi developers have no definite > plan about releasing of Windows binary. If it were built to binary > with mingw compiler, It cannot work with Windows API. It uses > dlopen,dlsym and dlclose instead of LoadLibrary,GetProcAddress and > FreeLibrary. The current hg repo seems to build under mingw with some patches (removing unused (under win32) functionality), however, I have been unable to get the gem install to work (i need to do some more reading in rake-compiler). Until I have some more time to debug I won't know much detail on that. iirc most or all of the ffi test suite passes, from a repo build. > I managed to build MSVC version of ruby ffi-0.2.0 using win32 libffi > source ported by the Python's ctypes library. You can download ctypes > at sourceforge [1]. > What's your thought about implementing ruby-ffi windows version? Is it > worthwhile or meaningless? FFI is slower, but provides significant implementation flexibility (namely portability). It could be harder to stub out in some cases, for users. A bigger problem with this is that under mingw we don't get the SEH stuff. GCC doesn't support it, and by the looks of the various documentation / mailing list messages around, there is no really solid implementation at this point (although this may be old/stale information). From what I can see, it appears that the strongest implementation can be found in the Wine project, but may take a lot of work to get it where ruby would want / need it. This means that _try, _finalize (both used in win32-services / win32- api (i can't remember which - may be both)) don't work as expected. My solution to date (using mingw), in order to maintain some semblance of error handling, is to simply gem inst --platform=x86-mswin32-60 win32-services, however this is far from ideal. I am doubtful that simply omitting these lines (_try, _finalize) is a good idea, and more than this, I am not sure there is any way at all to implement them whilst using the FFI. > At now the callback function support is not working but the others > work fine. > > I succeeded following test code: > > require 'ffi' > module Foo > extend FFI::Library > ffi_lib("advapi32.dll") > attach_function("GetUserName", "GetUserNameA", > [:string, :pointer], :int) > end > > buf = 0.chr * 256 > size = [256].pack('L') > p Foo.GetUserName(buf,size) > len = size.unpack('L').first > puts buf[0,len] > > > > [1] http://sourceforge.net/project/showfiles.php?group_id=71702&package_id=71318 > > Regards, > > Park Heesob > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel From phasis at gmail.com Fri Jan 23 17:40:57 2009 From: phasis at gmail.com (Heesob Park) Date: Sat, 24 Jan 2009 07:40:57 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2009/1/24 Berger, Daniel : >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Heesob Park >> Sent: Thursday, January 22, 2009 8:10 PM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > >> > Well, FFI is supposed to be universal now, though I can't get it to >> > build on Windows at the moment. So it would be the same code for MRI >> > (1.8 and 1.9) and Jruby. >> > >> In my thought, the current ruby ffi implementation don't care >> of the Windows support. As far as I know, the ffi developers >> have no definite plan about releasing of Windows binary. If >> it were built to binary with mingw compiler, It cannot work >> with Windows API. It uses dlopen,dlsym and dlclose instead of >> LoadLibrary,GetProcAddress and FreeLibrary. > > That's unfortunate. > >> I managed to build MSVC version of ruby ffi-0.2.0 using win32 >> libffi source ported by the Python's ctypes library. You can >> download ctypes at sourceforge [1]. >> What's your thought about implementing ruby-ffi windows >> version? Is it worthwhile or meaningless? > > It's only worthwhile if the other implementations can run it. Otherwise, > I don't see a practical advantage over win32-api. Do you? > I don't care of it. I just want to implement win32 version of libffi. > Also, do you mean that your version requires Python's ctypes library? Or > do you mean you've ported it to Ruby? > I have pasted the ctypes libffi win32 folder to ruby-ffi just as Lua did on alien library. At last, I succeeded callback function testing. The patched source code and binary gem is at http://121.78.227.9/ffi-0.2.0/ Regards, Park Heesob From Daniel.Berger at qwest.com Mon Jan 26 12:09:01 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 26 Jan 2009 11:09:01 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E10@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.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 23, 2009 3:41 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > 2009/1/24 Berger, Daniel : > >> -----Original Message----- > >> From: win32utils-devel-bounces at rubyforge.org > >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf > Of Heesob > >> Park > >> Sent: Thursday, January 22, 2009 8:10 PM > >> To: Development and ideas for win32utils projects > >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > > > > > > >> > Well, FFI is supposed to be universal now, though I > can't get it to > >> > build on Windows at the moment. So it would be the same code for > >> > MRI > >> > (1.8 and 1.9) and Jruby. > >> > > >> In my thought, the current ruby ffi implementation don't > care of the > >> Windows support. As far as I know, the ffi developers have no > >> definite plan about releasing of Windows binary. If it > were built to > >> binary with mingw compiler, It cannot work with Windows > API. It uses > >> dlopen,dlsym and dlclose instead of LoadLibrary,GetProcAddress and > >> FreeLibrary. > > > > That's unfortunate. > > > >> I managed to build MSVC version of ruby ffi-0.2.0 using > win32 libffi > >> source ported by the Python's ctypes library. You can > download ctypes > >> at sourceforge [1]. > >> What's your thought about implementing ruby-ffi windows > version? Is > >> it worthwhile or meaningless? > > > > It's only worthwhile if the other implementations can run it. > > Otherwise, I don't see a practical advantage over win32-api. Do you? > > > I don't care of it. I just want to implement win32 version of libffi. > > > Also, do you mean that your version requires Python's > ctypes library? > > Or do you mean you've ported it to Ruby? > > > I have pasted the ctypes libffi win32 folder to ruby-ffi just > as Lua did on alien library. > At last, I succeeded callback function testing. > The patched source code and binary gem is at > http://121.78.227.9/ffi-0.2.0/ Very impressive! In theory we should be able to rewrite win32-api with your FFI and it would be compatible with Jruby, Rubinius, etc. Is there a way to build and install it from source on Windows using MS VC++? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From luislavena at gmail.com Mon Jan 26 16:13:12 2009 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 26 Jan 2009 19:13:12 -0200 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0901261313p3eadff62n20f9a970b164b38c@mail.gmail.com> On Mon, Jan 26, 2009 at 3:09 PM, Berger, Daniel wrote: > > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Heesob Park >> Sent: Friday, January 23, 2009 3:41 PM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> 2009/1/24 Berger, Daniel : >> >> -----Original Message----- >> >> From: win32utils-devel-bounces at rubyforge.org >> >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf >> Of Heesob >> >> Park >> >> Sent: Thursday, January 22, 2009 8:10 PM >> >> To: Development and ideas for win32utils projects >> >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> > >> > >> > >> >> > Well, FFI is supposed to be universal now, though I >> can't get it to >> >> > build on Windows at the moment. So it would be the same code for >> >> > MRI >> >> > (1.8 and 1.9) and Jruby. >> >> > >> >> In my thought, the current ruby ffi implementation don't >> care of the >> >> Windows support. As far as I know, the ffi developers have no >> >> definite plan about releasing of Windows binary. If it >> were built to >> >> binary with mingw compiler, It cannot work with Windows >> API. It uses >> >> dlopen,dlsym and dlclose instead of LoadLibrary,GetProcAddress and >> >> FreeLibrary. >> > >> > That's unfortunate. >> > >> >> I managed to build MSVC version of ruby ffi-0.2.0 using >> win32 libffi >> >> source ported by the Python's ctypes library. You can >> download ctypes >> >> at sourceforge [1]. >> >> What's your thought about implementing ruby-ffi windows >> version? Is >> >> it worthwhile or meaningless? >> > >> > It's only worthwhile if the other implementations can run it. >> > Otherwise, I don't see a practical advantage over win32-api. Do you? >> > >> I don't care of it. I just want to implement win32 version of libffi. >> >> > Also, do you mean that your version requires Python's >> ctypes library? >> > Or do you mean you've ported it to Ruby? >> > >> I have pasted the ctypes libffi win32 folder to ruby-ffi just >> as Lua did on alien library. >> At last, I succeeded callback function testing. >> The patched source code and binary gem is at >> http://121.78.227.9/ffi-0.2.0/ > > Very impressive! > > In theory we should be able to rewrite win32-api with your FFI and it > would be compatible with Jruby, Rubinius, etc. > > Is there a way to build and install it from source on Windows using MS > VC++? > I think not without a fight. the libffi bundled in ruby-ffi includes makefiles that conform gnu-make format and don't play realy nice with nmake. > Thanks, > > Dan > > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From phasis at gmail.com Mon Jan 26 18:16:01 2009 From: phasis at gmail.com (Heesob Park) Date: Tue, 27 Jan 2009 08:16:01 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: >> > >> I have pasted the ctypes libffi win32 folder to ruby-ffi just >> as Lua did on alien library. >> At last, I succeeded callback function testing. >> The patched source code and binary gem is at >> http://121.78.227.9/ffi-0.2.0/ > > Very impressive! > > In theory we should be able to rewrite win32-api with your FFI and it > would be compatible with Jruby, Rubinius, etc. > > Is there a way to build and install it from source on Windows using MS > VC++? > I guess you didn't look into the source code package yet. I patched Rakefile and extconf.rb also. You can build and install it using your MSVC++. Regards, Park Heesob From Daniel.Berger at qwest.com Tue Jan 27 10:34:03 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 27 Jan 2009 09:34:03 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E21@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Monday, January 26, 2009 4:16 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > >> > > >> I have pasted the ctypes libffi win32 folder to ruby-ffi > just as Lua > >> did on alien library. > >> At last, I succeeded callback function testing. > >> The patched source code and binary gem is at > >> http://121.78.227.9/ffi-0.2.0/ > > > > Very impressive! > > > > In theory we should be able to rewrite win32-api with your > FFI and it > > would be compatible with Jruby, Rubinius, etc. > > > > Is there a way to build and install it from source on > Windows using MS > > VC++? > > > I guess you didn't look into the source code package yet. > I patched Rakefile and extconf.rb also. > You can build and install it using your MSVC++. Cool. Where did you post the new code? The link above looks like it's still the old code. Thanks, Dan From phasis at gmail.com Tue Jan 27 19:58:07 2009 From: phasis at gmail.com (Heesob Park) Date: Wed, 28 Jan 2009 09:58:07 +0900 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514E2E@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: 2009/1/28 Berger, Daniel : > > >> -----Original Message----- >> From: win32utils-devel-bounces at rubyforge.org >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of >> Heesob Park >> Sent: Monday, January 26, 2009 4:16 PM >> To: Development and ideas for win32utils projects >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem >> >> >> > >> >> I have pasted the ctypes libffi win32 folder to ruby-ffi >> just as Lua >> >> did on alien library. >> >> At last, I succeeded callback function testing. >> >> The patched source code and binary gem is at >> >> http://121.78.227.9/ffi-0.2.0/ >> > >> > Very impressive! >> > >> > In theory we should be able to rewrite win32-api with your >> FFI and it >> > would be compatible with Jruby, Rubinius, etc. >> > >> > Is there a way to build and install it from source on >> Windows using MS >> > VC++? >> > >> I guess you didn't look into the source code package yet. >> I patched Rakefile and extconf.rb also. >> You can build and install it using your MSVC++. > > Cool. Where did you post the new code? The link above looks like it's still the old code. > What do you expect? The current link http://121.78.227.9/ffi-0.2.0/ffi-0.2.0.tgz (948131 bytes) is the latest patched version. What's the problem? Did you try ruby extconf.rb and nmake in the ext folder? Regards, Park Heesob From Daniel.Berger at qwest.com Wed Jan 28 10:12:58 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 28 Jan 2009 09:12:58 -0600 Subject: [Win32utils-devel] win32-daemon 0.6.1 problem In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E04@ITOMAE2KM01.AD.QINTRA. COM><7524A45A1A5B264FA4809E2156496CFB04514E2B@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB 04514E2E@ITOMAE2KM01.AD.QINTRA.COM><7524A45A1A5B264FA4809E2156496CFB04514FBC@ITOMAE2KM01. AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB04514FC2@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: > -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Heesob Park > Sent: Tuesday, January 27, 2009 5:58 PM > To: Development and ideas for win32utils projects > Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > > 2009/1/28 Berger, Daniel : > > > > > >> -----Original Message----- > >> From: win32utils-devel-bounces at rubyforge.org > >> [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf > Of Heesob > >> Park > >> Sent: Monday, January 26, 2009 4:16 PM > >> To: Development and ideas for win32utils projects > >> Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem > >> > >> >> > > >> >> I have pasted the ctypes libffi win32 folder to ruby-ffi > >> just as Lua > >> >> did on alien library. > >> >> At last, I succeeded callback function testing. > >> >> The patched source code and binary gem is at > >> >> http://121.78.227.9/ffi-0.2.0/ > >> > > >> > Very impressive! > >> > > >> > In theory we should be able to rewrite win32-api with your > >> FFI and it > >> > would be compatible with Jruby, Rubinius, etc. > >> > > >> > Is there a way to build and install it from source on > >> Windows using MS > >> > VC++? > >> > > >> I guess you didn't look into the source code package yet. > >> I patched Rakefile and extconf.rb also. > >> You can build and install it using your MSVC++. > > > > Cool. Where did you post the new code? The link above looks > like it's still the old code. > > > What do you expect? The current link > http://121.78.227.9/ffi-0.2.0/ffi-0.2.0.tgz (948131 bytes) is > the latest patched version. > What's the problem? Did you try ruby extconf.rb and nmake in > the ext folder? Oh, my fault. I tried to do "rake install" and that failed. When I did "ruby extconf.rb" + "nmake" it worked fine. Thanks! Dan From noreply at rubyforge.org Thu Jan 29 22:17:36 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 29 Jan 2009 22:17:36 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Support Requests-23746 ] File.size fails on locked file (and causes major rdebug wierdness) Message-ID: <20090130031736.7BD0C1858109@rubyforge.org> Support Requests item #23746, was opened at 2009-01-29 22:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=412&aid=23746&group_id=85 Category: win32-file Group: None Status: Open Resolution: None Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: File.size fails on locked file (and causes major rdebug wierdness) Initial Comment: Running the following script fails in an ugly fashion. Note that the default File.size does not fail (but it also returns an incorrect result, a negative number). #test.rb require 'win32/file' x = File.size('c:/pagefile.sys') puts x C:\docs\Prog\PSTTools>test.rb c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586: in `get_file_type': unknown error - The process cannot access the file because it is being used by another process. (SystemCallError) from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' from C:/docs/Prog/PSTTools/test.rb:3 So I tried to dig into the win32-file source to see where it's failing -- a size command really shouldn't need to lock the file. The really puzzling thing is that I cannot successfully run rdebug on this. Even if I set a breakpoint before the call to File.size, rdebug errors out before it arrives. I'm not skilled enough (yet) to determine if this is related to the win32-size bug, or a problem with rdebug (ver 0.10.3). Here's what happens: C:\docs\Prog\PSTTools>rdebug test.rb C:/docs/Prog/PSTTools/test.rb:1 require 'win32/file' (rdb:1) list [-4, 5] in C:/docs/Prog/PSTTools/test.rb => 1 require 'win32/file' 2 3 x = File.size('c:/pagefile.sys') 4 puts x 5 (rdb:1) b 3 Breakpoint 1 file C:/docs/Prog/PSTTools/test.rb, line 3 (rdb:1) n INTERNAL ERROR!!! no implicit conversion from nil to integer c:/ruby/lib/ruby/1.8/pathname.rb:269:in `[]' c:/ruby/lib/ruby/1.8/pathname.rb:269:in `chop_basename' c:/ruby/lib/ruby/1.8/pathname.rb:322:in `cleanpath_aggressive' c:/ruby/lib/ruby/1.8/pathname.rb:310:in `cleanpath' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:93:in `canonic_file' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:98:in `print_location_and_text' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:243:in `process_commands' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:171:in `__at_line' (eval):5:in `at_line' (eval):3:in `synchronize' (eval):3:in `at_line' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-base-0.10.3-x86-mswin32/lib/ruby-debug-base.rb:54:in `at_line' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586:in `get_file_type' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 Uncaught exception: unknown error - The process cannot access the file because it is being used by another process. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=412&aid=23746&group_id=85 From noreply at rubyforge.org Fri Jan 30 09:30:22 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 30 Jan 2009 09:30:22 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Support Requests-23746 ] File.size fails on locked file (and causes major rdebug wierdness) Message-ID: <20090130143022.D9BF218580FC@rubyforge.org> Support Requests item #23746, was opened at 2009-01-30 12:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=412&aid=23746&group_id=85 Category: win32-file Group: None Status: Open Resolution: None Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: File.size fails on locked file (and causes major rdebug wierdness) Initial Comment: Running the following script fails in an ugly fashion. Note that the default File.size does not fail (but it also returns an incorrect result, a negative number). #test.rb require 'win32/file' x = File.size('c:/pagefile.sys') puts x C:\docs\Prog\PSTTools>test.rb c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586: in `get_file_type': unknown error - The process cannot access the file because it is being used by another process. (SystemCallError) from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' from C:/docs/Prog/PSTTools/test.rb:3 So I tried to dig into the win32-file source to see where it's failing -- a size command really shouldn't need to lock the file. The really puzzling thing is that I cannot successfully run rdebug on this. Even if I set a breakpoint before the call to File.size, rdebug errors out before it arrives. I'm not skilled enough (yet) to determine if this is related to the win32-size bug, or a problem with rdebug (ver 0.10.3). Here's what happens: C:\docs\Prog\PSTTools>rdebug test.rb C:/docs/Prog/PSTTools/test.rb:1 require 'win32/file' (rdb:1) list [-4, 5] in C:/docs/Prog/PSTTools/test.rb => 1 require 'win32/file' 2 3 x = File.size('c:/pagefile.sys') 4 puts x 5 (rdb:1) b 3 Breakpoint 1 file C:/docs/Prog/PSTTools/test.rb, line 3 (rdb:1) n INTERNAL ERROR!!! no implicit conversion from nil to integer c:/ruby/lib/ruby/1.8/pathname.rb:269:in `[]' c:/ruby/lib/ruby/1.8/pathname.rb:269:in `chop_basename' c:/ruby/lib/ruby/1.8/pathname.rb:322:in `cleanpath_aggressive' c:/ruby/lib/ruby/1.8/pathname.rb:310:in `cleanpath' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:93:in `canonic_file' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:98:in `print_location_and_text' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:243:in `process_commands' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:171:in `__at_line' (eval):5:in `at_line' (eval):3:in `synchronize' (eval):3:in `at_line' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-base-0.10.3-x86-mswin32/lib/ruby-debug-base.rb:54:in `at_line' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586:in `get_file_type' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 Uncaught exception: unknown error - The process cannot access the file because it is being used by another process. ---------------------------------------------------------------------- >Comment By: Park Heesob (phasis68) Date: 2009-01-30 23:30 Message: There are two issues in this error. First, the Standard API function CreateFile cannot open file locked by "System" such as "pagefile.sys". We need other workaround to handle system locked file. Second, the complex stat call is not needed to get only the file size. Here is a usable size method for win32-file: def size(file) # File::Stat.new(file).size buffer = 0.chr * 512 h = FindFirstFile(file,buffer) if h == INVALID_HANDLE_VALUE raise SystemCallError,get_last_error() end FindClose(h) (buffer[28,4].unpack('L').first << 32) + buffer[32,4].unpack('L').first end Regards, Park Heesob ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=412&aid=23746&group_id=85 From noreply at rubyforge.org Sat Jan 31 07:01:10 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 31 Jan 2009 07:01:10 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Bugs-23746 ] File.size fails on locked file (and causes major rdebug wierdness) Message-ID: <20090131120110.49DE218580F0@rubyforge.org> Bugs item #23746, was opened at 2009-01-29 20:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23746&group_id=85 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: File.size fails on locked file (and causes major rdebug wierdness) Initial Comment: Running the following script fails in an ugly fashion. Note that the default File.size does not fail (but it also returns an incorrect result, a negative number). #test.rb require 'win32/file' x = File.size('c:/pagefile.sys') puts x C:\docs\Prog\PSTTools>test.rb c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586: in `get_file_type': unknown error - The process cannot access the file because it is being used by another process. (SystemCallError) from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' from C:/docs/Prog/PSTTools/test.rb:3 So I tried to dig into the win32-file source to see where it's failing -- a size command really shouldn't need to lock the file. The really puzzling thing is that I cannot successfully run rdebug on this. Even if I set a breakpoint before the call to File.size, rdebug errors out before it arrives. I'm not skilled enough (yet) to determine if this is related to the win32-size bug, or a problem with rdebug (ver 0.10.3). Here's what happens: C:\docs\Prog\PSTTools>rdebug test.rb C:/docs/Prog/PSTTools/test.rb:1 require 'win32/file' (rdb:1) list [-4, 5] in C:/docs/Prog/PSTTools/test.rb => 1 require 'win32/file' 2 3 x = File.size('c:/pagefile.sys') 4 puts x 5 (rdb:1) b 3 Breakpoint 1 file C:/docs/Prog/PSTTools/test.rb, line 3 (rdb:1) n INTERNAL ERROR!!! no implicit conversion from nil to integer c:/ruby/lib/ruby/1.8/pathname.rb:269:in `[]' c:/ruby/lib/ruby/1.8/pathname.rb:269:in `chop_basename' c:/ruby/lib/ruby/1.8/pathname.rb:322:in `cleanpath_aggressive' c:/ruby/lib/ruby/1.8/pathname.rb:310:in `cleanpath' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:93:in `canonic_file' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:98:in `print_location_and_text' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:243:in `process_commands' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:171:in `__at_line' (eval):5:in `at_line' (eval):3:in `synchronize' (eval):3:in `at_line' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-base-0.10.3-x86-mswin32/lib/ruby-debug-base.rb:54:in `at_line' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586:in `get_file_type' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 Uncaught exception: unknown error - The process cannot access the file because it is being used by another process. ---------------------------------------------------------------------- >Comment By: Daniel Berger (djberg96) Date: 2009-01-31 05:01 Message: That will work, thanks. The problem with that approach, however, is that it would result in having two separate implementations - one for File.size, and one for File::Stat#size. The also noticed that GetFileAttributes fails on that file, so it's double trouble. Maybe I should replace the Win32::File::Stat implementation with one that uses FindFirstFile, since the WIN32_FIND_DATA struct stores attribute information as well. Dan ---------------------------------------------------------------------- Comment By: Park Heesob (phasis68) Date: 2009-01-30 07:30 Message: There are two issues in this error. First, the Standard API function CreateFile cannot open file locked by "System" such as "pagefile.sys". We need other workaround to handle system locked file. Second, the complex stat call is not needed to get only the file size. Here is a usable size method for win32-file: def size(file) # File::Stat.new(file).size buffer = 0.chr * 512 h = FindFirstFile(file,buffer) if h == INVALID_HANDLE_VALUE raise SystemCallError,get_last_error() end FindClose(h) (buffer[28,4].unpack('L').first << 32) + buffer[32,4].unpack('L').first end Regards, Park Heesob ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23746&group_id=85 From noreply at rubyforge.org Sat Jan 31 08:40:02 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 31 Jan 2009 08:40:02 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Bugs-23746 ] File.size fails on locked file (and causes major rdebug wierdness) Message-ID: <20090131134002.628E518580FB@rubyforge.org> Bugs item #23746, was opened at 2009-01-30 12:17 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23746&group_id=85 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: File.size fails on locked file (and causes major rdebug wierdness) Initial Comment: Running the following script fails in an ugly fashion. Note that the default File.size does not fail (but it also returns an incorrect result, a negative number). #test.rb require 'win32/file' x = File.size('c:/pagefile.sys') puts x C:\docs\Prog\PSTTools>test.rb c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586: in `get_file_type': unknown error - The process cannot access the file because it is being used by another process. (SystemCallError) from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' from c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' from C:/docs/Prog/PSTTools/test.rb:3 So I tried to dig into the win32-file source to see where it's failing -- a size command really shouldn't need to lock the file. The really puzzling thing is that I cannot successfully run rdebug on this. Even if I set a breakpoint before the call to File.size, rdebug errors out before it arrives. I'm not skilled enough (yet) to determine if this is related to the win32-size bug, or a problem with rdebug (ver 0.10.3). Here's what happens: C:\docs\Prog\PSTTools>rdebug test.rb C:/docs/Prog/PSTTools/test.rb:1 require 'win32/file' (rdb:1) list [-4, 5] in C:/docs/Prog/PSTTools/test.rb => 1 require 'win32/file' 2 3 x = File.size('c:/pagefile.sys') 4 puts x 5 (rdb:1) b 3 Breakpoint 1 file C:/docs/Prog/PSTTools/test.rb, line 3 (rdb:1) n INTERNAL ERROR!!! no implicit conversion from nil to integer c:/ruby/lib/ruby/1.8/pathname.rb:269:in `[]' c:/ruby/lib/ruby/1.8/pathname.rb:269:in `chop_basename' c:/ruby/lib/ruby/1.8/pathname.rb:322:in `cleanpath_aggressive' c:/ruby/lib/ruby/1.8/pathname.rb:310:in `cleanpath' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:93:in `canonic_file' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:98:in `print_location_and_text' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:243:in `process_commands' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/cli/ruby-debug/processor.rb:171:in `__at_line' (eval):5:in `at_line' (eval):3:in `synchronize' (eval):3:in `at_line' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-base-0.10.3-x86-mswin32/lib/ruby-debug-base.rb:54:in `at_line' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:586:in `get_file_type' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-stat-1.3.2/lib/win32/file/stat.rb:58:in `initialize' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `new' c:/ruby/lib/ruby/gems/1.8/gems/win32-file-0.6.0/lib/win32/file.rb:669:in `size' C:/docs/Prog/PSTTools/test.rb:3 c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_load' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:125:in `debug_program' c:/ruby/lib/ruby/gems/1.8/gems/ruby-debug-0.10.3/bin/rdebug:412 c:/ruby/bin/rdebug:19:in `load' c:/ruby/bin/rdebug:19 Uncaught exception: unknown error - The process cannot access the file because it is being used by another process. ---------------------------------------------------------------------- >Comment By: Park Heesob (phasis68) Date: 2009-01-31 22:40 Message: Win32::File::Stat implementation with FindFirst would be better. If you really want to keep the current implementation, you can get the handle of system locked file by the undocumented NtQuerySystemInformation API instead of CreateFile. Refer to http://forum.sysinternals.com/forum_posts.asp?TID=3577 Regards, Park Heesob ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-31 21:01 Message: That will work, thanks. The problem with that approach, however, is that it would result in having two separate implementations - one for File.size, and one for File::Stat#size. The also noticed that GetFileAttributes fails on that file, so it's double trouble. Maybe I should replace the Win32::File::Stat implementation with one that uses FindFirstFile, since the WIN32_FIND_DATA struct stores attribute information as well. Dan ---------------------------------------------------------------------- Comment By: Park Heesob (phasis68) Date: 2009-01-30 23:30 Message: There are two issues in this error. First, the Standard API function CreateFile cannot open file locked by "System" such as "pagefile.sys". We need other workaround to handle system locked file. Second, the complex stat call is not needed to get only the file size. Here is a usable size method for win32-file: def size(file) # File::Stat.new(file).size buffer = 0.chr * 512 h = FindFirstFile(file,buffer) if h == INVALID_HANDLE_VALUE raise SystemCallError,get_last_error() end FindClose(h) (buffer[28,4].unpack('L').first << 32) + buffer[32,4].unpack('L').first end Regards, Park Heesob ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23746&group_id=85 From noreply at rubyforge.org Sat Jan 31 17:16:38 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 31 Jan 2009 17:16:38 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Bugs-23761 ] crash when require 'win32/file' is followed by another require statement Message-ID: <20090131221638.26A4118580F6@rubyforge.org> Bugs item #23761, was opened at 2009-01-31 17:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23761&group_id=85 Category: win32-file Group: None Status: Open Resolution: None Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: crash when require 'win32/file' is followed by another require statement Initial Comment: gem --version win32-file => 1.3.1 1. Seems I cannot require anything after 'win32/file' without generating an error. The following 3-line foo.rb dies as shown below: ==================================== require 'win32/file' require 'trollop' # same behavior with various different requires puts 'hello world' ==================================== C:\docs\Prog\PSTTools>foo.rb c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- trollop (LoadError) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from C:/docs/Prog/PSTTools/foo.rb:2 2. No error occurs if I reverse the order of the two requires. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23761&group_id=85 From noreply at rubyforge.org Sat Jan 31 17:21:25 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 31 Jan 2009 17:21:25 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Bugs-23762 ] incompatibility with rubyscript2exe Message-ID: <20090131222125.66D1318580F6@rubyforge.org> Bugs item #23762, was opened at 2009-01-31 17:21 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23762&group_id=85 Category: win32-file Group: None Status: Open Resolution: None Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: incompatibility with rubyscript2exe Initial Comment: Attempting to "compile" script with win32/file generates an error. win32-file (0.6.0) win32-file-stat (1.3.2) rubyscript2exe (0.5.3) #foo.rb require 'win32/file' puts 'hello world' Error: C:\docs\Prog\PSTTools>rubyscript2exe foo.rb Tracing foo ... hello world Gathering files... c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/require2lib.rb:56:in `mkdir': No such file or directory - c:/temp/oldandnewlocation.1796/lib/rubyscript2exe.gems (Errno::ENOENT) from c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/require2lib.rb:56:in `gatherlibs' from c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/require2lib.rb:30 from foo.rb:3 Couldn't execute this command (rc=256): c:\ruby\bin\ruby -r 'enumerator.so' -r 'rubygems/rubygems_version.rb' -r 'rubygems/defaults.rb' -r 'thread.so' -r 'thread.rb' -r 'rbconfig.rb' -r 'rubygems/exceptions.rb' -r 'rubygems/requirement.rb' -r 'rubygems/version.rb' -r 'rubygems/dependency.rb' -r 'rubygems/gem_path_searcher.rb' -r 'rubygems/user_interaction.rb ' -r 'rubygems/platform.rb' -r 'rubygems/specification.rb' -r 'rubygems/source_index.rb' -r 'rubygems/builder.rb' -r 'stringio.so' -r 'yaml/error.rb' -r 'syck.so' -r 'yaml/ypath.rb' -r 'yaml/basenode.rb' -r 'yaml/syck.rb' -r 'yaml/tag.rb' -r 'yaml/stream.rb' -r 'yaml/constants.rb' -r 'rational.rb' -r 'date/format.rb' -r 'date.rb' -r 'yaml/rubytypes.rb' -r 'yaml/types.rb' -r 'yaml.rb' -r 'Win32API.so' -r 'rubygems/config_file.rb' -r 'rubygems/custom_require.rb' -r 'rubygems.rb' -r 'ubygems.rb' -r 'etc.so' -r 'fileutils.rb' -I 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe' -I 'c:/temp/tar2rubyscript.d.1796.1' -I './lib' -I 'c:/docs/prog/ruby/lib' -I 'c:/ruby/lib/ruby/gems/1.8/gems/rubyscript2exe-0.5.3/bin' -I 'c:/ruby/lib/ruby/gems/1.8/gems/rubyscript2exe-0.5.3/lib' -I 'c:/ruby/lib/ruby/site_ruby/1.8' -I 'c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt' -I 'c:/ruby/lib/ruby/site_ruby' -I 'c:/ruby/lib/ruby/vendor_ruby/1.8' -I 'c:/ruby/lib/ruby/vendor_ruby/1.8/i386-msvcrt' -I 'c:/ruby/lib/ruby/vendor_ruby' -I 'c:/ruby/lib/ruby/1.8' -I 'c:/ruby/lib/ruby/1.8/i386-mswin32' -I '.' -I 'C:/docs/Prog/PSTTools' -I 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe' -I 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/lib' -I 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe' -I 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/lib' -r 'c:/temp/tar2rubyscript.d.1796.1/rubyscript2exe/require2lib.rb' 'foo.rb' Stopped. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23762&group_id=85 From noreply at rubyforge.org Sat Jan 31 17:22:42 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 31 Jan 2009 17:22:42 -0500 (EST) Subject: [Win32utils-devel] [ win32utils-Bugs-23761 ] crash when require 'win32/file' is followed by another require statement Message-ID: <20090131222242.A072918580F6@rubyforge.org> Bugs item #23761, was opened at 2009-01-31 17:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23761&group_id=85 Category: win32-file Group: None Status: Open Resolution: None Priority: 3 Submitted By: Montgomery Kosma (mkosma) Assigned to: Nobody (None) Summary: crash when require 'win32/file' is followed by another require statement Initial Comment: gem --version win32-file => 1.3.1 1. Seems I cannot require anything after 'win32/file' without generating an error. The following 3-line foo.rb dies as shown below: ==================================== require 'win32/file' require 'trollop' # same behavior with various different requires puts 'hello world' ==================================== C:\docs\Prog\PSTTools>foo.rb c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- trollop (LoadError) from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' from C:/docs/Prog/PSTTools/foo.rb:2 2. No error occurs if I reverse the order of the two requires. ---------------------------------------------------------------------- >Comment By: Montgomery Kosma (mkosma) Date: 2009-01-31 17:22 Message: sorry, provided gem version not win32-file version. win32-file (0.6.0) win32-file-stat (1.3.2) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=411&aid=23761&group_id=85