kenphused has quit [Quit: I'll Get Back With You on That in a Few]
postmodern has quit [Quit: Leaving]
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
snusnu has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
snusnu has quit [Quit: Leaving.]
breakingthings has joined #rom-rb
CraigBuchek has joined #rom-rb
snusnu has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 248 seconds]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 245 seconds]
dkubb has joined #rom-rb
<dkubb>
good morning
<snusnu>
dkubb: hey
<snusnu>
dkubb: i saw that you pushed some commits towards nest/unnest . .that's great!
careo has joined #rom-rb
zekefast has quit [Quit: Leaving.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 241 seconds]
<dkubb>
snusnu: yeah, it wasn't too hard once I sat down to do it
<dkubb>
snusnu: it basically works, I just need to do some refactoring. much of the code can be shared between the join and nest operator, like the code that builds up the index
<snusnu>
dkubb: right that makes sense, both join and nest need to "collapse" the tuples via the index
<snusnu>
dkubb: i will start experimenting with nested relations as soon as you "give me a go" .. i'll use ducktrap to do the transformations in my app .. to get a feel for things
<dkubb>
right, they both build up an index keyed to a specific set of attributes
<snusnu>
dkubb: i have this feeling that what's currently rom-mapper, will be a rather slim dsl on top of (a potentially trimmed down) ducktrap
jfredett has joined #rom-rb
<dkubb>
oh yeah?
knowtheo1y is now known as knowtheory
<dkubb>
that would be really nice
<dkubb>
I love the idea of ROM becoming an ever-so-slim wrapper around more primitive libs
<snusnu>
dkubb: yeah ducktrap basically *is* a mapper, well, it's more than that, but it can certainly be used as a mapper
<dkubb>
like the front-end user interface to more powerful tools people can assemble in different ways
<dkubb>
with ROM i'm more interested in providing tools for building ORMS than I am for building "the" ORM everyone uses
<dkubb>
I would like to see cross polination between ROM and perpetuity for example
<snusnu>
yeah totally, ROM will be very different to that end .. it will be a toolkit assembling the lower level libs
<dkubb>
the ruby community is sorely lacking in good ORMs, and I would be arogant to assume our way is the absolute best way in all cases.. I'd rather assemble some preferred configuration out of simple, single purpose primitives.. and then let others do the same
<snusnu>
absolutely
<dkubb>
I think of ROM as an ORM toolkit that will have good defaults
<snusnu>
right
<dkubb>
if we do the proxy behaviour in ROM::Relation right, we could even plug in other kinds of enumerable/query-like interfaces underneath
<dkubb>
like Sequel::Core stuff
<snusnu>
for example, i doubt that i will ever use virtus in rom apps, i found that i don't need it .. anima and ducktrap separate concerns sharper, and fit nicely with the "immutable all the way down" approach i took
zekefast has joined #rom-rb
<dkubb>
I wonder if some of virtus could be built on top of anima
<snusnu>
yeah, it will be interesting to see where this goes … i guess we shouldn't assume too much, but initially start out with "our vision" of the relation interface .. if we get it right, other enumerables will be easy to inject
<snusnu>
i think virtus has its place the way it is, i just happen to want to structure my apps a bit differently
<dkubb>
yeah
<snusnu>
we'll see if eventually anima can be used under the hood
<dkubb>
my test for using libs is, would I use it as a dependency in my own lib
<dkubb>
if I did use virtus I would be more likely to use it at the app level
<dkubb>
I would probably never rewrite axiom itself to use virtus for example
<dkubb>
I may use anima in that case though
<snusnu>
virtus seems to be really nice for stuff like form objects .. but with my architecture, i don't have/need form objects
<dkubb>
I've done it, but I tend to just write a simple base class by hand that does everything I need
<snusnu>
i just post json data, pass that through ducktrap to do sanitization and "mapping" in one go
<dkubb>
yeah
<dkubb>
what I think I want for a form object would be more like a router
<dkubb>
I don't want a buffer for the form data, I want it routed to something underneath
<dkubb>
I guess that's a mapper
<snusnu>
yeah, i guess my (and mbj's) approach relies so much on angular.js (posting form data as json), that there simply is no need to "rebuild" the form (say, when a validation error happens)
<snusnu>
so i really simply render a form using mustache, and let angular and ducktrap/vanguard on the server do the rest
<snusnu>
we'll be starting a new side project soonish, and i plan to use my own miniframework (substation + the rom stack) for that … imo it's a very nice/different approach to writing web apps .. it's (immutable) objects all the way down .. directly on top of rack, no sinatra no rails whatsoever ...
<snusnu>
it's a nice playground to get a feel for how to develop apps using rom
<snusnu>
or in general, how to develop/architect web apps with a *real* datamapper
<dkubb>
interesting
marcosdsanchez has joined #rom-rb
<snusnu>
something i've never really done before
<dkubb>
I've been wanting to play a bit more with celluloid
<snusnu>
yeah that sounds interesting too .. i figured i want to have immutable objects first tho, *then* think about concurrency differently ;)
<dkubb>
there's a web framework https://github.com/celluloid/lattice that uses it. some of the examples look nice, but I still don't feel like any web framework out there works exactly like how I think about things
<dkubb>
yeah
<dkubb>
concurrency and parallelism are much easier when you start with immutable objects
<snusnu>
yeah, the thing with "my webframework" is, it's *no webframework* :)
<snusnu>
right
<dkubb>
or at the very least, keep the mutable objects self-contained and not leaking all over the place
<dkubb>
mutability is alright if you have a builder type object that you freeze after it's built too
<dkubb>
although I still think it's nicer to have state changes be explicit, and start with one builder and "mutate" it by returning a new object that is a combination of the old state and new state
<snusnu>
yeah, i just wanted to say that … i rarely, in fact, currently never, need to freeze otherwise mutable objects … i just build different immutable states
<dkubb>
yeah, that's a nicer way to do it
<snusnu>
in my current web app, there is *one* mutable object .. and that wraps joshbuddy/http_router and allows to collect user defined routes … i can then ask that object, to return an immutable version of itself
<dkubb>
for me, what I would like is a web framework that handles the HTTP side of things, but as a user I interact with it using immutable objects that represent each resource state
<snusnu>
oh wow, this surely looks interesting
<dkubb>
if it uses the standard protocol state machine that would be cool
<dkubb>
I would like to be able to describe a handler using a state machine
<snusnu>
i need to have a closer look at that .. what i currently do, is i build up the http response object manually, there's nothing in my (helper) code that's concerned with http so far
<marcosdsanchez>
anyone familiar with that? I've found the project very interesting and was willing to help even though i'm still new to ruby
<jfredett>
it appears there's a syntax error on line 254 of response.rb -- what version of ruby are you running on?
<marcosdsanchez>
2.0.0-p247 , 1.9.3 shows the same
<jfredett>
hmm
<jfredett>
I don't see anything on line 254 that would indicate some syntax error, I'll see if I can't reproduce it locally
<jfredett>
I dunno much about the project, but we can probably narrow it down to a you or him problem. :)
<marcosdsanchez>
it's happening in a fresh cloned repo
<marcosdsanchez>
thansk @jfredett
<jfredett>
okay, I'm bundling now, should just take a second
<jfredett>
marcosdsanchez: I'm just looking at this gist -- I don't see a syntax error listed in the output, and my `rake ci` only indicates one failing mutation
<jfredett>
which also shows up in yours
<jfredett>
I did get one stack trace, actually. hmm
<jfredett>
ah, yes, I think mutant mutated a syntax error
<jfredett>
I'd guess that's a bug in mutant, not response
<jfredett>
yah, I get that too
<marcosdsanchez>
okay, thanks
<jfredett>
I would say you probably don't need to worry about that, but check to see if there's a bug filed on mutant, that smells like something it shouldn't do
<jfredett>
something to the effect of "mutant creates a syntax error
<jfredett>
yah -- I see what happened
<jfredett>
it mutated away the default argument for headers
<jfredett>
but left the argument for body
<jfredett>
which is not legal ruby syntax
<jfredett>
(you haven't have a required argument surrounded by unrequired ones, it's ambiguous)
<jfredett>
that's definitely a mutant bug
<jfredett>
it's not super critical... probably mutant should just count syntax errors as failing tests... but I'd file a bug report on mbj/mutant
<marcosdsanchez>
ok, thanks a lot. I'll report the issue
<jfredett>
np -- the library should work no problem, btw. mutant tests not being 100% passing is not abnormal. `rake spec` is clean.
<marcosdsanchez>
cool
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<dkubb>
yeah, generally the goal is that mutant not ever produce syntax errors
<dkubb>
there's checks in various places to skip some kinds of mutations that would result in a syntax error
<dkubb>
for example, if you have some_variable, in many places it'll get mutated to nil, but not in: some_variable = 5;
<dkubb>
in the specific mutator that handles the variable w/nil replacement, it checks it's parent context to see if it's part of an assignment and skips doing anything
xargoon has quit [Ping timeout: 268 seconds]
xargoon has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
<jfredett>
I see.
<jfredett>
so to fix this, you'd need some check in whatever mutates the arguements of a definition (I assume mutator/node/arguments to be such a place), and make it check to see it's only un-defaulting from the leftmost part
<dkubb>
I believe so
<jfredett>
this code is lovely, though it's a pretty complicated thing.
<CraigBuchek>
Is this the right place to ask Virtus questions?
<dkubb>
yeah, mbj did a good job with it. it makes more sense when you've worked with it for a few days
<dkubb>
CraigBuchek: I think so, although I don't know if solnic is around
<CraigBuchek>
Yeah, I guess waiting for solnic might be a good idea.
snusnu has quit [Ping timeout: 240 seconds]
snusnu has joined #rom-rb
jfredett has quit [Remote host closed the connection]
<dkubb>
CraigBuchek: you could also just ask here and people may give you pointers. in any case, solnic can always see it in his history too
breakingthings has quit []
jfredett-w has joined #rom-rb
<cored>
hello all
<dkubb>
cored: hello
<cored>
have to come back to my devtools effort, but at the moment life is taking over taking classes and trying to find a job
<cored>
:-(
<cored>
would love to finish up what I started
<postmodern>
perhaps think of ways to simplify the problems?
<postmodern>
or make devtools more manageable?
<cored>
postmodern: I'm just extracting logic to be easily testable
<dkubb>
cored: you could also bite off one small piece at a time. it's hard to do huge changes all at once
<cored>
dkubb: yes, I have the main thing that I have to figure is what will be a valid assertion for flay new task
<cored>
dkubb: after that I can keep working on extracting more logic and separating things
<cored>
I'm guessing that devtools could be use to self check
<dkubb>
it's always good when a tool can check itself
<dkubb>
it's actually a pet peeve of mine when tools don't pass against themselves
<cored>
dkubb: yeap
<dkubb>
I hope to chip away at mutant and make it so it can mutation test itself
<dkubb>
mutant is a special case, since it needed to exist in order for it to be properly mutation tested
<dkubb>
maybe that's why so many tools don't pass themselves. the first version needs to be built first