Mirrored here.

gemstones glow !! fleeting response !! velvet-like goosebumps !!

yay!!

It br0ked my Rails. :-(

Rails now asks “What is this logger you speak of?” to which I cannot reply… :-(

Mister Cat, blame the clean_logger.rb file under activesupport (which may have come from Nitro – I’m not sure who was first).

Anyway, that whole file is an abomination and should be burned before its infection spreads, it’s ashes scattered across the ocean to prevent it from ever reforming again.

The good news is that I’m pretty sure this can be fixed in a backwards compatible way.

Good news, indeed. Except that rubygems still isn’t included. That needs to happen soon.

Matz is really cookin, guys! We’re cruising through bugs in Basecamp. Matz did the honorable thing and followed his roadmap precisely. (Bow.)

So where’s the changelog? Why should I care? Huh? Huh?

Was this announcement sent to the ruby-talk list? It’s not a big deal, I may have just missed it, what with all of the messages about the “Ruby Troll” in comp.lang.perl.misc clogging up my mailbox.

Most excellent. Hopefully it will build on HP-UX. I need it.

For work. Yeah.

Does anyone know why rubygems isn’t included (yet)?

Matz has just noted 1.8.4 milestones in Basecamp. API freeze on December 1st. Release on December 24th.

_why: Where can we see the 1.8.4 milestones in Basecamp? Is there a URL ? Is rubygems included?

Hopefully the Debian Ruby guys won’t get too put off by the current bunfight over on ruby-devel….I’ve just got comfy on etch, don’t fancy moving again for a few weeks at least..

rasputnik: Well, since I’ve just updated Ruby to 1.8.3 this morning on my Unstable Debian box, it seems they didn’t ;) . And then they say Debian takes forever to repackage things ;) .

And I have to say I agree with the Debian maintainers here more than with the Rubygems people (the Debian package system saved me countless times already, when I broke things by being too enthusiastic with my Unstable Debian Box). Making Rubygems standard as it is now would be wrong. But my opinion on this issue is already known . Make it transparent, and then only it will be a good candidate to become part of the standard library.

Tsela, RubyGems doesn’t need to support Debian. It needs to support Ruby, which universe is larger than just Debian, despite what Debian bigots like to think. I, for one, am quite glad that RubyGems doesn’t bow to Debian snobbery.

Austin: you might have noticed that I don’t mention the point you make. I don’t care if Rubygems support Debian or not (I do care when it actively makes it difficult to repackage things though, because if you followed the thread on ruby-dev you might have noticed that other people have problems, and are not Debian people. That’s what I was referring to when I was saying that I was inclined to agree with the Debian people there).

What I care about is that a package manager should be transparent. It shouldn’t matter whether a library has been installed through the package manager of my distro, manually through setup.rb or through Rubygems. Rubygems isn’t transparent, and instead forces its presence to the developer. That’s what I don’t agree with. First solve that problem, and then it can be put in the standard library.

Will RubyGems be included in 1.8.4?

Wait, so would apt be able to manage a package that RubyGems installed?

I’m confused, how transparent are all the various package-managers?

Danno: they’re not, and Tsela is complaining about a non-problem. RubyGems, when incorporated into the Ruby core, will be completely transparent. This has been the plan from day one, and people complaining about the lack of transparency (e.g., require_gem, require ‘rubygems’) have pretty much not understood that these are all temporary hacks. PDF ::Writer does not have anything special in it to support RubyGems, but instead depends on the user to have RUBYOPT =rubygems set or run ruby with -rubygems. That’s about as transparent as you can get until Ruby’s default require understands the RubyGems installations.

If some obscure arguments over Debian are what’s keeping RubyGems out of the std Ruby distro, then that’s really wrong. The vast majority of us don’t run Debian – most of us are on OS X , Windows, or other Linux distros (I personally run OS X and Gentoo). Why is some small group (probably less than 5%) holding up RubyGems goodness? Come on, get some perspective! Get on the RubyGems train, or get out of the way!

I really don’t care about some obscure problem with Debian. Let the Debianites deal with it. Personally, I use RubyGems instead of Gentoo ports for all my Ruby package needs, why can’t these Debianistas do that as well?

If these Debian people are having so much trouble, mabye they should switch from apt to RubyGems themselves. Maybe RubyGems could be used as a Linux package management system as well?

The Identicon is pissed!

Does anyone actually have data indicated what the distribution of systems running Ruby looks like? (Not linux distribution)

I primarily use debian; but end up building ruby & perl separately from source (and install in /usr/local) just to have the cpan and rubygems be the primary sources for those packages. I’d be quite happy if rubygems made it into core ruby.

Any ETA on the Windows all-in-one for 1.8.3?

I’m interested to see how this works

Brian, because of several problems with 1.8.3, I am hoping that Curt waits until 1.8.3.1 or 1.8.4 before doing the next release of the Windows all-in-one.

Thanks, Austin. I am pushing very hard to get some of our projects onto Rails (from J2EE ), and we are dotting the i’s and crossing the t’s on everything. Personally, I’m a Tiger developer myself, but we have a few holdouts :)

Yay, Rails broke. Two minutes browsing through rails bugs and I found a patch. Wonderful.

Anyway, rubygems (from source) is pretty weird in Debian: gem scripts and installed rubygems go in /usr, rubygems classes go in /usr/local. Personally I’m not going to reinstall the thing until they all go in /usr/local like God intended. If Perl’s CPAN module can do it right, I expect a supyeerior programming language to do at least the same!