03:12 <Whan> salve

03:12 <Whan> !list

03:12 <Whan> ciao

08:51 <robin_alm> Does merb have to reload itself every time I save a change to a model/controller? In rails I can just reload in a browser quickly without having to wait

09:05 <merboutpost> robin_alm: turn on template and class reloading...

09:12 <robin_alm> merboutpost: They are turned on. It seems that every class in the app is reloaded whenever I save though, which takes down my development server for a few seconds each time I save

09:18 <merboutpost> robin_alm: depends on your hardware, reloading is done with forking (don't know how rails does it, natively). Which is really fast. I don't think that works on Windows though. If you're on windows it reloads using ObjectSpace which is slow.

09:19 <robin_alm> merboutpost: I'm on OSX, and it doesn't seem very fast. Maybe forking is not being used for some reason?

09:19 <merboutpost> robin_alm: What ruby and merb versions you use?

09:20 <robin_alm> 1.8.7 and 1.0.11

09:29 <merboutpost> hm... on my mac os x, it was usually almost instant even with just saving couple of times a second

10:42 <snusnu> yo merboutpost, just had to do http://github.com/merb/merb_datamapper/commit/792bb1838d6a91347275b0570026f1c26ba49821 .. thought i'd let you know … as a side effect this means that rc1 gems are broken for dm :P

10:45 <merboutpost> snusnu: did you pushed to the rubygems?

10:46 <merboutpost> snusnu: I wonder why it didn't generate new gemspec, merb-auth gems seems to have similar Rakefile and dependencies were generated

10:46 <merboutpost> snusnu: sorry (having no project on DM) for inconvenience

10:48 <snusnu> merboutpost: no worries, i haven't yet pushed to gemcutter, no .. i guess we'd need to bump to rc2 for that now, don't we?

10:48 <merboutpost> snusnu: ah, grrrrrrrrrrr!

10:49 <merboutpost> snusnu: it should be possible to do gem yank merb_datamapper.... and gem push... (I hope). These are new features of rubygems.org I havent tested.

10:50 <merboutpost> snusnu: but yank should be there for this reason (it hides the version)

10:50 <snusnu> merboutpost: interesting, never tried that either

10:50 <merboutpost> snusnu: don't know if it allows to re-push when gem is yanked, though :-(

10:50 <merboutpost> snusnu: I definitely don't want to push rc2 :-(

10:51 <snusnu> merboutpost: any particular reason for that?

10:51 <merboutpost> snusnu: there are no changes in anything than just the Rake file of one gem.....

10:52 <snusnu> merboutpost: yeah, but if we can't work around it with yank or whatever, then i guess we have no other option, and really, it's not that bad imho, i see how it "looks weird" but i can totally live with that :P

10:54 <merboutpost> snusnu: if there's no other way, than obviously we need to go for it

10:54 <snusnu> merboutpost: we could go rc2 only for merb_datamapper .. but that's kinda weird too … i "hated" rspec when rspec-rails beta number was different from all other rspec gems (now they aligned it to be the same for all rspec gems)

10:55 <merboutpost> snusnu: well I don't mind gems outside the github.com/merb/merb have independent version nubmers.

10:55 <merboutpost> snusnu: merb_sequel, merb_cucumber has that

10:55 <merboutpost> snusnu: they also depend on merb 1.0.0

10:55 <snusnu> merboutpost: that's a good point

10:56 <merboutpost> snusnu: and not on 1.1.0.rc1 because there is no need

10:56 <snusnu> merboutpost: huh? they depend on a non existing version?

10:56 <snusnu> warrgh my mistake :P

10:56 <merboutpost> snusnu: well on 0.9.9 or something

10:56 <snusnu> read that as 1.1 obviously :P

10:57 <merboutpost> snusnu: I think that it should not be necessary to re-push gems which are "independent" of merb/merb when we dump merb/merb version....

10:59 <snusnu> merboutpost: yeah that's true, it's just feeling a bit weird that one gem has a different number, but really, that's no problem at all

10:59 <snusnu> merboutpost: btw, i like how you say "dump" the version :P

11:00 <snusnu> merboutpost: then i'm gonna "bump" merb_datamapper to 1.0.0.rc2 later on today :P

11:00 <merboutpost> snusnu: I read that in gemcutter channel :-)

