' $ So it's a Ruby 1.8 -> 1.9 regression? -- Jos Backus jos at catnook.com From Daniel.Berger at qwest.com Fri Aug 17 15:30:21 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 17 Aug 2007 14:30:21 -0500 Subject: [Rubygems-developers] [patch] lib/rubygems/format.rbnot compatiblewith Ruby 1.9 HEAD In-Reply-To: <20070817192045.GB20914@lizzy.catnook.local> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72D7F@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Jos Backus > Sent: Friday, August 17, 2007 1:21 PM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] [patch] > lib/rubygems/format.rbnot compatiblewith Ruby 1.9 HEAD > > > On Fri, Aug 17, 2007 at 02:10:39PM -0500, Berger, Daniel wrote: > > What difference does that make? The arrow notation is optional. > > Using Ruby 1.9 HEAD as of today: Ooof. Please say it isn't so. 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 jos at catnook.com Fri Aug 17 16:03:33 2007 From: jos at catnook.com (Jos Backus) Date: Fri, 17 Aug 2007 13:03:33 -0700 Subject: [Rubygems-developers] [patch] lib/rubygems/format.rbnot compatiblewith Ruby 1.9 HEAD In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72D7F@ITOMAE2KM01.AD.QINTRA.COM> References: <20070817192045.GB20914@lizzy.catnook.local> <7524A45A1A5B264FA4809E2156496CFBE72D7F@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <20070817200333.GC20914@lizzy.catnook.local> On Fri, Aug 17, 2007 at 02:30:21PM -0500, Berger, Daniel wrote: > Ooof. Please say it isn't so. Hey, I'm just the messenger. :-) -- Jos Backus jos at catnook.com From drbrain at segment7.net Sat Aug 18 16:32:04 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 18 Aug 2007 13:32:04 -0700 Subject: [Rubygems-developers] [patch] lib/rubygems/format.rb not compatible with Ruby 1.9 HEAD In-Reply-To: <20070817185801.GA20914@lizzy.catnook.local> References: <20070817185801.GA20914@lizzy.catnook.local> Message-ID: On Aug 17, 2007, at 11:58, Jos Backus wrote: > Fix: Patches placed here are 99% certain to get forgotten. Please post a ticket in the tracker. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From jos at catnook.com Sat Aug 18 16:42:45 2007 From: jos at catnook.com (Jos Backus) Date: Sat, 18 Aug 2007 13:42:45 -0700 Subject: [Rubygems-developers] [patch] lib/rubygems/format.rb not compatible with Ruby 1.9 HEAD In-Reply-To: References: <20070817185801.GA20914@lizzy.catnook.local> Message-ID: <20070818204245.GC24744@lizzy.catnook.local> On Sat, Aug 18, 2007 at 01:32:04PM -0700, Eric Hodel wrote: > Patches placed here are 99% certain to get forgotten. Please post a ticket > in the tracker. Done, ticket 13187. -- Jos Backus jos at catnook.com From farhan at thebitguru.com Sat Aug 18 17:28:28 2007 From: farhan at thebitguru.com (Farhan Ahmad) Date: Sat, 18 Aug 2007 16:28:28 -0500 Subject: [Rubygems-developers] Slow gem Update Message-ID: <46C7647C.9070202@thebitguru.com> Hi, I have been looking into why 'gem update' has been taking hours and hours on my computer to complete. Given that it's only a 700Mhz machine with 512MB RAM I still didn't think that would qualify it for such slow updates. Also, a normal system update, i.e. ArchLinux's pacman updates, takes only a minute to download and parse. So, I started playing around with the source and boiled everything down to the YAML.load call in source_index.rb. Later I found out that this was already being discussed in a few posts [0][1] on this mailing list. Ryan D., thanks a lot for removing the reduce_specs call [1] because that helped with the performance. Unfortunately, the problem is still there. I have looked through the mailing list archive and seen some other threads but can't figure out where this issue currently stands. Is there already a plan for rectifying this? Thanks! Farhan [0] http://rubyforge.org/pipermail/rubygems-developers/2007-May/002801.html [1] http://rubyforge.org/pipermail/rubygems-developers/2007-May/002807.html From drbrain at segment7.net Sun Aug 19 02:21:32 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 18 Aug 2007 23:21:32 -0700 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: <46C7647C.9070202@thebitguru.com> References: <46C7647C.9070202@thebitguru.com> Message-ID: <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> On Aug 18, 2007, at 14:28, Farhan Ahmad wrote: > I have been looking into why 'gem update' has been taking hours > and > hours on my computer to complete. Given that it's only a 700Mhz > machine > with 512MB RAM I still didn't think that would qualify it for such > slow > updates. Also, a normal system update, i.e. ArchLinux's pacman > updates, > takes only a minute to download and parse. So, I started playing > around > with the source and boiled everything down to the YAML.load call in > source_index.rb. Later I found out that this was already being > discussed in a few posts [0][1] on this mailing list. Ryan D., > thanks a > lot for removing the reduce_specs call [1] because that helped with > the > performance. Unfortunately, the problem is still there. > > I have looked through the mailing list archive and seen some other > threads but can't figure out where this issue currently stands. Is > there already a plan for rectifying this? How much RAM is it using? I see about 120MB max with a bulk update on OS X. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sun Aug 19 02:49:13 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 18 Aug 2007 23:49:13 -0700 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> References: <46C7647C.9070202@thebitguru.com> <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> Message-ID: On Aug 18, 2007, at 23:21, Eric Hodel wrote: > On Aug 18, 2007, at 14:28, Farhan Ahmad wrote: >> I have been looking into why 'gem update' has been taking hours >> and hours on my computer to complete. Given that it's only a 700Mhz >> machine with 512MB RAM I still didn't think that would qualify it >> for such >> slow updates. > > How much RAM is it using? I see about 120MB max with a bulk update > on OS X. Second data point, ~20 minutes and ~70MB resident on a machine that should be at least an order of magnitude, possibly two, slower than yours. CPU: Geode(TM) Integrated Processor by National Semi (266.66-MHz 586- class CPU) Origin = "Geode by NSC" Id = 0x540 Stepping = 0 Features=0x808131 real memory = 134217728 (128 MB) avail memory = 126078976 (120 MB) $ /usr/bin/time -l gem list -r *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org [...] 1223.66 real 508.13 user 62.21 sys 71700 maximum resident set size 3 average shared memory size 34417 average unshared data size 127 average unshared stack size 158228 page reclaims 51651 page faults 0 swaps 13 block input operations 40 block output operations 9 messages sent 1291 messages received 52739 signals received 51681 voluntary context switches 142100 involuntary context switches -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From djberg96 at gmail.com Sun Aug 19 07:53:05 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 19 Aug 2007 05:53:05 -0600 Subject: [Rubygems-developers] Platform selection in gem install In-Reply-To: <262F3FAC-92DB-4418-BE0B-0FD5D2043F03@segment7.net> References: <3945c4270706250943n1a2598c3y55fe0acd9b82e870@mail.gmail.com> <9e7db9110708141422j617b70d4qf717ab59f92609f9@mail.gmail.com> <3945c4270708141515j4ddcc6c8l9d05029ede696e20@mail.gmail.com> <46C231C3.6030900@gmail.com> <3945c4270708150827q3d38c3v3cbce0097198dff@mail.gmail.com> <9e7db9110708160530r6d73c225vc124c973c6a94030@mail.gmail.com> <7DED7621-3825-4D8A-8283-B91C0421BEE9@segment7.net> <9e7db9110708161243he324e94h8423ac0c3e0dfaf5@mail.gmail.com> <262F3FAC-92DB-4418-BE0B-0FD5D2043F03@segment7.net> Message-ID: <6037b70c0708190453v231628b4u1bd0358e911a07dc@mail.gmail.com> On 8/16/07, Eric Hodel wrote: > On Aug 16, 2007, at 12:43, Austin Ziegler wrote: > > On 8/16/07, Eric Hodel wrote: > >> So File.join Dir::COMMON_APPDATA, 'RubyGems', 'mumble' > >> > >> Would be the right place to put RubyGems system-wide configuration? > > > > I think so. So as to not depend on anything external, I'd recommend > > using the Win32API approach that Dan pointed out upthread. > > I think Win32API is going away in 2.0, so I'll need to use dl instead :/ Would that be dl1 or dl2? Good luck! :) Regards, Dan From farhan at thebitguru.com Sun Aug 19 09:45:49 2007 From: farhan at thebitguru.com (Farhan Ahmad) Date: Sun, 19 Aug 2007 08:45:49 -0500 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: References: <46C7647C.9070202@thebitguru.com> <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> Message-ID: <46C8498D.6090907@thebitguru.com> Sorry, I should have started off with a time output. Thanks for pointing this out Eric. Here are my time output. A basic gem list. $ /usr/bin/time -v gem list -r [...] A simulation/game with autonomous creatures Command being timed: "gem list -r" User time (seconds): 34.23 System time (seconds): 2.52 Percent of CPU this job got: 28% Elapsed (wall clock) time (h:mm:ss or m:ss): 2:10.74 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 507 Minor (reclaiming a frame) page faults: 19980 Voluntary context switches: 8424 Involuntary context switches: 19218 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 ...and here is the output with an actual update. Note how this took almost 41 minutes. # /usr/bin/time -v gem update Updating installed gems... Bulk updating Gem source index for: http://gems.rubyforge.org Gems: [] updated Command being timed: "gem update" User time (seconds): 56.06 System time (seconds): 19.18 Percent of CPU this job got: 3% Elapsed (wall clock) time (h:mm:ss or m:ss): 40:51.63 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 147876 Minor (reclaiming a frame) page faults: 303281 Voluntary context switches: 307667 Involuntary context switches: 19396 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 # ...and here are the specs on this machine. # hwd -s HARDWARE DETECT ver 4.8.2 (simple mode) Kernel : 2.6.20-ARCH CPU & Cache: Processor 0 is Pentium III (Katmai) 515MHz, 512 KB Cache [...] # Apparently, it seems that the system only has 128MB RAM instead of the original 512MB that I was thinking. # free -om total used free shared buffers cached Mem: 123 120 2 0 20 72 Swap: 956 84 872 # cat /proc/meminfo MemTotal: 126072 kB MemFree: 2176 kB Buffers: 20616 kB Cached: 74416 kB SwapCached: 7984 kB Active: 85792 kB Inactive: 17432 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 126072 kB LowFree: 2176 kB SwapTotal: 979924 kB SwapFree: 893748 kB Dirty: 2748 kB Writeback: 0 kB AnonPages: 8096 kB Mapped: 64828 kB Slab: 12572 kB SReclaimable: 3912 kB SUnreclaim: 8660 kB PageTables: 1160 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 1042960 kB Committed_AS: 281076 kB VmallocTotal: 901112 kB VmallocUsed: 6284 kB VmallocChunk: 894544 kB Thanks, Farhan Eric Hodel wrote: > On Aug 18, 2007, at 23:21, Eric Hodel wrote: > >> On Aug 18, 2007, at 14:28, Farhan Ahmad wrote: >> >>> I have been looking into why 'gem update' has been taking hours >>> and hours on my computer to complete. Given that it's only a 700Mhz >>> machine with 512MB RAM I still didn't think that would qualify it >>> for such >>> slow updates. >>> >> How much RAM is it using? I see about 120MB max with a bulk update >> on OS X. >> > > Second data point, ~20 minutes and ~70MB resident on a machine that > should be at least an order of magnitude, possibly two, slower than > yours. > > CPU: Geode(TM) Integrated Processor by National Semi (266.66-MHz 586- > class CPU) > Origin = "Geode by NSC" Id = 0x540 Stepping = 0 > Features=0x808131 > real memory = 134217728 (128 MB) > avail memory = 126078976 (120 MB) > > $ /usr/bin/time -l gem list -r > > *** REMOTE GEMS *** > Bulk updating Gem source index for: http://gems.rubyforge.org > > [...] > 1223.66 real 508.13 user 62.21 sys > 71700 maximum resident set size > 3 average shared memory size > 34417 average unshared data size > 127 average unshared stack size > 158228 page reclaims > 51651 page faults > 0 swaps > 13 block input operations > 40 block output operations > 9 messages sent > 1291 messages received > 52739 signals received > 51681 voluntary context switches > 142100 involuntary context switches > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From drbrain at segment7.net Sun Aug 19 14:46:33 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 19 Aug 2007 11:46:33 -0700 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: <46C8498D.6090907@thebitguru.com> References: <46C7647C.9070202@thebitguru.com> <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> <46C8498D.6090907@thebitguru.com> Message-ID: On Aug 19, 2007, at 06:45, Farhan Ahmad wrote: > Eric Hodel wrote: >> On Aug 18, 2007, at 23:21, Eric Hodel wrote: >> >>> On Aug 18, 2007, at 14:28, Farhan Ahmad wrote: >>> >>>> I have been looking into why 'gem update' has been taking hours >>>> and hours on my computer to complete. Given that it's only a >>>> 700Mhz >>>> machine with 512MB RAM I still didn't think that would qualify it >>>> for such >>>> slow updates. >>>> >>> How much RAM is it using? I see about 120MB max with a bulk update >>> on OS X. >>> >> >> Second data point, ~20 minutes and ~70MB resident on a machine that >> should be at least an order of magnitude, possibly two, slower than >> yours. > > Apparently, it seems that the system only has 128MB RAM instead of the > original 512MB that I was thinking. Try increasing the bulk theshold to something like 10000. `gem list - r -B 10000`. I'm working with Tom to get the new, fixed gem indexer installed so the quick index is always available. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sun Aug 19 18:11:06 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 19 Aug 2007 15:11:06 -0700 Subject: [Rubygems-developers] Recognizing Platforms Message-ID: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> Here's my proposal for how we recognize platforms. From Config::CONFIG, take the target_os and run it through a case statement to figure out OS and OS version (if any). Combine the target_cpu, OS and OS version. This value is your platform. There will be a rubygems-platforms.gem much like sources.gem that can be updated as-necessary. Using the tattle data, I came up with this implementation: def match(cpu, os) os = case os when /cygwin/ then [ 'cygwin', nil ] when /darwin(\d+)?/ then [ 'darwin', $1 ] when /freebsd(\d+)/ then [ 'freebsd', $1 ] when /^java([\d.]*)/ then [ 'java', $1 ] when /linux/ then [ 'linux', $1 ] when /mingw32/ then [ 'mingw32', nil ] when /mswin32/ then [ 'mswin32', nil ] when /openbsd(\d+)/ then [ 'openbsd', $1 ] when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] else [ 'unknown', nil ] end [cpu, os].flatten.compact.join("-") end require 'rbconfig' target_cpu = Config::CONFIG['target_cpu'] target_os = Config::CONFIG['target_os'] puts "Your target_cpu is: #{target_cpu.inspect}" puts "Your target_os is: #{target_os.inspect}" puts "Your platform is: #{match(target_cpu, target_os).inspect}" This code recognizes 26 unique platforms: amd64-freebsd-6 java java-1.4 powerpc-darwin-7 powerpc-darwin-8 powerpc-darwin-9 powerpc-linux powerpc64-linux sparc-solaris-2.10 sparc-solaris-2.8 sparc-solaris-2.9 x86-cygwin x86-darwin x86-darwin-8 x86-freebsd-4 x86-freebsd-5 x86-freebsd-6 x86-linux x86-mingw32 x86-mswin32 x86-openbsd-4 x86-solaris-2.10 x86-solaris-2.8 x86_64-linux x86_64-openbsd-3 x86_64-openbsd-4 Don't worry about legacy platforms, that's an entirely separate problem. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From alexey.verkhovsky at gmail.com Sun Aug 19 18:36:12 2007 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Sun, 19 Aug 2007 16:36:12 -0600 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> Message-ID: <3945c4270708191536p415621e0j704bff1bc5d86e1f@mail.gmail.com> On 8/19/07, Eric Hodel wrote: > Here's my proposal for how we recognize platforms. Are you thinking about integrating with native package managers? This would be rather useful if 'gem install' could take care of installing the 100+1 native dependencies of rmagick, for example, or check that the right version of glibc is present on this linux. On the flipside, it would have to know more than "it's a linux". Maybe the right way is to provide some simple hook for a native package manager, and let various Linux flavors create an implementation. -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From jeremy at hinegardner.org Sun Aug 19 19:17:30 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sun, 19 Aug 2007 17:17:30 -0600 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> Message-ID: <20070819231730.GL13531@hinegardner.org> We need to make a change for openbsd. On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: > def match(cpu, os) > os = case os > when /cygwin/ then [ 'cygwin', nil ] > when /darwin(\d+)?/ then [ 'darwin', $1 ] > when /freebsd(\d+)/ then [ 'freebsd', $1 ] > when /^java([\d.]*)/ then [ 'java', $1 ] > when /linux/ then [ 'linux', $1 ] > when /mingw32/ then [ 'mingw32', nil ] > when /mswin32/ then [ 'mswin32', nil ] > when /openbsd(\d+)/ then [ 'openbsd', $1 ] when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] > when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] > else [ 'unknown', nil ] > end > > [cpu, os].flatten.compact.join("-") > end [...] > x86_64-openbsd-3 > x86_64-openbsd-4 openbsd increments versions by .1 every 6 mos when it cuts a release. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From drbrain at segment7.net Sun Aug 19 19:31:08 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 19 Aug 2007 16:31:08 -0700 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <3945c4270708191536p415621e0j704bff1bc5d86e1f@mail.gmail.com> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <3945c4270708191536p415621e0j704bff1bc5d86e1f@mail.gmail.com> Message-ID: <69986429-6DF3-404F-97B3-E31171FF3498@segment7.net> On Aug 19, 2007, at 15:36, Alexey Verkhovsky wrote: > On 8/19/07, Eric Hodel wrote: >> Here's my proposal for how we recognize platforms. > > Are you thinking about integrating with native package managers? Not anytime soon, no. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From thewoolleyman at gmail.com Mon Aug 20 06:16:34 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 20 Aug 2007 03:16:34 -0700 Subject: [Rubygems-developers] Any experiences managing gems without root access? In-Reply-To: References: <356913E0-1EFC-4A35-ABF2-893FBD4C234A@segment7.net> Message-ID: On 7/25/07, Ryan Davis wrote: > I don't think that is right. GEM_HOME seems to be ... sketchy. I > think you want GEM_PATH and to use the -i flag on 'gem install'... I > got it working once and have a transcript with Jim where I worked it > out. I plan on writing it up because it'll really help consultants. OK, this is stumping me. I'd like to use a non-root user, without using sudo, to be able to 1. setup/install the rubygems dist from scratch to an alternate location for which the user has write access 2. install/uninstall gems from that location 3. tell rubygems at application runtime to only use gems from that location (only stick stuff gems from there on my load path) Should that all be possible? If not, is any subset possible? Any detailed commands would be great... Thanks, Chad From jim.weirich at gmail.com Mon Aug 20 07:36:30 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 20 Aug 2007 07:36:30 -0400 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: References: <46C7647C.9070202@thebitguru.com> <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> <46C8498D.6090907@thebitguru.com> Message-ID: <3AB112F0-0F61-4D2A-9B4A-8F85FC03343C@gmail.com> On Aug 19, 2007, at 2:46 PM, Eric Hodel wrote: > I'm working with Tom to get the new, fixed gem indexer installed so > the quick index is always available. What's the issue here? -- -- Jim Weirich -- jim.weirich at gmail.com From jim.weirich at gmail.com Mon Aug 20 09:06:06 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 20 Aug 2007 09:06:06 -0400 Subject: [Rubygems-developers] Any experiences managing gems without root access? In-Reply-To: References: <356913E0-1EFC-4A35-ABF2-893FBD4C234A@segment7.net> Message-ID: On Aug 20, 2007, at 6:16 AM, Chad Woolley wrote: > On 7/25/07, Ryan Davis wrote: >> I don't think that is right. GEM_HOME seems to be ... sketchy. I >> think you want GEM_PATH and to use the -i flag on 'gem install'... I >> got it working once and have a transcript with Jim where I worked it >> out. I plan on writing it up because it'll really help consultants. > > OK, this is stumping me. I'd like to use a non-root user, without > using sudo, to be able to > > 1. setup/install the rubygems dist from scratch to an alternate > location for which the user has write access > 2. install/uninstall gems from that location > 3. tell rubygems at application runtime to only use gems from that > location (only stick stuff gems from there on my load path) > > Should that all be possible? If not, is any subset possible? Any > detailed commands would be great... I made a wonderful little screen cast, and then discovered my server is down so I have nowhere to upload it to. So, you get the low tech version: # Create a repository mkdir repository # Install the sources gem. The sources gem has to be in # at least one of your repositories. Since you want to make this # be the one an only one, there you go. # # Oh, this assumes you have a rubygems repository already installed # in the more-or-less normal place. gem install -i repository `gem env gemdir`/cache/sources-0.0.1.gem # Now make this new repository the one that RubyGems will use. export GEM_HOME=$PWD/repository # Now you can install gems into it. gem install rake # The first install always seems to fail. Sigh. Someone should fix that. # Try again: gem install rake gem install flexmock # List your local gems, should list only sources, rake and flexmock: gem list -l # Try using the gems: irb require 'rubygems' require 'rake' # should work require 'builder' # should not work exit # and there you go! -- -- Jim Weirich -- jim.weirich at gmail.com From drbrain at segment7.net Mon Aug 20 15:43:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 20 Aug 2007 12:43:23 -0700 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <20070819231730.GL13531@hinegardner.org> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> Message-ID: <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: > We need to make a change for openbsd. > > On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: >> def match(cpu, os) >> os = case os >> when /cygwin/ then [ 'cygwin', nil ] >> when /darwin(\d+)?/ then [ 'darwin', $1 ] >> when /freebsd(\d+)/ then [ 'freebsd', $1 ] >> when /^java([\d.]*)/ then [ 'java', $1 ] >> when /linux/ then [ 'linux', $1 ] >> when /mingw32/ then [ 'mingw32', nil ] >> when /mswin32/ then [ 'mswin32', nil ] >> when /openbsd(\d+)/ then [ 'openbsd', $1 ] > > when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] > >> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] >> else [ 'unknown', nil ] >> end >> >> [cpu, os].flatten.compact.join("-") >> end > > [...] > >> x86_64-openbsd-3 >> x86_64-openbsd-4 > > openbsd increments versions by .1 every 6 mos when it cuts a release. All X.Y releases are compatible with each other, correct? If I have 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it working? If they're all compatible then using only the major number is the way to go. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Mon Aug 20 15:46:07 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 20 Aug 2007 12:46:07 -0700 Subject: [Rubygems-developers] Slow gem Update In-Reply-To: <3AB112F0-0F61-4D2A-9B4A-8F85FC03343C@gmail.com> References: <46C7647C.9070202@thebitguru.com> <71559EE9-7C85-45B8-8DCF-25B0E52C058E@segment7.net> <46C8498D.6090907@thebitguru.com> <3AB112F0-0F61-4D2A-9B4A-8F85FC03343C@gmail.com> Message-ID: <6D3FACA3-6167-4C28-9A85-3184987F6587@segment7.net> On Aug 20, 2007, at 04:36, Jim Weirich wrote: > On Aug 19, 2007, at 2:46 PM, Eric Hodel wrote: > >> I'm working with Tom to get the new, fixed gem indexer installed so >> the quick index is always available. > > What's the issue here? The index updater deletes /quick when it starts and writes it back it is done. Building the entire index can take several minutes. Now the indexer builds everything in /tmp/ and moves it into place when done. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Mon Aug 20 15:48:16 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 20 Aug 2007 12:48:16 -0700 Subject: [Rubygems-developers] Any experiences managing gems without root access? In-Reply-To: References: <356913E0-1EFC-4A35-ABF2-893FBD4C234A@segment7.net>

