[ClojureScript] [ANN] Serene - generate clojure.spec with GraphQL and extend GraphQL with clojure.spec

[Alan Moore]

This looks very useful, will give it a try. Thanks!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: ANN: re-frame-10x 0.3.0

[Alan Moore]

Thanks for the update!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] ANN: re-frame-10x: Become 10x more productive developing re-frame applications

[Alan Moore]

Are you asking about my project or the “this” in my response? For the later I 
was referring to the OP’s announcement of:

https://github.com/Day8/re-frame-10x

The project I’m working on includes a ClojureScript front end for a software 
cooperative (Co-op Source) which I’d be happy to discuss offline as it doesn’t 
relate directly to this mailing list. Clojure & ClojureScript do figure very 
prominently in many aspects of its implementation, including some VR based sw 
development experiments, I don’t think subscribers here would appreciate the 
distraction.

Feel free to email me at ‘alan’ w the domain coopsource.org.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] ANN: re-frame-10x: Become 10x more productive developing re-frame applications

[Alan Moore]

This looks really nice! I have to admit there are times when I have had to dig 
around quite a bit to find where my reframe app was going wrong. This should 
make that process 10x easier. ;-)

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Problems with Clojurescript quickstart — build fails

[Alan Moore]

I don’t know how far away the next release it but is it worth adding a note to 
this effect to the Getting Started page?

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: durable datascript experiments

[Alan Moore]

Christian,

Great to see the progress on this! I’ll join you again on the gitter channel as 
there are some things that might be complimentary, ie. holochain.org. TBD.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: Differences in read-string with quoted forms

[Alan Moore]

Ivan,

Thanks for the detailed explanation. Clearly I was off the mark re eval. I
guess it was my knee-jerk reaction from my (different) frustrations with
the lack of eval. My bad.

Alan


On Aug 23, 2017, at 10:18 AM, Ivan Pierre  wrote:

It's clear that edn reader will not apply macro substitutions. But this is
made in eval function.
Character macros are in the reader (){}[], these are managed by edn as a
standard. But ' (quote) is the injection of a special form that has a
functional meaning in the evaluation, no0t on the reading. So edn reader
doesn't have it, as we wish to have data, not code.
I think it's a bad call on the cljs version of read-string that read
edn and not s-expressions... to be seen in code. I think the solution will
be obvious.
You also get some weird problems with backquote and splice on Clojure, when
you make some nesting you get some exploding representations caused by the
way toString() don't use a real inverse function of read for `, ~, and ~@,
not tested on ClojureScript. ;)

-- 
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to a topic in the
Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojurescript/R6waOGeuxBU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: New Features coming to ClojureScript

[Alan Moore]

Awesome, thanks! It is nice to see all the hard work done by Maria, and now 
these latest changes, making ClojureScript integration with modules so seamless.

I'm teaching an HTML/JS class at our local tech hub and have been including 
some comparisons between js & cljs for interested/advanced students. Node.js is 
our next topic so the timing of this is perfect (was not looking forward to 
explaining away the last remaining pain points of using modules in cljs.)

Thanks again for all your work on ClojureScript!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] ANN: ClojureScript 1.9.660, compiler performance, runtime performance, cljs.spec fixes

[Alan Moore]

Wow... this is quite the list!

Thanks for all the hard work.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Specific greeting to be shown in browser

[Alan Moore]

Your code, when compiled will evaluate that (if ...) expression and on-change 
will most likely get nil instead of a function value.

The value you supply to on-change needs to be a function.

Two common ways of doing this are using inline anonymous functions:

