After poking around the Shoulda code I ended up writing my macros like this:

# Sets the current person in the session from the person fixtures.
def logged_in_as(person, &block)
  context "logged in as #{person}" do
    setup do
      @request.session[:person] = people(person).id
    end

    merge_block(&block)
  end
end

thanks fousto@me.com

Error: Port ruby1.9 not found

:D

install: you may need to run ldconfig

Unless you’re on a cell phone or something. If that’s the case, let me know whether Rubinius works on a cell ;-)

Ha! Good to know, thanks for the pointer :-)

Another one of those pro tips: for any non-compiler development activities you can currently set the environment variable SYDNEY (i.e. SYDNEY=1 bin/rbx … etc.) It should yield a moderate speed boost. (Sydney is the C parser, whereas the default is to use RubyParser which is currently still a bit slower.)

I just noticed the last post on your site is about macports. I’ll have to check it out after work :-)

Funny, a few minutes ago I wanted to use wget and I don’t have it installed at the moment. I realized I wouldn’t mind using port for small things like that ;-)

I’d love a quick primer on how to deal with the Macport issues, actually.

The doc didn’t seem too clear to me last time I checked. I’d just like to know what clutter I can remove when an install fails, what file to update to fix a build and finally how to contribute that fix.

Are you aware of any good tutorial? OTOH I don’t want to spend an evening going through all of their doc ;-)

But I understand your reasoning.

LOL @ tada.wav :-)

I’m trying to minimize my use of Macports now. It’s actually not installed on my new machine.

On my previous machine, half the time when I used port, it would end up failing to build a dependency or something. I never found an obvious way to fix these problems and never really investigated further either. So the blame is probably half on my side.

What I like about building my own is that the day the next version comes out, I can go back and build it myself and not wait for the macport update. Also, by using the “industrial strength” approach described briefly in the article, I can actually have an arbitrary amount of rubies installed in parallel.

These reasons may seem a bit shallow, but I guess I just like to have a better understanding and complete control over how the stuff is installed on my machine. :-)


$> port search ruby19
ruby19 lang/ruby19 1.9.1-preview1 Powerful and clean object-oriented scripting language


sudo port install ruby1.9

Tada.wav

Regards,

Dan

I’ve had much better luck just installing from the tarball.

@Lindsay Thanks for the link. As for building rubygems I’d have to agree with Radarek, however. Either for building a server or setting up one’s main machine. If you “build” Rubygems (it’s just Ruby, so it’s basically an install), afterwards it can update itself with the command mentioned in the article. Which lets you be as current as possible as soon as something’s available. The Ubuntu team and other distros do an awesome job, but they also have a lot on their plate, so updates are often trailing a few weeks/months behind, depending on the visibility of the project.

For most other things I usually go with what the distro provides though. But I still think there’s something to be said about building most of what’s public-facing on one’s server. It lets you react instantly if a vulnerability gets out (and gets fixed).

As for your point about the distro clobbering something you built, I somewhat agree. If you install rubygems and a few gems from the repo after building it, there will probably precedence problems. On the other hand Ruby is not installed by default for the moment, so we know nothing in the base system depends on it. At least for the time being…

If your distribution has a package manager you should use it. Heaven knows what stuff you install from source will conflict with your distribution’s updates. Also, you get security updates and bugfixes for free.

The Brightbox repo has RubyGems packages that are updated really frequently.

“1.9 was the default on 8.04 iirc”. No it wasn’t. 1.9 currently isn’t stable to include it as default package on any platform.

Brightbox maintain an Ubuntu PPA of updated Ruby packages including RubyGems. You can find instructions on setting up the repo at https://launchpad.net/~ubuntu-ruby-backports/+archive

As a bonus, you can find an Ubuntu-ready Passenger package in the repo too!

Most excellent! I admit I should have done that myself ;-)

http://rubyforge.org/tracker/index.php?func=detail&aid=22602&group_id=5650&atid=21859

Regards,

Dan

Yeah, our path with woulda is to be a bit of a catch-all for good shoulda macros, but also a proving ground for other macros before they’re sent upstream. For instance, the paperclip macro that started in woulda is now in paperclip. The gem should change in this manner quite a bit over time.

OTOH since it’s pretty new, of course it could be a good fit to go through woulda first.

I’ll send you a pull request as soon as I can. But first I’ll have to figure out a way to test a few more code paths.

http://github.com/seanhussey/woulda/tree

It’s one of the freely available ones for WordPress. The bottom of the page lists the two main culprits.

I edited your comment to properly show the double dashes.

I hate WordPress for that ;-)

I have the habit of working in a directory per project (be it an article or a mini code project). So I create one repo per project.

