<dbussink>
postmodern: yeah, looks like it can't find the headers there which sounds like some botched system setup
<postmodern>
dbussink, if i had a dime everytime ubuntu re-arranged something for the worse ;)
<dbussink>
postmodern: hehe
mbj has joined #rom-rb
<mbj>
.
mbj has quit [Read error: Connection reset by peer]
solnic has joined #rom-rb
yawniek has joined #rom-rb
splattael has joined #rom-rb
<Gibheer>
postmodern: didn't he say it was for fedora 18?
<postmodern>
Gibheer, correct
<postmodern>
Gibheer, im on fedora 17 still
<Gibheer>
just wondered why you mentioned ubuntu ;)
<postmodern>
bias caught my tongue ;)
<Gibheer>
hehe
<Gibheer>
did you decide on the -v/-V problem yet?
<postmodern>
i think -V is wining
kapowaz has joined #rom-rb
<postmodern>
i really wish there was a standard for -v vs. -V
<postmodern>
the current standards just say use -V if -v is already taken
<Gibheer>
hmm, too bad
<Gibheer>
I looked how other tools did it, but it isn't even consistent between clang, perl, python and ruby
<Gibheer>
the only "normal" thing is --version
<solnic>
kapowaz: morning you there? :)
mbj has joined #rom-rb
theCrab has joined #rom-rb
<namelessjon>
From my point of view, I prefer -v for verbose. I don't use either that often, but I think it works out that I toggle verbose more than I check the version.
zekefast has quit [Ping timeout: 248 seconds]
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] rom-rb/rom-mapper#23 (master - f2be17a : Piotr Solnica): The build has errored.
<mbj>
solnic: But my current project runs also under jruby, so I'll investigate!
<solnic>
mbj: btw, dkubb added zeus support to devtools
<solnic>
could be useful, esp on jruby :)
cored has joined #rom-rb
theCrab has quit [Quit: Gone Forever!]
namelessjon has quit [Read error: Operation timed out]
namelessjon has joined #rom-rb
<mongrelion>
exit
postmodern has quit [Quit: Leaving]
cored has quit [Ping timeout: 240 seconds]
cored has joined #rom-rb
splattael has quit [Remote host closed the connection]
knowtheory has quit [Ping timeout: 252 seconds]
knowtheory has joined #rom-rb
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
<solnic>
mbj: how about releasing ROM during eurucamp? :D
<cored>
hello
<cored>
eurucamp looks fun, would love to go. The only downside is the plane ticket for me
<cored>
it's even cheap in comparation to Railsconf
snusnu has joined #rom-rb
brandon7 has joined #rom-rb
<mbj>
solnic: yeah!
knowtheory has quit [Ping timeout: 260 seconds]
<solnic>
cored: where are you from?
_whitelogger has joined #rom-rb
<solnic>
dkubb: hi
<solnic>
dkubb, snusnu: what's up with calling buider methods "coerce"?
<solnic>
I find it really odd
<solnic>
builder even
<dkubb>
I would expect build methods to be called .build
<cored>
solnic: sorry, was reading Object on Rails
<cored>
solnic: Dominican Republic
<cored>
dkubb: morning
<dkubb>
I use .coerce in some places where the client is providing primitives
<dkubb>
cored: good morning
<cored>
solnic: that's what got me confuse yesterday, also
<cored>
dkubb: hi, do you have a couple of minutes for me today? I did not catch you yesterday night, maybe my calculations about time were wrong
<dkubb>
cored: yeah, I started on the refactoring in axiom to add axiom-types. there's still a ton of things to fix (lots and lots of spec failures), but I could push what I have into a WIP commit in a separate branch
_whitelogger has joined #rom-rb
_whitelogger has joined #rom-rb
<dkubb>
cored: yeah I can do that
<dkubb>
cored: don't sync up with that branch yet, I have one more thing to do to it
<cored>
still haven't fetch any branch
<cored>
just master
_whitelogger has joined #rom-rb
<solnic>
I also find things like Environment.coerce weird, Environment.setup would just look nicer
<solnic>
coerce sounds very...low-level
<solnic>
dkubb: ah ok, well we have a Repository.coerce method that accepts 2 args, so I find it weird
_whitelogger has quit [Excess Flood]
_whitelogger has joined #rom-rb
<dkubb>
cored: sometimes, to make sure there were no regressions I might run the next set of specs like: bundle exec rspec spec/unit/axiom/attribute/{boolean,class}/
<dkubb>
and keep going until you can do bundle exec rspec spec/unit/axiom/attribute/ with no failures. and then I'd move onto functions, and aggregates
<cored>
dkubb: good
<cored>
I'm kinda confuse with something
<dkubb>
cored: during the course of this you may find bugs in axiom-types. I found one last night which I fixed. I have another pending fix that I can't work on this morning, but it fixes some comparison with Float::INFINITY
<cored>
you were the one that open the pull request
<cored>
if I start working on your branch and then make pushes to that branch but on my remote, won't this cause me to create a new pull request for it?
<cored>
or can I keep making commits to that branch and it will affect your pull request?
<dkubb>
cored: oh, I'll give you commit rights to the repo
<cored>
dkubb: cool, thanks
<cored>
dkubb: going to remove my fork
knowtheory has joined #rom-rb
<dkubb>
cored: kk
cored has quit [Ping timeout: 246 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
dkubb has quit [Quit: Leaving...]
indrek_ has quit [Read error: Operation timed out]
dkubb has joined #rom-rb
<dkubb>
solnic: btw, in YARD there's a way to document a class as private using @private before the class definition
indrek has joined #rom-rb
<cored>
dkubb: I think I found a bug in axiom-types
<dkubb>
solnic: note it's not @api private, but rather @private. it's meant for times when you want to mark a class or constant as private visibility but ruby doesn't provide a mechanism
<dkubb>
cored: it's possible, can you reproduce?
<cored>
yes
<cored>
want me to create an issue and discuss there?
<dkubb>
cored: I changed something in axiom-types to use Range#cover?, and in the absence of a min or max number I defaulted to -Float::INFINITY and Float::INFINITY respectively
<dkubb>
cored: the problem is that you can't compare that against some numerics, oddly enough
<dkubb>
cored: so I'm adding an Axiom::Types::Infinity object that has a <=> that compares properly
<cored>
you can't compare Float::INFINITY?
<cored>
to some numbers?
<cored>
got it
<dkubb>
yeah it's weird
<dkubb>
at least with <=> you can't
<cored>
in that case the return of Infinity is correct
<cored>
for this particular spec?
<cored>
still odd for me because it was BigDecimal('1')
<dkubb>
Axiom::Types::Decimal.include?(operand) should return true in that case
<cored>
oki
kleech has quit [Remote host closed the connection]
<cored>
have a doubt
<cored>
we are using types inside axiom which compose axiom-types types
<cored>
or that's also related to the range bug in axiom-types
<cored>
this is for date_time/range_spec.rb
<cored>
the assertion says DateTime.new..DateTime::Infinity.new
<cored>
but that's not what I'm getting
<cored>
I can add the same thing as in axiom-types for minimum and maximium values, but that would seem testing axiom-types from axiom and that's not what we want
<cored>
right ?
<dkubb>
cored: yeah, you can change the spec to match for now
<dkubb>
cored: we'll change some of the methods to delegate straight through to axiom-types in the future, but for now we should just make things match up
<dkubb>
cored: once we delegate, then the specs won't need to care about the return values, more than the message was sent to axiom-types and whatever it's return value was is what was returned
<cored>
dkubb: ok
<cored>
let me change it then
<solnic>
dkubb, mbj, snusnu: are we happy with the logo?
<solnic>
I am
<snusnu>
me too
<solnic>
I like both colorful and the monochrom versions
<dkubb>
cored: what I would suggest is that you commit each time you fix a spec and push it. we can squash the commits down later, but we should save at each improvement .. even if it means we end up with 50 commits in that PR
<dkubb>
solnic: I like it
<solnic>
yay :)
<dkubb>
cored: you may want to pull and bundle update, I just fixed axiom-types and one spec for Attribute::Numeric#hash
<solnic>
dkubb: when we have a final version (kapowaz?) you will have to register it via gravatar in order to have it displayed on github :|
<solnic>
which is WEIRD btw
<dkubb>
solnic: I wonder if we can get an svg version of that logo, then we can scale it up and down in various places
<solnic>
dkubb: that's a question to mr kapowaz :)
<dkubb>
solnic: assuming it's not too much effort of course. I wouldn't want kapowaz to go to a ton of trouble for it.. I don't know what editor he is using, so maybe it's an export option
kleech has joined #rom-rb
<dkubb>
solnic: yeah, ideally we'd get it in the major formats like: png, gif, jpg (1x and 2x) along with sources in psd, svg
<cored>
dkubb: oki
<cored>
dkubb: great, will do that
<dkubb>
cored: there may be some remaining bugs in type inference, I'm seeing weird results in spec/unit/axiom/attribute/class_methods/infer_type_spec.rb .. I can't look at it today, but you can probably skip over that spec unless you want to dig in
kleech has quit [Ping timeout: 276 seconds]
<cored>
dkubb: I will take a look at it, but I think I ran those specs already
<cored>
dkubb: will check it out again
<cored>
dkubb: this is weird, before the update to axiom-types I just had the BigDecimal error now I have some more :-)
<dkubb>
cored: yeah I see one other issue with that decimal comparison. for now I'd skip numerics
<cored>
is there another project using axiom-types?
<cored>
oh now I see what you mean
<cored>
this means that your fix did not work, correct?
<cored>
dkubb: tested with all the numeric types, Integer, Float, Decimal with this values 1, 1.1, BigDecimal('1') non of them returned true
<dkubb>
I thought it worked, but my testing was flawed
<cored>
so
<cored>
should I keep workin gon the other specs?
<dkubb>
I need to make some shared specs for the numeric testing
<dkubb>
cored: yeah, skip the numeric attributes for now
<cored>
I will mark it as pending
<cored>
ok ?
<dkubb>
sure if you want
<cored>
ok
<cored>
bbl
<solnic>
dkubb, mbj: I love how devtools evolves, it's helping significantly
<dkubb>
solnic: yeah, I'm hoping to evolve it into something that also works well with rails apps
<dkubb>
solnic: I want to use it everyday, both in oss and work
<solnic>
yeah that'd be awesome
<dkubb>
solnic: I love using it on this new rails app I'm working on. mutant already found some stuff I forgot to spec
<cored>
back
<cored>
solnic: you have to give that metrics driven development talk
<solnic>
cored: first I must be accepted somewhere
<solnic>
well, before that I must send that proposal again somewhere heh
<cored>
solnic: eurocamp sounds good
<cored>
dkubb: where is minimum and maximum methods comming from ? I though they were defined in Axiom::Agreggate::Minimum
<solnic>
cored: CFP is closed :)
<cored>
solnic: :-(
<cored>
off topic: do you know a gem that have value objects defined for common things like 'money', 'geolocation' ?
<cored>
maybe that could be helpful to have
<cored>
dkubb: it's seems that all the range checks will drop the same error if they are related to numerics types
<dkubb>
cored: the minimum and maximum methods inside the types build block comes from axiom-types
zekefast has quit [Quit: Leaving.]
<cored>
dkubb: yes, found it
<cored>
dkubb: did you check my last gist? that's seems a problem related to numeric range
<cored>
dkubb: also there's not an equivalent to a Tuple in axiom-types
<dkubb>
cored: yeah, I saw the gist. I think I have a fix for it but I won't be able to finish testing it until later todat
<dkubb>
*today
<cored>
I see
djsell has joined #rom-rb
<cored>
dkubb: if you are still there, there's no Tuple equivalent in Axiom-types
<cored>
is that needed or should we use Set instead
<cored>
?
snusnu has quit [Quit: Leaving.]
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
snusnu has joined #rom-rb
<dkubb>
cored: afaik a Tuple type won't be needed yet. when it is needed we can add it
<dkubb>
cored: I tried to only add what I needed in axiom-types to remove the logic from axiom. I expect it to expand a bit over time
<cored>
dkubb: I see, so what do you think regarding the tuple spec, also pending?
<dkubb>
cored: sure
<dkubb>
cored: btw, bundle update I fixed some stuff in axiom-types
<dkubb>
cored: it's still not perfect yet, but it should make a difference
<dkubb>
cored: also I sometimes added --fail-fast to the .rspec file which would cut down on the number of failures I would have to look at so it's not overwhelming. it will stop on the first failure
<dkubb>
cored: feel free to mark anything as pending that you don't understand or you can't get working easily. we can always circle back to those later. I won't merge into master until those are fixed anyway
<cored>
dkubb: oh, nice
<cored>
dkubb: that's not part of axiom, right ?
zekefast has joined #rom-rb
<cored>
dkubb: yeap
<cored>
dkubb: sure
<cored>
let me bundle update
<cored>
dkubb: you said that after spec/attribute been green then run the entire spec suite or keep working with aggregate and the others directories ?
<dkubb>
cored: I would probably work on functions and aggregates. in general we want to fix from the leaves to the root.. in terms of dependencies
<dkubb>
cored: there's no point in trying to fix specs for, say, restrictions, because they're dependent on the attributes and types and functions all working well
<cored>
got it
<cored>
found another weird thing
<cored>
self.class.type when class is Class
<cored>
doesn't exist
<cored>
Class is a child for Attribute and the later has the method as you already know, I just debug it and notice that in fact this is an Axiom::Attribute child class so don't know what's the problem now
<cored>
don't know how this is even working in the spec Class.new(Attribute) taking in count that Class is an Attribute and the constructor of the later explicitly is calling .to_sym
<cored>
:-/
<cored>
sorry for all this information, just trying to make my mind around the lib
djsell has quit [Ping timeout: 252 seconds]
<dkubb>
Class.new(Attribute) is just a way of creating subclass for Attribute
<dkubb>
Class.new isn't an axiom thing.. it's part of ruby
<cored>
oh
<cored>
did not know that idiom
<cored>
looks odd
<dkubb>
youc an use Class.new(User) to make a subclass of a User class. it's often used in specs when you want to mutate a class but you don't want to mutate the original
<cored>
so Class.new(Attribute) means Class < Attribute
<cored>
?
<dkubb>
Class.new(User) is almost the same thing as class Thing < User; end
<cored>
interesting
<dkubb>
... except it doesn't make a constant named Thing
<dkubb>
it makes an anonymous class, also good for tests since it doesn't pollute the global namespace
<cored>
kinda like t = Thing.new; t.extend(module)
<dkubb>
and they can be GC'd
<cored>
right?
<dkubb>
well, this is more for making subclasses
<cored>
I mean, similar behavior of not changing the actual definition
<cored>
just the instance
<dkubb>
yeah
<mbj>
dkubb: I just pushed AST caching that reduces parser use signficantly
<mbj>
My target was to speedup unit specs, now they are close to 1s again on my machine.
<dkubb>
nice!
<dkubb>
mbj: I'm curious if you know how difficult it will be to mutate stuff in the class/module body?
<mbj>
dkubb: not very difficult
<mbj>
Lulz, my caching actually slows down axiom-types mutations.
<dkubb>
mbj: I just had a bug caused by code in a DSL being wrong, but since it wasn't in a method it wasn't caught
<dkubb>
heh
<dkubb>
that's odd, huh
<mbj>
But I'll keep it
<mbj>
As unit specs are really fast now!
<cored>
is there another easier way to add devtools to a project
<mbj>
Heh, it turns out bundler is slower in bundle exec on :path => '../mutant'!
<cored>
something like just gem 'devtool's
<cored>
and that is start to work ?
<mbj>
cored: Nope, mostly because Gemfiles cannot reference other gemfiles without magic.
<cored>
mbj: so, devtools will be always like this?
<cored>
dkubb: you closed the issue but the issue still persist, correct?
<mbj>
cored: Rubygems does not have the concept of platform specific deps.
<dkubb>
cored: no, it's fixed on master afaik
<dkubb>
cored: I just pushed a fix about 2 mins ago
kleech has joined #rom-rb
<cored>
dkubb: oh that's new
<cored>
dkubb: checking
<cored>
dkubb: which means the others pending specs that I add should be working now
<cored>
dkubb: but I'm kinda stuck with the current one, regarding Class.new(Attribute) not having the type method
mbj has quit [Quit: leaving]
<cored>
probably is because that method is a class method but the constructor is pointing to an instance method, does that make sense ?
kleech has quit [Read error: Operation timed out]
<dkubb>
cored: one tip is when you mark something pending wrap the body in a pending block, eg: pending { ... code that fails }
<dkubb>
cored: that code will still be run, but if it starts passing it will notify you
<dkubb>
cored: well, for those anonymous classes you will probably need to declare a type class method
<dkubb>
cored: I mean in the specs, since Attribute itself doesn't have a type method.. actually maybe it inherits one from Object, which would be bad. we should probably add (in Attribute itself) def self.type; raise NotImplementedError .... end
<dkubb>
cored: if you want to add that at least the errors will make more sense. there's a helper method you can use: abstract_singleton_method :type
<cored>
dkubb: hm, that's kinda looks ugly to me in some exten the raise NotImplementedError stuff
<dkubb>
cored: heh, yeah, but really it probably needs to be there since if you subclass Attribute you need to provide your own type method
<dkubb>
cored: it's not something we can provide as a default
<dkubb>
cored: if you have a ton of specs that need an anonymous type, you could always define a shared context and reuse that
<dkubb>
cored: ok, I've got to run for now, but I'll check in later. if you want feel free to leave me comments within the PR with anything you're unclear on
<dkubb>
cored: I'm going away for the weekend starting tomorrow morning, so I'm not sure how much I'll be able to reply tomorrow and over the weekend, but if you don't hear anything from me I'll be back on tuesday