(fn [event] (if (= (.-target.value event) "Hello") (reset! greeting "Hello, how 
are you")))

Or using reader shorthand:

#(if (= (.-target.value %) "Hello")  (reset! greeting "Hello, how are you")))

The reagent examples use both styles.

Alternatively, you could define a top level function with defn and just place 
that named function in place of the inline fn.

(defn mygreeting [event] ...)

... elsewhere 

:on-change mygreeting 

Also you might want to use a different name for that component function name - 
the name "input" could be confusing and/or may shadow referred refs/functions.

There may be other things wrong but I'm typing this on my phone w/o a repl.

Good luck!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Compiling different ClojureScript for different clients

[Alan Moore]

There is KLIPSE here:

http://app.klipse.tech/
https://github.com/viebel/klipse

You might also take a look at:

cljsfiddle.com
https://gitlab.com/escherize/cljsfiddle

There are other online REPLs listed here:

http://clojurescript.org/community/resources

The self hosted clojurescript compiler has been used to good effect in quite a 
few places.

Good luck!

Alan

On Friday, September 23, 2016 at 9:43:21 AM UTC-7, Simon Brooke wrote:
> This is probably not a problem that affects many people...
> 
> As I understand it, I cannot compile a function in ClojureScript and have it 
> integrated into the current ClojureScript compiled image (if I'm wrong, 
> please tell me so. I'd really, really like to be wrong).
> 
> I have a web app which allows people to write rules for a cellular automaton, 
> and watch them run (you can see it here http://www.journeyman.cc/microworld/ 
> if you're interested). The problem is that all the computation happens server 
> side, so it doesn't scale. I need to move as much as possible of the 
> computation to client side.
> 
> A key feature of the application is that users can edit the rules - in fact, 
> they're encouraged to. That's what it's about. When the rules are edited 
> they're compiled into Clojure functions, which then run.
> 
> I can move all the function of the application client side except (at this 
> stage) compiling the rules. So I'm envisaging a version of the app which, 
> when the user edits the rules, the parsing happens client side and any parser 
> errors are shown to the user immediately, but when they decide to commit 
> their changes, the generated Clojure text is sent back to the server, where 
> it is compiled with the rest of the CLJC code into a new app.js JavaScript 
> image and served back to the client. The state of the world can be cached in 
> HTML5 local storage while this is being done.
> 
> The problem I see is this: if Alice and Bob are both using the system at the 
> same time, both edit rules, I don't want Alice getting an image with Bob's 
> rules in it (or vice versa). So I'm going to need to compile separate copies 
> of app.js for each client that connects, and serve the right one to the right 
> client.
> 
> Has anyone else tried anything like this? Did it work? What were the problems?
> 
> Cheers
> 
> Simon

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] [ANN] beta.clojars.org: new Clojars infrastructure that needs testing

[Alan Moore]

Congrats on this important migration! Thanks also for the time and effort
the Clojars team put into this.

I encourage everyone to head over to the Clojars issues list where there
are many easy/low hanging fruit that await your awesomeness.

Alan

On Sep 25, 2016, at 8:24 PM, Daniel Compton 
wrote:

Hi folks

We have completed migration of the production server (clojars.org) from
Linode to Rackspace. Everything seems to have transferred across smoothly.
Please let us know if you have any issues.

Thanks

On Fri, Sep 23, 2016 at 9:26 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> Hi Andy
>
> Good spotting, thanks!
>
> We needed to regenerate the Lucene search index. Normally it is updated
> incrementally, so there was no Ansible automation to rebuild it. I’m
> rebuilding the index now, it should be updated soon.
>
> Thanks!
>
>
> On Fri, Sep 23, 2016 at 3:14 AM Andy Fingerhut 
> wrote:
>
>> Should searches for packages give results on beta.clojars.org ?
>>
>> I went to the web page and searched for a couple of packages using search
>> strings that give results on clojars.org, but give no results on
>> beta.clojars.org.
>>
>> Andy
>>
>> On Tue, Sep 20, 2016 at 4:17 PM, Daniel Compton <
>> daniel.compton.li...@gmail.com> wrote:
>>
>>> Hi folks
>>>
>>> We’re moving the Clojars infrastructure from Linode to the very kind
>>> folks at Rackspace. We’re getting close, and have a test server setup at
>>> beta.clojars.org. It has a copy of the live database as of a day ago,
>>> and is mirroring JARs from the live server. We’ve done testing of what we
>>> can, and everything looks ok, but there may be something we’ve missed.
>>>
>>> *N.B.* All state on this server is temporary and will be wiped at the
>>> end of the testing period. Make sure to do any real deploys to
>>> clojars.org
>>>
>>> *What we need from you:*
>>> We need testing from people running different setups, to make sure this
>>> isn’t going to break things for you. If you’re running any kind of unusual
>>> setup (OS, JDK, environment, network), we especially need you to test it.
>>> To test this, follow the instructions at Mirrors
>>> :
>>>
>>> In a nutshell, update your ~/.lein/profiles.clj to have this:
>>>
>>> :user {:repositories [["clojars" {:url "https://beta.clojars.org/repo/"}]]
>>>;; deploy-repositories is optional
>>>:deploy-repositories [["clojars" {:url "https://beta.clojars.org; 
>>> :username :gpg :password :gpg}]]
>>>
>>>;; other :user profile settings...
>>>}
>>>
>>>
>>> (You can always see the canonical Clojars mirrors at
>>> https://github.com/clojars/clojars-web/blob/master/MIRRORS)
>>>
>>> If you have issues, either reply to this email, or open an issue on
>>> GitHub .
>>>
>>> This is the first in a series of infrastructure enhancements coming over
>>> the next few months to improve the speed, stability, and security of
>>> Clojars.
>>>
>>> A special thanks goes to all of the people supporting Clojars at
>>> Bountysource , we really
>>> appreciate your support.
>>>
>>> Thanks,
>>>
>>> Your friendly neighbourhood Clojars caretakers.
>>> Toby and Daniel.
>>>
>> --
>>> —
>>> Daniel
>>>
>>> --
>>>
>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>>
>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ClojureScript" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojurescript+unsubscr...@googlegroups.com.
>>> To post to this group, send email to clojurescript@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/clojurescript.
>>>
>>
>> --
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojurescript+unsubscr...@googlegroups.com.
>> To post to this group, send email to clojurescript@googlegroups.com.
>> Visit this group at https://groups.google.com/group/clojurescript.
>>
> --
>
> Daniel
>
-- 

Daniel

-- 
You received this message because you are subscribed to the Google Groups
"clojars-maintainers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojars-maintainers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

[ClojureScript] cljs or js, I'm in a trouble

[Alan Moore]

Another red pill rescue... ;-)

I know how you feel... My day job is all in C++ and JS so it is nice to go home 
and work in a sane language.

I sometimes apply the general principles I've learned to the day job and I 
challenge myself to translate certain idioms from FP to C++. I've noticed that 
some of the most reliable C/C++ I've run across in the wild tends to be more 
functional in style. Const used to be an anachronism but now I reach for it 
early and often.

I also educate my peers on better ways to achieve the same things (without 
being too preaching or over-enthusiastic.) Some get it, others don't. You can 
lead a horse to water...

I hope you find a good outlet for your FP skills and that the day job isn't too 
unbearable.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: [ANN] clojurescript.org

[Alan Moore]

On Wednesday, August 17, 2016 at 9:34:39 PM UTC-7, mars0i wrote:
> No one's commented on this, but I keep wanting to comment.  I know that it's 
> the same content as the old site, and the same format as clojure.org, but I 
> still think it's great.  (Sorry!)  
> 
> What Clojurescript warrants.

+1 - Thanks! This should get more devs interested in ClojureScript.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: figwheel websocket configuration error?

[Alan Moore]

"Be sure to check your CORS headers." From the figwheel readme. This is due to 
browser security restrictions.

Are you using the static server option?

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] How to develop ClojureScript in Web worker?

[Alan Moore]

On Tuesday, May 31, 2016 at 7:51:15 AM UTC-7, Eivind Magnus Hvidevold wrote:
> I don't think so. Figwheel gives an error when run from a worker: "Figwheel: 
> Can't start Figwheel!! This browser doesn't support WebSockets".

Firefox was the last browser to add support for websockets in webworkers (fixed 
in FF 38):

https://bugzilla.mozilla.org/show_bug.cgi?id=504553

So make sure you are using a recent browser.

Figwheel tests for websocket support by checking for the existence of 
window.WebSocket. However, webworkers cannot access the window object so this 
will always fail in a webworker. This doesn't mean that a webworker-aware 
Figwheel couldn't use "new WebWorker(...)" and check for an exception/error 
instead.

Regardless, I don't think you are going to get Figwheel working in a webworker 
*and* in the main thread at the same time. Maybe one or the other but not both 
due to conflicts on the server-side w.r.t. port numbers and the like. Also, 
there are likely other assumptions in Figwheel about access to the DOM/window 
that go beyond simply testing for websocket support... YMWV.

Good luck!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Workshop report: Hi-perf Clojurescript with WebGL, asm.js and Emscripten

[Alan Moore]

Karsten,

Awesome, I'll give it a try today.

Have you found support for this to be consistent in all (major) browsers? I
am assuming this works in both directions to/from the worker.

We have been waiting several years for FF to support web sockets in
workers, the last one to do so. Even IE had it early on - big surprise.
caniuse.com only goes so far in their assessment of support for some of the
corner cases or combinations of features.

Thanks for the update! I'm looking forward to exploring more of your
excellent work.

Alan
-- 
*"Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now."* - *Goethe*

On May 4, 2016, at 5:34 AM, Karsten Schmidt <i...@toxi.co.uk> wrote:

Hi Alan,

in my tests I found that using buffer transfer is pretty much
immediate (0-2ms) whereas using copies goes up to ~30-40ms (for a 10MB
data buffer) - not the end of the world, but big difference when using
workers for in a realtime context (e.g. animation). In addition to
your message object you only need to specify another array of which
objects to transfer, the onmessage handler stays the same...

;; send
(let [buf (.-buffer (js/Uint8Array. 1e7))]
 (.postMessage worker #js [buf] #js [buf]))

Maybe important to point out: You can't transfer a typed array
directly, only its underlying ArrayBuffer. After transfer the entire
typed array will be unusable by the sender. Any writes to it will fail
silently and reads will produce `undefined`...

Hth!

On 2 May 2016 at 22:28, Alan Moore <kahunamo...@coopsource.org> wrote:

Nice work Karsten!


I'm especially curious about your experience with moving typed arrays
between web workers and the main thread. We use workers for limited
purposes now but would like to expand it to include pulling image content
from a web socket - now that web sockets inside workers are
recently/finally supported in FF.


Alan



On Sunday, May 1, 2016 at 5:54:29 PM UTC-7, Karsten Schmidt wrote:

Hi everyone,


last week I taught 3-day workshop about the above topics and thought

some of you might be interested in this workshop report:


https://medium.com/@thi.ng/workshop-report-hi-perf-clojurescript-with-webgl-asm-js-and-emscripten-a545cca083bc


The source code of the various examples/exercises is available here (a

README will be added in the next few days):


https://github.com/thi-ng/ws-ldn-8/

--

Karsten Schmidt

http://postspectacular.com | http://thi.ng





-- 
Karsten Schmidt
http://postspectacular.com | http://thi.ng | http://toxiclibs.org

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Workshop report: Hi-perf Clojurescript with WebGL, asm.js and Emscripten

[Alan Moore]

Nice work Karsten!

I'm especially curious about your experience with moving typed arrays between 
web workers and the main thread. We use workers for limited purposes now but 
would like to expand it to include pulling image content from a web socket - 
now that web sockets inside workers are recently/finally supported in FF.

Alan


On Sunday, May 1, 2016 at 5:54:29 PM UTC-7, Karsten Schmidt wrote:
> Hi everyone,
> 
> last week I taught 3-day workshop about the above topics and thought
> some of you might be interested in this workshop report:
> 
> https://medium.com/@thi.ng/workshop-report-hi-perf-clojurescript-with-webgl-asm-js-and-emscripten-a545cca083bc
> 
> The source code of the various examples/exercises is available here (a
> README will be added in the next few days):
> 
> https://github.com/thi-ng/ws-ldn-8/
> -- 
> Karsten Schmidt
> http://postspectacular.com | http://thi.ng

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: [ANN] Quil 2.4.0 and improved live editor

[Alan Moore]

+1, yes thanks very much!

FYI: The quil.info site has a broken link. The "Quil Intro" links to:

http://nbeloglazov.com/2014/05/29/quil-intro.html

But that's 404.

Alan

On Thursday, March 24, 2016 at 6:26:45 PM UTC-7, Dragan Djuric wrote:
>
> Thank you for keeping this fantastic library alive :)
>
> On Thursday, March 24, 2016 at 9:03:42 PM UTC+1, Nikita Beloglazov wrote:
>>
>> Happy to announce Quil 2.4.0 release.
>>
>> Quil is a Clojure/ClojureScript library for creating interactive drawings 
>> and animations.
>>
>> The release available on clojars: https://clojars.org/quil. List of 
>> changes:
>>
>>- Updated cheatsheet 
>>
>> . 
>>Thanks to @SevereOverfl0w .
>>- Added support for some new processing functions: pixel-density, 
>>display-density, clip, no-clip, key-modifiers.
>>- Fixes: #170 , #179 
>>.
>>- Upgraded to ProcessingJS 1.4.16 and Processing 3.0.2.
>>- Drop support of Clojure 1.6.0.
>>- Migrated from cljx to cljc and various refactorings to make Quil 
>>compile with self-hosted cljs.
>>
>> Documentation on http://quil.info has been updated as well.
>>
>> *Live editor*
>>
>> Editor  on quil.info was revamped and 
>> migrated to self-hosted ClojureScript! That means that now you can evaluate 
>> code ~instantly in browser and even reevaluate parts of code. Editor 
>> provides following features:
>>
>>
>>- full client-side compilation including macros from quil.core;
>>- partial evaluation: use Ctrl+Enter to evaluate selected code or 
>>form under cursor
>>- warning and error messages;
>>- easy sketch sharing via URL;
>>
>> Feedback and bug reports are welcome! Feel free to reply to this thread 
>> or file a bug in Quil repo . 
>>
>>
>> Happy hacking!
>>
>> Nikita
>>
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Alternative for Canvas/Image element in React Native?

[Alan Moore]

All,

I'm prototyping a native version of an existing webapp that uses a Canvas 
element to display video (raw RGBA frames @ ~20fps) obtained via a websocket.

The native version is built using re-natal (kudos!) and I'm able to connect to 
the websocket and obtain the ArrayBuffer. So far so good... unfortunately, the 
RN Image component only provides a source/URL property for the image source 
that it will use to download/decode images. But I already have the data. Of 
course I could transform my image data to a base64 encoding and use a data url 
but, eeewww.

I just need a surface I can draw the raw image data onto. How hard can that be?

Does anyone have an alternate suggestion for displaying a series of images 
quickly and efficiently. I'm looking over some of the RN opengl components - 
does anyone have experience using any of them? Suggested libraries? Flipboard 
has some components that look ok... I'm still evaluating them.

Is there another RN component I'm overlooking? A different technique altogether?

My next step is to create my own RN component to do this. I was just hoping to 
avoid that by using existing libraries/components.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

[ClojureScript] Re: Idea for a reactive and faster alternative to Datascript

[Alan Moore]

Vianney,

I haven't replied for the same reason other haven't... not a lot of time and a 
lack of understanding your proposal. I also don't want to sound like a broken 
record - I've posted to this list previously about this and figured I'd "stand 
down" to spare everyone the repetition.

However, for those who are new to the list and have not heard of Clara before, 
read on. Everyone else can press delete as they see fit.

The one other approach I would suggest you look into is the Clara library. It 
is a rule engine that works efficiently with small changes to large amounts of 
data/rules. You can think of a rule as an efficient means of creating 
materialized views except that they only fire when new data matches (including 
unification) with existing data/rule patterns.

It takes a little getting used to in a similar way that reactive programming 
inverts control as compared to imperative logic. The typical use would be:

1) Insert new data into existing Clara session (stored in app state)
2) Fire rules (only rules matching the new data), possibly changing the session 
state.
3) Store the resulting session value back into your app state.
4) Rinse, repeat.