Message-ID: <4E185DB1-FE68-4B18-8B27-3952966AFD4A@segment7.net> On Aug 20, 2007, at 06:06, Jim Weirich wrote: > On Aug 20, 2007, at 6:16 AM, Chad Woolley wrote: >> On 7/25/07, Ryan Davis wrote: >>> I don't think that is right. GEM_HOME seems to be ... sketchy. I >>> think you want GEM_PATH and to use the -i flag on 'gem install'... I >>> got it working once and have a transcript with Jim where I worked it >>> out. I plan on writing it up because it'll really help consultants. >> >> OK, this is stumping me. I'd like to use a non-root user, without >> using sudo, to be able to >> >> 1. setup/install the rubygems dist from scratch to an alternate >> location for which the user has write access >> 2. install/uninstall gems from that location >> 3. tell rubygems at application runtime to only use gems from that >> location (only stick stuff gems from there on my load path) >> >> Should that all be possible? If not, is any subset possible? Any >> detailed commands would be great... > > I made a wonderful little screen cast, and then discovered my server > is down so I have nowhere to upload it to. > > So, you get the low tech version: > > # Create a repository > mkdir repository > > # Install the sources gem. The sources gem has to be in > # at least one of your repositories. Since you want to make this > # be the one an only one, there you go. > # > # Oh, this assumes you have a rubygems repository already installed > # in the more-or-less normal place. > gem install -i repository `gem env gemdir`/cache/sources-0.0.1.gem There's something wrong with the step before this one, installing RubyGems as root. There's a bug in the tracker, but it is currently low on my priority list. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From Daniel.Berger at qwest.com Mon Aug 20 16:03:56 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Mon, 20 Aug 2007 15:03:56 -0500 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72D88@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Eric Hodel > Sent: Monday, August 20, 2007 1:43 PM > To: jeremy at hinegardner.org; rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] Recognizing Platforms > > > On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: > > > We need to make a change for openbsd. > > > > On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: > >> def match(cpu, os) > >> os = case os > >> when /cygwin/ then [ 'cygwin', nil ] > >> when /darwin(\d+)?/ then [ 'darwin', $1 ] > >> when /freebsd(\d+)/ then [ 'freebsd', $1 ] > >> when /^java([\d.]*)/ then [ 'java', $1 ] > >> when /linux/ then [ 'linux', $1 ] > >> when /mingw32/ then [ 'mingw32', nil ] > >> when /mswin32/ then [ 'mswin32', nil ] > >> when /openbsd(\d+)/ then [ 'openbsd', $1 ] > > > > when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] > > > >> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] > >> else [ 'unknown', nil ] > >> end > >> > >> [cpu, os].flatten.compact.join("-") > >> end > > > > [...] > > > >> x86_64-openbsd-3 > >> x86_64-openbsd-4 > > > > openbsd increments versions by .1 every 6 mos when it cuts > a release. > > All X.Y releases are compatible with each other, correct? If I have > 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it > working? > > If they're all compatible then using only the major number is > the way > to go. One would hope so. Otherwise...oof. Also, any chance we could add AIX and HP-UX in the mix? I think we get enough posts for those platforms on ruby-talk to warrant it. 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 jeremy at hinegardner.org Mon Aug 20 19:01:39 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Mon, 20 Aug 2007 17:01:39 -0600 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> Message-ID: <20070820230139.GX13531@hinegardner.org> On Mon, Aug 20, 2007 at 12:43:23PM -0700, Eric Hodel wrote: > On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: > > >We need to make a change for openbsd. > > > >On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: > >>def match(cpu, os) > >> os = case os > >> when /cygwin/ then [ 'cygwin', nil ] > >> when /darwin(\d+)?/ then [ 'darwin', $1 ] > >> when /freebsd(\d+)/ then [ 'freebsd', $1 ] > >> when /^java([\d.]*)/ then [ 'java', $1 ] > >> when /linux/ then [ 'linux', $1 ] > >> when /mingw32/ then [ 'mingw32', nil ] > >> when /mswin32/ then [ 'mswin32', nil ] > >> when /openbsd(\d+)/ then [ 'openbsd', $1 ] > > > > when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] > > > >> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] > >> else [ 'unknown', nil ] > >> end > >> > >> [cpu, os].flatten.compact.join("-") > >>end > > > >[...] > > > >>x86_64-openbsd-3 > >>x86_64-openbsd-4 > > > >openbsd increments versions by .1 every 6 mos when it cuts a release. > > All X.Y releases are compatible with each other, correct? If I have > 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it > working? No, not all X.Y release are compatible. For instance, the current version is 4.1, 4.0 is still supported. 4.2 will come out in a couple of months. I currently have a 4.0 box that needs to be upgraded. I could 'upgrade' to 4.1, but not to 4.2. To go to from 4.0 -> 4.2 I will need to reinstall. For most everything, when you upgrade you end up replacing all the binaries. A kernel from a new version will generally run the userland apps from the previous version, but the userland apps from a new version will generally NOT run on the previous versions kernel. > If they're all compatible then using only the major number is the way > to go. All openbsd releases that have the same "major" version are definately not compatible. OpenBSD's versions are not major.minor they are just numbers. 3.9 to 4.0 was not a 'major' milestone, it was just the next version. Every 6 months a new version of OpenBSD is released and they just increment the number by .1. Going from 3.0 to 4.0 was 10 releases over 5 years. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From jeremy at hinegardner.org Tue Aug 21 00:06:04 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Mon, 20 Aug 2007 22:06:04 -0600 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72D88@ITOMAE2KM01.AD.QINTRA.COM> References: <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> <7524A45A1A5B264FA4809E2156496CFBE72D88@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <20070821040604.GD712@hinegardner.org> On Mon, Aug 20, 2007 at 03:03:56PM -0500, Berger, Daniel wrote: > > On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: > > > > > We need to make a change for openbsd. > > > > > > On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: > > >> def match(cpu, os) > > >> os = case os > > >> when /cygwin/ then [ 'cygwin', nil ] > > >> when /darwin(\d+)?/ then [ 'darwin', $1 ] > > >> when /freebsd(\d+)/ then [ 'freebsd', $1 ] > > >> when /^java([\d.]*)/ then [ 'java', $1 ] > > >> when /linux/ then [ 'linux', $1 ] > > >> when /mingw32/ then [ 'mingw32', nil ] > > >> when /mswin32/ then [ 'mswin32', nil ] > > >> when /openbsd(\d+)/ then [ 'openbsd', $1 ] > > > > > > when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] > > > > > >> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] > > >> else [ 'unknown', nil ] > > >> end > > >> > > >> [cpu, os].flatten.compact.join("-") > > >> end > > > > > > [...] > > > > > >> x86_64-openbsd-3 > > >> x86_64-openbsd-4 > > > > > > openbsd increments versions by .1 every 6 mos when it cuts > > a release. > > > > All X.Y releases are compatible with each other, correct? If I have > > 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it > > working? > > > > If they're all compatible then using only the major number is > > the way > > to go. > > One would hope so. Otherwise...oof. Well OpenBSD is definitely different when it comes to versions (among other things). From Absolute OpenBSD: "OpenBSD releases are numbered sequentially, starting with 2.0 and incrementing .1 with every release. Unlike most software products a .0 release has no special meaning, it's just a point along a long path." enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From drbrain at segment7.net Tue Aug 21 00:26:26 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 20 Aug 2007 21:26:26 -0700 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72D88@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72D88@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Aug 20, 2007, at 13:03, Berger, Daniel wrote: > Also, any chance we could add AIX and HP-UX in the mix? I think we get > enough posts for those platforms on ruby-talk to warrant it. I'd love to, if I knew what they looked like. Do you know anyone who has an AIX or HP-UX machine that can run tattle (best) or run this code (second best)? Incidentally I have an HP-UX, but installing an OS modern-enough OS on it to run Ruby alone is a long day's work, I'd rather let the lazyweb take care of it. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From steven at lumos.us Tue Aug 21 19:22:45 2007 From: steven at lumos.us (Steven Lumos) Date: Tue, 21 Aug 2007 16:22:45 -0700 Subject: [Rubygems-developers] Recognizing Platforms References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> Message-ID: <86bqd079ru.fsf@bitty.lumos.us> Eric Hodel writes: > On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: > >> We need to make a change for openbsd. >> >> On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: >>> def match(cpu, os) >>> os = case os >>> when /cygwin/ then [ 'cygwin', nil ] >>> when /darwin(\d+)?/ then [ 'darwin', $1 ] >>> when /freebsd(\d+)/ then [ 'freebsd', $1 ] >>> when /^java([\d.]*)/ then [ 'java', $1 ] >>> when /linux/ then [ 'linux', $1 ] >>> when /mingw32/ then [ 'mingw32', nil ] >>> when /mswin32/ then [ 'mswin32', nil ] >>> when /openbsd(\d+)/ then [ 'openbsd', $1 ] >> >> when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] >> >>> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] >>> else [ 'unknown', nil ] >>> end >>> >>> [cpu, os].flatten.compact.join("-") >>> end >> >> [...] >> >>> x86_64-openbsd-3 >>> x86_64-openbsd-4 >> >> openbsd increments versions by .1 every 6 mos when it cuts a release. > > All X.Y releases are compatible with each other, correct? If I have > 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it > working? > > If they're all compatible then using only the major number is the way > to go. If that's the case then maybe it should be [ 'solaris', nil ]. Where is the $1 in linux coming from? Steve From drbrain at segment7.net Tue Aug 21 22:45:28 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 21 Aug 2007 19:45:28 -0700 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <86bqd079ru.fsf@bitty.lumos.us> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> <86bqd079ru.fsf@bitty.lumos.us> Message-ID: <39C4DB8B-4A4E-4D06-B221-76026827C35A@segment7.net> On Aug 21, 2007, at 16:22, Steven Lumos wrote: > Eric Hodel writes: >> On Aug 19, 2007, at 16:17, Jeremy Hinegardner wrote: >>> We need to make a change for openbsd. >>> >>> On Sun, Aug 19, 2007 at 03:11:06PM -0700, Eric Hodel wrote: >>>> def match(cpu, os) >>>> os = case os >>>> when /cygwin/ then [ 'cygwin', nil ] >>>> when /darwin(\d+)?/ then [ 'darwin', $1 ] >>>> when /freebsd(\d+)/ then [ 'freebsd', $1 ] >>>> when /^java([\d.]*)/ then [ 'java', $1 ] >>>> when /linux/ then [ 'linux', $1 ] >>>> when /mingw32/ then [ 'mingw32', nil ] >>>> when /mswin32/ then [ 'mswin32', nil ] >>>> when /openbsd(\d+)/ then [ 'openbsd', $1 ] >>> >>> when /openbsd(\d+\.\d+) then [ 'openbsd', $1 ] >>> >>>> when /solaris(\d+\.\d+)/ then [ 'solaris', $1 ] >>>> else [ 'unknown', nil ] >>>> end >>>> >>>> [cpu, os].flatten.compact.join("-") >>>> end >>> >>> [...] >>> >>>> x86_64-openbsd-3 >>>> x86_64-openbsd-4 >>> >>> openbsd increments versions by .1 every 6 mos when it cuts a >>> release. >> >> All X.Y releases are compatible with each other, correct? If I have >> 4.0 and upgrade to 4.1, do you need to reinstall anything to keep it >> working? >> >> If they're all compatible then using only the major number is the way >> to go. > > If that's the case then maybe it should be [ 'solaris', nil ]. I think Solaris 8 has the platform solaris2.8 and so-forth. AFAIK, 8 and 9 aren't necessarily compatible the same way OpenBSD 4.0 and 4.1 aren't necessarily compatible. > Where is the $1 in linux coming from? Typo. Linux doesn't seem to have any version numbers that autoconf exposes. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From halostatue at gmail.com Tue Aug 21 23:41:44 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 21 Aug 2007 23:41:44 -0400 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <39C4DB8B-4A4E-4D06-B221-76026827C35A@segment7.net> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> <86bqd079ru.fsf@bitty.lumos.us> <39C4DB8B-4A4E-4D06-B221-76026827C35A@segment7.net> Message-ID: <9e7db9110708212041g344d2d0en16e09b30088d6fb1@mail.gmail.com> On 8/21/07, Eric Hodel wrote: > I think Solaris 8 has the platform solaris2.8 and so-forth. AFAIK, 8 > and 9 aren't necessarily compatible the same way OpenBSD 4.0 and 4.1 > aren't necessarily compatible. Sun guarantees forward compatibility for an architecture; something built on Solaris 8 will run on 9 and 10. Something built on 10 won't run on 8 or 9. -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From hisham86 at aucegypt.edu Wed Aug 22 00:22:22 2007 From: hisham86 at aucegypt.edu (Hisham ElHifnawi) Date: Wed, 22 Aug 2007 07:22:22 +0300 Subject: [Rubygems-developers] HOWTO generate rails skeleton Message-ID: NEED help: My group are working on rails IDE and we're in the wizard part now and we're trying to generate the Rails skeleton and we looked in the rubygems and found in gems/1.8/gems/rails-1.2.2 /lib/rails_generator/generators/applications/app/app_generator.rb what does it do, does it generates rails skeleton? are there any other scripts we need to execute as well? plz email me at hisham86 at aucegypt.edu -- Best Regards, Hisham ElHifnawi Computer Science Senior, The American University in Cairo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070822/7fb52650/attachment.html From drbrain at segment7.net Wed Aug 22 01:06:31 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 21 Aug 2007 22:06:31 -0700 Subject: [Rubygems-developers] Recognizing Platforms In-Reply-To: <9e7db9110708212041g344d2d0en16e09b30088d6fb1@mail.gmail.com> References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> <86bqd079ru.fsf@bitty.lumos.us> <39C4DB8B-4A4E-4D06-B221-76026827C35A@segment7.net> <9e7db9110708212041g344d2d0en16e09b30088d6fb1@mail.gmail.com> Message-ID: <31DF7FB4-D054-4B6A-A4EF-1215C3CD9E86@segment7.net> On Aug 21, 2007, at 20:41, Austin Ziegler wrote: > On 8/21/07, Eric Hodel wrote: >> I think Solaris 8 has the platform solaris2.8 and so-forth. AFAIK, 8 >> and 9 aren't necessarily compatible the same way OpenBSD 4.0 and 4.1 >> aren't necessarily compatible. > > Sun guarantees forward compatibility for an architecture; something > built on Solaris 8 will run on 9 and 10. Something built on 10 won't > run on 8 or 9. Excellent. It looks like the platform will end up turning into a real object with a Gem::Requirement in it. For now, almost every gem with a non-ruby platform is for mswin32, so we still have some time to get things right :) -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drnicwilliams at gmail.com Wed Aug 22 01:07:18 2007 From: drnicwilliams at gmail.com (Nic Williams) Date: Wed, 22 Aug 2007 07:07:18 +0200 Subject: [Rubygems-developers] HOWTO generate rails skeleton In-Reply-To: References: Message-ID: <44b555bb0708212207t387c3917y9b8cd1e469f70d76@mail.gmail.com> That's correct. That file is the generator for a new rails app. It uses the root of the railties gem ("rails" gem) as the base for the template files, as opposed to a "templates" folder like normal. Look in the "railties/bin/rails" script for how the generator is invoked. On 8/22/07, Hisham ElHifnawi wrote: > > NEED help: > My group are working on rails IDE and we're in the wizard part now and > we're trying to generate the Rails skeleton and we looked in the rubygems > and found in > gems/1.8/gems/rails-1.2.2/lib/rails_generator/generators/applications/app/app_generator.rb > > what does it do, does it generates rails skeleton? are there any other > scripts we need to execute as well? > plz email me at hisham86 at aucegypt.edu > > -- > Best Regards, > > Hisham ElHifnawi > Computer Science Senior, > The American University in Cairo > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Dr Nic Williams http://drnicacademy.com - Ruby/Rails training around the world http://drnicwilliams.com - Ruby/Rails/Javascript/Web2.0 skype: nicwilliams (p) +61 7 3102 3237 (Finds me anywhere in the world, via Skype) (m) +49 162 347 2195 (German mobile) (f) +61 7 3305 7572 (sends fax to my email) (mail) Nic Williams c/o Bryatt-Paradeda Hohenzollerndamm 129 14199 Berlin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070822/38939900/attachment.html From drbrain at segment7.net Wed Aug 22 01:08:07 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 21 Aug 2007 22:08:07 -0700 Subject: [Rubygems-developers] HOWTO generate rails skeleton In-Reply-To: References: Message-ID: <869634DB-0FBA-41D9-B95E-A4C67F4419EB@segment7.net> On Aug 21, 2007, at 21:22, Hisham ElHifnawi wrote: > NEED help: > My group are working on rails IDE and we're in the wizard part now > and we're trying to generate the Rails skeleton and we looked in > the rubygems and found in > gems/1.8/gems/rails-1.2.2/lib/rails_generator/generators/ > applications/app/app_generator.rb > what does it do, does it generates rails skeleton? are there any > other scripts we need to execute as well? > plz email me at hisham86 at aucegypt.edu This list is for the RubyGems software itself, not for any third- party packages. I suggest you try the rails mailing list at rubyonrails- talk at googlegroups.com -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From hgs at dmu.ac.uk Wed Aug 22 09:27:12 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 22 Aug 2007 14:27:12 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. Message-ID: I've obtained flog 1.1.0 from the repository on my cygwin system. If I try to get flog on solaris9, I get 1.0.2. If I update, I still get 1.0.2. If I get rid of anything like a source cache: brains# ls -l sourc* -rw-r--r-- 1 root other 4 Aug 22 14:15 source_cache -rw-r--r-- 1 root other 2261136 Feb 4 2005 source_caches brains# rm source_caches brains# rm source_cache brains# gem install flog '=1.1.0' Bulk updating Gem source index for: http://gems.rubyforge.org ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find flog (> 0) in any repository brains# ls -ltr total 16 drwxr-xr-x 2 root other 1536 Aug 22 13:55 cache drwxr-xr-x 2 root other 2048 Aug 22 13:55 specifications drwxr-xr-x 50 root other 1536 Aug 22 13:55 gems drwxr-xr-x 37 root other 1024 Aug 22 13:57 doc -rw-r--r-- 1 root other 4 Aug 22 14:23 source_cache brains# od source_cache 0000000 002010 075400 0000004 brains# What do I need to do to get this working again? Thank you, Hugh From drbrain at segment7.net Thu Aug 23 17:53:48 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Aug 2007 14:53:48 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: Message-ID: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net> On Aug 22, 2007, at 06:27, Hugh Sasse wrote: > I've obtained flog 1.1.0 from the repository on my cygwin system. > If I try to get flog on solaris9, I get 1.0.2. If I update, I still > get 1.0.2. If I get rid of anything like a source cache: > > brains# ls -l sourc* > -rw-r--r-- 1 root other 4 Aug 22 14:15 source_cache > -rw-r--r-- 1 root other 2261136 Feb 4 2005 source_caches > brains# rm source_caches > brains# rm source_cache > brains# gem install flog '=1.1.0' > Bulk updating Gem source index for: http://gems.rubyforge.org > ERROR: While executing gem ... (Gem::GemNotFoundException) > Could not find flog (> 0) in any repository > brains# ls -ltr > total 16 > drwxr-xr-x 2 root other 1536 Aug 22 13:55 cache > drwxr-xr-x 2 root other 2048 Aug 22 13:55 specifications > drwxr-xr-x 50 root other 1536 Aug 22 13:55 gems > drwxr-xr-x 37 root other 1024 Aug 22 13:57 doc > -rw-r--r-- 1 root other 4 Aug 22 14:23 source_cache > brains# od source_cache > 0000000 002010 075400 > 0000004 > brains# > > What do I need to do to get this working again? It looks like gem can't talk to gems.rubyforge.org at all. What does `gem install -d flog` output? -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From nicksieger at gmail.com Thu Aug 23 18:48:42 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Thu, 23 Aug 2007 15:48:42 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: Message-ID: On 8/22/07, Hugh Sasse wrote: > > I've obtained flog 1.1.0 from the repository on my cygwin system. > If I try to get flog on solaris9, I get 1.0.2. If I update, I still > get 1.0.2. If I get rid of anything like a source cache: > > brains# ls -l sourc* > -rw-r--r-- 1 root other 4 Aug 22 14:15 source_cache > -rw-r--r-- 1 root other 2261136 Feb 4 2005 source_caches > brains# rm source_caches > brains# rm source_cache > brains# gem install flog '=1.1.0' > Bulk updating Gem source index for: http://gems.rubyforge.org > ERROR: While executing gem ... (Gem::GemNotFoundException) > Could not find flog (> 0) in any repository > brains# ls -ltr > total 16 > drwxr-xr-x 2 root other 1536 Aug 22 13:55 cache > drwxr-xr-x 2 root other 2048 Aug 22 13:55 specifications > drwxr-xr-x 50 root other 1536 Aug 22 13:55 gems > drwxr-xr-x 37 root other 1024 Aug 22 13:57 doc > -rw-r--r-- 1 root other 4 Aug 22 14:23 source_cache > brains# od source_cache > 0000000 002010 075400 > 0000004 > brains# > > What do I need to do to get this working again? Try "gem install flog" again. There is a bug in the latest release that prevents installing any gem when there is no source_cache. Now that there is at least a (near) empty file, it should work fine. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070823/2e8531ba/attachment.html From drbrain at segment7.net Thu Aug 23 21:25:11 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Aug 2007 18:25:11 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: Message-ID: On Aug 23, 2007, at 15:48, Nick Sieger wrote: > On 8/22/07, Hugh Sasse wrote: >> I've obtained flog 1.1.0 from the repository on my cygwin system. >> If I try to get flog on solaris9, I get 1.0.2. If I update, I still >> get 1.0.2. >> >> What do I need to do to get this working again? > > Try "gem install flog" again. There is a bug in the latest release > that prevents installing any gem when there is no source_cache. > Now that there is at least a (near) empty file, it should work fine. Unless the gem is hanging out on disk, you can't install anything without a source_cache, and if its not coming down from gems.rubyforge.org, I'm not sure what to do. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Thu Aug 23 22:10:10 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 23 Aug 2007 19:10:10 -0700 Subject: [Rubygems-developers] Beta Time? Message-ID: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net> I think its time to release a beta and have people beat on the new DependencyInstaller. There are major changes in all areas of RubyGems, and I think this is a good time to get feedback on them. I'll be leaving for a 2+ week vacation on Monday, so this will be a good time to have the beta floating around. Outstanding issues: * rake bug with packaging platform gems (reported with Jim) * `gem outdated` and `gem update` still don't handle platforms correctly * old rubygems scripts (gem_server, gemri, etc) are not cleaned up (do we want this yet?) Select Changes: * major refactorings in all areas * RubyGems knows its platform, so `gem install` will Just Work * gems in a diamond dependency tree with multiple versions will only be installed once * platforms can no longer be Strings, unless they are legacy platforms * Gem::Platform::CURRENT now works as expected * `gem install -i` makes sure all dependencies are installed * processing the source cache takes less memory * bulk update threshold can be specified * `gem env` now has more diagnostic information * gems can now depend on a specific RubyGems version * --proxy now supports HTTP basic authentication * require 'rubygems' now loads less code (no openssl, for example) * sources gem is gone, replaced by built-in defaults * exact gem names are match in various places making installation of the right gem easier * `gem query` (list) respects its defaults (don't print details) * mkrf extensions are supported -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From nicksieger at gmail.com Fri Aug 24 04:02:23 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 24 Aug 2007 01:02:23 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References:

Message-ID: On 8/23/07, Eric Hodel wrote: > > On Aug 23, 2007, at 15:48, Nick Sieger wrote: > > On 8/22/07, Hugh Sasse wrote: > >> I've obtained flog 1.1.0 from the repository on my cygwin system. > >> If I try to get flog on solaris9, I get 1.0.2. If I update, I still > >> get 1.0.2. > >> > >> What do I need to do to get this working again? > > > > Try "gem install flog" again. There is a bug in the latest release > > that prevents installing any gem when there is no source_cache. > > Now that there is at least a (near) empty file, it should work fine. > > Unless the gem is hanging out on disk, you can't install anything > without a source_cache, and if its not coming down from > gems.rubyforge.org, I'm not sure what to do. Relevant thread is here: http://rubyforge.org/pipermail/rubygems-developers/2007-June/002816.html I think Jim committed my patch, but I'm not sure in what revision. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070824/37f41993/attachment.html From nicksieger at gmail.com Fri Aug 24 04:13:54 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Fri, 24 Aug 2007 01:13:54 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References:

Message-ID: On 8/24/07, Nick Sieger wrote: > > On 8/23/07, Eric Hodel wrote: > > > > On Aug 23, 2007, at 15:48, Nick Sieger wrote: > > > On 8/22/07, Hugh Sasse wrote: > > >> I've obtained flog 1.1.0 from the repository on my cygwin system. > > >> If I try to get flog on solaris9, I get 1.0.2. If I update, I still > > >> get 1.0.2. > > >> > > >> What do I need to do to get this working again? > > > > > > Try "gem install flog" again. There is a bug in the latest release > > > that prevents installing any gem when there is no source_cache. > > > Now that there is at least a (near) empty file, it should work fine. > > > > Unless the gem is hanging out on disk, you can't install anything > > without a source_cache, and if its not coming down from > > gems.rubyforge.org, I'm not sure what to do. > > > Relevant thread is here: > > http://rubyforge.org/pipermail/rubygems-developers/2007-June/002816.html > > I think Jim committed my patch, but I'm not sure in what revision. > Looks like it was 1254. /Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070824/169b0f36/attachment.html From hgs at dmu.ac.uk Fri Aug 24 06:45:47 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 24 Aug 2007 11:45:47 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. In-Reply-To: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net> References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net> Message-ID: On Thu, 23 Aug 2007, Eric Hodel wrote: > > It looks like gem can't talk to gems.rubyforge.org at all. > > What does `gem install -d flog` output? I've replied to this, but my reply, even compressed is too big, so it's being moderated Hugh From steven at lumos.us Fri Aug 24 18:56:31 2007 From: steven at lumos.us (Steven Lumos) Date: Fri, 24 Aug 2007 15:56:31 -0700 Subject: [Rubygems-developers] Recognizing Platforms References: <79FAD2CC-3F6A-4FC1-9279-60A12A5A5762@segment7.net> <20070819231730.GL13531@hinegardner.org> <236FF6C1-68C8-49D4-AF9E-C559CF429370@segment7.net> <86bqd079ru.fsf@bitty.lumos.us> <39C4DB8B-4A4E-4D06-B221-76026827C35A@segment7.net> <9e7db9110708212041g344d2d0en16e09b30088d6fb1@mail.gmail.com> Message-ID: <867inkczj4.fsf@bitty.lumos.us> "Austin Ziegler" writes: > On 8/21/07, Eric Hodel wrote: >> I think Solaris 8 has the platform solaris2.8 and so-forth. AFAIK, 8 >> and 9 aren't necessarily compatible the same way OpenBSD 4.0 and 4.1 >> aren't necessarily compatible. > > Sun guarantees forward compatibility for an architecture; something > built on Solaris 8 will run on 9 and 10. Something built on 10 won't > run on 8 or 9. > > -austin Right. In an emergency, I once brought up a 15-year-old version of FrameMaker that was last used on SPARCStation 1s under SunOS 4.1 ("Solaris 1") on my Blade 2500 (UltraSPARC IV, Solaris 8). Including flexLM. Steve From thewoolleyman at gmail.com Sat Aug 25 22:42:32 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 25 Aug 2007 19:42:32 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net> Message-ID: Sounds great. I'll play with it. Do you have to package it, or is there a tag, or just use trunk? -- Chad W On 8/23/07, Eric Hodel wrote: > I think its time to release a beta and have people beat on the new > DependencyInstaller. > > There are major changes in all areas of RubyGems, and I think this is > a good time to get feedback on them. I'll be leaving for a 2+ week > vacation on Monday, so this will be a good time to have the beta > floating around. > > Outstanding issues: > * rake bug with packaging platform gems (reported with Jim) > * `gem outdated` and `gem update` still don't handle platforms correctly > * old rubygems scripts (gem_server, gemri, etc) are not cleaned up > (do we want this yet?) > > Select Changes: > * major refactorings in all areas > * RubyGems knows its platform, so `gem install` will Just Work > * gems in a diamond dependency tree with multiple versions will only > be installed once > * platforms can no longer be Strings, unless they are legacy platforms > * Gem::Platform::CURRENT now works as expected > * `gem install -i` makes sure all dependencies are installed > * processing the source cache takes less memory > * bulk update threshold can be specified > * `gem env` now has more diagnostic information > * gems can now depend on a specific RubyGems version > * --proxy now supports HTTP basic authentication > * require 'rubygems' now loads less code (no openssl, for example) > * sources gem is gone, replaced by built-in defaults > * exact gem names are match in various places making installation of > the right gem easier > * `gem query` (list) respects its defaults (don't print details) > * mkrf extensions are supported > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From drbrain at segment7.net Sun Aug 26 16:03:17 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 26 Aug 2007 13:03:17 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net> Message-ID: On Aug 25, 2007, at 19:42, Chad Woolley wrote: > Sounds great. I'll play with it. Do you have to package it, or is > there a tag, or just use trunk? svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 I sent packages to Jim, he should announce them in the next day or two when he gets a spare moment. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From jim.weirich at gmail.com Mon Aug 27 13:51:08 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon, 27 Aug 2007 13:51:08 -0400 Subject: [Rubygems-developers] Beta Time? In-Reply-To: References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