11:00 <snusnu> heh

11:02 <merboutpost> snusnu: what non pre version of the merb_datamapper you have?

11:03 <merboutpost> snusnu: 0.x? or 1.x?

11:03 <snusnu> merboutpost: no idea :P

11:03 <merboutpost> snusnu: I think unless you git yank 1.1.0.pre version 1.0.0.rc2 would be "older" than 1.1.0.pre

11:05 <snusnu> merboutpost: i have to take a look at that later on today, too busy atm .. i guess it's not just a matter of bumping merb_datamapper .. merb will need updates too, (merb-gen etc)

11:05 <namelessjon> merboutpost: sinatra 1.0.b is newer than 1.0.a

11:06 <merboutpost> namelessjon: I know but sinatra 1.1.a is not newer than 1.0.b

11:06 <namelessjon> merboutpost: Oh, I missed the 1.0.0 in the rc2

11:07 <merboutpost> namelessjon: actually sinatra 1.1.a is still newer than 1.0.b :-)

11:07 <snusnu> ok, so *i'm* missing something … "r" comes after "p" .. so rc's should be newer than the pre's ?

11:07 <merboutpost> snusnu: you wrote you want to push merb_datamapper 1.0.0.rc2

11:08 <merboutpost> snusnu: which will be "older" than 1.1.0.pre

11:08 <* snusnu> is confused

11:09 <snusnu> if sinatra-1.0.b is newer than 1.0.a .. why is 1.0.0.rc2 not newer than 1.0.0.pre ?

11:10 <merboutpost> snusnu: that's correct. But latest merb_datamapper version is 1.1.0.rc1

11:10 <merboutpost> snusnu: more 11111111

11:10 <merboutpost> snusnu: 1.1.0 != 1.0.0

11:11 <snusnu> lol, i'm seriously mixing up numbers … of course i want to push 1.1.0.rc2 :P

12:09 <merboutpost> snusnu: what updates you wanted for merb? (you mentioned merb-gen)?

12:10 <snusnu> merboutpost: i think a merb-gen'd app would need to reference merb_datamapper-1.0.0.rc2

12:10 <snusnu> merboutpost: currently it'd use rc1

12:11 <merboutpost> snusnu: ah.. ok

12:11 <merboutpost> snusnu: makes sense

12:41 <jonuts> woah, im trying to upgrade an app to 1.1 and active_support is being required(??) and messing everything up. is that a merb thing?

12:44 <merboutpost> jonuts: I can't grep any place which would require active support....

12:46 <jonuts> merboutpost: yeah, false alarm i think. sorry

12:47 <jonuts> although i have no clue where its suddenly coming from

12:47 <merboutpost> jonuts: :-) Some of dependencies probably, more and more people is adopting ActiveSupport 3

12:47 <merboutpost> jonuts: datamapper?

12:48 <merboutpost> jonuts: they thought about switching to AS3

12:49 <namelessjon> jonuts, merboutpost: It isn't in release gems, yet.

12:49 <jonuts> merboutpost: dont think its dm. i generated a new app and its not there

12:55 <jonuts> found it. it was from a different gem that needed upgrading. blerg, this is gonna be fun

13:19 <merboutpost> jonuts: it should not be that much pain, if you don't upgrade to 1.9.1 in one run as well :-)

13:22 <jonuts> merboutpost: heh, yeeeeeeeah.. that was the plan as well :P

13:22 <jonuts> maybe ill try this in baby steps

13:45 <merboutpost> jonuts: I did when the 1.9.1 was out

13:45 <merboutpost> jonuts: that was pain, most gems failed

13:45 <merboutpost> jonuts: but now it's doable

13:49 <jonuts> merboutpost: yeah, i know all about that. this is, i believe, my 5th attempt at getting this app on 1.9. i finally have all gems accounted for, except for this stupid one that went ahead and added activesupport as a dependency

13:53 <jonuts> merboutpost: hrm, actually, do you know anything about the way bundler loads gems?

13:58 <merboutpost> jonuts: not much, just integration stuff when we did it.

14:00 <jonuts> merboutpost: do you know if there is any way to make sure code is executed after the gem is loaded?