For example, this might look like:

(reset! app-state (-> @app-state
  (insert (->PurchaseOrder 123 "PO: 123"))
  (insert (->ApprovalRequest 123 false))
  (fire-rules)))

Note: app-state is an atom that holds a Clara session/db. Also, you can use 
Clojure records as is done above or just plain maps, provided you supply Clara 
with a function that can tell one map "type" from another.

The fire-rules function will run any rules that have been "activated" by 
previous data insertions or removals and can have side effects on the rest of 
the system (e.g. update the DOM, redraw React components, etc.)

A rule that matches the above facts might look (something) like this:

(defrule approve-po-request
   [?po <- PurchaseOrder (== ?id id)] ; ?id variable "bound" to value of id
   [?request <- ApprovalRequest (== ?id id)] ; Bound ?id variable used to unify
=>
   (insert! (approve ?request)))

Negation is also possible in a LHS pattern. See the Clara docs for more info.

http://www.clara-rules.org

Clara also has queries (that share the same LHS syntax as rules) so that you 
can get a snapshot of your state/session. This syntax is declarative and 
similar to datalog and/or core.logic syntax.

I'm currently working to integrate Clara with Om Next (among other things) in 
the same way DataScript has been. I don't have anything concrete to give you 
but I'm sure if you squint you can see the possibilities. I had it integrated 
it with other ClojureScript/React libraries but when Om Next came out I changed 
course and started over.