Message-ID: <0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: > On Aug 25, 2007, at 19:42, Chad Woolley wrote: >> Sounds great. I'll play with it. Do you have to package it, or is >> there a tag, or just use trunk? > > svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 > > I sent packages to Jim, he should announce them in the next day or > two when he gets a spare moment. I'm having a problem with the beta version. It complains about the POpen gem. I uninstalled POpen and reinstalled it using the beta, but it still fails. I suspect it is using a legacy platform issue. Here is the error message: $ gem list rake WARNING: # References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net> Message-ID: On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: > On Thu, 23 Aug 2007, Eric Hodel wrote: > >> >> It looks like gem can't talk to gems.rubyforge.org at all. >> >> What does `gem install -d flog` output? > > I've replied to this, but my reply, even compressed is too big, so > it's being moderated Put it on http://pastie.caboo.se/ or something similar (that is persistent for a few weeks--Eric just left for vacation). From ryand-ruby at zenspider.com Mon Aug 27 22:28:00 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 27 Aug 2007 19:28:00 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> Message-ID: <9E70BCE4-6E8E-4B1F-B86E-61E2AF60AC68@zenspider.com> On Aug 27, 2007, at 10:51 , Jim Weirich wrote: > > On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: > >> On Aug 25, 2007, at 19:42, Chad Woolley wrote: >>> Sounds great. I'll play with it. Do you have to package it, or is >>> there a tag, or just use trunk? >> >> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 >> >> I sent packages to Jim, he should announce them in the next day or >> two when he gets a spare moment. > > I'm having a problem with the beta version. It complains about the > POpen gem. I uninstalled POpen and reinstalled it using the beta, > but it still fails. I'll take a whack at that... From ryand-ruby at zenspider.com Mon Aug 27 23:08:29 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 27 Aug 2007 20:08:29 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> Message-ID: <4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com> On Aug 27, 2007, at 10:51 , Jim Weirich wrote: > > On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: > >> On Aug 25, 2007, at 19:42, Chad Woolley wrote: >>> Sounds great. I'll play with it. Do you have to package it, or is >>> there a tag, or just use trunk? >> >> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 >> >> I sent packages to Jim, he should announce them in the next day or >> two when he gets a spare moment. > > I'm having a problem with the beta version. It complains about the > POpen gem. I uninstalled POpen and reinstalled it using the beta, > but it still fails. Try this (made against head, but should apply to either?): Index: test/test_gem_specification.rb =================================================================== --- test/test_gem_specification.rb (revision 1378) +++ test/test_gem_specification.rb (working copy) @@ -454,6 +454,17 @@ @a0_0_1.platform = Gem::Platform::DARWIN assert_equal ['powerpc', 'darwin', nil], @a0_0_1.platform + + util_set_arch 'i686-linux' + @a0_0_1.platform = Gem::Platform::UNIX + assert_equal Gem::Platform.local, @a0_0_1.platform + + %w(java mswin32 mingw32).each do |arch| + util_set_arch arch + assert_raises Gem::Exception do + @a0_0_1.platform = Gem::Platform::UNIX + end + end end def test_require_paths Index: lib/rubygems/specification.rb =================================================================== --- lib/rubygems/specification.rb (revision 1378) +++ lib/rubygems/specification.rb (working copy) @@ -297,7 +297,11 @@ @platform = Gem::Platform::X86_LINUX when Platform::DARWIN then @platform = Gem::Platform::PPC_DARWIN - + when Platform::UNIX then + @platform = Gem::Platform.local + raise Gem::Exception, + "invalid platform #{platform.inspect}, see Gem::Platform" if + @platform[1] =~ /mswin|mingw|java/ # HACK prolly should go a more heirarchical route else raise Gem::Exception, "invalid platform #{platform.inspect}, see Gem::Platform" Index: lib/rubygems/platform.rb =================================================================== --- lib/rubygems/platform.rb (revision 1378) +++ lib/rubygems/platform.rb (working copy) @@ -106,7 +106,7 @@ WIN32 = 'mswin32' LINUX_586 = 'i586-linux' DARWIN = 'powerpc-darwin' + UNIX = 'unix' # :startdoc: - end From ryand-ruby at zenspider.com Tue Aug 28 00:40:02 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 27 Aug 2007 21:40:02 -0700 Subject: [Rubygems-developers] bug in latest_specs Message-ID: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> The platform dialog showed a bug in my flog-the-world script. It wasn't getting all the gems it could get. I didn't have the POpen4 gem that Jim referred to downloaded to my disk and it was indeed the latest version. The problem is latest_specs collapses down too much so I'm now keying on [name, platform]. The platform can and should be handled better, but I'm not sure how at this stage. There are values that Gem::Platform::normalize will puke on (nil for example). Here is the current breakdown against what I do have: --- i686-linux: 5 java: 2 windows: 1 jruby: 1 universal-darwin8.0: 1 i586-linux: 3 nil: 25 ruby: 1863 i386-mswin32: 7 i386-mswin32-mq6: 1 powerpc-darwin: 2 win32-1.8.2-VC7: 1 mswin32: 27 and here is my patch: Index: source_index.rb =================================================================== --- source_index.rb (revision 1378) +++ source_index.rb (working copy) @@ -135,10 +135,12 @@ each do |full_name, spec| name = spec.name - if thin.has_key? name then - thin[name] = spec if spec.version > thin[name].version + plat = (spec.platform || "ruby").sub(/.*win32.*/, 'mswin32') # FIX + key = [name, plat] + if thin.has_key? key then + thin[key] = spec if spec.version > thin[key].version else - thin[name] = spec + thin[key] = spec end end From hgs at dmu.ac.uk Tue Aug 28 05:32:47 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 28 Aug 2007 10:32:47 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On Mon, 27 Aug 2007, Ryan Davis wrote: > > On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: > > > On Thu, 23 Aug 2007, Eric Hodel wrote: > > > >> > >> It looks like gem can't talk to gems.rubyforge.org at all. > >> > >> What does `gem install -d flog` output? > > > > I've replied to this, but my reply, even compressed is too big, so > > it's being moderated > > Put it on http://pastie.caboo.se/ or something similar (that is > persistent for a few weeks--Eric just left for vacation). It's too big to go on there, in its raw form, and its compressed and base64 form. OK. I'll put it on the web here: http://www.eng.cse.dmu.ac.uk/~hgs/rubygems_debug_typescript Basically, -d didn't tell me much, but --debug gave me that. Hugh From ryand-ruby at zenspider.com Tue Aug 28 14:03:29 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 28 Aug 2007 11:03:29 -0700 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On Aug 28, 2007, at 02:32 , Hugh Sasse wrote: > On Mon, 27 Aug 2007, Ryan Davis wrote: >> On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: >>> On Thu, 23 Aug 2007, Eric Hodel wrote: >>>> It looks like gem can't talk to gems.rubyforge.org at all. >>>> What does `gem install -d flog` output? >>> >>> I've replied to this, but my reply, even compressed is too big, so >>> it's being moderated >> Put it on http://pastie.caboo.se/ or something similar (that is >> persistent for a few weeks--Eric just left for vacation). Unfortunately, the log is useless. By line 31 there is no relevant info (it is all rdoc output) and there is nothing network related, which is what I think Eric was hoping for. Does it still reproduce? From hgs at dmu.ac.uk Wed Aug 29 05:07:51 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 29 Aug 2007 10:07:51 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On Tue, 28 Aug 2007, Ryan Davis wrote: > > On Aug 28, 2007, at 02:32 , Hugh Sasse wrote: > > On Mon, 27 Aug 2007, Ryan Davis wrote: > >> On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: > >>> On Thu, 23 Aug 2007, Eric Hodel wrote: > >>>> It looks like gem can't talk to gems.rubyforge.org at all. > >>>> What does `gem install -d flog` output? > >>> > >>> I've replied to this, but my reply, even compressed is too big, so > >>> it's being moderated > >> Put it on http://pastie.caboo.se/ or something similar (that is > >> persistent for a few weeks--Eric just left for vacation). > > Unfortunately, the log is useless. By line 31 there is no relevant > info (it is all rdoc output) and there is nothing network related, > which is what I think Eric was hoping for. > > Does it still reproduce? I get flog-1.1.0 now, so it works now. I don't know what changed. I still think we need a command to flush the caches. Hugh From gregory.t.brown at gmail.com Wed Aug 29 10:15:56 2007 From: gregory.t.brown at gmail.com (Gregory Brown) Date: Wed, 29 Aug 2007 10:15:56 -0400 Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On 8/29/07, Hugh Sasse wrote: > On Tue, 28 Aug 2007, Ryan Davis wrote: > > > > > On Aug 28, 2007, at 02:32 , Hugh Sasse wrote: > > > On Mon, 27 Aug 2007, Ryan Davis wrote: > > >> On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: > > >>> On Thu, 23 Aug 2007, Eric Hodel wrote: > > >>>> It looks like gem can't talk to gems.rubyforge.org at all. > > >>>> What does `gem install -d flog` output? > > >>> > > >>> I've replied to this, but my reply, even compressed is too big, so > > >>> it's being moderated > > >> Put it on http://pastie.caboo.se/ or something similar (that is > > >> persistent for a few weeks--Eric just left for vacation). > > > > Unfortunately, the log is useless. By line 31 there is no relevant > > info (it is all rdoc output) and there is nothing network related, > > which is what I think Eric was hoping for. > > > > Does it still reproduce? > > I get flog-1.1.0 now, so it works now. I don't know what changed. > I still think we need a command to flush the caches. $ gem -v 0.9.4 $ sudo gem sources --clear-all *** Removed user source cache *** *** Removed system source cache *** From nicksieger at gmail.com Wed Aug 29 11:10:24 2007 From: nicksieger at gmail.com (Nick Sieger) Date: Wed, 29 Aug 2007 10:10:24 -0500 Subject: [Rubygems-developers] Size of gem index Message-ID: The gem index yaml file is starting to get pretty big. Folks are reporting Ruby's memory size gets in the range of 128-150MB when loading up the index. Does anyone else think this is starting to get problematic? It's especially a problem for JRuby since we need to specify the memory size of the Java VM up front, so as the gem index grows, eventually JRuby gem install fails with OutOfMemoryErrors. It seems wasteful to us to simply hike the max memory of the VM up to 512MB (currently the max is 256, but gem install is starting to err consistently for some even at that level). Would something like a two-tier index work, with the main yaml/yaml.Z just containing a list of all available gems/versions with pointers to individual gemspec files available on the web server, or could gem even get by w/o the gemspec before a gem is actually downloaded and installed? Or is the gem index not something to be mucked with at this stage? Cheers, /Nick From hgs at dmu.ac.uk Wed Aug 29 11:36:06 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 29 Aug 2007 16:36:06 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On Wed, 29 Aug 2007, Gregory Brown wrote: > On 8/29/07, Hugh Sasse wrote: > > On Tue, 28 Aug 2007, Ryan Davis wrote: > > > > > > > > On Aug 28, 2007, at 02:32 , Hugh Sasse wrote: > > > > On Mon, 27 Aug 2007, Ryan Davis wrote: > > > >> On Aug 24, 2007, at 03:45 , Hugh Sasse wrote: > > > >>> On Thu, 23 Aug 2007, Eric Hodel wrote: > > > >>>> It looks like gem can't talk to gems.rubyforge.org at all. > > > >>>> What does `gem install -d flog` output? > > > >>> > > > >>> I've replied to this, but my reply, even compressed is too big, so > > > >>> it's being moderated > > > >> Put it on http://pastie.caboo.se/ or something similar (that is > > > >> persistent for a few weeks--Eric just left for vacation). > > > > > > Unfortunately, the log is useless. By line 31 there is no relevant > > > info (it is all rdoc output) and there is nothing network related, > > > which is what I think Eric was hoping for. > > > > > > Does it still reproduce? > > > > I get flog-1.1.0 now, so it works now. I don't know what changed. > > I still think we need a command to flush the caches. > > $ gem -v > 0.9.4 > > $ sudo gem sources --clear-all > *** Removed user source cache *** > *** Removed system source cache *** Thanks. I managed to miss that. :r! gem help source | grep cache | wc 0 0 0 no mention of the cache in there. I'll try to work up a doc patch Hugh From hgs at dmu.ac.uk Wed Aug 29 13:38:29 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 29 Aug 2007 18:38:29 +0100 (WEST) Subject: [Rubygems-developers] Source caches again. In-Reply-To: References: <1D47FFF3-52DF-488D-B9FC-FF549356F5D0@segment7.net>

