skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
mbj has quit [Quit: leaving]
kapowaz has quit [Ping timeout: 260 seconds]
lgierth has quit [Quit: Ex-Chat]
lgierth has joined #rom-rb
robertjpayne has quit [Remote host closed the connection]
lgierth has quit [Remote host closed the connection]
lgierth has joined #rom-rb
lgierth has quit [Client Quit]
<dkubb>
good morning
dkubb has joined #rom-rb
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
<dkubb>
solnic: I'm not sure if you're even in the channel, but I saw your tweet/email about being burnt out. sorry to hear that, but I totally understand it.. I've burned out on OSS a few times. the good news is that you'll be able to rest and if you do come back you'll be able to balance things a bit better to make it less likely next time
<dkubb>
solnic: it's probably good timing too, because I knew you have another baby on the way and you were going to take off October anyway
<dkubb>
not that anything can be good timing. it always sucks when this happens. I really appreciate the work you've done on ROM and virtus. I hope you get lots of rest and come back feeling refreshed
skade has quit [Quit: Computer has gone to sleep.]
mbj has joined #rom-rb
<mbj>
hola!
<dkubb>
mbj: hola!
<jfredett>
I have a semi-philosophical question about concord — is there a reason you decided to make it limit you to three compositions? I understand the goal was to compose data objects and that maybe more than 3 is not great, but it seems somewhat arbitrary. My use case for it is purely utilitarian, I have a bunch of DSL-defined classes that all need to act like immutable data objects when instantiated (they are elements of a parse tree), an
<jfredett>
I guess what I'm really asking is — is there a reason that setting isn't configurable/injectable
<mbj>
jfredett: I take full blame.
<mbj>
jfredett: Lets say it this way. Concord is NOT for building DTOs.
<mbj>
jfredett: Its for building logic. And with logic you normally face a complexity explosion if you compose from too much objects.
<jfredett>
mbj: but it works _so well_ for that (and it let me delete like, 40LOC from my little compiler. :) )
<mbj>
jfredett: Initially it had an upper limit of 2.
<jfredett>
mbj: fair enough
<mbj>
jfredett: Than I raised it to 3.
<mbj>
jfredett: And yeah I love it to reduce "obvious" code.
<mbj>
jfredett: You considered anima? Anima works very well for n attributes.
<jfredett>
mbj: in my case it's representing an expression AST, so there are a couple of functions with 3 arguments.
<jfredett>
and I got bit when it was 2
<jfredett>
or something
<snusnu>
hey guys
<jfredett>
I haven't, I didn't need much, and I was already using Equalizer
<mbj>
jfredett: Anima includes equalizer also ;)
<jfredett>
replacing with concord was a −39 line change.
<jfredett>
:)
<mbj>
jfredett: Hehe, yeah concord has positional argument interface.
<snusnu>
mbj: fwiw, i'd vote for making it configurable too … also, i agree with your general take, but really, 3 is *very* arbitrary, and it surely wouldn't hurt if an essentially magic number, would be replaced with configuration
<mbj>
jfredett: BTW if you deal with an AST, you should consider whitequark/ast
<dkubb>
snusnu: good morning
<snusnu>
dkubb: hey dkubb
<snusnu>
lol, that looks weird
<mbj>
jfredett: It has a mind blowing concept. Its by *far* the most processable AST representation I saw.
<jfredett>
mbj: I think I remember opening anima in a tab, but not reading it. Basically the last few person-hours I've spent working on this little project of mine has been 'putz around in the rom-rb ecosystem, steal something, repeat'
<mbj>
jfredett: hehe
<jfredett>
mbj: I might have to dig into the AST bit, I've been trying to avoid it so far by defining my parser in terms of a couple instance_eval hacks, but ultimately the actual making of the Expression AST is less critical then building the simplifier/differentiator bits.
<mbj>
jfredett: Because mutant uses it internally. And mutant is a central tool ;)
<mbj>
jfredett: whitequark/ast is also somehow central to rom.
<jfredett>
which I'm procrastinating on, because it's hard and I don't want to do the cheap hacky method, but also don't want another little DSL in the project.
<mbj>
jfredett: I'll accpet patches to make that limit configurable. Maybe you can create your own concord in your namespace.
<mbj>
jfredett: But that limit should NOT be adjusted globally.
<snusnu>
mbj: i like the idea, but really, the interface can't be what you really think should be the interface? ;)
<mbj>
snusnu: Yeah interface is stupid. Just my first idea.
<jfredett>
mbj: tbh, I think Anima is probably what I wanted, though I'm not entirely sure what the difference is between it and concord.
<mbj>
jfredett: class Foo; include Concord.new(:bar); end; Foo.new(a_value_for_bar)
<jfredett>
mbj: one thing I've found I like doing is doing a dynamic definition a la `SimpleDelegator`, so you'd do `include Concord(2).new(:foo, :bar)`
<mbj>
jfredett: class Foo; include Anima.new(:bar); end; Foo.new(:bar => a_value_for_bar)
<jfredett>
aah
<jfredett>
yah
<mbj>
jfredett: Also Animas attributes are by default public
<jfredett>
I can't have the hash bits.
<mbj>
jfredett: Concords attributes are by default protected.
<jfredett>
that's probably why I skipped over it
<mbj>
jfredett: I'd love to move to kwargs. But I'll do this later once 1.9 dies.
<jfredett>
well, more generally, I need them to be positional (well, I could make them nonpositional, but it's a bit tricksy, because I'm metaprogramming these classes in based on a DSL)
<mbj>
jfredett: +1 for abstracting away the DSL from your code domain (the AST).
<snusnu>
mbj: btw, offtopic, are there any specific ducktrap processors for dealing with "regular" form params sent with a post?
<mbj>
snusnu: Nope
<mbj>
snusnu: I had some.
<snusnu>
mbj: you do custom ones with your stuff?
<jfredett>
mbj: you have no idea… I have a DSL for defining the DSL… :)
<mbj>
snusnu: Yeah
<mbj>
jfredett: hehe
<snusnu>
mbj: ok
<snusnu>
mbj: mind sharing one of those? ;)
<mbj>
snusnu: They are gone.
<mbj>
snusnu: angular form submissions via JSON.
<mbj>
snusnu: Dont have the time to "DIG" in git. surry.
<snusnu>
mbj: what about a login form? i thought we recently talked about that
<mbj>
dkubb: And it should be far more stable than that one ;)
<mbj>
dkubb: You could use mutants source extractors!
<mbj>
dkubb: I have code for matching methods against source location that covers all edge cases I know.
<dkubb>
oh yeah?
<dkubb>
I guess the #to_source part could use unparser
<mbj>
dkubb: I need to have something like sourify buildin to mutant.
<mbj>
dkubb: *sourcify
<dkubb>
would you still use parsetree for 1.8?
<mbj>
dkubb: Else I could not find something to mutate ;)
<dkubb>
not you, I mean, just if you were recommending it to someone to build
<dkubb>
or I guess 1.8 is dead so it'd be a waste of time
<mbj>
I'd ditch 1.8 and use parser.
<mbj>
Jo
<mbj>
>= 1.9
<mbj>
1.8 is dead.
<elskwid>
ping @solnic
<elskwid>
er, ping solnic
<elskwid>
Yay. I can computer.
<dkubb>
elskwid: I'm not sure if he's around atm
<elskwid>
dkubb: Thanks. He just DM'd me on Twitter and I figured it would be faster here.
<dkubb>
if I was going to jump into virtus today, my first start would be to look at the oldest issues first and triage them
<dkubb>
assuming I didn't have an itch to scratch of my own ;)
<dkubb>
some of them may not be applicable because they've been resolved in master, or some might be doable to fix because of recent improvements, etc
<elskwid>
dkubb: Right. I want to have a quick chat so I can keep the project going (if at all possible) and that the direction is in keeping with his goals.
<dkubb>
it's not super sexy work, but it's probably a good thing to start with. I think keeping the open and active issue list as small as possible is a good idea in general
<dkubb>
elskwid: if I hear back from solnic I'll let him know you were asking where to start. I'll ask him to let snusnu, mbj and I know what his goals are so that at least we can point people in the right direction if he's not around
<dkubb>
virtus is pretty cool, but afaik when it hits 1.0 it will be feature complete, and the interface will be solid, so bug fixing will probably be where things shift
<elskwid>
dkubb: I agree with that, for what it's worth. :)
<jfredett>
elskwid: hit me up after the first, and you'll have my axe in maintaining virtus (I'm funemployed as of then, to work on getting to grad school, so I should have plenty of time to work on virtus)
<dkubb>
elskwid: I might also suggest running "rake ci" on virtus and looking at what it flags. I believe the plan was to get it to pass before 1.0
<dkubb>
mbj: ok, I was thinking when/if we update axiom to use the ast gem internally, we could have the in-memory adapter generate efficient ruby code from the ast that'll process the tuples
<dkubb>
mbj: I was wondering though how much overhead there'll be in generating ruby code and evaling it
<dkubb>
mbj: right now we basically just process the ruby objects, but it is probably not as efficient as it could be if we were working with primitives in generated code
<mbj>
dkubb: It will be the typical optimization tradeoff. Does the optimization process take longer than the optimized effect.
<dkubb>
mbj: I know you were talking about that with ducktrap, but I'm unsure how efficient it'll be
<dkubb>
mbj: yeah, and perhaps it is something that could be done lazily. so like the first time it does it in-memory.. but it spawns off a separate thread to create the optimized processor code for the next time
<mbj>
dkubb: So lets say it this way: Mutant does a lot of ruby generation. A LOT. And the emitter is barely visible in profiles. Rspec execution time is the major profile hit.
<dkubb>
mbj: and if the object is GC'd then the processor is GC'd.. but if it's used again it can use the optimized version
<dkubb>
interesting
<dkubb>
mbj: I wonder if you evaluate code whether it blows away the global method cache
<mbj>
dkubb: Also I have another interesthing thought I discussed with some folks at eurucamp.
<mbj>
dkubb: Implementation specific.
<dkubb>
heh
<jfredett>
mbj: it does, iirc.
<mbj>
dkubb: jruby for example has a very fine grained cache system.
<jfredett>
virtually anything interesting does.
<jfredett>
I have a link for this somewhere, though I don't know if it addresses eval proper, I remember that `instance_eval` blows the cache
<mbj>
dkubb: So my idea was, what if we'd have a heap the GC is allowed to place objects in. And this heap would be allocated per request. (Talking about webapps).
<dkubb>
I suppose another option, and this is something I just thought of, is you could have a mode where you log out the behaviour of the relations at runtime. then you can inspect the file and generate optimized code from it for the next time. it's a bit nasty, but it could work
<mbj>
dkubb: With our current immutable style we'll NOT have any objects leaking outside the Request.
<dkubb>
in ROM/axiom there'll be quite a few relations that are "global" in nature.. or rather things that will be used over and over
<mbj>
dkubb: But I think its a nice idea.
skade has joined #rom-rb
<mbj>
dkubb: This would need help from the implementations.
<mbj>
dkubb: Imagine a close to 0 GC overhead on request processing ;)
<mbj>
dkubb: So that heap could be droppped AS IS after the request handler finished. Resulting in a single free operation (and some hosekeeping). No need for more tricky GC operations.
<dkubb>
one other thing I noticed is that AR is moving to a system where SQL queries are cached per relation
<dkubb>
you wrap some code in a block, and give it some object as an identifier, and it goes through the work of generating the SQL. the next time the block is executed the cached SQL is used
<dkubb>
I saw a presentation tenderlove gave at a local meetup a few weeks ago about it
<dkubb>
ok, I've got to run to do some client work, but I will bbl
dkubb is now known as dkubb|away
skade has quit [Quit: Computer has gone to sleep.]
<mbj>
cored: That one from eurucamp was my first talk ever. So do not expect a brilliant presentation ;)
<mbj>
cored: The second one I gave at FrOSCon was far better. Also I had 45min and a nice Q&A.
<mbj>
cored: But that recording does NOT have sound ;)
skade has quit [Quit: Computer has gone to sleep.]
im_jebus has quit [Ping timeout: 256 seconds]
<elskwid>
jfredett: Roger that.
<cored>
mbj: got it
<mbj>
jfredett: Does whitequark/ast fit into your use case? Do the AST nodes need to carry behavior? Is there need for AST transformation?
<jfredett>
mbj: haven't had a ton of time to look at it just yet
<jfredett>
but it does look interesting
<mbj>
jfredett: Can you speak about your DSL domain?
<mbj>
jfredett: I'm just curious ;)
<jfredett>
mbj: I built `jfredett/katuv`, and one of the tertiary goals of this Automatic Differentiation project I've been working on is to try to exercise ways to make it better
<jfredett>
basically, katuv is a hack, and I want to make it less hacky
<elskwid>
mbj: Have you looked at the work Twitter did on Kiji(sp?)? It was cool stuff where it was smarter about promoting long-lived objects.
<elskwid>
mbj: Regarding your special heap.
<mbj>
kapowaz: ods a DDSL ;)
<mbj>
kapowaz: a dsl for dsls ;)
<jfredett>
the idea is that DSL's done in the standard instance-eval style are actually pretty easy to generalize into a nice little framework for building what is essentially a parse tree
<jfredett>
mbj: basically
skade has joined #rom-rb
<jfredett>
at some point I want a katuv DSL for defining katuv DSL's
<mbj>
jfredett: You think self hosting is possible here?
<jfredett>
but the way I go about things at the moment is… well, it's hacky
<mbj>
jfredett: *without reimplementing ruby
<jfredett>
mbj: it is if I generate a set of bootstrap classes
<jfredett>
so if I have some katuv/core
<jfredett>
that I implement some of the higher level features in
<mbj>
jfredett: Its an interesting approach
<mbj>
jfredett: The whole idea of defining a dsl this way.
<mbj>
jfredett: I maintain multiple DSL and deduplicating them would be really nice.
<mbj>
jfredett: Currently my dsls are build around a keyword registry and method_missing.
<mbj>
jfredett: And instance_eval / yield. (if you invoke with a block that takes args).
<jfredett>
mbj: that's been one of the discoveries I've made — the core -> extended mapping, dugout (which is the current home of this autodiff thing) has a similar approach
<jfredett>
define a minimal DSL for defining a bigger DSL
<jfredett>
yah
<jfredett>
mbj: the original ideas for katuv were borne out of a large EDSL I worked on at work
<jfredett>
big declarative thing where we did that
<jfredett>
and then the inevitable happened
<mbj>
jfredett: Been there ;)
<jfredett>
after we had a bunch of code written in the dsl
<jfredett>
we wanted to change a foo to a bar somewhere
<jfredett>
and there were regexes
<jfredett>
and I knew only pain.
<mbj>
hehe
<mbj>
Yeah. Over DSLism.
<mbj>
If a DSL isnt "thin" and needs regexps, I think its a misuse of this pattern.
<jfredett>
I ended up working on something else that needed a DSL, and wrote the first hack of Katuv in a branch, mucked with it, and said, "This is deserving of more study"
<jfredett>
anyway, one thing I've definitely found is the need to make it friendlier to transform the AST
<jfredett>
it's pretty hard to get anything done, and even basic stuff requires digging around and tossing constants at things.
<jfredett>
this whitequark/ast thing seems interesting
<mbj>
jfredett: You'll need the concept of an AST walker
<jfredett>
mbj: yah, when we implemented it it was very much "make it work" without a lot of forethought, so there was a highly direct mapping between business objects and DSL code
<jfredett>
as in, a lot of the top level DSL methods were aliases for `#new`
<mbj>
jfredett: That builds up the domain specific object tree.
<mbj>
jfredett: And here comes whitequark/ast into the game.
<mbj>
jfredett: Walking and transforming that thing is *easy*.
<jfredett>
yah, katuv has some basic visitor stuff, but it's recursive (which I don't love), and it's a bit tough to add stuff to those classes without making stuff less than SOLID...
<jfredett>
yah
<mbj>
jfredett: For example implementing unparser in given quality and speed was only possible because of this uniform public interface each AST node has.
<jfredett>
what I *really* want is Transformers a la Parslet
<jfredett>
and it looks like ast is a path to that kind of victory
<mbj>
jfredett: Recursive visitors arent that bad. Mostly because nobody will write insane nesting levels.
<jfredett>
mbj: yah, but it just sort of *feels* wrong.
<jfredett>
which is odd, coming from a erstwhile Haskeller.
<mbj>
jfredett: Why it feels wrong? You are walking a finite recursive datastructure with a finite recursion ;)
<mbj>
jfredett: If you walk iterative you'll somehow simulate a stack again. So no win.
<jfredett>
mbj: yah… I should probably just get over myself on that one. :)
<mbj>
jfredett: heh
<mbj>
jfredett: My rule is: Do the simples powerful thing that does work.
<jfredett>
mbj: yah
<mbj>
jfredett: Only if there is a problem with the most simple strategy, I'll consider more powerful ones.
<jfredett>
I tend to end up in analysis paralysis land on a regular basis.
<mbj>
jfredett: heh, yeah you need to start the feedback loop.
<jfredett>
it's my kryptonite.
im_jebus has joined #rom-rb
<mbj>
jfredett: been there.
<mbj>
jfredett: And it took me years to stop it. I still have NIH. Also quite hard.
<jfredett>
mbj: I am the president, chancellor, emperor and court jester of the Kingdom of NIH.
<jfredett>
:)
<jfredett>
I solved that problem by just trying to do stuff that hasn't already been done, though. NIH becomes "Not invented anywhere"
<jfredett>
:)
<mbj>
jfredett: I try to force myself to limit NIH outcome to OSS activity. And it works. Sometimes (and more often!) it feeds back to my commercial work.
<mbj>
jfredett: And lulz on our statement above ;)
<jfredett>
mbj: *nod*, same for me.
<mbj>
jfredett: Heh, maybe I'm just the biggest NIH infected person ever. Because somehow the clients problem always finds something that needs my OSS stuff.
<mbj>
jfredett: But for a person with "recursion avoiding" you have a pretty decend domain: http://recurs.es/ ;)
<jfredett>
mbj: I know that, at least for the last few weeks, it's been "Hmm, dunno how to solve this… sounds like I need to dig through the ROM folkses githubs…. aaand there it is."
<mbj>
jfredett: I'm happy to think also about that DSL-DSL problem. I need to solve this duplication also.
<jfredett>
also, it's given me some salve for impostor syndrome recently, walking around seeing code that looks like I wrote it with someone else's name attached.
<jfredett>
hehehe
<jfredett>
like I said, erstwhile Haskeller
<jfredett>
it's not so much that I avoid it, it just seems not very object-y
<jfredett>
mbj: cool. I think I've got a sense of direction on it — I've been looking at building a little pattern matcher for the simplifier part of the autodiff, but that's going to need a cleaner way of walking over trees, so I think it's time for katuv to get that cleanup It's been headed towards. the `ast` thing seems to carry a lot of that load. The remaining question is figuring out where to draw the lines between DSL, Parse Tree, AST, a
<jfredett>
I think katuv could be quite nice if I can get it into a state where it's easy to build up instead of where it is now.
<mbj>
jfredett: I'd use it.
<cored>
mbj: curious about something, why is the Ruby AST represented as set of lists like in LISP ?
<mbj>
cored: somehow
<mbj>
cored: There are two "styles" I know.
<mbj>
cored: The other is nested uniform datastructure. Benefit: Generic processors are possible.
<mbj>
cored: One is class per node. Benefit: Somehow self communicating.
<mbj>
cored: I strongy encourage to sue the uniform datastructure. Its is far easier to write processors.
<jfredett>
mbj: that. that is a very good insight, and precisely what I needed to hear (in addition to reading through `whitequark/ast`)
<mbj>
jfredett: haha, yeah
<jfredett>
katuv _clearly_ just needs to be a friendly frontend to making Node's in this thing, and can provide a friendly DSL for making processors.
<jfredett>
so that you get the benefits of the uniform DS, but the communication of one-class-per-node.
<cored>
mbj: got it, thanks
cored has quit [Ping timeout: 264 seconds]
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
knowtheory has joined #rom-rb
revans has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
<mbj>
intern
<mbj>
lulz this is a command to teardown my multi monitor setup into the "internal" one.
<mbj>
That one that is buildin to my notebook....
<mbj>
So I'm about to leave ;)
<mbj>
cu, maybe online later.
mbj has quit [Quit: leaving]
jfredett has quit [Quit: Leaving.]
breakingthings has quit []
im_jebus has quit [Ping timeout: 264 seconds]
im_jebus has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
cored has joined #rom-rb
cored has joined #rom-rb
<cored>
hello
<snusnu>
hey cored
<cored>
snusnu: hi
<cored>
was looking for dkubb
<cored>
want some guidence regarding dm-ambition but on top of axiom
<snusnu>
cored: ah ok, well, i guess i can't help you with that