However, if you just need DataScript/Datomic integration and don't need the 
power of a rule based system, going with the existing Om Next integration will 
be the simplest path forward. Rule engines have their own cognitive overhead 
that some find unacceptable or that doesn't match with their coding style. To 
each their own... YMWV.

Good luck!

Alan

On Thursday, December 3, 2015 at 6:40:56 AM UTC-8, Vianney Stroebel (vibl) 
wrote:
> I posted an idea for a reactive and faster alternative to Datascript:
> 
> https://github.com/tonsky/datascript/issues/132
> 
> It seems too good to be true on paper so I probably have overlooked things.
> 
> Comments are welcome!
> 
> Vianney

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: ANN: DataScript, in-memory database and datalog queries in ClojureScript

[Alan Moore]

FYI: Om Next has new built-in affordances for using pull syntax to resolve 
local/remote datom fetching that plays nicely with local datascript instances. 
Nothing in Om Next is Datomic or Datascript specific but there are working 
examples of using both including the proverbial TODO app.

If you can't use Om Next you could do something similar in your own code. David 
Nolan has put in a lot of thinking around this and seems to have hit a sweet 
spot in this area. Replicating all the features/aspects he has designed in 
might be a challenge.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] multiple iframe performance

[Alan Moore]

Yes, you would be surprised at where all the time goes...

As Colin said, my advice is to measure everything using something like chrome 
tools, react's chrome tools or wireshark to find out how long each operation is 
taking.

If it turns out not to be the network you could be reaching a worst case with 
react and/or reagent. Maybe your games are too complex for the differencing 
algorithm and too much is changing each frame or you aren't using key= 
properly. One copy may work fine but maybe it doesn't scale. The react chrome 
tools should help you figure out what is going on.

Surprisingly, iframes can come in handy but less so as a UI feature and more as 
a performance tool. We have a page that has to display a small window of 
uncompressed video from a web socket onto a canvas element at 16-24 frames/sec 
and doing this in the main page/thread sucked up so much cpu that other 
background processing on the page was delayed or blocked and we were forced to 
move it to its own iframe. Most browsers give each page at least one thread, 
including iframes. YMMV.

Good luck.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: ISO lein-cljsbuild maintainer

[Alan Moore]

Thanks Chas, Evan and Maria!

Let us know if there is anything we can do to help out. This is a critical 
piece of the ClojureScript toolchain and I'm grateful for the time and effort 
you put into it.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Performance tuning a Reagent/Re-frame application

[Alan Moore]

Obviously using reagent/re-frame should minimize Dom updates but sometimes an 
app can behave differently than we think it should. Especially in an event 
driven system some operations may occur in different orders, etc, sometimes 
this can be caused by the inversion of control that comes with event oriented 
systems.

One biggie is Dom reflow so make sure your app isn't triggering some worst case 
in FF. Rendering a large table or sequence of flex-box all in one chunk is 
going to be way faster than one row/box at a time.

Good luck.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: Startups that bank on Clojure/Script

[Alan Moore]

Ah, my bad. I should have considered the issue of problem domains. For my
day job I don't work in an enterprise or business consulting context. I
build specialty hardware products where just making it work is job #1,
reliability is #2, time to market is #3. Feedback from product management
is limited at best and primarily given up front, modulo some UI tweaking.

Also, when I used to work in more typical sw projects, remote teams worked
best when everyone is remote. Hallway conversations short circuit the
communications and remote engineers are at a disadvantage unless there is
good discipline/sharing.

I think this thread has gone somewhat off topic so further discussion
should probably be carried on off list. I can be reached @coopsource on
Twitter.

Alan
-- 
*Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now.* - *Goethe*

On Jul 3, 2015, at 2:29 AM, Colin Yates colin.ya...@gmail.com wrote:

Having worked remotely for nearly a decade I can say that when it works
well it is unbeatable in terms of productivity, satisfaction, home/work
balance and so on. When it works badly it is unbeatable in terms of lack of
productivity, lack of satisfaction etc.

Delivering the software that the business wants depends far less on
developer productivity then it does on communication. By orders of
magnitude. I realise that we as developers are highly skilled, creative,
specialist/generalists and so on, but I have seen many more projects that
were built well but delivered the wrong thing then projects that failed
because of developer insufficiency. Almost always because there is inherent
ambiguity translating:
- what the business _thinks_ they want
- what the business _meant_ to ask for
- what the team _heard_ the business ask for
- what the developers _interpreted_ those requirements to be

It is communication that is our achille’s heel, not distraction, skill or
tooling.

For me, if I haven’t sat down face to face and shown the key stake holders
a realisation (i.e. working software) of what they asked for every other
week or so I get very twitchy.

