Two other things:
1) The link to the snap of the ODI video I mentioned earlier should be:
http://twitter.com/reasonsto/status/439416380761591809
2) @Kuba - In terms of working on a large codebase in Clojure:
As a long term Eclipse user for my previous Java work, I still occasionally
miss its amazing refactoring tools, but Emacs with a bunch of add-ons
(helm, org-mode, projectile & especially iedit-mode(!!!)) brings me 90+%
there too (by now). I also can't emphasize enough, how much adopting
org-mode & a literate programming format for my recent projects has
increased my productivity and generally reduced the cognitive load of
navigating & organizing a large project. So in general (and taking into
account all the other positive things Clojure enables me to do), I'm very
happy with my current process so far...
On the more problematic side: One of the most hairy & obstructing things
though, has been Clojure's insistence of non-circular dependencies between
namespaces and I've yet to come up with a solution to truly make this work
as elegant as I think it could/should be. I do understand the reasons &
reasoning behind that limitation, but the truth is, there're a number of
use cases where there simply is no clean way to avoid a circular nature and
in total I've probably lost a few weeks just trying to find a workaround
for this project alone. In the specific case of this project and to avoid
having to pack everything into a huge monolithic namespace, I ended up
defining all non-core `defrecords` in a dedicated ns (thi.ng.geom.types)
which is then `(:required)` by the different entity namespaces and their
implementations provided via `extend-type` only (instead of being able to
use the faster runtime path and include protocol impls as part of
`defrecord`). The other issue with this approach is that a user of the
library needs to include namespaces which he might not even directly use,
for example: If I wanted to compute the area of the bounding rect of a
triangle, I should just be able to write:
(require
'[thi.ng.geom.core :as g]
'[thi.ng.geom.triangle :as t])
(-> (t/equilateral2 [0 0] [100 0])
(g/bounds)
(g/area))
However, this will fail with:
IllegalArgumentException No implementation of method: :area of
protocol:#'thi.ng.geom.core/PArea found for class: thi.ng.geom.types.Rect
clojure.core/-cache-protocol-fn
The reason for this is that the triangle ns can't refer to the rect ns
(which provides the implementation of `area` for rects) and vice versa.
Hence the user will have to also manually require the rect ns (even though
it's not directly used) in order to make this work:
(require
'[thi.ng.geom.core :as g]
'[thi.ng.geom.triangle :as t]
'[thi.ng.geom.rect])
(-> (t/equilateral2 [0 0] [100 0])
(g/bounds)
(g/area))
;; => 8660.254037844386
There're a many, many such inter-dependencies in this project and IMHO all
of them are valid and not necessarily "bad" design: E.g. A circle or rect
could be sampled/interpreted as polygon, but I also want to compute the
bounding circle/rect of a polygon. Similarly, triangles are polygons too,
but polygons can be tessellated into triangles. All of these have
edges/lines, but lines have bounding rects/circles too etc. Since all of
these types and operations are working via protocols, I could see no better
way than what I've currently done. If anyone has some clever idea to
improve on this (and is CLJS compatible), I'm all ear!
On 15 Mar 2014 16:00, "Karsten Schmidt" <i...@toxi.co.uk> wrote:
> Thank you all for the kind words - I'm very chuffed and excited to develop
> this further! Sorry also for sluggish response - it's been a super busy
> week. Some combined responses below...
>
> @Malcolm - Since much of my work deals with creating visualizations of all
> sorts (not just data viz in the traditional sense), my mission for this
> project is very much about making these things easier & the process of
> data/design exploration more fluid. Projects like Processing & d3 are a
> great stepping stone in that direction as well and provide a much more
> direct route from pure data to graphic representation, but for me the main
> shortcoming of all those frameworks is their focus on pure drawing
> functionality, whereas geom is all about providing the underlying geometric
> models. Eg. Processing/Quil/OpenGL/WebGL etc. make it very easy to *draw* a
> line or other shape, but they have absolutely no concept of it and don't
> provide any functionality in order to meaningfully work with say a bunch of
> lines as entities, e.g. to find intersections, calculate a curve from them,
> turn it into a polygon, sort shapes by area or extrude them into a 3d
> object etc. I've been going on about this lack of models for a decade
> whilst using Processing and it too was the initial impetus for starting
> toxiclibs, the previous iteration of this new geom toolkit. I think,
> especially when dealing with data visualization, the presence of geometric
> models/entities representing the to-be-visualized data is of core essence
> and I don't know of any other Clojure lib dealing with this (to this
> extend) so far. Having data sets transformed/mapped into abstract geometric
> models, it's then easy to create visualizations in all sorts of formats,
> but one can't do this if only working with an output-specific graphics lib
> (e.g. SVG centric).
>
> Also, one of the next releases under the thi.ng umbrella will be a RDF and
> SPARQL-like toolkit, which will provide a more direct (and missing) link to
> use this geom package for data viz purposes. I've already used both
> (+luxor) in combo to create some 3d visualizations of open data sets about
> London boroughs for the ODI Summit last October. For that project we had
> approx. 1600 CSV files of published borough spending data, ambulance &
> crime stats and GPS shapes from the UK Statistics office. These were all
> combined into an RDF dataset, from which I created a 60sec animated 3d
> heatmap of the boroughs, rendered in full HD with Luxrender on AWS with 350
> CPUs. At my workshop at Resonate in Belgrade (in 2 weeks time) we will
> explore this kind of approach further. Next time you're at MastotonC, you
> should ask around if someone @ ODI can show you the video. An image of it
> is here[1].
>
> @Kuba - I'm afraid toxiclibs is pretty much a closed chapter by now and
> it's been over 2 years since I worked on my last Java project. I've been
> meaning to cut one more release (0021), which I've been sitting on and
> using for various workshops, but getting this out is always a (too)
> daunting process (also thanks to Processing 2.0) and honestly is very low
> priority over the next 4 months... The source is up on bitbucket[2] though,
> but I can't "release" this until I've checked & updated all 100+ examples
> and added docs for the last additions.
>
> @Lee - Thank you too! The GP part of my DevArt project[3] is (as I said in
> the video) more metaphorical. The way I see it is that visitors in the
> gallery will fulfill the fitness function and vote on designs created by
> the people using the online design tool. Every day the visitors will choose
> one of the created objects to be 3d printed in the gallery and hence
> indirectly (and over time) inform design decisions made by the "designers"
> (who want their creation to be fabricated). These "designers" are, in a
> way, the population of the GP and continuously & autonomously evolve the
> genome of the generative design process encoded by the tool. The design
> options will be fairly limited and only involve subdivision, extrusion &
> replication steps. These steps are encoded in an AST for each object, for
> which I still have to create an easy-to-use visual programming env, in the
> browser. To allow for cross-breeding & re-use, people will be able to cut &
> paste short "DNA" sequences from other existing objects. Each such re-use
> will be logged and forms a graph of co-authorships.
>
> [1] http://twitter.com/reasonsto/439416380761591809
> [2] http://hg.postspectacular.com/toxiclibs/
> [3] https://devart.withgoogle.com/#/project/16501507
> On 11 Mar 2014 07:07, "Baishampayan Ghose" <b.gh...@gmail.com> wrote:
>
>> Brilliant work. Major kudos for writing a literate program. ~BG
>>
>> On Tue, Mar 11, 2014 at 3:02 AM, Karsten Schmidt <toxmeis...@gmail.com>
>> wrote:
>> > It is my absolute pleasure to finally announce the first public
>> > release of the 2d/3d geometry library/toolkit: thi.ng/geom
>> >
>> > Having worked on this regularly since late 2011 as successor of my
>> > Java-based toxiclibs.org project, the new project has already
>> > undergone three complete overhauls as I've been improving my grasp of
>> > Clojure. The project currently consists of 26 namespaces and 6500+
>> > lines of code.
>> >
>> > You can find all existing details, sources & initial examples at:
>> > https://github.com/thi-ng/geom/blob/master/src/index.org
>> >
>> > Leiningen coords: [thi.ng/geom "0.2.0"] (available from Clojars)
>> >
>> > This project is part of a bigger & rapidly growing collection of
>> > Clojure libraries targeted at the wider computational/generative
>> > design context. All libraries in the thi.ng collection are (will be)
>> > developed in a literal programming format to also encourage their use
>> > in teaching contexts and generally try to improve the state of
>> > documentation & managing source code. Clojure with its focus on
>> > isolated functionality is particular nice to work with in this sense
>> > and Org-mode has completely transformed my way of working.
>> >
>> > Since this is only the 1st release and I've planned a few more
>> > (potentially) breaking API changes I cannot currently accept major
>> > pull requests until the API is more solid (and once I'm less up
>> > against deadlines). In general though, I hope this project has a wide
>> > enough scope & license to encourage further communal development.
>> >
>> > Lastly, if you're not too allergic to strong German accents, you can
>> > also watch (and follow along) a little live coding session I've done
>> > with Paul Kinlan @ Google Developers Live last month:
>> >
>> > http://youtu.be/tKIVJ2TaS2k?t=20m9s
>> >
>> > Happy coding! :)
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Baishampayan Ghose
>> b.ghose at gmail.com
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
