03:43 <dkubb> !memo mbj I'm curious if you're open to the idea of converting Buffer into a Stream-like object, compatible with the IO/StringIO type interface

03:43 <Cinchy> dkubb: Memo recorded for mbj.

05:53 <dkubb> !memo mbj if you're worried about how to handle indentation, that should be relatively simple with a proxy that represents indentation, and it's #unindent returns the proxied object (and of course #indent would return itself wrapped in another indentation object

05:53 <Cinchy> dkubb: Memo recorded for mbj.

05:55 <dkubb> !memo mbj then the append (<<) operator in that object would just do @output << ' ' << string

05:55 <Cinchy> dkubb: Memo recorded for mbj.

07:38 <dawkirst> Hi, anyone awake?

07:44 <mbj> .

07:44 <Cinchy> mbj: [4h 0m 53s ago] <dkubb> I'm curious if you're open to the idea of converting Buffer into a Stream-like object, compatible with the IO/StringIO type interface

07:44 <Cinchy> mbj: [1h 50m 46s ago] <dkubb> if you're worried about how to handle indentation, that should be relatively simple with a proxy that represents indentation, and it's #unindent returns the proxied object (and of course #indent would return itself wrapped in another indentation object

07:44 <Cinchy> mbj: [1h 49m 15s ago] <dkubb> then the append (<<) operator in that object would just do @output << ' ' << string

07:45 <mbj> dkubb: This is the 4th generation of unparsers I wrote. And I tried man approaches.

07:45 <mbj> dkubb: Passing an unaugmented buffer around just adds code complexity in the emitters.

07:45 <mbj> dkubb: s/man/many

07:48 <mbj> dkubb: Feel free to try optimize yourself, I dont think you'll come up with an "easier" solution. But I'd happy to see it!

07:48 <mbj> dkubb: The emitters are very straitforward now, you dont have to pass the buffer (or an indented buffer) anywhere.

07:48 <mbj> dkubb: Using a plain IO object is IMHO primitive obsession.

07:49 <mbj> dkubb: We can also move Generator.generate logic to Node#to_sql

07:49 <mbj> dkubb: Than move app specs to Node#to_sql and kill mutations in Emitter.visit via that spec (symlink for mutant 0.2) kill configuration for mutant-0.3

07:51 <dawkirst> mbj, in which cases would .sum => nil?

07:51 <mbj> dawkirst: Can you give me a context?

07:52 <dawkirst> mbj, So I have Foo with property bar (Integer) and I try Foo.sum(:bar) => nil. Some of bar's values are negative though, don't know if that makes the difference.

08:04 <dawkirst> mbj, not sure if that is what you meant with "context"? Sorry.

08:22 <mbj> dawkirst: The context of your problem ;)

08:22 <mbj> dawkirst: You gave it already.

08:22 <mbj> dawkirst: I never used the sum feature, sorry.

08:53 <dawkirst> mbj, ok, thanks :)

10:24 <mongrelion> hi there o/

10:25 <viranch> can someone comment on this? http://stackoverflow.com/questions/16459168/ruby-datamapper-conditions-through-associations

10:25 <Cinchy> [URL] orm - Ruby DataMapper: Conditions through associations - Stack Overflow

11:00 <mongrelion> I'm trying to create an instance of a class that includes DataMapper::Resource via params on a Sinatra application and it happens that this class belongs_to :foo and in the params you can find the foo's id as { name: 'meh', foo_id: '1' } but it doesn't get assigned because it's a string rather than an number. Before hacking I first wanna make sure that DataMapper doesn't have anything for handling these cases. Any thoughts/suggestions?

18:07 <kapowaz> so; I'm getting `DataMapper::UpdateConflictError: #update cannot be called on a dirty resource` when I'm updating a resource.

18:08 <kapowaz> I've got some validations (with contexts) on this model, though, so I'm wondering if that's why

18:08 <kapowaz> certainly I'm not updating anything else on the resource prior to this single #update call

18:09 <kapowaz> can you specify a validation context when updating?

18:10 <kapowaz> ha, just tried calling MyModel.update({:foo => "whatever"}, :my_context) and that works fine

18:10 <kapowaz> duh.