Of course, when there is a whole bunch of hidden complexity to solve then
sure, working from home and getting your head down is great. All I am
saying is that for the project as a whole, it can be exacerbate the
fundamental thing success depends on - getting you and them in a room
demonstrating what they asked for.

I should also say that a lot of developers (in my non-scientific and
non-validated opinion) are prone to introspection and depression and
isolation, which is sometimes what they most crave can be the absolute last
thing they need.

My advice - work from home sure, but regularly get into the same room
(Skype really doesn’t cut it. FaceTime neither as then you need to remember
to put your pants on before work!) with the key stake holders and other
team mates. Also make sure you have a _very_ disciplined and structured
process for separating home and work life.

Anyway, enough ramblings from me.


On 3 Jul 2015, at 03:02, Marc Fawzi marc.fa...@gmail.com wrote:



The future has arrived, but it's not evenly distributed -- William Gibson


I think the remote vs in the office issue is ultimately about our ability
to achieve eventual consistency with the rest of the team on multiple
levels spanning the inter-personal, cultural, process oriented and
technical domains.


But the truth in today's work environment is that being in the office is
less productive than working from your own office where you can shut out
all distractions. It reduces productivity and increases distraction and
therefore software defects by a critical amount and it does not solve the
problem of getting everyone on the same page; it only alleviates it. Raw
productivity is not the goal, so many companies prefer to bring people
under one roof than let them loose on independent projects or going in
separate directions on the same thing.


I think we could use better tooling for the remote lifestyle to make sense
in the common scenario. But the tools for collaboration that we have are so
so. Myself, i feel like a good balance can be attained between productivity
and mission coherence. Maybe I'm wrong?


Sent from my iPhone


On Jul 2, 2015, at 2:17 PM, Joe R. Smith j...@uwcreations.com wrote:


Having worked remotely for a couple years now, I can definitely say I’m far
more productive.


This sums up why:
http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/


On Jul 2, 2015, at 4:14 PM, Alan Moore kahunamo...@coopsource.org wrote:


When constrained by a technology choice you may have to give up requiring
other developers to be physically proximate.


I know managers want the comfort of observing warm bodies in cubes banging
on keyboards but it doesn't necessarily translate into higher productivity,
I get my best work done when everyone else goes home.


I've worked for self-edit, a while in cubes emailing co-workers

[ClojureScript] Re: Startups that bank on Clojure/Script

[Alan Moore]

When constrained by a technology choice you may have to give up requiring other 
developers to be physically proximate.

I know managers want the comfort of observing warm bodies in cubes banging on 
keyboards but it doesn't necessarily translate into higher productivity, I get 
my best work done when everyone else goes home.

I've worked for self-edit, a while in cubes emailing co-workers in their 
cubes and I see no reason why we even have to be in the same building... 
confounding actually, stand-ups not withstanding :-0

Alan

On Wednesday, July 1, 2015 at 3:33:22 PM UTC-7, Nate Wildermuth wrote:
 Interesting questions! 
 
 The startup I work for (Nowthis News) made the switch to Clojurescript a few 
 months ago, but I don't think our VCs care much about our tech stack. In my 
 experience, they focus on metrics like growth rates, users, and views.
 
 On hiring and employment, I can't imagine working anywhere else. I get to 
 program in lisp all day long. But I haven't had much luck finding people to 
 join my team. Would love to hear from anyone who's had success on that front!

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: [ANN] Clojure 1.7.0-RC1 now available

[Alan Moore]

I've started porting a library to use Reader Conditionals - I haven't seen 
any issues with it yet but my troubles are more related to the library and 
re-organizing the code than to RC specifically. I'll report back when I'm 
done...

Alan


On Friday, May 22, 2015 at 2:09:28 PM UTC-7, Daniel Compton wrote:

 One of the most significant features of 1.7 are Reader Conditionals. I'm 
 pretty confident after all the discussion that has gone on that we have a 
 good design. However I haven't seen many or any libraries which have gone 
 through the porting process to use Reader Conditionals. 

 I've worked on porting a few libraries and everything has gone mostly 
 smoothly. However I'd feel more confident that we've got the right design 
 if we had more people trying to port their libraries/projects to cljc and 
 reporting their experiences.

 Is this a reasonable concern, or am I missing something and this isn't 
 necessary?
 On Fri, 22 May 2015 at 7:35 pm Jason Wolfe ja...@w01fe.com javascript: 
 wrote:

 We haven't shipped it to production yet, but I just verified that our 
 full test suite at Prismatic passes on RC1 after fixing a few tests that 
 were erroneously depending on hash ordering.   Thanks everyone for all the 
 hard work on this release!  

 On Thursday, May 21, 2015 at 9:31:08 AM UTC-7, Alex Miller wrote:

 Clojure 1.7.0-RC1 is now available.

 Try it via
 - Download: 
 https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC1/
 - Leiningen: [org.clojure/clojure 1.7.0-RC1]

 The only change since 1.7.0-beta3 is CLJ-1706, which makes reader 
 conditional splicing an error at the top level (previously it would 
 silently drop all but the first spliced element).

 For a full list of changes since 1.6.0, see:
 https://github.com/clojure/clojure/blob/master/changes.md

 Please give it a try and let us know if things are working (or not). The 
 more and quicker feedback we get, the sooner we can release 1.7.0 final!

 - Alex

  -- 
 You received this message because you are subscribed to the Google Groups 
 Clojure Dev group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to clojure-dev...@googlegroups.com javascript:.
 To post to this group, send email to cloju...@googlegroups.com 
 javascript:.
 Visit this group at http://groups.google.com/group/clojure-dev.
 For more options, visit https://groups.google.com/d/optout.



-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: freactive vs rum

[Alan Moore]

On Tuesday, April 21, 2015 at 5:28:40 AM UTC-7, Julien Eluard wrote:
 I am also curious about the advantages of using something like Clara versus 
 DataScript listen feature. Especially there has been discussions [1] of 
 improving listen so that it can accept a query details argument.
 Alan I can see you commented on this ticket how do you think it compares to 
 Clara?
 
 Cheers,
 Julien
 
 [1] https://github.com/tonsky/datascript/pull/12

The two are very close in concept but I think, under some conditions, Clara has 
an advantage in being based on the Rete algorithm. My guess is that the Rete 
algorithm might be more efficient but am unsure where the cost/benefit cross 
over is re: # rules, amount of data, etc.. It heavily depends on how much 
commonality/overlap and sharing happens in the graph which is dependent on your 
rules and their structure. Caveat emptor.