14:01 <jonuts> the old style depedencies used to take a block

14:01 <merboutpost> jonuts: yes after_app_loads bootloader

14:01 <jonuts> but i dont think bundler does

14:01 <merboutpost> jonuts: no you need to do it in the Bootloader hook, or I beleive I've patched it so you can do it in init.rb

14:01 <merboutpost> jonuts: let met check

14:01 <jonuts> merboutpost: i need the code to be called after gem a is loaded and before gem b

14:03 <merboutpost> jonuts: ah :-)

14:04 <merboutpost> jonuts: I don't know that would be possible now, because all is handled in the Gemfile.

14:04 <merboutpost> jonuts: unless Bundler supports it.

14:06 <jonuts> merboutpost: yeah, thats what i'm trying to figure out. it doesn't look like it supports it, but i was hoping you would tell me otherwise :)

14:09 <merboutpost> jonuts: what you need it for? Merb::Cache?

14:10 <jonuts> merboutpost: garb. its the library i was talking about before that added in activesupport as a dependency

14:12 <jonuts> merboutpost: i was using a hack in dependencies.rb to keep it from clashing with dm (both overload methods on Symbol)

14:13 <merboutpost> jonuts: ah now I get the full picture :-)

14:13 <jonuts> merboutpost: if i can keep the hack, i can keep the old version (with no activesupport)

14:14 <merboutpost> jonuts: no idea, other than patch Bundler to support it ;-)

14:15 <jonuts> merboutpost: heh, probably the best option. it makes sense to have that functionality in bundler, right?

14:22 <felipec> hi, I'm trying to run my merb app automatically with apache in a sub-uri, but I can't find how to do it

14:23 <felipec> I end up with: The directory "/var/www" does not appear to be a valid Ruby on Rails application root.

14:23 <felipec> (with passenger)

16:04 <felipec> how do I tell merb that the root of the app is /foo ?

16:05 <merboutpost> felipec: ./merb --help

16:07 <felipec> merboutpost: there's nothing there

16:07 <merboutpost> felipec: :-))))) -m, --merb-root /path/to/approot The path to the Merb.root for the app you want to run (default is current working directory).

16:07 <merboutpost> felipec: really! don't think so

16:07 <felipec> merboutpost: that's not what I want

16:08 <merboutpost> felipec: you want URL?

16:08 <felipec> merboutpost: yeah

16:08 <merboutpost> felipec: path_prefis

16:08 <merboutpost> path_prefix

16:11 <felipec> doesn't seem to work =/

16:12 <felipec> Merb::Config.setup(:path_prefix => "foo")

16:12 <felipec> ?

16:14 <merboutpost> felipec: no you need to have it in router :-)

16:14 <merboutpost> felipec: if you want to have this for urls

16:14 <merboutpost> felipec: http://wiki.merbivore.com/howto/router

16:15 <felipec> merboutpost: right, I just found about it... but still doesn't work

16:15 <felipec> slice(:merb_auth_slice_password, :name_prefix => nil, :path_prefix => "insanity")

16:16 <felipec> but actually that url doesn't mention path_prefix

16:22 <merboutpost> felipec: I was wrong

16:23 <merboutpost> felipec: it seems you should add it to the init to your config because : Merb::Config[:path_prefix] + uri if Merb::Config[:path_prefix]

16:23 <merboutpost> felipec: co in your init.rb add c[:path_prefix] = 'insanity' and you shoyuld be done

16:25 <felipec> merboutpost: nope, nothing different

16:26 <merboutpost> felipec: what version of merb you use? Also paster init.rb

16:26 <jonuts> felipec: what are you trying to do?

16:26 <merboutpost> paste init.rb

16:27 <felipec> jonuts: setup my merb app in a suburi, like localhost/app

16:28 <felipec> merboutpost: 1.0.15

16:29 <felipec> merboutpost: http://pastie.org/871177

16:32 <merboutpost> felipec: looks, right, I grepped the 1.1.0.rc1 source though

16:33 <merboutpost> felipec: so don't know if it's in 1.0.15 working the same way

16:35 <namelessjon> I don't think that's been touched in a while.

16:37 <felipec> all I want is my app to start automatically with the system, so I thought I would setup merb with apache, but so far it has turned impossible

