@bensu @thheller I am using export already, but yeah as you said, for the module to get consumed by another node module export.xxxx = xxx has to be inside the file. On :simple this works great because it all compiles down into 1 file, but for debugging when using :none, the file that contains the export is not the one that gets consumed by node. That one is somewhere inside the out/ folder

For now, I just leave it on :simple so my code works but was wondering if someone had to deal with this problem already

to give context what I'm doing: in electron (the thing that githubs atom runs in), to be able to communicate from the frontend to the backend of the app, you need to use remote.require which is then just using a require inside the backend folder. That is afaik the only way to use backend functions inside the frontend and do things like opening file dialogs and what not. So I created a new cljsbuild target and use clojurescripts aset to manually export my file as a module: (aset js/exports "core" markright.core) - https://github.com/dvcrn/markright/blob/master/src_actions/markright/core.cljs#L35

@dvcrn: this is node?

ah electron ok

what is the best way to check if some var is defined in cljs? exists?? I want to define system-time in my code if user uses cljs version prioir that having system-time in core

but even better if it is possible compile-time

@ul a really ugly way would be to invoke it in a try/catch….. yeah.

@dvcrn: the frontend running on a browser like environment and the backend running on node, right? To communicate between boths there is also ipc. I've been developing with :none https://github.com/bensu/asterion/blob/master/project.clj#L29 using figwheel on the frontend part

the only challenge was that to change my backend code (under app/app.js) I had to restart Electron on each change....

@bensu why is your backend code not cljs?

@thheller: because I used a template that had a bunch of setup in js and didn't bother to extract the 3 functions I needed there into a cljs namespace. Also, some JS API's are very awkward to use from cljs (think d3) and it might be simpler to stay there to call them.

@bensu just teasing ... but I agree some (most) "standard" js is quite awkward to use

Hey peeps. I'm trying to get the result of <!'ing a chan inside a go block out of the go block - and failing. Can anyone tell me how?

@reefersleep: got some code?

I do indeed, @thheller

I create a channel in my namespace using (def input-buffer (chan 1)), then, :onclick for a button, I do #(let [input-char (-> (sel1 ".char-input") .-value)] (go (>! input-buffer input-char))) , and then, inside a function body, I do (assoc cells cell-pointer (int (go <! (go (<! input-chan))))) But I can't get it to work - the return value from reading the chan is ignored it seems.

I've tried with just the one "go <!" as well, at first, but that didn't work either

The chan is passed in as a parameter called "input-chan"

you cannot do that

go creates a block of code that runs async

so you'll need to move the assoc into the go

the return value from go is a channel that will eventually receive the return value of the go block

@thheller: I'm trying to comprehend that. So how can I return something from a function if I want to wrap some part of the function body in a go block?

Do I have to mutate a namespace-wide ref - like an atom or something - to affect the world outside of the go block?

well you can create a local atom and mutate that

but yeah

consider go equals to a callback in js

you do not call this callback, it will be called for you

or a Promise

I will hammock a bit on that comparison Thank you a lot for taking the time to explain. I will attempt with the atom-mutating approach

well the callback comparison isn't entirely correct

but it helped me in the beginning

FWIW the reason this doesn't work is that it would require blocking to wait for the click

since the UI would be block, there would be no click ... simple deadlock

Ah

@thheller: So, I could do this?

(let [return-value (atom {})] (do (go (reset! return-value (<! input-chan)))) (assoc cells cell-pointer (int @return-value)))

no

go returns immediately, which means the assoc happens without go having had a chance to run

thus @return-value returning {}

all code after that assoc also happens before the go executes

argh

async is a lot of fun isn't it?

x)

@reefersleep: protip - you can enclose code in three backticks so it formats nicer, like so: \

some code

(just without the slash)

` (dec 4) 

``

(dec 4)

`

(dec 6) 

There we go

Thanks

If you're doing it on one line then a single backtick is enough. So you can do something like this for example. Tripel backtics are useful for longer swathes of code.

@jaen are you still working the es6 conversion stuff? I sort of gave up for a bit after looking at too much weird React js trying to identify the issue 😛

No problem. It's easier to read that way after all.

@thheller: didn't have time recently to do anything useful really, though I imagine figuring out what's breaking with advanced compilation might turn out to be a nightmare.

Well @thheller, how would I return something from the go block, then? Pass in an atom and deref it elsewhere?

(rather than immediately after)

well you can only get to that from another go

Yeah, go blocks can't really return, just like callbacks.

