Fork me on GitHub
#specter
<
2016-08-02
>
borkdude15:08:54

Does anyone has an example of how I should require specter from clojurescript?

borkdude15:08:00

It's missing in the intro page (that uses use)

nathanmarz15:08:44

@borkdude

(require '[com.rpl.specter :as s])
(require-macros '[com.rpl.specter.macros :refer [select transform]])

borkdude15:08:12

@nathanmarz: cool, I was trying something with :refer :all, but that isn't going to work probably

nathanmarz15:08:14

macros namespace also has declarepath, providepath, and other operations for defining navigators

nathanmarz15:08:58

yea I think you need to require macros individually

nathanmarz15:08:03

not sure, don't really use cljs

borkdude15:08:14

where should I require walker from, is it a function or macro?

borkdude15:08:54

I'm trying to get Specter going with Planck, but failing so far: https://gist.github.com/borkdude/a7706bf096e1280b3d8a3fd0b33ec95e

nathanmarz15:08:11

can you get a stack trace for that?

mfikes15:08:49

FWIW, I quickly tried that expression with older versions of specter, back to 0.9.3 and it fails in Planck in the same way. So not a regression at least. Perhaps just a problematic expression.

nathanmarz15:08:30

@borkdude: can you open an issue on github for this?

borkdude15:08:49

of course! I'm cooking right now, but will do so after dinner

nathanmarz15:08:28

@mfikes: master branch is on clojure 1.7.0 now, does that mean we should be able to integrate automated tests for specter+bootstrap ?

nathanmarz16:08:33

@mfikes: hmmm, timestamps there aren't so encouraging

nathanmarz16:08:03

would it be possible to fork test.check in the meantime with the appropriate changes? I'd be perfectly happy using that

mattsfrey16:08:26

few questions.. how would I make select* analogous to get-in, currently (select* [:bleh :blah] {:bleh {:blah 1}}) returns [1] instead of just 1

mattsfrey16:08:44

and why do the examples on the github use just 'select' when the function is select* ?

mfikes17:08:58

@nathanmarz: Yeah… let me check. There’s an issue related to Transit that might be holding it up, and if that’s the case perhaps I can address it. I agree, if no progress, I’ll pursue an interim fork.

codonnell17:08:18

@mattsfrey: There is a select* function, but it's preferred to use the select macro, as in the docs

codonnell17:08:43

and if you know you'll only be selecting one thing, you can use select-one or select-any

codonnell17:08:11

(`select` is in the com.rpl.specter.macros namespace)

nathanmarz17:08:49

@codonnell @mattsfrey select* is the navigator implementation function, which is distinct from select

nathanmarz17:08:11

select-any (introduced in 0.12.0) is the most efficient way to get one result back

nathanmarz17:08:07

@codonnell @mattsfrey nevermind, just realized you were referring to the functional version of select macro

nathanmarz17:08:48

the reason to use the macro is because it does inline caching of the navigation path, so is very efficient

hueyp19:08:52

noob question … how do I combine clauses? ;p

(spec/comp-paths THINGS spec/ALL (and (spec/selected? :category #{"A"})
                                      (spec/not-selected? :id #{1 2})))

nathanmarz19:08:01

@hueyp: just get rid of the and

nathanmarz19:08:26

(spec/comp-paths THINGS spec/ALL (spec/selected? :category #{"A"}) (spec/not-selected? :id #{1 2}))

hueyp19:08:17

perfect thanks 🙂

puzzler19:08:37

If you know you are selecting one element, what are the pros and cons of choosing select-one or select-any vs select-first?

mattsfrey19:08:52

@nathanmarz: ahh, ok it's a macro

nathanmarz19:08:34

@puzzler: select-any is the fastest

nathanmarz19:08:08

not really any perf difference between select-one and select-first (for now), they just have different semantics in terms of what happens if there's multiple elements to select

codonnell19:08:51

@puzzler: Also, select-one will throw an exception if more than one result is found, while select-first and select-any will not (as you may infer from their names)

puzzler19:08:59

Is select-any in the latest stable version 0.11.2? For some reason, although I'm "use"ing the macros namespace, I'm not seeing it.

nathanmarz19:08:44

it's in 0.12.0

nathanmarz19:08:02

should probably get around to releasing it

mattsfrey19:08:31

this question will probably sound dumb, but I can't for the the life of me figure out how to include the macros

mattsfrey19:08:42

(:require-macros [com.rpl.specter.macros])

mattsfrey19:08:44

results in..

mattsfrey19:08:13

#object[TypeError TypeError: undefined is not an object (evaluating 'bocl.account.data_test.select.call')]

codonnell19:08:17

@mattsfrey: are you using clojure or clojurescript?

mattsfrey19:08:22

clojurescript

codonnell19:08:57

I haven't done much clojurescript; you have the correct namespace. Did you do a lein clean?

mattsfrey19:08:35

i can pull in the normal lib, but not the macros

mattsfrey19:08:43

'select' is always undefined

codonnell20:08:15

maybe you need it to be (:require-macros [com.rpl.specter.macros :refer [select transform]])?

mattsfrey20:08:21

tried pretty much every permutation of :refer :all, :include-macros, etc etc and they all end up in error other than just (:require-macros [com.rpl.specter]), but that isn't actually incuding any macros

mattsfrey20:08:08

including transform made it work

mattsfrey20:08:03

actually nvm

mattsfrey20:08:04

(:require-macros [com.rpl.specter.macros :refer [select]])

mattsfrey20:08:10

definitely have to refer whichever ones you need though

mattsfrey20:08:24

:refer :all and :refer-all causes build errors

codonnell20:08:13

that's good to know

mattsfrey20:08:04

anyone know how to get the ALL keyword?

mattsfrey20:08:13

doesn't seem to be part of macros or the core

codonnell20:08:06

it should be in com.rpl.specter

hueyp20:08:04

is there clojure sugar around importing both ns's as the same alias? e.g. (s/select [s/ALL] things)

nathanmarz20:08:23

@hueyp: not that I know of

hueyp20:08:25

thanks~ upgrading 10 -> 11 so was wondering if any tricks 🙂

puzzler21:08:41

It appears that transform [ALL] on a lazy sequence does not produce a lazy sequence. Is there a way to make it operate in a lazy fashion?

nathanmarz21:08:19

@puzzler: you would need to make a new navigator for that

nathanmarz21:08:38

ALL could have been implemented to work differently for lazy sequences, but I think it's better for lazy behavior to be explicit

hueyp23:08:03

not sure which construct in specter I’d want to use … I have this:

(defn Foo
  [foo-id]
  [(spec/selected? :type #{"foo"}) (spec/selected? :id #{foo-id})])

(select [THINGS (Foo "bar")]
        things)
… which works, but I feel is wrong 🙂. I can move it to declarepath / providepath but wondering if it should use something else

hueyp23:08:19

this example could also just be a predicate fn, but other examples include navigation~

hueyp23:08:38

attempt at declarepath / provide path is

(declarepath Foo [foo-id])
(providepath Foo
             [(spec/selected? :type #{"foo"})
              (spec/selected? :id (paramsfn [foo-id] [id] (= foo-id id)))])

hueyp23:08:10

first time using paramsfn … I think it works? 😜

nathanmarz23:08:39

@hueyp: use comp-paths

nathanmarz23:08:43

(def Foo
  (comp-paths
    (spec/selected? :type #{"foo"})
    (spec/selected? :id (paramsfn [foo-id] [id] (= foo-id id)))))

nathanmarz23:08:04

declarepath/`providepath` is for defining recursive navigators

hueyp23:08:25

I saw the example with comp-paths in tests but it didn’t click

hueyp23:08:33

yah, I felt like those were wrong

hueyp23:08:36

the declare stuff

nathanmarz23:08:08

comp-paths result will be high performance and can be further composed with other navigators without its params

hueyp23:08:22

thanks much 🙂