<mbj>
xybre: anima/adamantium use pure ruby APIs. This should NEVER segfault the interpreter.
<xybre>
But 2.1 has all the cool stuff :(
<mbj>
If so its an MRI bug.
<dkubb>
I really wish ruby-core had a better approach for testing
<solnic>
xybre: it's a bug in MRI, fixed in head
<solnic>
just use 2.0 or 1.9
<solnic>
or rbx or jruby
<dkubb>
it's easy to add cool features when you don't test them :P
<xybre>
Yeah, thats true
<dkubb>
if they just ran ruby against rubyspec and the rubygems corpus, they'd find so many bugs before release
<mbj>
dkubb: I'd be totally okay if the'd only use rubyspec.
<elskwid>
dkubb: ZING
<dkubb>
mbj: yeah, you think rubyspec covers most of the cases?
<dkubb>
I guess by definition it should
<xybre>
Wait.. they don't?
<mbj>
dkubb: Its quite verbose. But I dont think they'd cover the adamantium/anima spec.
<xybre>
Then... how do they test?
<mbj>
xybre: AFAIK rubyspec is not part of their test setup per default.
<elskwid>
xybre: ding ding ding
<mbj>
xybre: There are some devs that run it locally.
<dkubb>
xybre: I think they just use their own test suite
<mbj>
Sadly ruby is a language defined by implementation. Not definition.
<xybre>
Why would anything ever be released without fucking testing??
<dkubb>
xybre: my thoughts exactly
<xybre>
Also, speaking of which, mbj, you know that Anima classes are not frozen, right?
<dkubb>
what's crazy too is we always test our stuff against ruby-head too, and the problem didn't manifest earlier, so I'd assume the segfault is caused by code that was snuck in at the last minute
<mbj>
xybre: you can use anima without adamantium.
<mbj>
xybre: Than the instances dont get frozen.
<xybre>
mbj: right, but I'm running the code in your readme, and getting different results.
<mbj>
xybre: I typically only use Anima together with Adamantium.
<xybre>
Thats one of the thigns I'm fixing.
<mbj>
xybre: that #frozen? yeah, its wrong.
cored has joined #rom-rb
cored has joined #rom-rb
<xybre>
k, its fixed in my version
<mbj>
xybre: PR it pls!
<xybre>
mbj: PR in
<mbj>
xybre: and merged! Thx!
<xybre>
mbj: How do you use it with Adamantium?
<mbj>
xybre: class Foo; include Anima.new(:baz), Adamantium; end
jgaskins_ has joined #rom-rb
<mbj>
xybre: Foo.new(:baz).frozen? # true
<mbj>
xybre: Foo.new(:bar => :baz).frozen? # true
<mbj>
xybre: sorry ;)
<xybre>
Hmm makes sense
<snusnu>
mbj: "shouldn't" it be include Adamantium, Anima.new(:bla) ?
<dkubb>
I released a new adamantium last night, which I think you saw, but I also released a new axiom-types
<dkubb>
solnic: ^^^
<solnic>
dkubb: I didn't, thanks! what about new axiom-* stuff?
<dkubb>
I'm working through them
<solnic>
ah that's great
<dkubb>
once I get the Gemfile's clear of git references I'll drop gems
<dkubb>
it's probably time for some axiom releases
<solnic>
I'd like to finish rom-mapper + morpher and continue on rom-session + UoW
<dkubb>
very cool. once I drop some axiom gems I'm going to go back to sql
<solnic>
I wil also probably come up with an axiom-abstract-adapter
<solnic>
I tweaked rom-relation yesterday to work with do-adapter and figured it's a good moment to establish the required interface
<dkubb>
yeah, the adapter interface from axiom-memory-adapter is probably the best reference
<xybre>
Random idea: Would it make sense to take a big API dump, maybe one of those awful XML responses and use axiom to query it? I heard someone was doing it with CSVs.
<solnic>
dkubb: I'm not sure yet
<dkubb>
xybre: it coulde be done
<solnic>
there are things in memory adapter that are not needed elsewhere, like keeping @schema with built relation gateways
<solnic>
for DO we just need an adapter to return the wrapped relation
<solnic>
nothing else is required
<dkubb>
xybre: depending on how large the xml file is, you'd probably want to use a sax based parser so that you can scan the text and match in chunks, rather than building up a huge DOM and matching that
<solnic>
and having []= for that feels weird
<solnic>
it's also a bit ambigious, like when you look at "[]=" method you can't really tell what it does except that it assigns something under some key, in case of the adapter it actually builds a gateway so a different method name would be more descriptive
<xybre>
dkubb: I assumed it'd already be loaded into memory by like Nokogiri or as a hash or other complex set of objects already.
<jgaskins_>
how many twitter accounts do you have?! :-)
<xybre>
jgaskins_: One for each of my double lives ;)
<dkubb>
solnic: hmm, that wasn't the exact design I was going for
<dkubb>
solnic: I think we need a few more adapters before we can generalize it. maybe mbj should write the abstract adapter since he's written more than even I have
<xybre>
jgaskins_: I tend to compartmentalize most things. The problem comes in becauase I've always hung out on Freenode and IRC in general as xybre, so when I get into dev discussions it inevitably links people back to my dev compartment. If I was less lazy, I'd have a seperate connection using my "acook" handle to lessen the confusion.
<dkubb>
there's a bit of drift between the memory and do adapters that we need to resolve too
<mbj>
dkubb: To push down stuff to the adapter I currently Imagine an AST based rewriter.
<solnic>
ok, I will just do stuff inside rom itself
<mbj>
dkubb: So we dont need to build an RA tree with a "consuming adapter gateway"
<mbj>
dkubb: thats a nice idea, but IMHO its just easier to do this via ASTs describing the RA tree.
<mbj>
dkubb: I'm not 100% sure if its possible, just showing an idea.
<solnic>
I have no idea what "an AST based rewriter" means
<mbj>
solnic: Currently RA trees and how such an RA tree gets ops pushed down is defined on how the gateway adapter relations "consume" Operations.
<mbj>
solnic: So the whole query must be build on the adapters base relation.
<mbj>
solnic: In the current design.
<mbj>
solnic: I'd love if we'd not have this restriction.
<mbj>
solnic: This restriction could also turn out to be a good feature.
<mbj>
solnic: I'm just mentioning an tree of RA operations repesented in AST style could also be used to push down operations through an adapter.
<mbj>
solnic: Without the need of an adpater specific base relation while building the RA - tree.
skade_ has quit [Quit: Computer has gone to sleep.]
jgaskins_ has quit [Quit: This computer has gone to sleep]
mkristian has quit [Quit: bye]
<solnic>
mbj: sorry I was on a long call
<solnic>
mbj: I'm not really sure if I understand but that's OK. I'm gonna just focus on my short-term goals
jgaskins has joined #rom-rb
<solnic>
mbj: I'm pretty sure whatever it is that we're gonna release as version 1.0 will quickly become 2.0 and then 3.0 so let's just start with something; it feels like we're trying to build a perfect thing right from the start - ain't gonna work like that
<solnic>
so, I'm gonna just continue working on stuff using what we already have (we have quite a lot)
<mbj>
solnic: I dont like a major version race.
<mbj>
solnic: Not something spiky
<mbj>
solnic: And 1.0 I'd like to release should be solid.
<solnic>
mbj: 1.0 is stable interface
cored has quit [Ping timeout: 272 seconds]
<solnic>
mbj: treating 1.0 as some kind of a holy version is really bad
<solnic>
I'm fine with releasing 1.0 if I'm happy with the public API
<solnic>
also, define "solid"
<solnic>
because for me something that's useful and has a stable interface == solid and ready for 1.0
<solnic>
mbj: lemme put it this way - if it's possible to build an app using ROM and we're happy with the interface then it's ready for a 1.0 release. otherwise you will work endlessly on it
<mbj>
solnic: solid == Nice public API
<mbj>
solnic: And not broken.
<mbj>
solnic: And nice public API does not create "ugly internals".
<solnic>
mbj: not broken? O_o
<solnic>
that's kind obvious we don't want to release broken libraries
<solnic>
not sure if there's a strong connection between nice public API and quality of internals
<solnic>
anyhow, gotta run
<solnic>
ttyl
<solnic>
oh one more thing - I don't think we can get things 100% right from the start, we will need at least 2 major versions to achieve something "solid" as you said
<solnic>
there are many more factors here; we may hit issues we haven't thought about
<solnic>
running now, ttyl
judofyr has quit [Remote host closed the connection]
judofyr has joined #rom-rb
judofyr has quit [Ping timeout: 248 seconds]
snusnu has quit [Quit: Leaving.]
snusnu1 has joined #rom-rb
judofyr has joined #rom-rb
judofyr has quit [Ping timeout: 252 seconds]
judofyr has joined #rom-rb
judofyr has quit [Ping timeout: 246 seconds]
<xybre>
Some types of nice public APIs do result in ugly internals, or least some interesting metaprogramming, but other than that, nothing dictates what your code looks like. You know, except the Socket interface, which is just damn ugly..
<solnic>
xybre: yeah I can have a fantastic public interface with really crappy internals
<solnic>
and I can have fantastic internals with a really crappy public interface :)
<xybre>
Since I tend to design UI down, sometimes I'll realize that the nice API I had in mind will mean some heavy lifting on the backend.
<solnic>
I think UI always drives the rest of implementation
<solnic>
for instance in rails starting with basic UI and high-level acceptance tests is nice
<solnic>
it's a great starting point
<xybre>
Speaking of heavy lifting on the backend, have you guys noticed things getting simpler using a lot of the functional-style in Ruby? I've always thought the functional style was generally noisy/messier from a coders standpoint, and I wonder how the GC handles all those immutable objects.
<xybre>
I see tools like Anima, IceNince, and Adamantium, or is it just dkubb that is into that (since I think they're all his)?
<solnic>
xybre: I avoid mutating things too these days
<solnic>
I haven't done it on a larger scale yet
snusnu has joined #rom-rb
<xybre>
I should look through my code and see how often objects in memory actually are mutated. I bet not often, which is actually kind of interesting, I hadn't thought about it before.
<solnic>
I try to design objects in a way that mutation is not needed
<solnic>
I also avoid ||= idiom
<CraigBuchek>
How do you avoid the ||= idion?
<solnic>
it's way nicer when all you need to do in order to know how an object looks like is to look at its constructor
<CraigBuchek>
Sometime things take a while to compute.
<CraigBuchek>
Even with value objects.
<solnic>
CraigBuchek: that's the trick, if something is not always needed, then why is it there in the first place?
<CraigBuchek>
For instance, if you've got a geograhic location object, you might store x and y, but want to get polar coordinates instead.
<CraigBuchek>
And that conversion might be costly.
snusnu1 has quit [Ping timeout: 272 seconds]
<solnic>
yeah there are many valid cases where it makes sense to use it
<solnic>
I said I avoid which doesn't mean I never do that
<xybre>
Yeah I do lazy evaluation/memoization a lot. I don't like heavy lifting being done in the constructor.
<solnic>
it's one of those things in ruby that was used too often
<solnic>
so I avoid it
<CraigBuchek>
OK, I think you're just saying try to make value objects, which gets rid of a lot of the need for ||=. but not all.
<CraigBuchek>
I've wondered what Ruby would look like if we could default objects/classes to immutable and methods as pure.
<CraigBuchek>
Then the language iteslf could memoize for you when appropriate.
<solnic>
whole axiom is built like that (or at least 99.9% of it)
<solnic>
so if you wonder how it looks like, look there
<solnic>
all methods have no side-effects, there's no mutation in-place, any change to an object results in a new instance with the new state etc
<solnic>
this actually makes working with axiom really freaking awesome
<CraigBuchek>
Yeah, I like that style.
<solnic>
I know as I tried to use ARel which is mutable all over the palce
<solnic>
place even
<solnic>
funny, "palce" means "fingers" in Polish :D
<solnic>
anyhow, I love this style
<solnic>
I'm a little worried it's gonna be a bit slow on a larger scale but we will see
<CraigBuchek>
Yeah, that's why I wish the language defaulted to immutable in order to encourage that style.
<solnic>
we'll see :)
<solnic>
one thing I know for sure is that this style of programming is just better
<solnic>
ok gotta go get some sleep. good night!
<CraigBuchek>
Good night. Good to see you here.
<solnic>
CraigBuchek: oh thanks! <3
skade has joined #rom-rb
solnic has quit [Quit: Leaving...]
mbj has quit [Ping timeout: 246 seconds]
skade has quit [Quit: Computer has gone to sleep.]