Fork me on GitHub
#planck
<
2017-03-27
>
futuro15:03:18

Does Planck currently offer asynchronous file read/write?

mfikes15:03:55

It imitates the system.

futuro15:03:56

Cool, just wanted to double check my brief tour through the source

futuro15:03:51

How do you feel about adding asynchronous counterparts to the synchronous file operations?

futuro15:03:26

I've been thinking more about the point of threading in the nREPL server, and I believe the reason there's no async i/o is because you just wrap things in thread or future calls

futuro15:03:58

However, JavaScript doesn't have that ability, instead opting for callbacks and event loops

mfikes16:03:06

I see no issue with that. (Planck already has support for an async variant of clojure.shell, for example.)

futuro16:03:55

(Turns out I can just edit my comments)

futuro16:03:50

Cool; I'll mess around with abio and see if I can come up with a prototype

achikin19:03:49

Hi! I’m trying to hack around in planck and stuck with adding external dependencies.

achikin19:03:25

Works great with clojurescript.csv but things like clojure.data.xml or clj-http refuse to load.

slipset19:03:46

planck has http suport

slipset19:03:13

and I’d be surprised if clojure.data.xml has (standalone)clojurescript support

mfikes19:03:24

@achikin Looks like some of the libraries you are trying to load are Clojure libs

mfikes19:03:31

For HTTP, require the planck.http namespace and then do (dir planck.http)

slipset19:03:32

hmm, there is a cljc file in clojure.data.xml

mfikes19:03:43

A small example is at the bottom of http://planck-repl.org/planck-namespaces.html for HTTP

achikin19:03:04

@mfikes it works perfectly, but I wanted to use planck to explore several “native” libraries.

mfikes19:03:09

What kind of error do you get with clojure.data.xml? (Perhaps it is not compatible with self-hosted ClojureScript.)

achikin19:03:31

From the docs of clojure.data.xml The Clojurescript implementation uses the same namespace as the Clojure one clojure.data.xml.

slipset19:03:50

@achikin what version are you using?

slipset19:03:52

the docs suggest 0.0.8 as the latest stable, which doesn’t seem to contain cljc stuff.

mfikes19:03:10

@slipset is right. It only contains clojure/data/xml.clj

slipset19:03:54

Current alpa seems to be at 0.2.somethingrather.

slipset19:03:56

If you’re interested, I could code up a suggestion for this...

slipset19:03:07

Won’t be happening on this side of easter though (I think)

mfikes19:03:31

Issue #446 seems reasonable. I bet to pull it off you'd have to convey it via a well-known JavaScript variable.

slipset19:03:00

maybe, but you’ve got in-ns as a special thing in planck, right?

achikin19:03:02

@slipset you’re right - i’m on 0.0.8

slipset19:03:45

so I was thinking something like *repl-capabilities* or some such

mfikes19:03:27

If it were exposed at the ClojureScript level, I wonder what namespace it would be in.

slipset19:03:27

How’s it done with in-ns? Because I found that lumo has lumo.repl/in-ns whereas planck has it as in-ns

slipset19:03:50

(and it seems to live in clojure.core in, well clojure.

mfikes19:03:29

I don't understand the in-ns question. FWIW, in-ns is a REPL special that switches to, or creates a namespace.

slipset19:03:06

my point is that in lumo and clojure, you need to prefix in-ns.

slipset19:03:26

in lumo it’s lumo.repl/in-ns in clojure it’s clojure.core/in-ns.

slipset19:03:56

Whereas in planck it doesn’t hava a ns, it seems to live at some top-level, since it’s only called by issuing in-ns

slipset19:03:34

My thought was that if you had a function/var which lived in the same place as plancks in-ns, it could be the same place for all repls.

mfikes19:03:17

Oh. Right. You are effectively saying *repl-capabilities* could be a REPL special. Gotcha.

slipset19:03:46

I’m not a standalone-repl-native speaker 🙂

mfikes19:03:19

Actually, FWIW, in the regular ClojureScript REPL, in-ns is a REPL special as well.

slipset19:03:36

also, planck is lagging behind lumo, since lumo has get-arglists

mfikes19:03:54

What is get-arglists?

mfikes19:03:09

I've seen the ticket. I've just never heard of it...

slipset19:03:34

I imagine it’s a way to ask the arguments of a function?

mfikes19:03:24

It is a function defined in Clojure?

slipset19:03:58

user=> (-> 'println resolve meta :arglists)
([& more])
user=>

slipset19:03:24

That’s from my clojure repl.

slipset19:03:43

user=> (-> '+ resolve meta :arglists)
([] [x] [x y] [x y & more])
user=>

slipset19:03:49

resolve doesn’t, err, resolve in planck.

mfikes19:03:50

cljs.user=> (require '[planck.core :refer [resolve]])
nil
cljs.user=> (-> 'println resolve meta :arglists)
([& objs])
cljs.user=> (-> '+ resolve meta :arglists)
([] [x] [x y] [x y & more])

mfikes20:03:07

So, what did Lumo do?

slipset20:03:25

(lumo.repl/get-arglists \”%s\")

mfikes20:03:33

(I'm on Lumo 1.1.0 which doesn't seem to have it.)

slipset20:03:37

that’s from inf-clojure.el

slipset20:03:06

funny, doesn’t seem to exist

slipset20:03:33

but the inf-clojure.el (the emacs lisp for implementing inf-clojure) mentions it.

mfikes20:03:04

Ah. Interesting. With Planck, I took the approach of porting Clojure core functions by putting them in the planck.core namespace. The planck.repl namespace has some things that are in cljs.repl (like source, doc, pst, etc.)

slipset20:03:28

I guess this is too much, but looking through here (searching for either planck or lumo) you see the problem I’m trying to solve with 466