[Rubygems-developers] Pull Request #2: progress downloader

James Tucker jftucker at gmail.com
Sun Sep 26 22:26:29 EDT 2010


spinner = %w[|/-\]
class << spinner; def next; @s||=0; self[@s]; ensure; @s = @s + 1 == size ? 0 : @s + 1; end
t = Thread.new do
while true
	sleep 0.5
	$stdout.sync = true
	ui.print "\r#{spinner.next}"
end
end


# when done:
t.kill

seems cheap and portable enough, with a bit more work, would this do?

(sorry for bugs, 5 mins whilst wine'd up)

On 26 Sep 2010, at 18:44, Luis Lavena wrote:

> Hello guys,
> 
> In case you didn't see the pull request #2:
> 
> http://github.com/rubygems/rubygems/pull/2
> 
> I wanted to bring it to attention.
> 
> Basically the problem is raised due big gems, particularly QtBindings
> which Windows binaries weight 49MB and the pure-ruby one is 1.6MB
> 
> The problem with such gems is evident: there is no 'clue' on what is going on.
> 
> Over the pull request I mentioned that adding ProgressBar class is not ideal:
> 
> 1) makes RubyGems depend on another piece of code
> 
> 2) It clashes with another definition of ProgressBar
> 
> I suggested do a clean and simple implementation as Rubinius guys did
> for the downloader.
> 
> Is there any other point of concerns I should think off? Any UI that
> will be broken by this? Also, any recommendation to properly fake this
> out?
> 
> This affects mostly binary gems or jruby ones that bundle big .jar files in it.
> 
> Thank you for your time and looking forward your comments.
> -- 
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exupéry
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers



More information about the Rubygems-developers mailing list