Fork me on GitHub
#juxt
<
2018-12-13
>
martinklepsch17:12:57

aero question incoming: I have a custom reader that reads a file if a certain profile is used. Now that file is usually not present and only supplied in production environments:

:cljdoc/version #profile {:prod #slurp "CLJDOC_VERSION"
                           :default "dev"}
I think because everything is implemented using reader tags the file is being read regardless of what profile is being used, causing an exception in non-production environments. Does anyone have advice around dealing with this situation?

dominicm19:12:09

I have something that makes aero lazy

dominicm19:12:18

Deferreds aren't always perfect.

mccraigmccraig11:12:24

what deficiencies are you thinking of ? i use Deferreds for just about everything on the backend which isn't a pure fn...

dominicm11:12:41

#join[#state 1, #state 2]

dominicm11:12:50

That will šŸ’„

dominicm11:12:56

Same as (str #state 1, #state 2)

mccraigmccraig11:12:33

dyu mean where #state 1 and #state 2 are Deferred ?

mccraigmccraig14:12:06

so you see exceptions when you stringify two Deferreds ? that's weird, i've never seen anything like that

mccraigmccraig14:12:39

although i suppose it would be rare for me to stringify more than one Deferred without having combined them first

dominicm21:12:32

You can't really do anything with a deferred if your result is non-walkable

mccraigmccraig22:12:08

what do you mean by non-walkable @dominicm ? we commonly have opaque objects in deferreds, so presumably you mean something else ?

dominicm22:12:19

I'm thinking the other way round, a string isn't walkable. Anything that creates an opaque object, cannot take a deferred as a return value.

mccraigmccraig22:12:22

do you have some example code ? i return Deferred<String> all the time without any trouble, so i think i'm misunderstanding something

dominicm06:12:42

Implement #state as something that returns deferred<string>

dominicm06:12:06

āÆ replme aero           
[Rebel readline] Type :repl/help for online help info
user=> (require '[aero.core :as aero])
nil
user=> (defmethod aero/reader 'state
  #_=>   [_ _ value]
  #_=>   (aero/deferred value))
#object[clojure.lang.MultiFn 0x474c9131 "[email protected]"]
user=> (aero/read-config (java.io.StringReader. "#join [#state 1 #state 2]"))
"[email protected]@ec3736c9"
That's not what you wanted as a result! šŸ˜„

dominicm06:12:44

Same thing was true for #ref, but I made it specialer

dominicm06:12:24

The problem is that deferred is really a patch over the eagerness of aero. What you need is a lazy resolution mechanism. I based my solution around macros & functions. Macros (e.g. #profile) can lazily operate on what they're given. Functions have everything they're given pre-resolved. This should remove any need for deferred.

mccraigmccraig08:12:21

oh, wow, now i understand - :rolling_on_the_floor_laughing: - you are talking about aero.core.Deferred and i am talking about manifold.deferred.IDeferred !

mccraigmccraig08:12:33

which, looking at the conversation history, is entirely my fault - looks like i dyslexed into the Deferred i was familiar with šŸ˜Š

mccraigmccraig09:12:02

so now i understand what you are talking about, i think it's quite similar to a problem i had with our own app-context factory - in cljs i had factory fns which returned a promise of something, say a file-area, and i wanted other components to depend on that file-area

mccraigmccraig09:12:32

in order to do this i made the app-context factory return a Promise<app-context> - and once everything is Promise based it's fine to compose promises

dominicm10:12:39

Yep. But the root of the problem is deeper.

dominicm19:12:38

It's a major rewrite though, and it's living in a hacked up alternative branch

dominicm19:12:45

But the tests pass šŸ˜

martinklepsch21:12:04

https://github.com/ztellman/aleph/issues/441 since yada is based on aleph (IIRC) this might be interesting for juxt folks... cc @dominicm et al

martinklepsch21:12:38

Yeah, pinged you because I wasn't sure how often Malcolm is around here šŸ™‚

dominicm21:12:46

I just answer quicker because I'm addicted to my phone