03:25 <robholland> morning

07:45 <GitHub129> cucumber-rails: 07master 03aslakhellesoy * 48ca8ba (2 files in 2 dirs): Bugfix: @culerity tag breaks Rails 3 RESTful helpers. Closes #17. - http://bit.ly/d8mh8B

07:51 <GitHub134> cucumber-rails: 07master 03Johan Kiviniemi * e0b7190 (2 files in 1 dirs): {capybara,webrat}_specs.rb: Support RSpec 2

07:51 <GitHub134> cucumber-rails: 07master 03aslakhellesoy * 6f8911f (1 files in 1 dirs): Attribution

07:51 <GitHub134> cucumber-rails: 07master 03aslakhellesoy * 287222f (3 files in 2 dirs): Merge branch 'ion1/master'

07:51 <GitHub134> cucumber-rails: 07master commits 48ca8ba...287222f - http://bit.ly/dyOQTC

08:53 <Keats> Hi, got an "undefined method [...] on click_button", the method that's supposed to be undefined is a model method called after clicking button. Do I have to mock the model or something?

08:58 <aslakhellesoy> Keats: Rails 2.3.5?

08:58 <Keats> yes

08:58 <aslakhellesoy> can you gist a trace?

08:59 <aslakhellesoy> run cucumber with --backtrace

09:00 <Keats> http://pastie.org/870383

09:01 <aslakhellesoy> Keats: is navigation_controller.rb:7 (#new) looking something up?

09:01 <Keats> yeah it works well in the app

09:02 <aslakhellesoy> looks like whatever happened before that line returned nil

09:02 <rolfb> *pushing cucumber on everyone*

09:02 <aslakhellesoy> Keats: what class is calculate_score on?

09:02 <Keats> oh frak i'm stupid, forgot to create a user_profile in the background -__________________-

09:03 <aslakhellesoy> Keats: ha ok

09:03 <Keats> thanks !

09:06 <aslakhellesoy> Keats: I only asked questions :-)

09:08 <Keats> you made me think of the nil thing ;) works like a charm now :D

09:08 <robholland> Teddy bear programming

09:08 <robholland> :)

09:08 <rolfb> wait, is that the new thing?

09:08 <rolfb> :P

12:16 <aslakhellesoy> msassak: ping

12:16 <msassak> aslakhellesoy: pong

12:16 <aslakhellesoy> I've started to refactor the treetop parser like we talked about

12:16 <msassak> cool!

12:16 <aslakhellesoy> going pretty well - it should be fairly trivial to drop in gherkin :-)

12:16 <msassak> that's great news

12:17 <aslakhellesoy> yeah

12:17 <aslakhellesoy> all we need is that end of table event

12:17 <msassak> greg and i have talked about that

12:17 <aslakhellesoy> maybe call it :last_row

12:17 <msassak> and we favor #2

12:17 <aslakhellesoy> :eof ?

12:17 <msassak> yeah

12:18 <msassak> i have a draft email to the cukes groups that i need to finish about it

12:18 <aslakhellesoy> ok, i'll get back to my refactoring - can touch base later

12:18 <msassak> the point though is that turning rows into a table is a real AST abstraction

12:18 <aslakhellesoy> msassak: i agree

12:19 <msassak> and we think we've got a pretty good idea of how to handle comments in general

12:19 <aslakhellesoy> using :eof makes the listeners a little more complex, but not a whole lot

12:19 <msassak> i think that it will keep the lexer and parser simpler, though

12:20 <aslakhellesoy> maybe. i actually have an un-pushed gherkin branch using :eof

12:20 <aslakhellesoy> i can push it up

12:20 <aslakhellesoy> (well - it used :end_feature, but I think it should be renamed to :eof)

12:20 <aslakhellesoy> also updated the transition tables.

12:20 <msassak> and that includes the new row-based parsing?

12:21 <GitHub73> gherkin: 07eof-event 03aslakhellesoy * f8ae002 (1 files in 1 dirs): upate gemspec - http://bit.ly/9P9ZOF

12:21 <aslakhellesoy> msassak: yes - branched off that

12:21 <msassak> cool

12:21 <aslakhellesoy> i also updated java and c# with row events

12:22 <msassak> one of us will take a look at it soon

12:22 <aslakhellesoy> msassak: ghnatiuk: awesome

12:22 <msassak> ahh good--so all that remains is the pretty printer?

12:23 <ghnatiuk> sending an eof event should be trivial since we already have a FEATURE_END string stuck on there