uuuh

(go 1) returns (async/chan) and if you read from (<! c) you get 1

Oh, does it?

TIL then

yep

But if I do (go (<! c)), I get another chan, not 1, correct?

oops

hehe yeah

in cljs you can only take/`<! from a channel inside go`

teh fuck slack

<! bug

hmm weird

test /`<!` test

Hm, you can't call take outside of a go block? I thought it was the counterpart of put.

In that it can be called outside

ok ... doesn't like the / 😉

@jaen yeah but you really really shouldn't

well I can't think of a reason why you would

CLJ is a bit easier since it allows blocking, but there is no blocking in js

Ok, let me ask this in a different way. If I mutate an atom passed in from outside a go block, then I could read it at some later point and view the result of the mutation, yeah?

Yeah

if LATER is some point after the actual mutation happened yes

Yeah, with it being async and all

All the usual concurrency gotchas might apply

hehe yeah, later as in later time-wise

not lexically

If you can put it that way.

probably better than the callback analogy is go equal to window.setTimeout (which it is under the hood)

maybe that helps

Which is still basically a scheduled callback, but yeah, maybe that's clearer on the fact it doesn't happen immediately.

Maybe I should try asking about my problem rather than fumbling about with what I thought would help me with core.async

I'm building a visual Brainfuck interpreter As an exercise. I have a step function that takes a map representing the state of the interpreter, and returns the next state. I run this in a loop, swap/assoc'ing the state into an atom that represents my Reagent app state.

This way, each state is shown in sequence in the app.

But I have to block when I read a \,, because this means "read input from the user". Then the user has to type a character and click "input character" or whatever, and the interpreter would pick the input up and the loop would continue.

So, I thought I could block using a chan, and maybe I can, I'm just a bit lost in the async of it now

yeah you want to stop the loop on \, then and call the go .. which then restarts the loop when the input arrives

Ah that sucks, that complects the code.

you can pass a function into the go that it can call with the new input

so it doesn't know what happens

So, basically pass the function with the looping body into the go?

it is really hard to describe without knowing your code

It's right here: https://github.com/Reefersleep/derpanet/blob/master/src/derpanet/core.cljs

hehe you already have everything you need

Since the loop is already wrapped in a go?

(needed that for the timeout, needed the timeout in order to actually see the different sequential state

s

https://github.com/Reefersleep/derpanet/blob/master/src/derpanet/core.cljs#L55

pass current-symbol as an argument to the function

and call retrieve in the go loop

and check if \, there

but that I really do not understand what is going on in that code, just a very rough idea

It's a bit messy, planning on having it reviewed on a stack site once it's working

let me just see if I follow you reads own code

So

basically make step do one thing

Inside my already existing go loop, I can just check for \, before running step, and if true, how do I block until input?

you (<! (wait-for-that-click))

just <! from the chan that I >! the typed char into?

you already do the check if the loop should terminate

you just need to check that outside step

Oh yeah. That was more of a copy-paste thing, I think, I didn't properly get it when that entered the code base.

I will attempt to implement this tomorrow, just about bedtime here.

But one thing - when you said "basically make step do one thing", what did you mean?

Decomplecting by removing the call to retrieve-current-symbol inside the step body?

yes

That makes sense

Well, thanks a lot for all of your helpe

*help!

Hopefully, this is just the start of my asynchronous journey

you are almost there

😄

Not sure if this is the right way to go about this, but i'm trying to get a version of the clojurescript compiler used in this post: http://swannodette.github.io/2015/07/29/clojurescript-17/ but build to work in a webworker. I found the https://github.com/swannodette/cljs-bootstrap repo, but following the instructions i've hit a wall. When I run lein npm install in the cljs-bootstrap repo I get:

org.sonatype.aether.resolution.DependencyResolutionException: The following artifacts could not be resolved: org.clojure:clojure:jar:0.0-SNAPSHOT, org.clojure:clojurescript:jar:0.0-3653: Could not find
artifact org.clojure:clojure:jar:0.0-SNAPSHOT in clojars ()

@colinkahn: not sure if any of this still works but probably just try to get the latest version of cljs and remove tools.reader

[org.clojure/clojurescript "1.7.145"] is the latest

@thheller: thanks, turns out it was a dumb mistake on my part, was updating the clojure version, not clojurescript

just cut Om 1.0.0-alpha8, fixes a subtle union bug found by @thomasdeutsch

back to my property based testing for UIs experiment ...