Hi all, thanks for the kind words, it's very encouraging and I also hope to provide more small examples soon to better document basic usage patterns and help more people to get started...
Kovas, I understand the org-mode based approach isn't for everyone, but this route was a long deliberated and conscious step for me to better manage and split up the code, keep notes for development, describe in advance what a thing needs to do and add illustrations of some concepts. E.g. I honestly doubt I could have written the trio query engine without it! Adopting the tool (org-mode) and its approach was a thought transforming process for me, just like switching to Clojure after over a decade of Java and switching to Java from Assembly before that... This format was also especially helpful for sections of large distinct code blocks differing between CLJ & CLJS (e.g. the vector protocol impls). Allowing one to add wiki-style links, tags & mult-level headings (sections) in org-mode, and (un)folding them on demand has proven to be hugely helpful for navigating the different projects and keeping an overview & task lists in long namespaces (since I often work offline/outdoors, GH issue tracking doesn't work for me so well). Even though GH's .org file rendering has drastically improved in the past few months, it still is nowhere near as good as in org-mode itself, but I also often use just that to just quickly check & compare code. Admittedly, for many of these libs I still haven't made full use of the literate approach, often simply due to lack of time, but it's something I can and want to prioritise more in the near future... The other thing to bear in mind is that these libs have been pretty much developed in a round-robin manner for over 2 years: a new feature in one project triggers a cascade of work in one or two other projects etc. Having all of them based on the same kind of template made this all this much more efficient. TL;DR - I agree that somewhat of a more overview document/global table of contents or searchable sitemap is well needed and on the TODO list! :) (Speaking of which, most namespaces in the geom, trio, shadergraph projects now at least have their own TOC at the top of each file to quickly jump to the right place and I will add this for other libs too) I'm surprised to hear that you were struggling with the tangling process. All you need is emacs with org-mode installed (which can easily be done via M-x package-install org), then launch the tangle.sh from the command line... If that doesn't work, could you please file an issue? Re: performance I actually went through a lot of effort and *many* iterations to make most core types as fast as I could and generally speaking I think its a very capable setup for interactive apps. E.g. Vectors & matrices are lean deftypes and the former have recently been rewritten to use a pretty intense macro code generation setup, are backed by a double-array on Clojure and Float32Array in CLJS, generally resulting in a 10x speed up for WebGL (since they can now be more efficiently/directly transferred to GL attribute buffers). In many places I eschewed "idiomatic" Clojure approaches and tried avoid laziness wherever it wasn't really needed. I'm keenly awaiting the 1.7 release, though, to rewrite many lowlevel fns as transducers (which I'm still having to wrap my head around in some cases). Having said all this, I can't comment on cljs-quil at all, but am sure there're use cases where vanilla JS will give you more performance, simply due to the extra work needing to be done in CLJS for protocol dispatch and multi-arity fns. However, having spent several years working with and on Processing (committer from 2003-05), I came to realize that I like my geometry not just as loose coordinates, but deal with them as mathematical/abstract models/entities. Since 2006, this first lead to 6 years of fulltime development of toxiclibs.org, and once I discovered Clojure, eventually to thi.ng... So even though the geom lib deals with some of the same aspects & use cases as Processing/Quil, it is primarily *not* a graphics engine to throw pixels on screen, but provides tools to solve geometrical problems/tasks in a more natural/conceptual manner. The lib gives you free choice as to how you actually visualize this data. On the other hand, P5/Quil offers zero handholding for almost anything non-graphical in this field - so I don't see them as competing at all... Last but not least, the bottleneck for most interactive graphics apps these days is very often not CPU bound at all. Here I think the shadergraph tools are something I'm very, very excited about, since this allows us to provide re-usable GLSL functions and micro-libs in a very easy to use manner (and also has no other dependency to anything else in the thi.ng collection). I don't just think here about effect composers and more eye candy, but also more GPGPU style apps... Again, I have zero insight by now if/how this is addressed by cljs-quil... I'm grateful for any ideas or proposals to improve any of that, so let's please keep 'em coming! Thanks! :) K. On 25 February 2015 at 20:20, Ivan L <[email protected]> wrote: > Hi Karsten, would you consider the thing libs as a good foundation for > interactive graphics in clojurescript? Also, have you compared performance > via straight js and quil? I have seen people struggle a bit to maintain > similar performance to quil cljs for example. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. -- Karsten Schmidt http://postspectacular.com | http://toxiclibs.org | http://toxi.co.uk -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