Rete doesn't have to recompute the results of the query over and over again as 
data arrive like I suspect Datascript would have to. With Datascript, after 
each query is run there is no memory of what the previous results were. Rete 
maintains the state of all of your rules/queries across all of your data that 
you insert/remove in/out it.

Re: Datascript and listen! At a conference a couple years ago I asked Rich a 
similar question re: Datomic, I couldn't hear his response very well but I 
think he said that Datomic doesn't support persistent queries and probably 
won't. I would think that datalog could handle it but I don't know how you'd do 
it. I think that pull request says the same thing basically if I'm reading it 
right.

I know this kind of thing is very powerfule - I embedded Jess into IE 4 as a 
Windows Scripting Engine way back in the day. Just like javascript, Jess code 
could be embedded in your page using script language=jess(defrule xyz ...) 
/script and you had full access to the DOM and events, with all the event 
wiring/registration happening automagically, etc. It made for a really elegant 
programming model.

It worked great but internally it was a tangled mess of C++ COM objects, 
jscript, and java. IE 5 broke everything so I gave up on it.

As previously mentioned, I'll post a more complete example of Clara tomorrow 
after I recover from my trip.

Take care.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: freactive vs rum

[Alan Moore]

Caution, my comments should be taken with a grain of salt. I've build
prototypes with Clara in the browser but nothing of production quality.
Therein could lay dragons... YMWV.

Ryan, Clara's author, uses it much more extensively on servers and such.
His use cases are primarily JVM based but I hear it does quite well there.

Alan
-- 
*Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now.* - *Goethe*

On Apr 20, 2015, at 3:35 PM, Marc Fawzi marc.fa...@gmail.com wrote:

Thank you for sharing this Alan!  Its really interesting.

Would Clara then work with something like Hipo? I like the distinction you
make between it and mutation based reactions. Very interesting topic that
deserves more discussion imo.

Sent from my iPhone

On Apr 20, 2015, at 2:56 PM, Alan Moore kahunamo...@coopsource.org wrote:


On Mon, Apr 20, 2015 at 1:45 PM, Kurt Sys kurt@gmail.com wrote:

 The basic stuff I need is really very similar. What I like about react, is
 not the dom diffing as such, the 'should-update' mixin. This really can
 make things way easier. It doesn't play as nice as I thought it to be
 between rum and datascript queries, but it'll work. Datascript queries are
 really amazingly powerful to me. I use them really a lot, and full dom
 diffing might be pretty, or more, expensive compared to a 'should-update'.

 That said, I had been looking to clara before (for another kind of
 project), but I pretty much like the idea of using it as 'database/query
 engine'-someting. Would you implement something like the should-update on
 component basis as well. I'm really very interested in your wrapper/library
 and how it would work out.


The nice thing about Clara (and rule engines in general) is that you can
declare that certain functions (RHS) are to be called when a set of
conditions/queries (LHS) over your data evaluate truthfully. There is no
need for should-update polling, it is more don't call us, we will call
you - control is inverted. When a user or server event happens the handler
code inserts the event data into the engine and then calls the fire-rules
function to trigger subsequent actions based on the rule conditions.

Clara does truth maintenance which is an awesome feature but in my use case
I have to work around it slightly to accommodate transient facts/events.
Not a big deal just something to keep in mind when first understanding how
it works.

I don't really see there being a need for a wrapper around Clara - you can
use it as-is. I'm just trying to figure out the best way to integrate it in
the client-side context. It was built with a particular set of use cases in
mind that don't always match up with my experience with other rule engines
that are more mutation oriented. Clara's rule engine is a value in the
same way that Datomic's database is a value. This is super powerful but
that means you need to organize your code slightly to take this into
account.

Alan

-- 
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to the Google Groups
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

 --
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to a topic in the
Google Groups ClojureScript group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojurescript/kCdOQzPNAug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: freactive vs rum

[Alan Moore]

On Mon, Apr 20, 2015 at 1:45 PM, Kurt Sys kurt@gmail.com wrote:

 The basic stuff I need is really very similar. What I like about react, is
 not the dom diffing as such, the 'should-update' mixin. This really can
 make things way easier. It doesn't play as nice as I thought it to be
 between rum and datascript queries, but it'll work. Datascript queries are
 really amazingly powerful to me. I use them really a lot, and full dom
 diffing might be pretty, or more, expensive compared to a 'should-update'.

 That said, I had been looking to clara before (for another kind of
 project), but I pretty much like the idea of using it as 'database/query
 engine'-someting. Would you implement something like the should-update on
 component basis as well. I'm really very interested in your wrapper/library
 and how it would work out.


The nice thing about Clara (and rule engines in general) is that you can
declare that certain functions (RHS) are to be called when a set of
conditions/queries (LHS) over your data evaluate truthfully. There is no
need for should-update polling, it is more don't call us, we will call
you - control is inverted. When a user or server event happens the handler
code inserts the event data into the engine and then calls the fire-rules
function to trigger subsequent actions based on the rule conditions.

Clara does truth maintenance which is an awesome feature but in my use case
I have to work around it slightly to accommodate transient facts/events.
Not a big deal just something to keep in mind when first understanding how
it works.

I don't really see there being a need for a wrapper around Clara - you can
use it as-is. I'm just trying to figure out the best way to integrate it in
the client-side context. It was built with a particular set of use cases in
mind that don't always match up with my experience with other rule engines
that are more mutation oriented. Clara's rule engine is a value in the
same way that Datomic's database is a value. This is super powerful but
that means you need to organize your code slightly to take this into
account.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: Himera update

[Alan Moore]

Nice! Thanks Mike - how I can play with ClojureScript from my phone when I get 
bored in meetings :-)

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: freactive vs rum

[Alan Moore]

Absolutely, thank you! More time to work on other stuff, yay :-)

Native ClojureScript FTW! Wrappers are convenient and good if you need to
play nice with existing frameworks (looking at you React) but otherwise
they seem suboptimal.

Thanks for the library Julien and a hat tip to Prismatic for dommy.

Alan
-- 
*Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now.* - *Goethe*

On Apr 18, 2015, at 11:25 AM, Julien Eluard julien.elu...@gmail.com wrote:

Hi Alan,

you might be interested by the latest release of the hipo [1] library which
provides reconciliation (à la react) [2] of live DOM nodes. It is
essentially a native ClojureScript 'virtual-dom' implementation using
hiccup vectors as syntax.

Cheers,
Julien

