<snusnu>
2 env objects? one with a comment that it extends the base one but doesn't?
<solnic>
ah those comments are outdated :P
<solnic>
lemme fix
<snusnu>
heh ok, but still, we have 2 env objects now?
<snusnu>
lol ok, it's reopening the ROM::Environment .. but yeah, we need 2 classes for that?
<snusnu>
it's a bit confusing
<solnic>
dude
<solnic>
I don’t know what’s the problem?
<solnic>
I added Environment#session
<solnic>
so you don’t have to call Session.start(env)
<solnic>
env.session { |session| } feels nicer
<solnic>
it’s just syntax suger
<solnic>
that’s all
<snusnu>
absolutely, i'm just confused with the fact that we have an extra ROM::Session::Environment i guess
<snusnu>
i'm not familiar with rom-session yet, so i noticed
<solnic>
it’s a monkey patch
<solnic>
hello? :)
<solnic>
oh you’re talking about session’s env
<solnic>
yeah it’s a proxy
<snusnu>
ah i see, i haven't noticed that yet … makes sense now, for a bit i was like, wtf
<solnic>
session’s env is basically a mutable version of rom’s env because session relations are created on-the-fly when you access them
<solnic>
when you call session[:users] it will create session’s relation wrapping users relation from rom-relation
<snusnu>
ok i see, but yeah ROM::Environment is mutable too, just sayin' ;)
<snusnu>
not complaining btw, making it immutable will probably come later
<solnic>
well
<solnic>
you’re right :P
breakingthings has joined #rom-rb
<solnic>
I have some interesting finds btw
<solnic>
snusnu: one guy tried ROM
<solnic>
and he had MAJOR performance issues
<solnic>
I did some tricks and made it much faster but it’s still ridiculously slow
<solnic>
basically when adding stuff and then deleting stuff memory adapter takes extreme amounts of time
<solnic>
I will push a repro later today
<solnic>
should be interesting for dkubb to look at it
<solnic>
like…4-5 seconds to add 16 objects and then delete them and add again
<solnic>
which is like LMAO-slow
<solnic>
memory adapter is thread safe and dkubb is using some 3rd party libs because of that, maybe that’s the reason
<solnic>
but still, it cannot be that slow
<solnic>
its so weird :)
mbj has joined #rom-rb
<snusnu>
solnic: i saw the issue and thought wtf … must be something "low hanging" tho, no way we have a fundamental problem that large
<solnic>
snusnu: we have :P
<snusnu>
lol
<solnic>
actually I will push repro in a second
cored has joined #rom-rb
<solnic>
snusnu: it’s a rails engine with AS crap etc loaded
<solnic>
maybe some AS monkey patches make things super slow
<solnic>
I will write something identical to run w/o AS / AM crap loaded
<snusnu>
omg
<cored>
morning all
<cored>
I'm kinda missing dkubb where is he?
<mbj>
cored: guess dkubb is BUSY
<mbj>
cored: even more than me!
snusnu has quit [Ping timeout: 264 seconds]
<cored>
yeap, it's looks like that
mbj has quit [Quit: Lost terminal]
<solnic>
cored: he’s been SUPER busy at work lately
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
<solnic>
heh using session is actually faster than directly inserting stuff via relations, that’s pretty neat
breakingthings has quit [Remote host closed the connection]
breakingthings has joined #rom-rb
<namelessjon>
solnic: But isn't a session doing more work?
snusnu has joined #rom-rb
jfredett has joined #rom-rb
<solnic>
namelessjon: yeah but in my limited basic benchmark it’s faster :)
* namelessjon
doesn't trust your benchmark, then :)
<namelessjon>
Or, well, finds it harder to trust
<solnic>
namelessjon: the only diff is that session runs everything at once at the end
<solnic>
vs just using relation#insert
<solnic>
so maybe that’s the case
<solnic>
namelessjon: benchmark is trivial so I don’t think I screwed up anything there
<namelessjon>
Oh, so it inserts multiple items at once or something?
<solnic>
hmm…actually no, not yet O_o
<solnic>
which makes it even weirder :D
<namelessjon>
Really
<snusnu>
offtopic (naming) question: is one name/value pair one http cookie, or one http cookie crumb, i.e. can one cookie have more than one name/value pairs?
<namelessjon>
I believe a cookie is a name/value pair
<snusnu>
so an HTTP_COOKIE header with name=value;name2=value2 is actually sending two cookies, not one cookie with two crumbs?
<snusnu>
it actually makes sense, given the "key part" is usually referred to as name .. then again, i read lots of confusing stuff with mixing vocabularies
<namelessjon>
Now you phrase it like that, I'm no longer sure
<snusnu>
heh yeah, me neither
mbj has joined #rom-rb
jfredett has quit [Remote host closed the connection]
jfredett has joined #rom-rb
kleech has quit [Read error: Connection reset by peer]
kleech has joined #rom-rb
halogenandtoast has joined #rom-rb
<halogenandtoast>
Does rom have an ActiveModel::Model interface, or can one be applied?
<mbj>
halogenandtoast: What part of the interface you are looking for?
<halogenandtoast>
I was thinking of trying to use rom in a rails application and wanted to figure out how painful it's going to be.
<halogenandtoast>
Since most of rails relies on that interface.
<mbj>
halogenandtoast: Do you expect #save, #valid? etc?
<mbj>
halogenandtoast: or #to_params?
<halogenandtoast>
model_name, to_partial_path etc.
<mbj>
halogenandtoast: Rom does not even deal with the objects interface :D
<snusnu>
ROM doesn't provide any of those, and never will
<mbj>
halogenandtoast: You can use any object :D
<snusnu>
but, you're free to implement them in your own poros i guess
<mbj>
halogenandtoast: If you can write a loader and dumper for it (transform from/to tuple)
<mbj>
halogenandtoast: so feel free to mixin ActiveModel::Model (I'd refuse to do this in my apps).
<snusnu>
iirc it's mainly a naming convention thing, you should be able to include/extend the respective amo modules into your poros
<mbj>
jo
<halogenandtoast>
mbj, snusnu: Seems like the case, I'd would probably start with none of it included until I needed it.
<mbj>
And you'll most likely end up with a better implementation if you try to avoid these :D
<mbj>
halogenandtoast: Yeah! +1
<mbj>
halogenandtoast: Make your domain objects SHARP like hell.
<mbj>
In my latest project most of my domain objects are stupid DTOs. Without behavior.
<halogenandtoast>
SHARP?
<mbj>
halogenandtoast: just uppercased sharp :D
<mbj>
halogenandtoast: To tell you about the need for an minimal interface.
<mbj>
halogenandtoast: As more you mix into your domain objects as more you loose benefits of layering.
<halogenandtoast>
Ah here I thought it was something similar to SOLID, have to be careful with caps.
<mbj>
surry
<halogenandtoast>
I love minimal interfaces.
<mbj>
Just wanna get your attention :D
<mbj>
feel welcome here!
<halogenandtoast>
method #1) initialize, method #2) Do something
<halogenandtoast>
done
<halogenandtoast>
Sometimes I need more, but I fight against adding methods.
<mbj>
halogenandtoast: Maye you like anima and concord than.
<mbj>
halogenandtoast: Yeah concord is nothing more than a small helper reducing terminal duplication in our code.
<mbj>
snusnu: BTW I'll do a major version bump to anima soon.
<mbj>
snusnu: attrs will be protected by default
<mbj>
snusnu: Anima::Public must be used for old behavior.
<mbj>
snusnu: Same chance we did to concord once.
<mbj>
snusnu: Must be protected because of equalizer :D
<mbj>
WHY THE HECK I MISSED TO RELEASE A NEW MUTANT :(
<snusnu>
mbj: sounds like a plan
<snusnu>
mbj: then again, i dunno, do you expect a lot of usecases for not doing Anima::Public ?
<mbj>
snusnu: DTOs
<mbj>
snusnu: I have LOTS of DTOs currently
<mbj>
snusnu: domain specific request objects for substation chains etc.
<snusnu>
mbj: ok, and you don't need to access their properties most of the time?
<snusnu>
mbj: also, would it work in "mixed mode"? i.e. some properties public, some protected?
<mbj>
snusnu: DTOs most of the time dont have private properties (By definition)
<mbj>
snusnu: DTO - Data Transfer Object
<mbj>
snusnu: An object that "transfers" structured state across layers.
<snusnu>
well yeah, that's my thinking, so why you want them protected "by default"
<mbj>
snusnu: Because I also use anima a lot for other cases. And for these cases I found myself anima is exposing to much original state.
<mbj>
s/original/internal/
<snusnu>
interesting, i never encountered that
<snusnu>
but i don't use anima that heavily yet
<mbj>
snusnu: I have to admit for most of the cases I might could use Concord also.
<mbj>
snusnu: But Anima instantiations are "self explaining"
<snusnu>
tbh, i always think hard about anima, if i can go with concord, i'll do that
<mbj>
snusnu: I like to initialize "very persistend" objects with anima.
<snusnu>
anima kinda implies a bag of related properties, "ideal" for stuff like DTOs obviously
<mbj>
snusnu: So objects that carry the core of my domain, for example encapsulate a specific java API.
<mbj>
snusnu: You make me think to go into Anima::Protected instead :D
<mbj>
snusnu: Nice idea to have concord and anima with inverse defaults!
<snusnu>
yeah imo, when i use anima, i know that i will be needing a lot of related properties, too many for a "regular" #initialize signature .. i mostly want to do that, for data capsules, aka DTOs .. where i want to access every property from the outside
<mbj>
snusnu: I'll review my use cases.
<mbj>
snusnu: The bad thing is, I currently dont have any tool identifing public interface that might get created "accidentally".
<snusnu>
what i noticed a few times (not that often) .. is that 1) i'd love to be able to define my own #initialize in a concord class, and be able to call super for the concord constructor, and 2) that i sometimes want to be able to do: include Concord.new(:foo); include Concord::Public.new(:bar)
<snusnu>
i'm totally unsure about 2) .. but yeah, as soon as not all state is either protected or public, we have to drop concord completely, atm
<mbj>
snusnu: I just override some attr reader visibility
<mbj>
snusnu: include Concord.new(:foo, :bar); private :bar
<snusnu>
which leads to ruby warnings ...
<mbj>
?
<snusnu>
ah ok, like that, sorry
<mbj>
This is perfect ruby (should be IMHO)
<mbj>
MRI warnings... :D
<snusnu>
no it's ok like that, i (stupidly) didn't use only private/public for already defined readers
<snusnu>
but did stuff like attr_reader :foo (in a public section=
<snusnu>
which leads to redefinition warnings
<mbj>
hah, yeah
<snusnu>
but yeah, that was just me being stupid
<mbj>
np, all are. But hopefully not at the same time :D
<snusnu>
hehe
<snusnu>
so, completely forget about 2) above ;)
<snusnu>
1) still holds tho
<mbj>
calling super should also be possible.
<mbj>
snusnu: can you open an issue?
<snusnu>
yeah, easypeasy
<snusnu>
just include a module containing #initialize
<mbj>
There is a zeppeli flying around here (one of the small ones) I need to take a trip!
<mbj>
*zeppelin
<snusnu>
hehe
<snusnu>
i think there's already an issue for that even
<snusnu>
it's not live or anything, and i haven't read about it in depth yet, but it seems to be a nice take on it
<snusnu>
the guy behind it said he's basically missing an actual project trying to be funded using the concept
<snusnu>
seems like all the ideas are purely theoretical atm
<snusnu>
oh hah! i get 0.5 too! ;)
<snusnu>
so awesome
breakingthings has quit [Remote host closed the connection]
breakingthings has joined #rom-rb
kleech has quit [Remote host closed the connection]
bf4 has joined #rom-rb
kleech has joined #rom-rb
mbj has quit [Quit: leaving]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
cored has quit [Ping timeout: 240 seconds]
halogenandtoast has quit [Quit: halogenandtoast]
cored has joined #rom-rb
<solnic>
snusnu: I think I want to use rom’s issue tracker only
<solnic>
snusnu: this will be much easier to manage
<solnic>
thoughts?
<snusnu>
solnic: that might be a good idea yeah, while involved people will probably know which project is affected, a central place for filing issues might be cool for the uninitiated
kleech has joined #rom-rb
kleech has quit [Read error: Operation timed out]
<solnic>
snusnu: frankly I don’t think we will ever need to store issues in separate projects
<solnic>
you can use labels to filter out stuff
<solnic>
much more convenient than jumping between projects
<solnic>
also you can close issues in other projects
<solnic>
in git messages
<solnic>
so it’s not a problem
<solnic>
snusnu: I’m actually thinking about putting all those three projects to the same repo…hmmm…wdyt?
<solnic>
kinda like rails and its pieces
<snusnu>
lol, same old question …
<solnic>
snusnu: not really
<snusnu>
solnic: re issues, i'm totally fine with only managing them in rom
<solnic>
snusnu: I’m talking about placement for sources
<solnic>
not about merging projects
<snusnu>
i know, i just don't see the point
<solnic>
visibility
<solnic>
simplifying setup
<solnic>
those things matter
<solnic>
you have one canonical place for the project on github
<solnic>
instead of 4
<solnic>
less to read about, less to learn
<solnic>
less to know
<solnic>
etc
<solnic>
one project to watch
<solnic>
one project to star
<solnic>
etc
<solnic>
I see only benefits
<solnic>
I also happen to work on those projects at the same time and I’m pretty sure it’ll be a common thing to do
<solnic>
I’ve got 3 clones inside rom project right now, gitignored
<solnic>
that’s why I started thinking about just making them part of the repo
<solnic>
those would remain as separate gems
<solnic>
with separate test suites etc
<snusnu>
hmmm
<solnic>
also I should mention there is a need to share various stuff between the test suites
<solnic>
would be easier if we had them in one repo
<solnic>
think about it
<snusnu>
there's really only a few things that are *very* important to me … i don't want the standalone usability to suffer, i don't want to introduce dependencies where they are not necessary, i want nothing making that easy for me, and i want as tight as possible APIs, that are nicely integrated .. and there's another thing, closely related to the *repo* merge … history .. i want an easy way to see project history, probably GH's view does
<snusnu>
that fair enough already tho
<solnic>
snusnu: good point about history
<namelessjon>
Though can't you filter the history via the start of the path?
<snusnu>
solnic: i guess GH views handle that anyway
<snusnu>
when you step into a folder, it shows you the latest commit affecting that folder .. then again, it doesn't extend to the commit log
<snusnu>
so yeah, it's kinda suboptimal
<snusnu>
namelessjon: that surely is possible .. but would involve "extra" stuff … i use the same GitX gui since ~4years .. i hate changing habits … :p
<solnic>
snusnu: you use gitx?
<snusnu>
oldskool
<snusnu>
well, to me at least
<snusnu>
heh
<snusnu>
but yeah, you know, once a tool works fair enough for me, i tend to not change it hehe
<snusnu>
solnic: i definitely see all the visibility/centralization points tho
<solnic>
snusnu: I think it’s very important
<snusnu>
i dunno tho, maybe it's just cause i'm so used to the way we did things ...
<solnic>
well
<solnic>
educating people all the time where they should report issues is fucking stupid, pardon for the language, but it really is
<snusnu>
also, i'd *hate* to start prefixing commit msgs with [rom-session] stuff … stealing precious chars from me
<snusnu>
i totally agree … is there no way to turn issues off for repos?
<snusnu>
i'd be fine with turning them off for everything but rom
<solnic>
I think you can turn them off
<solnic>
man if only git submodules weren’t so...
<solnic>
…how do I put this?...
<solnic>
frustrating to work with?
<snusnu>
also, my opinion is not final in any way, i'm happy to hear arguments from all of us, and then change my mind
<snusnu>
hah, i guess so, they were frustrating me so much at one point, that i immediately stopped using them, never to try again
<solnic>
yeah I want to run this by dan and markus
<solnic>
I use them on various projects
<solnic>
it’s so annoying
<snusnu>
hehe
<snusnu>
know what, it's all just because GH doesn't allow you to follow an org
<snusnu>
which you could, at least for some time, but only for users who transferred their account into an org (like datamapper)
<solnic>
snusnu: yeah
<snusnu>
to me, the watch/star argument weighs most
<snusnu>
the others, well, they can be handled easily
<solnic>
snusnu: this model is nicer on gitorious where you have projects and projects have repos
<solnic>
and you can watch *a project*
<solnic>
makes more sense to me
<snusnu>
absolutely
<snusnu>
solnic: lol, of course GH shows history like we want it to .. there's the History link on the right side of each page, when scoped to a folder, it only shows commits that affected this folder
<solnic>
that’s sweet
<snusnu>
i guess i could live with moving all gems into one repo then
<snusnu>
altho i still think that they somewhat loose their standalone character by doing so .. probably no big deal tho
mbj has joined #rom-rb
<solnic>
snusnu: lemme put it this way - 99.999999% of people will be using rom as a whole
<solnic>
for those who really need to use one of the pieces separately, they will know it’s possible, trust me
postmodern has joined #rom-rb
kleech has joined #rom-rb
<snusnu>
solnic: agreed
<mbj>
solnic: +1
<solnic>
mbj: ?
<mbj>
solnic: for that "99.9999" of people will be using rom as while
<mbj>
*% of people
<snusnu>
mbj: but do you agree that we should move all gems below rom-rb/rom while still keeping them separate gems inside one repo?
<mbj>
snusnu: I dont get this one :D
<mbj>
snusnu: Talk in repos to me :D
<snusnu>
lol
<mbj>
snusnu: So we should move all rom code to rom-rb/rom REPO, no.
<snusnu>
solnic wants to move rom-relation,rom-session and rom-mapper into rom-rb/rom repository, keeping them separate gems, but inside one repo
<mbj>
snusnu: But this surelywasnt your idea.
<snusnu>
...
<mbj>
snusnu: nope, separate gems/repos.
<mbj>
So we dont end up in rails/rails
<snusnu>
mbj: read the logs please, so that solnic doesn't need to repeat his arguments
<mbj>
snusnu: hah
<mbj>
will do so!
<mbj>
solnic, snusnu: Good arguments.
<mbj>
Especially the visibility thing!
<mbj>
And the issues thing etc.
<mbj>
TBH I'm convinced :D
<solnic>
yeah remember I’m talking about LOCATION of the projects, it has nothing to do with merging codebases
<mbj>
I was on a totally differend track, BUT for this case it really makes sense!
<mbj>
jo
<mbj>
I see!
<solnic>
separate test suites, keeping things decoupled, releasing as separate gems
<mbj>
directly layout would be just LIKE rails, I'll have to accept this.
<mbj>
So lets go the "one location" route.
<solnic>
yeah I don’t consider this as something bad tbh
<snusnu>
+1
<mbj>
Rails couples much unrelated stuff together.
<mbj>
Roms domain is far more narrow.
<solnic>
lemme put it this way - I worked on DM which was split into many repos and it was T-E-R-R-I-B-L-E
<mbj>
And also we extract support gems into other LOCATIONS :D
<snusnu>
not comparable tho imo
<snusnu>
rom is dm-core somehow
<mbj>
As long true support gems like equalizer, adamantium etc are still differend locations.
<solnic>
snusnu: yes it is
<mbj>
And rom-session is NOT a true support gem. It is a component!
<solnic>
actually, it’s a bit less even
<mbj>
We are on the same track.
<solnic>
conceptually :)
<snusnu>
yeah
<solnic>
yeah good point about support gems mbj
<breakingthings>
[Obligatory "everything in moderation" statement]
<solnic>
btw did you see what I discovered? in the benchmark I added to rom project today using session was slightly *faster* than just using rom-relation to insert objects
<solnic>
WEIRD
<solnic>
I thought session was broken and it didn’t insert stuff, but nope, it works just fine
<snusnu>
lol
<solnic>
I have no idea why it’s like that
<solnic>
the diff was small
<solnic>
like 0.032 vs 0.024
<solnic>
but still
<snusnu>
repeatedly i assume?
<solnic>
snusnu: yes
<solnic>
I was really like “O_o” when seeing this
<snusnu>
same INSERT statement count?
<solnic>
snusnu: geez, yes
<solnic>
go and see for yourself
<snusnu>
nah
<snusnu>
:p
<namelessjon>
Have you tried profiling it? Is there some other layer of object reuse in there?
<solnic>
namelessjon: not yet
<solnic>
I will though
<mbj>
I got my first PR from "outside" our community for unparser this day!
<mbj>
Really happy to see it beeing used.
<solnic>
mbj: I saw that, congrats :)
<mbj>
So, for coincidence I'll leave to cinema soon, watching the new X-Man mutants film :D
<solnic>
nice
<mbj>
So have fun, I'll be available for opensource over the weekend.
<mbj>
Cleaning up mutant and making the "spec widening thing" configurable via CLI
<mbj>
Also adding blacklists (my current client projects and axiom needs it).
<mbj>
Than I'll start to nitpick about your mapper :D
<solnic>
mbj: my friend used mutant recently and he liked it a lot
<mbj>
Trying to port some of my most complex mappers to ROM.
<mbj>
solnic: Nice!
<mbj>
solnic: Also I need a release, latest mutant does not fit the stack anymore.
<mbj>
solnic: Its time for 0.3!
<solnic>
:)
<mbj>
solnic: you switched to chruby ?
<mbj>
okay, have to run. cu
mbj has quit [Quit: leaving]
breakingthings has quit []
jfredett has quit [Quit: Leaving.]
kleech has quit [Remote host closed the connection]