Message-ID: On Wed, 29 Aug 2007, I wrote: > Thanks. I managed to miss that. > > :r! gem help source | grep cache | wc > 0 0 0 > > no mention of the cache in there. I'll try to work up a doc patch > > Hugh I've come up with this so far. Not as nice as I'd like, the duplication in the second part is basically vile, maybe remove_cache could be a protected method of command? Well, that isn't beautiful either, is it? Command then knows too much about Source. Oh well, I'm sure someone here can come up with something better. This is untested as yet, by the way, so beware. A patch against the unpacked tar ball grabbed from Rubyforge. Hugh :r! (cd /scratch/hgs; display_diffs.rb rubygems-0.9.4) --- rubygems-0.9.4/lib/rubygems/commands/sources_command.rb.orig 2007-05-23 15:51:31.000000000 +0100 +++ rubygems-0.9.4/lib/rubygems/commands/sources_command.rb 2007-08-29 18:15:20.674031000 +0100 @@ -18,7 +18,7 @@ options[:remove] = value end - add_option '-c', '--clear-all', 'Remove all sources' do |value, options| + add_option '-c', '--clear-all', 'Remove all sources (clear the cache)' do |value, options| options[:clear_all] = value end end --- rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb.orig 2007-08-29 18:22:58.049867000 +0100 +++ rubygems-0.9.4/lib/rubygems/commands/clear_cache_command.rb 2007-08-29 18:29:57.586782000 +0100 @@ -0,0 +1,37 @@ +module Gem + module Commands + + class Clear_cacheCommand < Command + + def initialize + super 'clear_cache', 'clear the sources i.e the cache.' + + end + + def defaults_str + '' + end + + def execute + remove_cache_file("user", Gem::SourceInfoCache.user_cache_file) + remove_cache_file("system", Gem::SourceInfoCache.system_cache_file) + say "Cache cleared" + + end + + def remove_cache_file(desc, fn) + FileUtils.rm_rf fn rescue nil + if ! File.exist?(fn) + say "*** Removed #{desc} source cache ***" + elsif ! File.writable?(fn) + say "*** Unable to remove #{desc} source cache (write protected) ***" + else + say "*** Unable to remove #{desc} source cache ***" + end + end + private :remove_cache_file + # It's private, so we need our own copy. Very non-DRY. + + end # class Clear_cacheCommand + end # module Commands +end # module Gem From ryand-ruby at zenspider.com Wed Aug 29 22:11:39 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Aug 2007 19:11:39 -0700 Subject: [Rubygems-developers] bug in latest_specs In-Reply-To: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> References: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> Message-ID: <09485DF5-7CDE-4840-BBBD-C7AF64330F44@zenspider.com> anyone??? bueller? On Aug 27, 2007, at 21:40 , Ryan Davis wrote: > The platform dialog showed a bug in my flog-the-world script. It > wasn't getting all the gems it could get. I didn't have the POpen4 > gem that Jim referred to downloaded to my disk and it was indeed the > latest version. The problem is latest_specs collapses down too much > so I'm now keying on [name, platform]. The platform can and should be > handled better, but I'm not sure how at this stage. There are values > that Gem::Platform::normalize will puke on (nil for example). Here is > the current breakdown against what I do have: > > --- > i686-linux: 5 > java: 2 > windows: 1 > jruby: 1 > universal-darwin8.0: 1 > i586-linux: 3 > nil: 25 > ruby: 1863 > i386-mswin32: 7 > i386-mswin32-mq6: 1 > powerpc-darwin: 2 > win32-1.8.2-VC7: 1 > mswin32: 27 > > and here is my patch: > > Index: source_index.rb > =================================================================== > --- source_index.rb (revision 1378) > +++ source_index.rb (working copy) > @@ -135,10 +135,12 @@ > each do |full_name, spec| > name = spec.name > - if thin.has_key? name then > - thin[name] = spec if spec.version > thin[name].version > + plat = (spec.platform || "ruby").sub(/.*win32.*/, 'mswin32') > # FIX > + key = [name, plat] > + if thin.has_key? key then > + thin[key] = spec if spec.version > thin[key].version > else > - thin[name] = spec > + thin[key] = spec > end > end > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From ryand-ruby at zenspider.com Wed Aug 29 22:13:09 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Aug 2007 19:13:09 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> <4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com> Message-ID: On Aug 27, 2007, at 20:08 , Ryan Davis wrote: > On Aug 27, 2007, at 10:51 , Jim Weirich wrote: >> On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: >>> On Aug 25, 2007, at 19:42, Chad Woolley wrote: >>>> Sounds great. I'll play with it. Do you have to package it, or is >>>> there a tag, or just use trunk? >>> >>> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 >>> >>> I sent packages to Jim, he should announce them in the next day or >>> two when he gets a spare moment. >> >> I'm having a problem with the beta version. It complains about the >> POpen gem. I uninstalled POpen and reinstalled it using the beta, >> but it still fails. > > Try this (made against head, but should apply to either?): did it work for you? As an aside, the last three or four issues I've raised / tried to get feedback on were met with deafening silence on this list... Eric is familiar enough with the code that he can work on his own but I like feedback for my stuff... From djberg96 at gmail.com Wed Aug 29 22:37:06 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 29 Aug 2007 20:37:06 -0600 Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta on Windows Message-ID: <46D62D52.3070103@gmail.com> Hi all, Ruby 1.8.5 (one click) Windows XP SP 2 Rubygems tag REL_0_9_4_4 Most of these look like path handling or teardown issues in the test suite itself, but I'll investigate a couple of these. Look for a patch this weekend... Dan C:\Documents and Settings\djberge\workspace\rubygems-beta>rake test C:0:Warning: require_gem is obsolete. Use gem instead. (in C:/Documents and Settings/djberge/workspace/rubygems-beta) Loaded suite C:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake/rake_test_loader Started .........................................................C:/ruby/lib/ruby/1.8/openssl/x509.rb:24: warning: instance vari able @config not initialized C:/ruby/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized C:/ruby/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized ...............................E....................................EE.......EE..........E............................FF .......E......F................E.EEEEEE................................................................................. ........................................................................................................................ .................F.............. Finished in 25.875 seconds. 1) Error: test_execute(TestGemCommandsPristineCommand): NotImplementedError: the symlink() function is unimplemented on this machine ./lib/rubygems/installer.rb:256:in `symlink' ./lib/rubygems/installer.rb:256:in `generate_bin_symlink' ./lib/rubygems/installer.rb:214:in `generate_bin' ./lib/rubygems/installer.rb:205:in `each' ./lib/rubygems/installer.rb:205:in `generate_bin' ./lib/rubygems/installer.rb:111:in `install' ./test/gemutilities.rb:113:in `install_gem' ./test/test_gem_commands_pristine_command.rb:19:in `test_execute' 2) Error: test_download_gem_local(TestGemDependencyInstaller): Gem::InstallError: unsupported URI scheme C ./lib/rubygems/dependency_installer.rb:128:in `download' ./test/test_gem_dependency_installer.rb:343:in `test_download_gem_local' 3) Error: test_download_gem_local_read_only(TestGemDependencyInstaller): Gem::InstallError: unsupported URI scheme C ./lib/rubygems/dependency_installer.rb:128:in `download' ./test/test_gem_dependency_installer.rb:357:in `test_download_gem_local_read_only' 4) Error: test_install_dependency(TestGemDependencyInstaller): Gem::InstallError: unsupported URI scheme C ./lib/rubygems/dependency_installer.rb:128:in `download' ./lib/rubygems/dependency_installer.rb:181:in `install' ./lib/rubygems/dependency_installer.rb:175:in `each' ./lib/rubygems/dependency_installer.rb:175:in `install' ./test/test_gem_dependency_installer.rb:72:in `test_install_dependency' ./test/test_gem_dependency_installer.rb:70:in `chdir' ./test/test_gem_dependency_installer.rb:70:in `test_install_dependency' 5) Error: test_install_dependency_existing(TestGemDependencyInstaller): NotImplementedError: the symlink() function is unimplemented on this machine ./lib/rubygems/installer.rb:256:in `symlink' ./lib/rubygems/installer.rb:256:in `generate_bin_symlink' ./lib/rubygems/installer.rb:214:in `generate_bin' ./lib/rubygems/installer.rb:205:in `each' ./lib/rubygems/installer.rb:205:in `generate_bin' ./lib/rubygems/installer.rb:111:in `install' ./test/test_gem_dependency_installer.rb:79:in `test_install_dependency_existing' 6) Error: test_install_reinstall(TestGemDependencyInstaller): NotImplementedError: the symlink() function is unimplemented on this machine ./lib/rubygems/installer.rb:256:in `symlink' ./lib/rubygems/installer.rb:256:in `generate_bin_symlink' ./lib/rubygems/installer.rb:214:in `generate_bin' ./lib/rubygems/installer.rb:205:in `each' ./lib/rubygems/installer.rb:205:in `generate_bin' ./lib/rubygems/installer.rb:111:in `install' ./test/test_gem_dependency_installer.rb:248:in `test_install_reinstall' 7) Failure: test_class_build(TestGemExtRakeBuilder) [./test/test_gem_ext_rake_builder.rb:41]: <["ruby mkrf_conf.rb", "", "rake RUBYARCHDIR=C:/WINDOWS/temp/test_rubygems_4044/prefix RUBYLIBDIR=C:/WINDOWS/temp/test_rubygems_4044/prefix", "(in C:/WINDOWS/temp/test_rubygems_4044/ext)\n"]> expected but was <["ruby mkrf_conf.rb", "", "rake RUBYARCHDIR=C:/WINDOWS/temp/test_rubygems_4044/prefix RUBYLIBDIR=C:/WINDOWS/temp/test_rubygems_4044/prefix", "(in C:/WINDOWS/temp/test_rubygems_4044/ext)\nC:0:Warning: require_gem is obsolete. Use gem instead.\n"]>. 8) Failure: test_class_build_fail(TestGemExtRakeBuilder) [./test/test_gem_ext_rake_builder.rb:55]: exception expected but none was thrown. 9) Error: test_generate_index(TestGemIndexerIndexer): Zlib::BufError: buffer error ./lib/rubygems/indexer/compressor.rb:22:in `inflate' ./lib/rubygems/indexer/compressor.rb:22:in `unzip' ./lib/rubygems/indexer/master_index_builder.rb:38:in `paranoid' ./lib/rubygems/indexer/master_index_builder.rb:20:in `cleanup' ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build' ./lib/rubygems/indexer/indexer.rb:34:in `build_index' ./lib/rubygems/indexer/indexer.rb:91:in `generate_index' ./test/test_gem_indexer_indexer.rb:34:in `test_generate_index' ./lib/rubygems/user_interaction.rb:45:in `use_ui' ./lib/rubygems/user_interaction.rb:27:in `use_ui' ./test/test_gem_indexer_indexer.rb:33:in `test_generate_index' 10) Failure: test_expand_and_validate_gem_dir(TestGemInstaller) [./test/test_gem_installer.rb:163]: <"/nonexistent"> expected but was <"C:/nonexistent">. 11) Error: test_install(TestGemInstaller): NotImplementedError: the symlink() function is unimplemented on this machine ./lib/rubygems/installer.rb:256:in `symlink' ./lib/rubygems/installer.rb:256:in `generate_bin_symlink' ./lib/rubygems/installer.rb:214:in `generate_bin' ./lib/rubygems/installer.rb:205:in `each' ./lib/rubygems/installer.rb:205:in `generate_bin' ./lib/rubygems/installer.rb:111:in `install' ./test/test_gem_installer.rb:461:in `test_install' ./lib/rubygems/user_interaction.rb:45:in `use_ui' ./lib/rubygems/user_interaction.rb:27:in `use_ui' ./test/test_gem_installer.rb:460:in `test_install' 12) Error: test_install_check_dependencies(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 13) Error: test_install_force(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 14) Error: test_install_ignore_dependencies(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 15) Error: test_install_missing_dirs(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 16) Error: test_install_with_message(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 17) Error: test_install_writable(TestGemInstaller): Errno::EACCES: Permission denied - C:/WINDOWS/temp/test_rubygems_4044/a-0.0.2.gem C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `unlink' C:/ruby/lib/ruby/1.8/fileutils.rb:1281:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:1289:in `platform_support' C:/ruby/lib/ruby/1.8/fileutils.rb:1280:in `remove_file' C:/ruby/lib/ruby/1.8/fileutils.rb:497:in `mv' C:/ruby/lib/ruby/1.8/fileutils.rb:1379:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest0' C:/ruby/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' C:/ruby/lib/ruby/1.8/fileutils.rb:490:in `mv' ./test/test_gem_installer.rb:31:in `setup' 18) Failure: test_extract_entry_works(TestTarInput) [./test/test_package.rb:248:in `test_extract_entry_works' C:/ruby/lib/ruby/1.8/fileutils.rb:243:in `each_with_index' ./lib/rubygems/package.rb:444:in `each_entry' ./lib/rubygems/package.rb:438:in `loop' ./lib/rubygems/package.rb:438:in `each_entry' ./lib/rubygems/package.rb:423:in `each' ./lib/rubygems/package.rb:595:in `each' ./lib/rubygems/package.rb:410:in `new' ./lib/rubygems/package.rb:594:in `each' ./lib/rubygems/package.rb:444:in `each_entry' ./lib/rubygems/package.rb:438:in `loop' ./lib/rubygems/package.rb:438:in `each_entry' ./lib/rubygems/package.rb:423:in `each' ./lib/rubygems/package.rb:590:in `each' ./test/test_package.rb:237:in `each_with_index' ./test/test_package.rb:237:in `test_extract_entry_works' ./lib/rubygems/package.rb:583:in `open_from_io' ./lib/rubygems/package.rb:576:in `open' ./test/test_package.rb:234:in `test_extract_entry_works']: <33162> expected but was <33188>. 449 tests, 1507 assertions, 4 failures, 14 errors rake aborted! Command failed with status (1): [C:/ruby/bin/ruby -w -Ilib "C:/ruby/lib/rub...] (See full trace by running task with --trace) From drbrain at segment7.net Thu Aug 30 00:01:08 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 29 Aug 2007 21:01:08 -0700 Subject: [Rubygems-developers] bug in latest_specs In-Reply-To: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> References: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> Message-ID: <00EC1E04-9054-47E8-AE6B-E68CB730E090@segment7.net> On Aug 27, 2007, at 21:40, Ryan Davis wrote: > The platform dialog showed a bug in my flog-the-world script. It > wasn't getting all the gems it could get. I didn't have the POpen4 > gem that Jim referred to downloaded to my disk and it was indeed the > latest version. The problem is latest_specs collapses down too much > so I'm now keying on [name, platform]. The platform can and should be > handled better, but I'm not sure how at this stage. There are values > that Gem::Platform::normalize will puke on (nil for example). That's a bug, it should be mapping to "ruby". Please file me a ticket. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Thu Aug 30 00:08:31 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 29 Aug 2007 21:08:31 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> Message-ID: On Aug 27, 2007, at 10:51, Jim Weirich wrote: > On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: >> On Aug 25, 2007, at 19:42, Chad Woolley wrote: >>> Sounds great. I'll play with it. Do you have to package it, or is >>> there a tag, or just use trunk? >> >> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 >> >> I sent packages to Jim, he should announce them in the next day or >> two when he gets a spare moment. > > I'm having a problem with the beta version. It complains about the > POpen gem. I uninstalled POpen and reinstalled it using the beta, > but it still fails. I suspect it is using a legacy platform issue. > Here is the error message: > > > $ gem list rake > WARNING: # rubygems/specification.rb:302:in `platform=': invalid platform > "unix", see Gem::Platform> Dang. I forgot that evaling a platform gem's spec called #platform=, which would break the two gems with totally bizarre platforms like this one. I didn't bother attempting to support automatic installation for these two gems (POpen4 and rubywmq) and instead filed bugs against the projects pointing them at the correct platforms to use. (Of course, they still should install and work if they are already installed, but with the full name or something.) -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Thu Aug 30 00:15:10 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 29 Aug 2007 21:15:10 -0700 Subject: [Rubygems-developers] Beta Time? In-Reply-To: <4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com> References: <69323084-BA01-4F9E-B589-BCFEAD011CC5@segment7.net>