16:37 <felipec> first I had many problems with passenger, finally I managed to workaround some includedir problem

16:38 <felipec> now that passenger seems to start merb correctly, everything is redirected incorrectly

16:38 <felipec> I see sites mentioning path_prefix for sub-uris, but not how to set it

16:41 <felipec> I keep getting Controller class not found for controller `insanity'

16:41 <jonuts> felipec: try with c[:path_prefix] = '/insanity'. that seems to work for me

16:42 <felipec> jonuts: aha!

16:42 <felipec> yeah, that works

16:42 <felipec> but apparently the stylesheet is not prefixed

16:43 <namelessjon> felipec: How do you include the stylesheet?

16:43 <felipec> easy to fix, though

16:44 <felipec> jonuts: thanks!

16:44 <felipec> namelessjon: the default: <link rel="stylesheet" href="/insanity/stylesheets/master.css" type="text/css" media="screen" charset="utf-8" />

16:44 <felipec> how would I grab the path_prefix from there?

16:46 <felipec> ah, Merb::Config[:path_prefix], it seems

16:46 <namelessjon> felipec: try 'require_css "master"', if you're using merb assets.

16:49 <felipec> namelessjon: that doesn't work, so I suppose I'm not using merb assets

16:55 <felipec> hmm, same problem with /images

16:56 <careo> * merb-core (= 1.1.0.pre, runtime) required by merb_datamapper (= 1.1.0.rc1, runtime)

16:56 <careo> d'oh

17:04 <merboutpost> careo: My mistake yeasterday. I didn't checked the regenerated gemspec and for some reason it didn't regenerated the dependencies.

17:04 <kenphused> congrats to the merb team for 1.1 rc1

17:04 <kenphused> ... and thanks!

17:04 <merboutpost> careo: snusnu already did the patch in the gitrebo

17:04 <merboutpost> kenphused: thx

17:05 <merboutpost> careo: problem is that we can't now repush releases as we did with 1.1.0.pre because it's not allowed now by rubygems.

17:05 <merboutpost> careo: so snusnu will push merb_datamapper 1.1.0.rc2

17:06 <careo> merboutpost: yup yup. I saw the fix and just had bundler use the git repo

17:06 <* careo> does a happy dance after seeing "Your bundle is complete!"

17:06 <merboutpost> careo: cool!

17:06 <careo> yes. major kudos and thanks to all involved!

17:07 <merboutpost> careo: I did moved yeasterday with one of my apps to 1.1.0.rc1 and Unicorn... sweet to see the whole cluster been replaced with the Unicorn :-)

17:07 <careo> merboutpost: hehe nice

17:07 <careo> yeah, I'm upgrading merb as part of a grander move to async thin or rainbows

17:07 <merboutpost> careo: its much much stable than merb cluster of thins

17:08 <merboutpost> careo: I was able to kill the merb cluster of thins with "ab -n1000 -c5", now it just happily serves requests :-)

17:10 <careo> merboutpost: yeah.

17:10 <careo> merboutpost: it's really the concurrency models of rainbows! I'm after. but all the other sexy unicorn kit is appealing too

17:11 <careo> all it took to get a rough asymc merb 1.0.10 going was a quick patch

17:11 <careo> async

17:13 <merboutpost> careo: rainbows looks nice,

17:14 <merboutpost> well good night for today

17:48 <careo> has anyone seen this with a freshly generated app: uninitialized constant DataMapper::Serialize::Model

17:48 <careo> from rake?

18:29 <careo> ahh. bundler 0.9.7 is the answer, not the latest.

20:08 <careo> has anyone come across this before: undefined method `request' for #<Webrat::MerbAdapter:0x10296e620> ?

20:08 <careo> I'm attempting to upgrade to 1.1

20:24 <careo> snusnu: does this wring a bell by chance? undefined method `request' for #<Webrat::MerbAdapter:0x1026379c0>

20:24 <snusnu> careo: sorry, never saw it

20:28 <careo> are you using request specs at all?

20:30 <careo> brb

20:30 <careo> well. in a few

22:26 <careo> ah. webrat version problem

22:26 <careo> 0.7.0 doesn't do it 0.5.something did.

22:26 <careo> 'night