Note that I don’t necessarily push them to a remote server. I’m only talking about using git as a powerful local undo button :-)

@Brian

Wow, cool trick :-) My bash skills are not high enough for me to pretend I understand all of that little script. But I’ll definitely give it a try. Thanks!

If you want to add something to your local repo’s .gitignore, you can create an alias which will make it easier:

git config −−global alias.ignore ‘!f () { local ignore_file=$( git rev-parse −−show-cdup ).gitignore arg; for arg in $*; do echo $arg >> $ignore_file; done; sort -u -o $ignore_file $ignore_file; }; f’

Git will do tab-completion on the alias (provided you use git’s bash-completion, “git ig” will complete to “git ignore” for you), each argument will be appended to the .gitignore file (without you having to figure out the correct parent path), and the file will then be sorted and duplicates tossed.

Follow grb on GitHub: http://github.com/webmat/git_remote_branch/tree/master

Hope you are enjoying your summer thus far…

c’est sur je viendrais, je n’avais pu me liberer pour cette date. Entre ca et Montreal Python il y a des choses interessantes.

A bientot surement!

Rafraîchis ma mémoire: c’est bien à toi que j’avais parlé de Montreal on Rails? Si oui, j’étais bien déçu que tu ne viennes pas :-)

Je pourrai pas être présent au prochain événement, mais ça serait cool que tu viennes faire un tour un de ces 4… C’est plein d’autre monde intéressé à Ruby et Rails. Le groupe est vraiment cool.

Content de voir que ca va bien tes affaires,

git clone git@github.com:webmat/git_remote_branch.git
cd git_remote_branch
rake gem:gem
sudo rake gem:install

This gem works perfectly fine, that’s the version I’m using :-)

...
gem 'webmat-git_remote_branch', version
load 'grb'

The load command failed.
This week-end I think I’ll just post the gem to Rubyforge. This will make it easier until we figure out what the deal is.

I’m looking forward to chatting about how this is going. Unfortunately I’ll probably miss the next Montreal on Rails, due to a bit of vacation time :-)

Ahhh, life’s hard ;-)

clap-clap-clap… Félicitation!

Unfortunately, as a Mac heretic I don’t have a Tk implementation that allows me to interact much with Gitk, as opposed to Linux users. I can copy/paste the SHA ID, click the buttons / select the combo boxes, but I can’t right-click anything. Well, I can, but nothing happens ;-)

Now if only an approximate equivalent to TextMate could appear on Linux…

An example of Felix’ trick:

gitk [--all] <lost_commit_id>

git-fsck –lost-found
gitk [--all]

Right-click, “make branch” -> same as git-checkout -b something

In fact I had a sneaking suspicion that this may be the case. Maybe due to Git itself or to GitHub. Although from what I can see, Git seems to have a correct 755 mode for the file.

I’ve been extremely busy in the last few days and couldn’t spent any significant amount of time trying to get to the bottom of it. I should have time to nail this down towards the middle of next week.

I also have the RubyForge project approved so this should simplify the installation greatly by having g_r_b on the default gem server and this may help me avoid the problems with GitHub’s server (if it is due to it).

For example, I had this same permission issue happen to the defunkt-github gem.

In fact I made an alias md=’mkdir’. But I am under OS X, yes. I’ll fix the typo…

I’ll keep you posted!

But it’s my first gem, so maybe I made a n00b mistake somewhere along the way :-)

I’ll check it out.

$ grb -h
/opt/local/bin/grb:19:in `load’: no such file to load — grb (LoadError)

I’m not sure what went wrong, but the grb script in the gem’s bin directory was not world readable:

$ ls -l /opt/local/lib/ruby/gems/1.8/gems/webmat-git_remote_branch-0.2.2/bin
total 8
-rwx-wx-wx 1 root admin 446 Jun 23 17:17 grb

Chmod’ing it to be world readable fixed the problem

$ sudo chmod 777 /opt/local/lib/ruby/gems/1.8/gems/webmat-git_remote_branch-0.2.2/bin/grb

@Rory and Anon: I’ll be posting more about Git shortly. I’ll revisit both your suggestions while I’m at it.

[...]A walkthrough to recovering from most kinds of bad situations you can get into with Git, the revolutionary version control system. With cameos by ninjas and motocrosses![...]…

One tip I always give to avoid getting in situation like this is to always run git status between commands. It’s a nice habit to get into and the output is generally more helpful than the git error/warning message.

I checked the docs about the dangling commits. I think if you ran git prune before gc, it would have removed them. git gc runs prune but keeps commits for 30 days. Then it packs the repository, and according to the prune doc, packed commits do not get removed. That’s my guess.