From djberg96 at yahoo.com Sun Nov 14 23:15:29 2004 From: djberg96 at yahoo.com (Daniel Berger) Date: Sun Nov 14 23:15:14 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 Message-ID: <20041115041529.18861.qmail@web50303.mail.yahoo.com> Hi all, Windows 2000 VC++ 6 I recently hit a couple of issues with RC9. First, I wanted to uninstall and reinstall an old version to confirm that it was an RC9 issue. But, when I rolled back to RC7 and tried to build an extension I got this: ruby: No such file to load -- ubygems (LoadError) It turns out that the RUBYOPT environment variable was causing that. Deleting it solved that problem. So, may I suggest that the uninstall program remove the RUBYOPT environment variable as well? The second issue is with a particular function call within a C extension. When I tried to build an extension with the rb_class_new_instance() function, I would always get this error: test.rb:12:in `initialize': Invalid argument (Errno::EINVAL) However, when I rolled back to RC7 it worked fine again. My *guess* is that it's an issue caused by the fact that I'm using VC 6 instead of the newer compiler. But, I wanted to verify that with you all. If you need some sample code, just check out the latest CVS code for win32-file in the Win32Utils project, create a simple text file and try to run this test script: require "win32/file" fh = File.nopen("test.txt") fh.close Regards, Dan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From curt at hibbs.com Sun Nov 14 23:50:57 2004 From: curt at hibbs.com (Curt Hibbs) Date: Sun Nov 14 23:50:38 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <20041115041529.18861.qmail@web50303.mail.yahoo.com> Message-ID: Daniel Berger wrote: > > Hi all, > > Windows 2000 > VC++ 6 > > I recently hit a couple of issues with RC9. First, I > wanted to uninstall and reinstall an old version to > confirm that it was an RC9 issue. But, when I rolled > back to RC7 and tried to build an extension I got > this: > > ruby: No such file to load -- ubygems (LoadError) > > It turns out that the RUBYOPT environment variable was > causing that. Deleting it solved that problem. So, > may I suggest that the uninstall program remove the > RUBYOPT environment variable as well? Oops, that's my fault. You are correct, I'm not removing the RUBYOPT env var on uninstall. > The second issue is with a particular function call > within a C extension. When I tried to build an > extension with the rb_class_new_instance() function, I > would always get this error: > > test.rb:12:in `initialize': Invalid argument > (Errno::EINVAL) > > However, when I rolled back to RC7 it worked fine > again. My *guess* is that it's an issue caused by the > fact that I'm using VC 6 instead of the newer > compiler. But, I wanted to verify that with you all. > > If you need some sample code, just check out the > latest CVS code for win32-file in the Win32Utils > project, create a simple text file and try to run this > test script: > > require "win32/file" > fh = File.nopen("test.txt") > fh.close I don't know if this is a vc6 vs. vc7 issue, but I'll try building your lib and running this test (I may not get to it for a few days I've got a very heavy work schedule at the beginning of this week). Thanks for the reports! Curt From sdate at everestkc.net Mon Nov 15 00:15:52 2004 From: sdate at everestkc.net (Shashank Date) Date: Mon Nov 15 00:15:55 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <20041115041529.18861.qmail@web50303.mail.yahoo.com> References: <20041115041529.18861.qmail@web50303.mail.yahoo.com> Message-ID: <41983B88.40708@everestkc.net> Shashank Date wrote: > Daniel Berger wrote: > >> However, when I rolled back to RC7 it worked fine >> again. My *guess* is that it's an issue caused by the >> fact that I'm using VC 6 instead of the newer >> compiler. But, I wanted to verify that with you all. >> >> > When I tried with VC++ 6 (SP5) I got some other error ("incompatile > binary file format" > or some such). > >> If you need some sample code, just check out the >> latest CVS code for win32-file in the Win32Utils >> project, create a simple text file and try to run this >> test script: >> >> require "win32/file" >> fh = File.nopen("test.txt") >> fh.close >> >> Regards, >> >> Dan >> >> > I had no problem with it (transcript below) after compiling using > VC++ Toolkit 2003. > I am on Win XP Home, using the latest one-click installer (and latest > win32-file from CVS): > > ------------------ > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\win32utils\win32-file>setvc7.cmd > > C:\win32utils\win32-file>set > PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program > Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ > Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program > Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; > > C:\win32utils\win32-file>ruby extconf.rb > checking for GetLongPathName()... yes > creating Makefile > > C:\win32utils\win32-file>nmake clean > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > C:\win32utils\win32-file>nmake > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl -nologo -MD -Zi -O2b2xg- -G5 -I. > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_GETLONGPATHNAME -I. > -I./.. -I./../missing -c -Tcfile.c > file.c > cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link > -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" > -def:file-i386-mswin32.def > Creating library file.lib and object file.exp > > C:\win32utils\win32-file>nmake install > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > install -c -p -m 0755 file.so > c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 > > C:\win32utils\win32-file>type tst_file.rb > require "win32/file" > fh = File.nopen("test.txt") > p fh > fh.close > C:\win32utils\win32-file> > C:\win32utils\win32-file>copy con test.txt > this is a test > ^Z > 1 file(s) copied. > > C:\win32utils\win32-file>ruby tst_file.rb > > C:\win32utils\win32-file>ruby tst_file.rb > # > > C:\win32utils\win32-file> > ----------------------------------------------------------- > > From sdate at everestkc.net Mon Nov 15 00:19:07 2004 From: sdate at everestkc.net (Shashank Date) Date: Mon Nov 15 00:18:59 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <20041115041529.18861.qmail@web50303.mail.yahoo.com> References: <20041115041529.18861.qmail@web50303.mail.yahoo.com> Message-ID: <41983C4B.4020305@everestkc.net> Daniel Berger wrote: >However, when I rolled back to RC7 it worked fine >again. My *guess* is that it's an issue caused by the >fact that I'm using VC 6 instead of the newer >compiler. But, I wanted to verify that with you all. > > When I tried with VC++ 6 (SP5) I got some other error ("incompatile binary file format" or some such). >If you need some sample code, just check out the >latest CVS code for win32-file in the Win32Utils >project, create a simple text file and try to run this >test script: > >require "win32/file" >fh = File.nopen("test.txt") >fh.close > >Regards, > >Dan > > I had no problem with it (transcript below) after compiling using VC++ Toolkit 2003. I am on Win XP Home, using the latest one-click installer (and latest win32-file from CVS): ------------------ Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\win32utils\win32-file>setvc7.cmd C:\win32utils\win32-file>set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; C:\win32utils\win32-file>ruby extconf.rb checking for GetLongPathName()... yes creating Makefile C:\win32utils\win32-file>nmake clean Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. C:\win32utils\win32-file>nmake Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. cl -nologo -MD -Zi -O2b2xg- -G5 -I. -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_GETLONGPATHNAME -I. -I./.. -I./../missing -c -Tcfile.c file.c cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" -def:file-i386-mswin32.def Creating library file.lib and object file.exp C:\win32utils\win32-file>nmake install Microsoft (R) Program Maintenance Utility Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. install -c -p -m 0755 file.so c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 C:\win32utils\win32-file>type tst_file.rb require "win32/file" fh = File.nopen("test.txt") p fh fh.close C:\win32utils\win32-file> C:\win32utils\win32-file>copy con test.txt this is a test ^Z 1 file(s) copied. C:\win32utils\win32-file>ruby tst_file.rb C:\win32utils\win32-file>ruby tst_file.rb # C:\win32utils\win32-file> ----------------------------------------------------------- From curt at hibbs.com Mon Nov 15 00:29:43 2004 From: curt at hibbs.com (Curt Hibbs) Date: Mon Nov 15 00:29:28 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <41983C4B.4020305@everestkc.net> Message-ID: Thanks Shahsank for checking this out. I guess it is a vc6 vs vc7 problem. Curt > -----Original Message----- > From: rubyinstaller-users-bounces@rubyforge.org > [mailto:rubyinstaller-users-bounces@rubyforge.org]On Behalf Of Shashank > Date > Sent: Sunday, November 14, 2004 11:19 PM > To: Daniel Berger; rubyinstaller-users@rubyforge.org > Subject: Re: [Rubyinstaller-users] A couple of issues with RC9 > > > Daniel Berger wrote: > > >However, when I rolled back to RC7 it worked fine > >again. My *guess* is that it's an issue caused by the > >fact that I'm using VC 6 instead of the newer > >compiler. But, I wanted to verify that with you all. > > > > > When I tried with VC++ 6 (SP5) I got some other error ("incompatile > binary file format" > or some such). > > >If you need some sample code, just check out the > >latest CVS code for win32-file in the Win32Utils > >project, create a simple text file and try to run this > >test script: > > > >require "win32/file" > >fh = File.nopen("test.txt") > >fh.close > > > >Regards, > > > >Dan > > > > > I had no problem with it (transcript below) after compiling using VC++ > Toolkit 2003. > I am on Win XP Home, using the latest one-click installer (and latest > win32-file from CVS): > > ------------------ > Microsoft Windows XP [Version 5.1.2600] > (C) Copyright 1985-2001 Microsoft Corp. > > C:\win32utils\win32-file>setvc7.cmd > > C:\win32utils\win32-file>set > PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WI > NDOWS\Microsoft.NET\Framework\v1.1.4322;C:\Program > > > Files\Microsoft.NET\SDK\v1.1\Bin;C:\Program Files\Microsoft Visual C++ > Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin\Win64;C:\Program > Files\Microsoft SDK\Bin;C:\bison\bin;c:\ruby\bin; > > C:\win32utils\win32-file>ruby extconf.rb > checking for GetLongPathName()... yes > creating Makefile > > C:\win32utils\win32-file>nmake clean > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > C:\win32utils\win32-file>nmake > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > cl -nologo -MD -Zi -O2b2xg- -G5 -I. > -Ic:/ruby/lib/ruby/1.8/i386-mswin32 -Ic:/ruby/lib/ruby/1.8/i386-mswin32 > -I. -DHAVE_GETLONGPATHNAME -I. -I./.. -I./../missing -c -Tcfile.c > file.c > cl -nologo -LD -Fefile.so file.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no > -debug -opt:ref -opt:icf -dll -libpath:"c:/ruby/lib" > -def:file-i386-mswin32.def > Creating library file.lib and object file.exp > > C:\win32utils\win32-file>nmake install > > Microsoft (R) Program Maintenance Utility Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > install -c -p -m 0755 file.so > c:/ruby/lib/ruby/site_ruby/1.8/i386-msvcrt/win32 > > C:\win32utils\win32-file>type tst_file.rb > require "win32/file" > fh = File.nopen("test.txt") > p fh > fh.close > C:\win32utils\win32-file> > C:\win32utils\win32-file>copy con test.txt > this is a test > ^Z > 1 file(s) copied. > > C:\win32utils\win32-file>ruby tst_file.rb > > C:\win32utils\win32-file>ruby tst_file.rb > # > > C:\win32utils\win32-file> > ----------------------------------------------------------- > > > > > _______________________________________________ > Rubyinstaller-users mailing list > Rubyinstaller-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-users > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.788 / Virus Database: 533 - Release Date: 11/1/2004 > From austin at halostatue.ca Mon Nov 15 08:17:13 2004 From: austin at halostatue.ca (Austin Ziegler) Date: Mon Nov 15 08:17:00 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: References: Message-ID: <4198AC59.7080504@halostatue.ca> Curt Hibbs wrote: >Daniel Berger wrote: > > >>But, when I rolled >>back to RC7 and tried to build an extension I got >>this: >> >>ruby: No such file to load -- ubygems (LoadError) >> >>It turns out that the RUBYOPT environment variable was >>causing that. Deleting it solved that problem. So, >>may I suggest that the uninstall program remove the >>RUBYOPT environment variable as well? >> >> >Oops, that's my fault. You are correct, I'm not removing the RUBYOPT env var on uninstall. > > I have an issue with the setting of RUBYOPT in any case. Unless and until RubyGems is provided by default in Ruby as a whole, this environment variable should not be set on most installs, and the Windows Installer shouldn't require it in any way whatsoever. (This particularly matters for me as I do NOT want to have RubyGems loaded automatically *ever* with the development that I do.) I don't mind the inclusion of RubyGems by default, but the enabling of RubyGems in the environment is not a good thing, IMO, because it silently modifies the way that $LOAD_PATH works. Either make this an option (checked by default, for users that don't care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. When installing, make sure you don't overwrite an existing RUBYOPT, but append to it. -austin From curt at hibbs.com Mon Nov 15 08:58:11 2004 From: curt at hibbs.com (Curt Hibbs) Date: Mon Nov 15 08:57:59 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <4198AC59.7080504@halostatue.ca> Message-ID: Austin Ziegler wrote: > > Curt Hibbs wrote: > > >Daniel Berger wrote: > > > > > >>But, when I rolled > >>back to RC7 and tried to build an extension I got > >>this: > >> > >>ruby: No such file to load -- ubygems (LoadError) > >> > >>It turns out that the RUBYOPT environment variable was > >>causing that. Deleting it solved that problem. So, > >>may I suggest that the uninstall program remove the > >>RUBYOPT environment variable as well? > >> > >> > >Oops, that's my fault. You are correct, I'm not removing the > RUBYOPT env var on uninstall. > > > > > I have an issue with the setting of RUBYOPT in any case. Unless and > until RubyGems is provided by default in Ruby as a whole, this > environment variable should not be set on most installs, and the Windows > Installer shouldn't require it in any way whatsoever. (This particularly > matters for me as I do NOT want to have RubyGems loaded automatically > *ever* with the development that I do.) > > I don't mind the inclusion of RubyGems by default, but the enabling of > RubyGems in the environment is not a good thing, IMO, because it > silently modifies the way that $LOAD_PATH works. > > Either make this an option (checked by default, for users that don't > care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. > When installing, make sure you don't overwrite an existing RUBYOPT, but > append to it. It should only get set if RubyGems is selected to install (which it is, by default). But having said that I wasn't thinking along these lines and did not explicitly check that out. I will veryfy and/or fix as appropriate. Thanks, Curt From curt at hibbs.com Wed Nov 17 06:22:52 2004 From: curt at hibbs.com (Curt Hibbs) Date: Wed Nov 17 06:22:32 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: <4198AC59.7080504@halostatue.ca> Message-ID: Austin Ziegler wrote: > > Curt Hibbs wrote: > > >Daniel Berger wrote: > > > > > >>But, when I rolled > >>back to RC7 and tried to build an extension I got > >>this: > >> > >>ruby: No such file to load -- ubygems (LoadError) > >> > >>It turns out that the RUBYOPT environment variable was > >>causing that. Deleting it solved that problem. So, > >>may I suggest that the uninstall program remove the > >>RUBYOPT environment variable as well? > >> > >> > >Oops, that's my fault. You are correct, I'm not removing the > RUBYOPT env var on uninstall. > > > > > I have an issue with the setting of RUBYOPT in any case. Unless and > until RubyGems is provided by default in Ruby as a whole, this > environment variable should not be set on most installs, and the Windows > Installer shouldn't require it in any way whatsoever. (This particularly > matters for me as I do NOT want to have RubyGems loaded automatically > *ever* with the development that I do.) > > I don't mind the inclusion of RubyGems by default, but the enabling of > RubyGems in the environment is not a good thing, IMO, because it > silently modifies the way that $LOAD_PATH works. > > Either make this an option (checked by default, for users that don't > care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. > When installing, make sure you don't overwrite an existing RUBYOPT, but > append to it. If RubyGems is installed, then he environment should be enabled. If you don't want this it would be better to uncheck the rubygems option (and possiby install rubygems yourself later, if that's what you want). Also, thanks for pointing out the issue of appending to RUBYOPT, not just setting it. RC9 is just setting it, so I need to fix that. Curt From austin at halostatue.ca Wed Nov 17 07:51:46 2004 From: austin at halostatue.ca (Austin Ziegler) Date: Wed Nov 17 07:51:27 2004 Subject: [Rubyinstaller-users] A couple of issues with RC9 In-Reply-To: References: Message-ID: <419B4962.1000104@halostatue.ca> Curt Hibbs wrote: >Austin Ziegler wrote: > > >>Curt Hibbs wrote: >> >> >>>Daniel Berger wrote: >>> >>> >>>>But, when I rolled >>>>back to RC7 and tried to build an extension I got >>>>this: >>>> >>>>ruby: No such file to load -- ubygems (LoadError) >>>> >>>>It turns out that the RUBYOPT environment variable was >>>>causing that. Deleting it solved that problem. So, >>>>may I suggest that the uninstall program remove the >>>>RUBYOPT environment variable as well? >>>> >>>> >>>Oops, that's my fault. You are correct, I'm not removing the RUBYOPT env var on uninstall. >>> >>> >>I have an issue with the setting of RUBYOPT in any case. Unless and >>until RubyGems is provided by default in Ruby as a whole, this >>environment variable should not be set on most installs, and the Windows >>Installer shouldn't require it in any way whatsoever. (This particularly >>matters for me as I do NOT want to have RubyGems loaded automatically >>*ever* with the development that I do.) >> >>I don't mind the inclusion of RubyGems by default, but the enabling of >>RubyGems in the environment is not a good thing, IMO, because it >>silently modifies the way that $LOAD_PATH works. >> >>Either make this an option (checked by default, for users that don't >>care) or provide a couple of scripts to quickly add ubygems to RUBYOPT. >>When installing, make sure you don't overwrite an existing RUBYOPT, but >>append to it. >> >> >If RubyGems is installed, then he environment should be enabled. If you >don't want this it would be better to uncheck the rubygems option (and >possiby install rubygems yourself later, if that's what you want). > >Also, thanks for pointing out the issue of appending to RUBYOPT, not just >setting it. RC9 is just setting it, so I need to fix that. > > > I don't agree. This should be a separate option (at best), as RubyGems does not require this option to work. It is recommended, but any application or option provided by the Win32 installer that depends on a library that we are including by RubyGems should be modified before packaging to Do The Right Thing. The same basically applies to RPA if and when we include rpa-base (which, frankly, we should). One of the concerns that I have is precedence. Which has precedence when -rubygems is specified? A library in the system library, the site library, or the Ruby Gem? If it's the latter, then there is a definite downside to -rubygems. Let me have RubyGems and/or rpa-base installed by default, but don't change my environment more than you have to. Right now, that should probably extend to PATH and PATH only, because that's the only change that Ruby (including RubyGems) REQUIRES be done to work properly. Offer to add or change RUBYOPT for users, but don't make it manditory. -austin From austin at halostatue.ca Fri Nov 19 08:19:17 2004 From: austin at halostatue.ca (Austin Ziegler) Date: Fri Nov 19 08:18:55 2004 Subject: [Rubyinstaller-users] Re: I need your opinion on setting RUBYOPT In-Reply-To: References: Message-ID: <419DF2D5.8020409@halostatue.ca> Curt Hibbs wrote: >Chad Fowler wrote: > > >>I'm pro-RUBYOPT but wouldn't mind an option to enable/disable it during >>install (on by default--I think that most users who don't know they >>_don't_ want it will have a better experience if it's set by default). >> >> > >Ok, I'm going to make setting RUBYOPT a checkable option in the installer >that will be checked (enabled) by default. > I'm fine with that. I would make sure the description is clear and not obtuse, something like: "Enable searching of RubyGems for all programs" -austin From emmanuel.touzery at wanadoo.fr Fri Nov 19 08:26:21 2004 From: emmanuel.touzery at wanadoo.fr (Emmanuel Touzery) Date: Fri Nov 19 09:11:03 2004 Subject: [Rubyinstaller-users] incompatibility of installer with ruby-gtk2 In-Reply-To: References: Message-ID: <419DF47D.30700@wanadoo.fr> Hello, Curt Hibbs wrote: >Emmanuel Touzery wrote: > > >>Hello, >> >>Curt Hibbs wrote: >> >> >> >>>First of all, thank you for your very detailed post. >>> >>>Since the one-click installer is built with msvc 7.1 (aka, >>> >>> >>Visual Studio.NET 2003), I think it would be very informative if >>it were possible to compile ruby-gtk2 with msvc instead of mingw >>to see if the problem goes away, or persists. >> >> Just to let you know: the maintainer of ruby-gtk2 managed to compile it (experimentally for now) with the visual studio compiler, with improved stability apparently, so you can forget about this bug report. Thank you, emmanuel From holmberg at iar.se Fri Nov 19 10:02:33 2004 From: holmberg at iar.se (Johan Holmberg) Date: Fri Nov 19 10:02:13 2004 Subject: [Rubyinstaller-users] I need your opinion on setting RUBYOPT In-Reply-To: <419DF2D5.8020409@halostatue.ca> References: <419DF2D5.8020409@halostatue.ca> Message-ID: Hi ! I just read the thread discussing Rubygems and RUBYOPT. I haven't used Rubygems, but I have some general comments. My instinctive reaction is that it is a bad thing to use RUBYOPT for this purpose. My experience is that a "misuse" of a mechanism that "happens to exist" (like RUBYOPT) often turns out to have undesirable consequences. Until Rubygems becomes an integrated part of Ruby, I think it is better to have the user make some explicit step to enable it. Or if you really want the Rubyinstaller version of Ruby to have Rubygems "integrated", I think you should use some other mechanism than RUBYOPT. For example by modifying the Ruby source so it becomes Rubygems-aware. Maybe via a newly invented environment variable if it should be optional (e.g. RUBYGEMS_ENABLED). I see you have already discussed the issue of setting vs. appending to RUBYOPT. Another issue is the following: RUBYOPT is only read on $SAFE level 0. As far as I understand, this implies that a script would silently work different if $SAFE >= 1. This seems like a bad thing. /Johan Holmberg