<0A186DAA-2D91-4636-98F8-F3E0004D3D35@gmail.com> <4E316973-6D54-48CD-BF8E-0F46B065EB8F@zenspider.com> Message-ID: <072A6FC7-0924-40A1-9BB6-514132D948B9@segment7.net> On Aug 27, 2007, at 20:08, Ryan Davis wrote: > On Aug 27, 2007, at 10:51 , Jim Weirich wrote: >> On Aug 26, 2007, at 4:03 PM, Eric Hodel wrote: >>> On Aug 25, 2007, at 19:42, Chad Woolley wrote: >>>> Sounds great. I'll play with it. Do you have to package it, or is >>>> there a tag, or just use trunk? >>> >>> svn+ssh://rubyforge.org/var/svn/rubygems/tags/REL_0_9_4_4 >>> >>> I sent packages to Jim, he should announce them in the next day or >>> two when he gets a spare moment. >> >> I'm having a problem with the beta version. It complains about the >> POpen gem. I uninstalled POpen and reinstalled it using the beta, >> but it still fails. > > Try this (made against head, but should apply to either?): > > Index: test/test_gem_specification.rb > =================================================================== > --- test/test_gem_specification.rb (revision 1378) > +++ test/test_gem_specification.rb (working copy) > @@ -454,6 +454,17 @@ > @a0_0_1.platform = Gem::Platform::DARWIN > assert_equal ['powerpc', 'darwin', nil], @a0_0_1.platform > + > + util_set_arch 'i686-linux' > + @a0_0_1.platform = Gem::Platform::UNIX > + assert_equal Gem::Platform.local, @a0_0_1.platform > + > + %w(java mswin32 mingw32).each do |arch| > + util_set_arch arch > + assert_raises Gem::Exception do > + @a0_0_1.platform = Gem::Platform::UNIX > + end > + end > end > def test_require_paths > Index: lib/rubygems/specification.rb > =================================================================== > --- lib/rubygems/specification.rb (revision 1378) > +++ lib/rubygems/specification.rb (working copy) > @@ -297,7 +297,11 @@ > @platform = Gem::Platform::X86_LINUX > when Platform::DARWIN then > @platform = Gem::Platform::PPC_DARWIN > - > + when Platform::UNIX then > + @platform = Gem::Platform.local > + raise Gem::Exception, > + "invalid platform #{platform.inspect}, see > Gem::Platform" if > + @platform[1] =~ /mswin|mingw|java/ # HACK prolly should go > a more heirarchical route > else > raise Gem::Exception, > "invalid platform #{platform.inspect}, see Gem::Platform" My thought for raising the exception was to make gem authors switch from whichever string they thought was appropriate (like "unix" or "win32-1.8.2-VC7") to Gem::Platform::CURRENT. It shouldn't be raised when evaling a gemspec. I don't like the code that would be needed (checking the stack) to make that work. Maybe it should just be dropped and a HACK tag added pointing to the POpen4 gem? -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Thu Aug 30 00:30:00 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 29 Aug 2007 21:30:00 -0700 Subject: [Rubygems-developers] Size of gem index In-Reply-To: References: Message-ID: <9F2ED914-E43F-47D7-9418-2E3300068F37@segment7.net> On Aug 29, 2007, at 08:10, Nick Sieger wrote: > The gem index yaml file is starting to get pretty big. Folks are > reporting Ruby's memory size gets in the range of 128-150MB when > loading up the index. Does anyone else think this is starting to get > problematic? > > It's especially a problem for JRuby since we need to specify the > memory size of the Java VM up front, so as the gem index grows, > eventually JRuby gem install fails with OutOfMemoryErrors. It seems > wasteful to us to simply hike the max memory of the VM up to 512MB > (currently the max is 256, but gem install is starting to err > consistently for some even at that level). > > Would something like a two-tier index work, with the main yaml/yaml.Z > just containing a list of all available gems/versions with pointers to > individual gemspec files available on the web server, You just described the "quick index" perfectly. There's a problem with the index-building script on RubyForge that has been fixed in trunk but not deployed yet that causes bulk updates (yaml.Z/yaml) when they aren't necessary. > or could gem even get by w/o the gemspec before a gem is actually > downloaded and > installed? The index is needed to resolve versions and platforms across dependencies. > Or is the gem index not something to be mucked with at this stage? I think the fix to the indexer script will solve the problem unless the source index is extremely out of date. I get annoying bulk index updates when I'm doing things at just the right times of day. Still, we're open to improvements. Previously Ryan Davis proposed an index of just the latest gems, since 90% of the time that's all people want. I don't think it was fully implemented. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From ryand-ruby at zenspider.com Thu Aug 30 00:56:16 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 29 Aug 2007 21:56:16 -0700 Subject: [Rubygems-developers] bug in latest_specs In-Reply-To: <00EC1E04-9054-47E8-AE6B-E68CB730E090@segment7.net> References: <43679DC1-DB01-4802-A136-B1AC2BAF0519@zenspider.com> <00EC1E04-9054-47E8-AE6B-E68CB730E090@segment7.net> Message-ID: On Aug 29, 2007, at 21:01 , Eric Hodel wrote: > That's a bug, it should be mapping to "ruby". Please file me a > ticket. done. thanks From Daniel.Berger at qwest.com Fri Aug 31 10:27:35 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 31 Aug 2007 09:27:35 -0500 Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta on Windows In-Reply-To: <46D62D52.3070103@gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72DC0@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Daniel Berger > Sent: Wednesday, August 29, 2007 8:37 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] Test failures for 0.9.4.4 beta > on Windows > > > Hi all, > > Ruby 1.8.5 (one click) > Windows XP SP 2 > Rubygems tag REL_0_9_4_4 > > Most of these look like path handling or teardown issues in the test > suite itself, but I'll investigate a couple of these. > > Look for a patch this weekend... I've submitted a series of patches on the project page that cut it down to 2 failures and 2 errors. Please see: http://rubyforge.org/tracker/index.php?func=detail&aid=13528&group_id=12 6&atid=577 http://rubyforge.org/tracker/index.php?func=detail&aid=13529&group_id=12 6&atid=577 http://rubyforge.org/tracker/index.php?func=detail&aid=13533&group_id=12 6&atid=577 http://rubyforge.org/tracker/index.php?func=detail&aid=13535&group_id=12 6&atid=577 http://rubyforge.org/tracker/index.php?func=detail&aid=13537&group_id=12 6&atid=577 Here are the remaining issues: 1) Error: test_execute(TestGemCommandsPristineCommand): SecurityError: Insecure operation - initialize ./lib/rubygems/installer.rb:272:in `initialize' ./lib/rubygems/installer.rb:272:in `open' ./lib/rubygems/installer.rb:272:in `shebang' ./lib/rubygems/installer.rb:290:in `app_script_text' ./lib/rubygems/installer.rb:229:in `generate_bin_script' ./lib/rubygems/installer.rb:228:in `open' ./lib/rubygems/installer.rb:228:in `generate_bin_script' ./lib/rubygems/installer.rb:241:in `generate_bin_symlink' ./lib/rubygems/installer.rb:215:in `generate_bin' ./lib/rubygems/installer.rb:206:in `each' ./lib/rubygems/installer.rb:206:in `generate_bin' ./lib/rubygems/installer.rb:112:in `install' ./test/gemutilities.rb:117:in `install_gem' ./test/test_gem_commands_pristine_command.rb:19:in `test_execute' I may have introduced this bug in my attempt to fix the filehandle closing issue in patch #13533. I haven't investigated further. 2) Failure: test_download_gem_local_read_only(TestGemDependencyInstaller) [./test/test_gem_dependency_installer.rb:356]: <"C:/WINNT/temp/test_rubygems_2032/a-1.gem"> expected but was <"C:/WINNT/temp/test_rubygems_2032/gemhome/cache/a-1.gem">. I'm not sure if the patch is bad or the test is bad. See my comment in patch #13537. 3) Error: test_generate_index(TestGemIndexerIndexer): Zlib::BufError: buffer error ./lib/rubygems/indexer/compressor.rb:22:in `inflate' ./lib/rubygems/indexer/compressor.rb:22:in `unzip' ./lib/rubygems/indexer/master_index_builder.rb:38:in `paranoid' ./lib/rubygems/indexer/master_index_builder.rb:20:in `cleanup' ./lib/rubygems/indexer/abstract_index_builder.rb:42:in `build' ./lib/rubygems/indexer/indexer.rb:34:in `build_index' ./lib/rubygems/indexer/indexer.rb:91:in `generate_index' ./test/test_gem_indexer_indexer.rb:34:in `test_generate_index' ./lib/rubygems/user_interaction.rb:45:in `use_ui' ./lib/rubygems/user_interaction.rb:27:in `use_ui' ./test/test_gem_indexer_indexer.rb:33:in `test_generate_index' No clue. Will require diving into some ugly C code with a wet suit and a spear gun. 4) Failure: test_self_match_version(TestGemPlatform) [./test/test_gem_platform.rb:74]: versionless == any. is not true. This failure is caused by changing the architecture in patch #13529, but the lack of a release number in Config::CONFIG['arch'] for MS Windows made me unsure how the tests should be refactored. That's all for now. Comments welcome. 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 han.holl at tietoenator.com Fri Aug 31 10:53:53 2007 From: han.holl at tietoenator.com (han.holl at tietoenator.com) Date: Fri, 31 Aug 2007 16:53:53 +0200 Subject: [Rubygems-developers] Problem with ruby-debug-base and ruby-debug Message-ID: <200708311653.53475.han.holl@tietoenator.com> Hi, If you 'gem install ruby-debug' you get ruby-debug-base as a dependency. However, if you do: gem contents ruby-debug you get the contents of ruby-debug-base. The problem is probably that ruby-debug-base is seen as the latest version of ruby-debug. In other words, gem names that are real subsets of other gem names can lead to trouble. Cheers, Han Holl From drbrain at segment7.net Fri Aug 31 12:45:29 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 31 Aug 2007 09:45:29 -0700 Subject: [Rubygems-developers] Problem with ruby-debug-base and ruby-debug In-Reply-To: <200708311653.53475.han.holl@tietoenator.com> References: <200708311653.53475.han.holl@tietoenator.com> Message-ID: On Aug 31, 2007, at 07:53, han.holl at tietoenator.com wrote: > Hi, > If you 'gem install ruby-debug' you get ruby-debug-base as a > dependency. > > However, if you do: gem contents ruby-debug > you get the contents of ruby-debug-base. > > The problem is probably that ruby-debug-base is seen as the latest > version of > ruby-debug. > In other words, gem names that are real subsets of other gem names > can lead to > trouble. Check the tracker, its been marked as fixed. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From jochen at remote.org Fri Aug 31 15:56:22 2007 From: jochen at remote.org (Jochen Topf) Date: Fri, 31 Aug 2007 21:56:22 +0200 Subject: [Rubygems-developers] Gems for several architectures Message-ID: <20070831195622.GA3914@eldorado.remote.org> Hi! Couldn't find any information about this. What is the right way to handle gems for several architectures? For the Proj4rb project 'rake gem' created those gems on Linux and Mac, respectively: proj4rb-0.2.1-i486-linux.gem proj4rb-0.2.1-universal-darwin8.0.gem Now on Linux when I do a gem install proj4rb it pulls the darwin one instead of the linux one. Of course, I can do a gem install proj4rb-0.2.1-i486-linux and it will do the right thing, but shouldn't it do this automatically? Maybe it has something to do with the darwin one beeing an universal binary which works on i386 and PPC. So at the rubyforge release form I said "any" for the platform. Any ideas on what the right procedure is here? Jochen -- Jochen Topf jochen at remote.org http://www.remote.org/jochen/ +49-721-388298