[1] https://github.com/jeluard/hipo
[2] https://github.com/jeluard/hipo#reconciliation


Le samedi 18 avril 2015 14:20:14 UTC-3, Alan Moore a écrit :

Sorry for the delayed response. Yes, I stand corrected, I evaluated just
about every front end library there is for ClojureScript and some of the
names are starting to get confusing to my age addled brain (react, reagent,
freactive, re-frame, etc..)




I really just want the DOM diffing from React and don't need any of the
other stuff. I'm considering making a ClojureScript wrapper for:



https://github.com/Matt-Esch/virtual-dom



My goal is to write most of the front end logic using rules (Clara is the
best candidate ATM) so the view portion needs to be as simple as possible
for the rules to manipulate the DOM. The rule engine provides all the data
reactivity I need - any data (normal clojure data) you put into it is
automatically pattern matched against the rules, including
unification/relationships with existing data - as defined by your rules.
Here is the general idea:



Model: Data inserted into the rule engine's working memory

View: DOM/React/Rum/vdom

Controller: Rules in the engine



It is reactive in the sense that inserting data/facts/events (from server
or user/view events) into the engine triggers rules to fire, those rules
may then update the UI or the server, rinse and repeat. There is no
polling the data for changes because the engine maintains a data
structure (a Rete graph) that pattern matches against your data as you
insert it, edge-triggered as it were... You can query the data stored in
the engine using a defquery... which is like a defrule without a RHS.



The goal for my app is to keep all the core app logic in the rules which
makes them easily unit tested because the primary externalities are just
data. Think of it as a reactive version of Datascript, at least that is how
I see it. Also, in theory, Clara artifacts such as rulesets and sessions
can be moved around a system as self contained units of logic giving you a
lot of flexibility in how you organize (or re-organize) your architecture.
According to Ryan Brush, the author of Clara, they deploy Clara in Hadoop
jobs to great effect.



Along the same lines, another experiment I want to look into is extending
the core Clojure data protocols (ISeq, Iterable, etc.) to the Clara
sessions so that, to the rest of the system, the session looks just like a
regular Clojure data container... or something like that (e.g. conj ==
insert, etc.)




I'm curious to hear how Rum works out for you. I think Rum and Quiescent
are both excellent minimalist React wrappers. Om is awesome but is more
than I need. If my experiments don't work out I may go back to it... TBD.
If you like Datascript and Quiescent then you might want to check out:




https://github.com/thegeez/clj-crud




It is a really cool app template to get you started.




I'll let you know how it goes, my app is still very much a work in
progress. I'm currently working on converting the Clara codebase from
crossovers to using reader conditionals so that is a bit of a diversion
from the UI side of things.



As with your project, this is one of many side projects for me. I need the
day job to pay the bills... :-/



Take care.



Alan



-- 
Note that posts from new members are moderated - please be patient with
your first post.
---
You received this message because you are subscribed to a topic in the
Google Groups ClojureScript group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojurescript/kCdOQzPNAug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript

Re: [ClojureScript] Re: freactive vs rum

[Alan Moore]

Sorry for the delayed response. Yes, I stand corrected, I evaluated just
about every front end library there is for ClojureScript and some of the
names are starting to get confusing to my age addled brain (react, reagent,
freactive, re-frame, etc..)

I really just want the DOM diffing from React and don't need any of the
other stuff. I'm considering making a ClojureScript wrapper for:

https://github.com/Matt-Esch/virtual-dom

My goal is to write most of the front end logic using rules (Clara is the
best candidate ATM) so the view portion needs to be as simple as possible
for the rules to manipulate the DOM. The rule engine provides all the data
reactivity I need - any data (normal clojure data) you put into it is
automatically pattern matched against the rules, including
unification/relationships with existing data - as defined by your rules.
Here is the general idea:

Model: Data inserted into the rule engine's working memory
View: DOM/React/Rum/vdom
Controller: Rules in the engine

It is reactive in the sense that inserting data/facts/events (from server
or user/view events) into the engine triggers rules to fire, those rules
may then update the UI or the server, rinse and repeat. There is no
polling the data for changes because the engine maintains a data
structure (a Rete graph) that pattern matches against your data as you
insert it, edge-triggered as it were... You can query the data stored in
the engine using a defquery... which is like a defrule without a RHS.

The goal for my app is to keep all the core app logic in the rules which
makes them easily unit tested because the primary externalities are just
data. Think of it as a reactive version of Datascript, at least that is how
I see it. Also, in theory, Clara artifacts such as rulesets and sessions
can be moved around a system as self contained units of logic giving you a
lot of flexibility in how you organize (or re-organize) your architecture.
According to Ryan Brush, the author of Clara, they deploy Clara in Hadoop
jobs to great effect.

Along the same lines, another experiment I want to look into is extending
the core Clojure data protocols (ISeq, Iterable, etc.) to the Clara
sessions so that, to the rest of the system, the session looks just like a
regular Clojure data container... or something like that (e.g. conj ==
insert, etc.)

I'm curious to hear how Rum works out for you. I think Rum and Quiescent
are both excellent minimalist React wrappers. Om is awesome but is more
than I need. If my experiments don't work out I may go back to it... TBD.
If you like Datascript and Quiescent then you might want to check out:

https://github.com/thegeez/clj-crud

It is a really cool app template to get you started.

I'll let you know how it goes, my app is still very much a work in
progress. I'm currently working on converting the Clara codebase from
crossovers to using reader conditionals so that is a bit of a diversion
from the UI side of things.

As with your project, this is one of many side projects for me. I need the
day job to pay the bills... :-/

Take care.

Alan


