00:36
thewoolleyman joined
02:30
thewoolleyman joined
04:06
hipertracker joined
06:27
<g0bl1n>
Hi, <%= select :birth_day, :collection => (1..31).each { |d| << [d,"#{d}"] } %>
06:27
<g0bl1n>
this doesn't work
06:27
<g0bl1n>
what is the best approach ?
06:28
<merboutpost>
g0bl1n: collection needs to be [[],[]]
06:28
<g0bl1n>
but I'd like to automate it
06:28
<g0bl1n>
since I'll need to insert much greater values
06:28
<merboutpost>
g0bl1n: so (1..31).map {|d| [d,d.to_s] }
06:29
<merboutpost>
g0bl1n: read difference between map/each
06:29
<g0bl1n>
ty merboutpost
06:30
<merboutpost>
g0bl1n: how it works is that the select helper calls first/last on the element
06:30
<merboutpost>
g0bl1n: so [] responds to first/last, but any object which respond the same can be element of the collection
06:32
<merboutpost>
g0bl1n: also if you have collection of objects, you can actually define, what methods will be called on element, for example if you have collection of Objects with #name and #id you can say call these instead of first/last
06:33
<g0bl1n>
rereading this last one :)
06:35
<g0bl1n>
ty merboutpost sweet, working nice !!
07:40
<merboutpost>
namelessjon: there are no specs for Merb::Config
07:51
<hcatlin>
this 1.1rc1
07:52
<hcatlin>
can we get that via gems?
08:01
<merboutpost>
hcatlin: hi
08:01
<merboutpost>
hcatlin: do you use DataMapper?
08:01
<merboutpost>
hcatlin: I made mistake and merb_datamapper depends on the pre still
08:01
<merboutpost>
hcatlin: but otherwise you should be able to do gem install merb-core (and friends) --pre
08:01
<merboutpost>
hcatlin: and get rc1
08:02
<merboutpost>
hcatlin: rc2 will deliver bug fixes
08:07
<hcatlin>
wait, 1.1rc1 is just... what's been going on in master for a while, right?
08:08
<hcatlin>
we really, really, really want this to be out as 1.1.1
08:08
<hcatlin>
(speaking as wikipedia)
08:08
<hcatlin>
its causing my sysadmins to get really pissed at me
08:08
<hcatlin>
puppet doesn't understand "--pre"
08:11
<hcatlin>
merboutpost: rc2 will do *more* bugfixes?
08:11
<merboutpost>
hcatlin: yes
08:12
<hcatlin>
any chances in not using the --pre bit anymore? :)
08:12
<hcatlin>
or not really
08:12
<hcatlin>
using that wonderful 3rd version number that we don't use
08:12
<merboutpost>
hcatlin: well I wanted to push 1.1.0 instead of rc1 :-)
08:12
<hcatlin>
who disagreed?
08:12
<merboutpost>
hcatlin: and get rid of --pre and do other releases with 1.1.1 ...
08:13
<hcatlin>
well, me and my 20 million daily hits on merb agrees
08:13
<hcatlin>
(does that count like votes?)
08:13
<merboutpost>
hcatlin: :-)
08:13
<merboutpost>
hcatlin: What version are you running currently?
08:14
<hcatlin>
a custom build of 1.1.0.pre
08:14
<hcatlin>
i built my own release
08:14
<hcatlin>
its using bundler
08:14
<hcatlin>
however, in attempting to get this in a scalable state
08:14
<hcatlin>
(aka, where we can comission servers)
08:14
<hcatlin>
bundler doesn't work with 1.3.5 gems... so i'm SOL
08:15
<hcatlin>
(debian addicts)
08:15
<hcatlin>
so now we are having to manually do gems
08:15
<merboutpost>
hcatlin: I use 1.3.5 and bundler 0.9.7 and 1.1.0.rc1 on Ubuntu
08:15
<hcatlin>
wait, i thought bundler required 1.3.6?
08:15
<merboutpost>
hcatlin: that works, later versions of the bundler requires that not that one particular version I stop on
08:16
<merboutpost>
hcatlin: ubuntu doesn't have 1.3.6 packages and my sysadmis would kill me if I'd install rubygems from source
08:17
<hcatlin>
i am sending my sysadmin in here
08:17
<hcatlin>
do you have a second to discuss it?
08:17
<merboutpost>
hcatlin: if you don't need some features from Bundler > 0.9.7 you can happily live with the Bundler 0.9.7
08:17
<merboutpost>
hcatlin: yep.
08:17
<hcatlin>
it uses the same directory structure
08:18
<merboutpost>
hcatlin: so did you made any changes for the merb 1.1.0.pre (like any patches you'd like to see in rc2) ?
08:18
<g0bl1n>
hcatlin, are you from Yellow Pages ? 20M daily hits :-O
08:18
<hcatlin>
wikipedia
08:18
<merboutpost>
hcatlin: they changed directory structure changed only in 0.8.x -> 0.9.x AFAIK
08:18
<hcatlin>
merboutpost: no, but we do have an ugly workaround for some routes stuff
08:19
<merboutpost>
hcatlin: I found that mutex was always off :-)
08:19
<hcatlin>
if you look at the show action
08:19
<hcatlin>
the first two ifs deal with things we can't do in routes
08:19
<merboutpost>
hcatlin: grr... use_mutex == true all the time
08:20
<hcatlin>
wait, would that fix this?
08:20
<merboutpost>
hcatlin: no, just that merb did locked currently in 1.1.x and other versions.
08:20
thewoolleyman joined
08:20
<merboutpost>
hcatlin: it ignored c[:use_mutex] = false settings...
08:22
<merboutpost>
hcatlin: ahh... I remember some debate about the // in the urls
08:26
<merboutpost>
hcatlin: not sure if I understand completely the second if but that should be possible with the deferred routes
08:30
<namelessjon>
merboutpost: s/shuld/should/ Other than that, any idea why the original location was failing?
08:32
<snusnu>
merboutpost: that's really it :P? i mean, it may very well be … have no chance to really test atm i'm afraid :/ .. it'd be most awesome to have that fixed tho, fo sure
08:36
<merboutpost>
namelessjon: yes
08:37
<merboutpost>
namelessjon: because classes are loaded before the Configuration is loaded. And because that previous location was class scope it as set when classes were loaded
08:38
<namelessjon>
merboutpost: Ah, of course.
08:39
<merboutpost>
namelessjon: I first moved that to the Dispatcher#handle but it's waste to do assignment every time
08:39
<merboutpost>
namelessjon: I think that in the setup of the configuration is right place. Since it really involves configuration.
08:40
<merboutpost>
namelessjon: also if you checkout the specs I made.... You may wonder why the examples are wrapped in the lamba {}
08:40
<namelessjon>
merboutpost: Yeah, I can't think of why you'd want to change the option in a running app.
08:42
<merboutpost>
namelessjon: Merb.start_environment setups... well whole environment and that's kind a global. So lambdas{} makes it local to the example.
08:44
<namelessjon>
merboutpost: That's a nice trick :)
08:48
<snusnu>
merboutpost: so, wouldn't that fix warrant an rc2 :P … yeah, i'm lazy, and don't want to adapt merb-gen for different merb/merb_datamapper version numbers :)
08:49
<merboutpost>
namelessjon, snusnu: Probably, I'm working on more fixes
08:49
<merboutpost>
namelessjon, snusnu: hcatlin wanted to push 1.1.0, --pre cause sysadmin headaches
08:49
<snusnu>
merboutpost: awesome, really nice that you found more time to work on merb again
08:51
<snusnu>
merboutpost: yeah, i skimmed over the conversation .. i agree, 1.1 should get out, and then it's time to leverage the patch level .. pre should mostly be for convenience .. and looses more and more importance to me, with bundler working nicely with git repos .. that may just be me tho
08:57
<merboutpost>
snusnu, namelessjon: +1 to push 1.1.0
08:58
<merboutpost>
and do fast and plenty of 1.1.x :-0
09:09
<namelessjon>
merboutpost: +1. Do we have release notes? Or at least "Stuff that broke/changed from 1.0.x to 1.1.x"?
09:12
<merboutpost>
namelessjon: that's the biggest tricky part :-(
09:13
<merboutpost>
namelessjon: I know snusnu put something together. Maybe some git log magick could help
09:24
<namelessjon>
merboutpost: If people have been good with commit messages, yeah :)
09:25
<namelessjon>
merboutpost: /me has a play
09:31
<namelessjon>
merboutpost: Wow, 309 commits. (with some dups in there)
09:32
<merboutpost>
namelessjon: yep its more than year :-)
09:33
<merboutpost>
namelessjon: maybe when we dump that & filter dups. And than go through it some major commits will pop up so we can write more about them. Others we can include just as CHANGELOG
09:34
<namelessjon>
merboutpost: Yeah, I'm playing with git-log opts to filter out as many as I can.
09:39
<snusnu>
merboutpost: yeah, i remember that :)
09:44
<namelessjon>
man, we must have some confused history and merges. ^^;
09:45
<merboutpost>
namelessjon: I did. I pushed 2x my master instead of official
09:46
<merboutpost>
namelessjon: that resulted in the good code but messed up history
09:49
<namelessjon>
merboutpost: Ah. Also, I have to go out now. bbl.
09:50
<merboutpost>
namelessjon: ok, no prob.
09:58
<merboutpost>
namelessjon, snusnu, careo: Anybody knows about multipart/form-data parser in a GEM!
09:59
<merboutpost>
^^ Best would be C implementation really.
10:01
<snusnu>
merboutpost: isn't there rack-param parser or something?
10:01
<snusnu>
merboutpost: oh wait, i dunno if that handles multipart stuff or if it was just about nested form params ...
10:02
<merboutpost>
snusnu: I'm fixing now multipart parsing in Merb and really it's a mess.
10:02
<merboutpost>
snusnu: it only will be slow, but also prone to errors. This should definitely be gem, most likely written in C!
10:02
<snusnu>
merboutpost: what about jruby?
10:02
<merboutpost>
snusnu: that's the reason I played with Nginx upload module which does multipart parting for you and not in merb
10:03
<merboutpost>
snusnu: well jruby would be kind a specific solution, how many people can host on jruby?
10:07
<snusnu>
merboutpost: i dunno, but probably quite some, with more to come
10:07
<snusnu>
merboutpost: anyhow, i'm not against a C impl .. i wonder if it's really necessary tho
10:08
<merboutpost>
snusnu: WTF!!! Rack has multipart parsing, and it suffers all the bugs which was fixed for merb! And it's almost the same code!
10:09
<* snusnu>
hates gems that check if rails or merb are present
10:09
<Tass`>
snusnu, like?
10:09
<snusnu>
only because they need to know an app root .. seriously, that's the only reason i came across so far
10:09
<snusnu>
dm-paperclip
10:10
<Tass`>
there should just be ROOT
10:11
<snusnu>
Tass`: i'm leaning towards a #root and #root= module accessor in the toplevel namespace (Paperclip in this case) .. that could be set by application initializers .. or fallback to: @root ||= (ENV['RAILS_ENV'] || ENV['MERB_ENV'] || ENV['RACK_ENV'])
10:15
<snusnu>
Tass`: i will patch dm-paperclip to work like that .. i can't stand all those conditionals that assume (only 2) of ruby webframeworks
10:16
<snusnu>
Tass`: lol .. i just realized how stupid my code above is .. assigning an ENV to a root :P
10:17
<snusnu>
Tass`: you get the idea tho … obviously that needs to be done for both env and root
10:17
<snusnu>
Tass`: the gems i mean (resque and paperclip) both need env and root iirc, i already patched resque and it was accepted .. now paperclip
10:17
<Tass`>
snusnu, heh, Rango.root :-)
10:18
<snusnu>
Tass`: yeah there's Rails.root and Merb.root too .. the thing is, if a gem needs to place something relative to the app root (or based on the app env) .. it shouldn't access these constants (imho) .. it should provide a way to tell it "its own root"
10:19
<snusnu>
Tass`: otherwise you always end up assuming one (out of possibly many) candidates .. like rails or merb in this example .. or even more, Rango,Ramaze,Waves .. whatever
10:20
<snusnu>
Tass`: imho "feature detection" is the wrong approach here as it assumes to much about the loadpath .. paperclip needs a root to anchor it's relative paths to? give it one
10:20
<snusnu>
Tass`: don't let it guess one
10:21
<snusnu>
Tass`: needless to say, bundler made the problem creep up (by not respecting Gemfile order, and imho rightfully so, but that's a different discussion :P)
10:25
<Tass`>
snusnu, yeah, heroku blew up due to that... had to make some hacks ;-)
10:25
<snusnu>
Tass`: on a related note … i hate gems that check for the presence of dm-validations .. seriously, who doesn't use them at all?
10:27
<snusnu>
Tass`: looking at tht gemfile .. i pushed fixes for all of dm-more yesterday to my AS branch .. so in case you use your fork because of this, you shouln't need to anymore, soon
10:28
<Tass`>
snusnu, AS? activesupport?
10:29
<snusnu>
3.0.0.beta1
10:29
<Tass`>
well, I'm using my branch due to validates_size ;-)
10:29
<snusnu>
ah right! :) sorry
10:43
<Tass`>
snusnu, you can merge that ;>
10:50
<snusnu>
Tass`: haven't had time yet to look closer at it .. it's about validation has 1..5, :things and such, right?
10:53
<Tass`>
snusnu, well, yes, you can do that too
10:54
<Tass`>
snusnu, it basically adds validates_size :citations, :max => 5, :min => 3, :within => (3..5) # if I remember the API correctly
10:55
<snusnu>
Tass`: ah ok, so that could be triggered with autovalidation of relationships too then?
10:55
<Tass`>
snusnu, correctly.
10:55
<snusnu>
Tass`: pardon my ignorance :P .. what part of the validates_size wasn't working before?
10:56
<snusnu>
Tass`: :min and :max?
10:57
<Tass`>
snusnu, it didn't exist at all ;-)
10:57
<snusnu>
Tass`: or have you "generalized the check" to take relationships into account … sorry, i should probably read the patch before talking about it, but i (think) i don't have time now :P
10:57
<snusnu>
Tass`: heh
10:57
<snusnu>
Tass`: i thought there was a validates_size already ...
10:57
<Tass`>
snusnu, didn't see it
11:16
<merboutpost>
snusnu, namelessjon: please review and +-1 :-)
11:21
<merboutpost>
snusnu: more verbose commit :)
11:21
<merboutpost>
snusnu: ok
11:27
<namelessjon>
merboutpost: The it "should" is still there?
11:27
<snusnu>
merboutpost: ah ok, more verbose message now i get it, but yeah, the "should" is still there :P
11:35
<merboutpost>
namelessjon: that is another commit (second) fixing multipart, the shuld in the first will be fixed in a minute
11:39
<merboutpost>
I think these patches justify to push rc2.
11:40
<namelessjon>
merboutpost: No, I meant in the spec in the multipart fix, the spec is 'it "should" do'
11:41
<merboutpost>
namelessjon: he, so I had mistakes in both specs :-)
12:07
<snusnu>
merboutpost: looks good, i'd probably elaborate a bit more on the :use_mutex issue, like, merb now actually *works* in threaded mode
12:08
<snusnu>
merboutpost: also, iirc i asked you that already some time ago .. but what does !!!BC!!!! mean?
12:08
<merboutpost>
snusnu: backward compatibility ?
12:08
<merboutpost>
snusnu: and !!!!! === break :-)
12:08
<snusnu>
merboutpost: ahh yes now i remember :P
12:09
<merboutpost>
snusnu: feel free to change whatever you want
12:09
<snusnu>
merboutpost: i'm lost in datamapper plugin code atm :/
12:11
<merboutpost>
MAN! it's such a pain to switch VIM <-> XCode!
12:27
<Frost>
merboutpost: can't you use vim as a source code editor from xcode?
12:34
<merboutpost>
Frost: but the code completion? Will it work?
12:34
<merboutpost>
Frost: did you try some vim integration for objc?
12:36
<Frost>
merboutpost: I have no idea, actually. It might work, but on the other hand, it might not.. :/
12:40
<Frost>
at least it seems like you can get vim to interpret .m file endings as objc instead of matlab quite easily
12:43
<merboutpost>
Frost: I'm trying and it seems to be good enough
12:43
<Frost>
google is your friend, and so on :)
13:00
justin-george joined
13:15
<felipec>
but how do I workaround it?
13:16
<namelessjon>
felipec: That's an old thread. DM has changed significantly since then
13:17
<felipec>
but I'm still getting the error
13:17
<namelessjon>
felipec: Could you pastie some code?
13:20
<namelessjon>
felipec: brb. I'll look when I get back
13:21
<felipec>
namelessjon: do you know how much time?
13:32
<namelessjon>
felipec: What merb/dm version, btw?
13:38
<felipec>
namelessjon: nah, I checked the model: property :test_result, Integer
13:38
<felipec>
has 1, :test_result isn't working either, but I'm on that
13:39
<namelessjon>
felipec: It should work down a has 1. Though in dm, you do need one end to have a belongs_to
13:40
<felipec>
namelessjon: er, but that doesn't make sense in this model: last_test_result is a view, showing the last row of test_result
13:45
<felipec>
I guess I will have to use TestResult.get
13:46
<namelessjon>
felipec: The number of queries is the same. You could maybe wrap it in a nice method.
13:48
<felipec>
right, I could override LastTestResult's method
13:59
<felipec>
can't seem to ad a method either in the generator, nor in the model
16:30
thewoolleyman_ joined
16:33
hipertracker joined
17:10
thewoolleyman joined
17:13
thewoolleyman joined
17:18
thewoolleyman_ joined
17:20
beawesomeinstead joined
17:43
hipertracker_ joined
18:05
<merboutpost>
another patch for rc2 :-)
18:18
<merboutpost>
GoTTeM: ?
18:59
<snusnu>
nice merboutpost, i really appreciate your wildness :P
19:00
<namelessjon>
snusnu: Wildness?
19:06
<snusnu>
namelessjon: is wildness an english word :)?
19:08
<namelessjon>
snusnu: Ah, that was said whilst I was pinged out.
19:08
<merboutpost>
snusnu, namelessjon: I'm trying to crack it for a while but can't find fix
19:09
<snusnu>
merboutpost: hmm i dunno, i remember confirming it, but i never saw that syntax, ever
19:14
<namelessjon>
merboutpost: I was just about to say, that was the issue
19:16
<namelessjon>
merboutpost: I think we can work around with something like...
19:18
<merboutpost>
namelessjon: trying...
19:18
<namelessjon>
merboutpost: n/b, that is untested :)
19:19
<merboutpost>
namelessjon: I managed to fix it with:
19:19
<merboutpost>
code = "def #{name}(_locals={}); #{assigns}; #{template.src}; end"
19:19
<merboutpost>
code.gsub!(/Erubis::XmlHelper/, '::Erubis::XmlHelper')
19:19
<merboutpost>
:-)))))))))))))
19:19
<merboutpost>
brute force
19:21
<namelessjon>
merboutpost: Does my solution not work?
19:22
<merboutpost>
namelessjon: no that was solution before you posted
19:22
<merboutpost>
namelessjon: your solution works! Sweeet!
19:23
<merboutpost>
namelessjon: another bug killed.
19:30
<namelessjon>
merboutpost: sweet. If my understandng of ruby classes is right, that should only be a reference to the real module, too.
19:33
<merboutpost>
namelessjon: I still try to understand what that actually do :-)
19:33
<merboutpost>
namelessjon: how I can change autor of the commit?
19:33
<merboutpost>
namelessjon: I'd like to give you credit
19:36
<merboutpost>
namelessjon: ah git ament
19:36
<merboutpost>
amend
19:42
<namelessjon>
merboutpost: I'd probably move line 193 down about 6-7 lines.
19:43
<namelessjon>
merboutpost: We might as well do it when we already have the class open.
19:43
<namelessjon>
merboutpost: The gist was just to show the class structure.
19:47
<merboutpost>
namelessjon: repushed
19:48
<namelessjon>
merboutpost: That's neater, thanks :)
19:49
<merboutpost>
namelessjon: This reminded me that I should stop hacking... stupid.
19:50
<merboutpost>
namelessjon: I like to merge all patches which are ready. To master tomorrow.
19:50
<merboutpost>
namelessjon: today could be too risky.
19:50
<namelessjon>
merboutpost: Yeah, 2am is a little late for that ;)
20:47
<merboutpost>
namelessjon: cool! Thanks!
20:52
<namelessjon>
merboutpost: The main issue I see with Matteti's suggestion is that ... a precondition match isn't exceptional. But it's about the only way you could do the necessary halt in a helper method.
20:52
justin-george joined
20:53
<merboutpost>
namelessjon: wycats claimed that Rails3 solve condidional get in propper way and that implementation in Merb was hack
20:54
<merboutpost>
namelessjon: I'm too tired now, have to sleep
20:55
<namelessjon>
merboutpost: naturally. ;) Well, it certainly has some problems with regards to the spec, anyway.
20:55
<merboutpost>
namelessjon: ttyl
20:55
<namelessjon>
merboutpost: G'night
21:35
thewoolleyman joined
22:09
maximeguilbot joined
23:36
thewoolleyman joined