12:23 <ghnatiuk> it will, by default at least, get sent when using the steps parser/lexer as well

12:24 <aslakhellesoy> I think i fixed the pretty printer too

12:24 <msassak> cool

12:25 <msassak> then let's get this thing out the door :-)

12:25 <aslakhellesoy> http://github.com/aslakhellesoy/gherkin/commit/7e62d127748a3f16d30216ee7913811c6588e7e4

12:25 <aslakhellesoy> notice the flush_table calls

12:26 <ghnatiuk> aslakhellesoy: Nice!

12:26 <aslakhellesoy> in the future, when cucumber builds an AST, we'll have to have similar calls

12:26 <msassak> yup

12:26 <aslakhellesoy> ghnatiuk: what you were thinking about right? except that :eof is a better name i suppose

12:27 <ghnatiuk> yep, absolutely.

12:27 <ghnatiuk> eof is probably better

12:28 <ghnatiuk> we still need to address the :eol argument specifying CRLF or newlines somewhere

12:28 <aslakhellesoy> do you agree with how it's fired?

12:28 <aslakhellesoy> http://github.com/aslakhellesoy/gherkin/commit/7e62d127748a3f16d30216ee7913811c6588e7e4#diff-6

12:28 <aslakhellesoy> http://github.com/aslakhellesoy/gherkin/commit/7e62d127748a3f16d30216ee7913811c6588e7e4#L5R194

12:28 <ghnatiuk> yep, i'd spiked that on a branch and did it identically a while ago

12:28 <aslakhellesoy> ghnatiuk: wicked

12:29 <aslakhellesoy> java and c# still need to be updated with this event, but that's trivial.

12:29 <msassak> is it possible to send that event only when the lexer does not end in an error?

12:29 <msassak> that's my only question

12:30 <ghnatiuk> yeah, true

12:30 <aslakhellesoy> msassak: i was thinking about that. i guess we could move it to the bottom of the action

12:30 <ghnatiuk> that should probably fire if there's no error

12:30 <msassak> that's what i would expect

12:30 <aslakhellesoy> i'll let one of you change that - and rename to :eof

12:30 <aslakhellesoy> i'm deep into treetop now

12:30 <msassak> okay

12:30 <ghnatiuk> okay, sounds good.

12:30 <msassak> well good luck

12:30 <ghnatiuk> crud, gotta run, back in a bit

12:31 <msassak> :-)

12:31 <msassak> later aslak

12:38 <aslakhellesoy> laters

13:41 <ghnatiuk> aslakhellesoy: hi

14:53 <aslakhellesoy> ghnatiuk: hi, i'm back

14:53 <ghnatiuk> aslakhellesoy: hello again

14:53 <ghnatiuk> had maybe a crazy opinionated idea

14:53 <ghnatiuk> that comments should not go into the AST at all

14:53 <aslakhellesoy> i like those :-)

14:54 <ghnatiuk> or in general even be printed

14:54 <aslakhellesoy> just the line number, and pull it back out of the source?

14:54 <ghnatiuk> as in throw them away (for every purpose except reformatting, maybe)

14:55 <aslakhellesoy> interesting

14:55 <ghnatiuk> they're useful, sure, for commenting out things you want to skip when testing, but I think they're really smelly as a means of providing communication

14:55 <aslakhellesoy> i guess it wouldn't hurt anyone if the cucumber pretty output didn't have them

14:55 <aslakhellesoy> but as you say, the reformatter needs to preserve them - but that's a different beast

14:56 <aslakhellesoy> (although the reformatter and cucumber's pretty output will share the same code from gherkin's pretty printer)

14:56 <aslakhellesoy> i like that idea.

14:57 <ghnatiuk> I'm not sure what kind of complaining it might cause :)

14:57 <aslakhellesoy> by users you mean?

14:57 <ghnatiuk> yeah

14:57 <ghnatiuk> it's also near impossible to infer what the comment should be attached to in many cases

14:58 <ghnatiuk> which lead me to start thinking of them as noise

14:59 <aslakhellesoy> ghnatiuk: it would definitely be nice to toss them out of the ast

15:00 <aslakhellesoy> ghnatiuk: but this doesn't affect gherkin right? only the cucumber gherkin builder right?

15:00 <ghnatiuk> right

15:01 <aslakhellesoy> hi dastels

15:01 <dastels> aslakhellesoy: Hey

15:01 <aslakhellesoy> been a while - how are you

15:02 <dastels> aslakhellesoy: Been too long.

15:02 <dastels> aslakhellesoy: Doing well enough. Moved into San Francisco.