On Sat, Apr 18, 2015 at 3:56 AM, Kurt Sys kurt@gmail.com wrote:

 Op dinsdag 14 april 2015 17:24:42 UTC+2 schreef Alan Moore:
  I tried them both and they are equally viable for most projects. In my
 case I was looking for the thinnest possible wrapper to React - and I don't
 use *any* of the ratom or other state tracking features so my use
 requirements are a bit out of the mainstream. I just needed a view layer.
 
  I ended up with Rum for this reason but it was very much a toss up. I
 found I could understand the code base slightly better and liked the
 simplicity of the mixin support. I also found an example of integrating
 Datascript with Rum (same author) that was helpful because I had to
 integrate a similar data engine.
 
  Freactive might be a better choice if you have a lot of animations - I
 seem to remember that it has explicit support for it... TBD. Let us know
 how you get on with whatever you choose.
 
  Good luck.

 I found myself (re)writing all kinds of atoms and/or cursors to make it
 work in freactive - since not everything is an atom, e.g. datascript
 queries and websockets. Instead, I started creating just plain vanilla
 stuff, and got to the point where things like react components where pretty
 interesting, so I ended up using rum :p. I very much like the idea of the
 datascript chat example (http://tonsky.me/blog/datascript-chat/)
 application. freactive did'nt make that easy on me. rum mixins rather do...

 --
 Note that posts from new members are moderated - please be patient with
 your first post.
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups ClojureScript group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/clojurescript/kCdOQzPNAug/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 clojurescript+unsubscr...@googlegroups.com.
 To post

[ClojureScript] Re: freactive vs rum

[Alan Moore]

I tried them both and they are equally viable for most projects. In my case I 
was looking for the thinnest possible wrapper to React - and I don't use *any* 
of the ratom or other state tracking features so my use requirements are a bit 
out of the mainstream. I just needed a view layer.

I ended up with Rum for this reason but it was very much a toss up. I found I 
could understand the code base slightly better and liked the simplicity of the 
mixin support. I also found an example of integrating Datascript with Rum (same 
author) that was helpful because I had to integrate a similar data engine.

Freactive might be a better choice if you have a lot of animations - I seem to 
remember that it has explicit support for it... TBD. Let us know how you get on 
with whatever you choose.

Good luck.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: ClojureScript in Existing Web Application

[Alan Moore]

Marc,

You mention using La Clojure - while I have nothing against it you should 
really check out Cursive. Colin has done a fantastic job with it. See:

www.cursiveclijure.com

Just be sure to uninstall La Clojure first. If you have questions there is a 
mailing list for it:

https://cursiveclojure.com/mailinglist.html

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

Re: [ClojureScript] ExceptionInfo No such namespace: cljsjs.react at line 1 when using piggieback

[Alan Moore]

OT: I have noticed docs/comments saying that lein deps is deprecated and could 
be going away - is this still true?

I find it very useful especially to pull down dependencies before going 
somewhere w/o Internet access. If it is going to be removed are there any 
suggested alternatives/shortcuts to do this - besides a full compile, etc.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: How do we do authentification in a Om app?

[Alan Moore]

On Friday, January 23, 2015 at 7:05:58 PM UTC-8, Leon Talbot wrote:
 Le jeudi 22 janvier 2015 23:41:10 UTC-5, Zubair Quraishi a écrit :
  On Wednesday, January 21, 2015 at 5:54:28 PM UTC+1, Leon Talbot wrote:
   What are good yet simple examples of om app that that implements 
   authentification. 
   
   Thanks!
  
 
 @Zubair. Thank you for your offer! What I want to build is: a platform where 
 users can post ideas and comments, can vote for those ideas and comments 
 (hacker-news/reddit) and *eventually* can crowdfund them (a la kicktarter)

We are building this. It is being prototyped at the moment so there is nothing 
to show. It was supposed to be done by Jan 1 but my son had health issues so 
here we are at the end of Jan...

Here are the places you can get more info: 

kahunamo...@coopsource.org
@coopsource
https://groups.google.com/forum/#!forum/coopsource
https://coopsource.slack.com/messages/general/
http://coopsource.org (not live yet)

We are just now transitioning to the above from an old Atlassian account so 
there is not much there right now. We need to pull/curate from a backup.

There is still quite a bit of work to do still so we welcome all the help we 
can get.

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: Auth Token Implementation for a REST api

[Alan Moore]

On Monday, June 30, 2014 2:44:11 PM UTC-7, Geoff Little wrote:
 Does anyone know of a simple library I can use with liberator (for the 
 api-part) to, someone suggested, implement an authentication scheme using an 
 auth token?  

As Antonio said, Friend is your friend :-)

Also, I found this example to be a fairly complete starting point for building 
a REST API w/ Friend and other libraries you will likely need. While it isn't a 
basic example, it is something like what you might end up with once you flesh 
your app out a bit.

https://github.com/thegeez/clj-crud

Good luck!

Alan

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[ClojureScript] Re: ANN: Om 0.6.1, moving towards independently addressable components

[Alan Moore]

To what extent are the issues you are addressing with Om and state/cursors 
related to ORM-like problems? In a previous post:

https://groups.google.com/forum/#!topic/clojurescript/88u7kcomnUA

Here you mentioned that in Om you have a database-like system + time 
model. That made me think about the nasty ORM issues with databases and 
how cursors could be thought of as falling into the same problem set. Maybe 
there is something that can be learned (avoided?!) in Om. The component - 
app state mapping(s) looks to be a fairly difficult problem.

You probably already have this figured out so I'm interested to see your 
solution. I'm especially interested to see how your solution will work with 
a large state/DOM model and being able to support progressive reveal.

In our domain we have a very large data set that if fully rendered in the 
DOM would consume too much time/space. We have tried to solve this problem 
by only rendering those portions of the state into the DOM that are visible 
to the user so as to avoid doing work that won't ever be needed. We provide 
a means for the user to navigate into the data set and render only as much 
as is necessary but our solution is clunky...

It would be nice if Om is able to help us solve that problem. While we 
aren't using it yet, I have been experimenting with Om and am stumbling 
into the same state/data management questions as other have. In particular, 
there is the notion of application data (e.g. user profile) that represents 
the underlying data model for the domain (often stored on the server w/ 
portions cached on the client) and then there is the 
non-durable/temporary/non-shared client state that reflects the user's 
interaction and component view of that application data (e.g. the user has 
partially edited their profile's phone number.)

Maybe Om already does all that and I just don't get it... TBD.

BTW - thank you for all your hard work on Om.

Alan

On Thursday, April 24, 2014 10:03:37 AM UTC-7, David Nolen wrote:

 Om 0.6.1 significantly changes how component local state works - we now 
 rely on React's forceUpdate to update components that use local state. This 
 is a significant change so I would like people test this out on their 
 existing code bases as soon as possible.

 The immediate benefit is that components now use `=` for the 
 shouldComponentUpdate logic instead of `identical?`. This means 
 considerably more flexibility with regards to what a component may receive 
 without taking a performance hit with respect to rendering. Even more 
 importantly it's a big step towards independently addressable components.

 What are independently addressable components? Currently many people 
 struggle with the fact that parent components must take all the data 
 associated with their children. This often results in a tight coupling that 
 is not ideal for real applications. The next few releases of Om will be 
 focused on providing a sensible solution to this issue without backing away 
 from the existing efficient time travel capabilities.

 Feedback welcome!

 http://github.com/swannodette/om

 David


-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
ClojureScript group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.