15:03 <aslakhellesoy> dastels: great! i collect people to visit in SF :-)

15:05 <aslakhellesoy> ghnatiuk: why is it so hard to infer where the comment belongs though?

15:06 <aslakhellesoy> the pretty printer just stores them in a buffer, and when a _proper_ ast event comed along, they're grabbed (and the buffer is cleaned)

15:06 <aslakhellesoy> we could do the same for the ast couldn't we?

15:06 <ghnatiuk> http://gist.github.com/333331

15:06 <ghnatiuk> yeah, mike and I were talking about sticking them in a separate buffer

15:06 <ghnatiuk> and, if requested

15:06 <ghnatiuk> pulling and merging them back into output based on line number

15:07 <aslakhellesoy> ghnatiuk: well, if you think about a comment as _always_ belonging to the next syntax element...

15:08 <aslakhellesoy> -and comments at the bottom of the file could be handled separately

15:08 <dastels> aslakhellesoy: get in touch next time you visit!

15:09 <aslakhellesoy> re: http://gist.github.com/333331 - even if line 3 is about the scenario (for the human reading it) it could still belong to the step for gherkin couldn't it?

15:09 <ghnatiuk> aslakhellesoy: Yeah, could do that. would we be wrong 50% of the time?

15:09 <aslakhellesoy> dastels: definitely!

15:10 <aslakhellesoy> ghnatiuk: does it matter if we're wrong 100% of the time as long as it's outputted in the same order as in the source?

15:10 <aslakhellesoy> (i'm still open to ditching comments in the ast, just not sure i get why it's hard to support)

15:10 <ghnatiuk> hah, I suppose not. Does the pretty printer for gherkin retain indentation information about comments, or do they all get pushed to the front of the line

15:13 <ghnatiuk> We were discussing handling them nicely w/ tables. I guess it doesn't matter if we're wrong 100% of the time.

15:13 <ghnatiuk> I don't like them, though ;)

15:13 <aslakhellesoy> ghnatiuk: comments are indented according to the syntax element they belong to

15:14 <aslakhellesoy> ghnatiuk: so basically, comments aren't outputted instantly - only stored in a buffer.

15:14 <aslakhellesoy> the scenario event will output the buffer at the right indentation level

15:15 <ghnatiuk> aslakhellesoy: at the indentation level for the element that follows the comment?

15:15 <ghnatiuk> sorry, i haven't looked at the printer in a while

15:16 <aslakhellesoy> anyway - let's get back to ditching comments in the ast when after we have it integrated with cucumber

15:17 <aslakhellesoy> which is going to happen this week!!!!

15:17 <ghnatiuk> sweet!!

15:17 <ghnatiuk> are you actually changing treetop or adding a builder to use the current ast w/ gherkin?

15:19 <aslakhellesoy> ghnatiuk: i'm adding an #emit(builder) method to all the treetop nodes that have #build

15:19 <aslakhellesoy> #build will go away

15:20 <aslakhellesoy> then i'm adding a builder class that will build the same AST that the treetop grammar's #build methods used to do directly

15:20 <aslakhellesoy> the builder class will have exactly the gherkin apu

15:20 <aslakhellesoy> api

15:21 <aslakhellesoy> so gherkin will be a drop-in replacement

15:22 <ghnatiuk> aslakhellesoy: wow. I was just expecting the builder, not changing treetop to match.

15:23 <ghnatiuk> but probably easier to keep in the green that way, eh?

15:23 <aslakhellesoy> ghnatiuk: have you seen the treetop grammar? it builds the ast.

15:24 <aslakhellesoy> in order to make gherkin a drop-in replacement we have to make treetop behave like gherkin

15:24 <aslakhellesoy> which is what i'm doing

15:24 <aslakhellesoy> this will be rather low friction

15:27 <ghnatiuk> aslakhellesoy: yeah, nice. I'd taken a stab at a builder for gherkin to create the same ast that treetop does (leaving treetop alone)

15:27 <ghnatiuk> but it was a real pain to test that way

15:28 <aslakhellesoy> ghnatiuk: i'm not entering beauty contest with this

15:28 <ghnatiuk> hah. With 200+ committers, that would be hard anyway.

15:29 <ghnatiuk> we can build a beautiful AST later

15:29 <aslakhellesoy> after getting gherkin in i want to get rid of the current ast and make a nicer one like we started on the gherkin branch

15:29 <aslakhellesoy> yep!

15:30 <aslakhellesoy> gotta go. laters.

15:30 <ghnatiuk> 'night!