Re: Java learning resources for Clojurists?

[Paul Gowder]

Oh, thank you, that looks like a great resource!

On Tuesday, August 15, 2017 at 9:24:45 PM UTC-5, Daniel Compton wrote:
>
> Eric Normand has a course "JVM Fundamentals for Clojure" which might be 
> useful? https://purelyfunctional.tv/courses/jvm-clojure/
>
> On Wed, Aug 16, 2017 at 2:20 PM Paul Gowder  > wrote:
>
>> Hi there, 
>>
>> Can anyone recommend decent resources for learning Java for experienced 
>> Clojurists who don't do enough interop?  
>>
>> After writing Clojure for about a year and a half, I find that the most 
>> continuous barrier I encounter is in understanding how to drop down to the 
>> JVM.  And it's even a barrier in using some core CLJ libraries.  
>>
>> Here's an illustration of the problem I often have.  I was writing a web 
>> application using Reagent/Immutant, and I wanted to pass data from frontend 
>> to backend over a websocket in transit format. But the only example in the 
>> github readme for Transit-CLJ involves dealing with data as a Java 
>> bytestream.  And it was just too daunting to try to figure out what flavor 
>> of JVM string the stuff being received over the websocket was under the 
>> hood, how to cast it into a bytearrayinputstream or whatever else can fit 
>> into a transit "writer," etc. Or even just like where to start translating 
>> from "here, I have a Clojure string" to "oh god, now it has to turn into 
>> some kind of low-level object that isn't a string and isn't a file but is 
>> something in between and maybe it has to be a stream and maybe it doesn't 
>>
>> Yet almost all "how to learn java" materials I can turn up seem to be 
>> directed at total beginner programmers, and start with stuff like "here's 
>> what a for loop is" rather than practical stuff like "here's how to sort 
>> out the different kinds of array-whatsits and byte-whatsats" or "here's how 
>> the entry point of a java library works" or whatnot. 
>>
>> I'm hoping there's something out there (that goes a bit deeper than the 
>> wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that 
>> someone can recommend.
>>
>> thanks!
>>
>> -Paul
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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.

Re: Java learning resources for Clojurists?

[Daniel Compton]

Eric Normand has a course "JVM Fundamentals for Clojure" which might be
useful? https://purelyfunctional.tv/courses/jvm-clojure/

On Wed, Aug 16, 2017 at 2:20 PM Paul Gowder  wrote:

> Hi there,
>
> Can anyone recommend decent resources for learning Java for experienced
> Clojurists who don't do enough interop?
>
> After writing Clojure for about a year and a half, I find that the most
> continuous barrier I encounter is in understanding how to drop down to the
> JVM.  And it's even a barrier in using some core CLJ libraries.
>
> Here's an illustration of the problem I often have.  I was writing a web
> application using Reagent/Immutant, and I wanted to pass data from frontend
> to backend over a websocket in transit format. But the only example in the
> github readme for Transit-CLJ involves dealing with data as a Java
> bytestream.  And it was just too daunting to try to figure out what flavor
> of JVM string the stuff being received over the websocket was under the
> hood, how to cast it into a bytearrayinputstream or whatever else can fit
> into a transit "writer," etc. Or even just like where to start translating
> from "here, I have a Clojure string" to "oh god, now it has to turn into
> some kind of low-level object that isn't a string and isn't a file but is
> something in between and maybe it has to be a stream and maybe it doesn't
>
> Yet almost all "how to learn java" materials I can turn up seem to be
> directed at total beginner programmers, and start with stuff like "here's
> what a for loop is" rather than practical stuff like "here's how to sort
> out the different kinds of array-whatsits and byte-whatsats" or "here's how
> the entry point of a java library works" or whatnot.
>
> I'm hoping there's something out there (that goes a bit deeper than the
> wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that
> someone can recommend.
>
> thanks!
>
> -Paul
>
> --
> 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.

Java learning resources for Clojurists?

[Paul Gowder]

Hi there, 

Can anyone recommend decent resources for learning Java for experienced 
Clojurists who don't do enough interop?  

After writing Clojure for about a year and a half, I find that the most 
continuous barrier I encounter is in understanding how to drop down to the 
JVM.  And it's even a barrier in using some core CLJ libraries.  

Here's an illustration of the problem I often have.  I was writing a web 
application using Reagent/Immutant, and I wanted to pass data from frontend 
to backend over a websocket in transit format. But the only example in the 
github readme for Transit-CLJ involves dealing with data as a Java 
bytestream.  And it was just too daunting to try to figure out what flavor 
of JVM string the stuff being received over the websocket was under the 
hood, how to cast it into a bytearrayinputstream or whatever else can fit 
into a transit "writer," etc. Or even just like where to start translating 
from "here, I have a Clojure string" to "oh god, now it has to turn into 
some kind of low-level object that isn't a string and isn't a file but is 
something in between and maybe it has to be a stream and maybe it doesn't 

Yet almost all "how to learn java" materials I can turn up seem to be 
directed at total beginner programmers, and start with stuff like "here's 
what a for loop is" rather than practical stuff like "here's how to sort 
out the different kinds of array-whatsits and byte-whatsats" or "here's how 
the entry point of a java library works" or whatnot. 

I'm hoping there's something out there (that goes a bit deeper than the 
wonderful-but-not-quite-what-i-need interop chapter in Brave and True) that 
someone can recommend.

thanks!

-Paul

-- 
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.

Re: Entity–component–system and Clojure

[Mark Mandel]

A while ago, I wrote a library called *brute *as an ECS library for Clojure
+ ClojureScript.

Articles:
http://www.compoundtheory.com/category/brute/

Github:
https://github.com/markmandel/brute
https://github.com/markmandel/brute-play-pong

Mark

On 15 August 2017 at 18:49, James Reeves  wrote:

> I wrote Ittyon  a little while
> ago, which is a database partially inspired by the entity-component model,
> but uses a more clojurey architecture.
>
> There are also experiments with trying to make rule systems like Clara
> fast enough to use in games.
>
> On 16 August 2017 at 02:05, Jeaye  wrote:
>
>> Alex Kehayias gave a talk about designing a functional game engine in
>> ClojureScript, using components, here: https://www.youtube.com/watch?
>> v=TW1ie0pIO_E I thought it was a superb talk.
>>
>> There's also Arcadia, here: https://github.com/arcadia-unity/Arcadia
>> which wrap's Unity3D in Clojure, but Unity takes about the most imperative
>> approach to components as possible.
>>
>> In general, and as Alex shows, the entity-component approach can work
>> very well with game engines. The issues of coupling can either be tackled
>> with explicit dependency declaration or by a more flexible async
>> notification/inbox system. I haven't yet built something like this, though
>> I'd like to, but, if/when I do, my design would be very much along the
>> lines of Alex's.
>>
>> J
>>
>> On Tue, Aug 15, 2017 at 05:52:38PM -0700, Didier wrote:
>> > I recently stumbled upon the entity-component-system design pattern
>> which
>> > is popular in game engine
>> > design: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80
>> %93system,
>> > and really liked what I saw, thought it could be a good fit for Clojure.
>> >
>> > Basically, it has three concepts:
>> >
>> > 1) Components are pure data grouped together as per a given domain. In a
>> > game engine that would be for example the 3D positional data related to
>> > positioning of objects in the 3D scene. So one component would be
>> > PositionComponent and it would have :X, :Y.
>> >
>> > 2) Entities are collections of Components with a unique ID.
>> >
>> > 3) Systems are processing functions that take an entity, transforming
>> their
>> > components' data, or performing side effects from them.
>> >
>> > Generally, in games, they inverse the entities, so instead of having
>> > entities contain components, they have components stored in an array
>> with
>> > the index being the entity ID, and another array which contains the set
>> of
>> > components for the entity at that index. All of this is kept track of
>> by a
>> > world container.
>> >
>> > (def world
>> >   {:entities []
>> >:comp1 []
>> >:comp2 []
>> >...})
>> >
>> >
>> > So say you want to create an entity which is composed of comp1 and
>> comp2,
>> > you would just add to the world :entities at index 0 a set #{:comp1
>> > :comp2}, and to the world :comp1 and :comp2 vectors at index 0 an
>> initial
>> > component1 and component2 data structure. In games, for performance,
>> they
>> > use a bitmask instead of a set for the entry of :entities.
>> >
>> >
>> > I'm not sure this structure is necessary if trying to use the pattern
>> not
>> > for game, but it doesn't hurt either I think.
>> >
>> > What I like about this, is I'm thinking its possible to use it to do
>> > data-driven functional object modeling in Clojure. A problem I face,
>> and I
>> > feel other faces in Clojure, is how do you model entities without OOP? I
>> > find this creates a kind of OO that is functional and data driven.
>> >
>> > You would spec a bunch of component, they're pure data. Then you'd
>> define
>> > systems (aka functions) which take an entity, and operate on the
>> entity's
>> > components (aka its data). At first glance, this appears to just be OOP,
>> > but there's no inheritance here, and functions that operate or related
>> data
>> > are decoupled from the data. Systems are implicitly mapped to
>> components,
>> > based on what they work on. So you can extend all entities with more
>> > functionality easily. You can also create entities from components on
>> the
>> > fly.
>> >
>> > On second glance, I wonder what's different about this from just
>> functions
>> > operating over data. I think its just a more rigid means to do so when
>> you
>> > need the concept of entities. In a way, entities act as a class, in that
>> > they're a template of data. A system works over that template.
>> >
>> > Has anyone experimented with this in Clojure?
>> >
>> > --
>> > 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 

Re: Clojure rookie vs parsing

[dennis zhuang]

In my experience, instaparse + defun is a good choice.

https://github.com/Engelberg/instaparse
https://github.com/killme2008/defun/

2017-08-15 22:02 GMT+08:00 Gary Trakhman :

> I enjoyed working with clj-antlr recently, it's a wrapper over a java
> library, but gives you a fast feedback loop with an interpreter instead of
> generated java code.  The 'clojurey' part is that the output is a nested
> sequence, from there it's really effective to use tree zippers and
> core.match to transform the parse-tree into the data structure you need.
>
> Take a look at:
> https://github.com/clojure/core.match
> https://github.com/aphyr/clj-antlr
> https://www.ibm.com/developerworks/library/j-treevisit/
> https://github.com/akhudek/zip-visit
>
> On Tue, Aug 15, 2017 at 9:56 AM Laurens Van Houtven <_...@lvh.cc> wrote:
>
>> Hi,
>>
>>
>> Instaparse is a great parser generator, especially if you already have a
>> BNF.
>>
>> Sent from my iPhone
>>
>> On Aug 15, 2017, at 08:44, sventrax...@gmail.com wrote:
>>
>> Thanks for your input. LFE is quite an unexpected "thing".
>>
>> What I'm trying to do, is just a "lunch time project"; something that I
>> can target without corporate constrains just as a learning exercise.
>> Furthermore I can test the Clojure version against my old working Java
>> version.
>>
>> As I was saying, while experimenting with Instaparse, I'm having the
>> feeling it is not the correct Clojure tool for this type of development
>>
>>
>>
>> On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:
>>>
>>> If you need the features of Erlang but would like that in a Lisp (not
>>> Common Lisp, though) environment, have you taken a look at LFE (Lisp
>>> Flavored Erlang)? I'm not trying to discourage you from looking at Clojure,
>>> but if you need/depend on some of the features of Erlang, LFE might be a
>>> closer fit.
>>>
>>> http://lfe.io
>>>
>>> On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com
>>> wrote:


 Hi

 Months ago I read a review that praised Clojure's clean approach and
 use of JVM that is almost always available in my deployments.

 My background: started with 370 assembly ( so I'm not young!!!) and
 during the last four years I've been using Erlang for network applications.
 For my type of work the functional approach, concurrency and bit handling
 of Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an
 exercise I would like to re implement something I did years ago in Java,
 i.e. a sort of parser. What I have on my hands is a DSL like this

 HeaderRule=hr-ftp
Term=100
   name="ftp"
   From=1
  networkPort="21"
  Protocol=1
 Tcp=1
up
 up
  up
   Then=1
  ProtocolInspection=1
 ftpRuleSet="frs-ftp"
 up
  ServiceDataFlowId=1
 payload=99
 up
  up
   up
up
 HeaderRule=hr-http
   ..

 For my old Java implementation I used state machines to build an
 internal representation, sort of an AST, that would be used to analyze pcap
 files. In my Clojure challenge, I would like to have a different approach.
 Googling around I've found many options: Parsley, Instaparse, cljcc and
 more. Some mentioned on www.clojure-toolbox.com seem to be more
 abandonware.
 At the moment I'm focusing on Instaparse. However, maybe due to the
 previous implementation, I feel that this is not the best approach with
 Clojure. Certainly my rookie state is leading me the wrong way.

 Comments and feedback will be greatly appreciated

 Fred





 --
>> 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 

Re: Entity–component–system and Clojure

[James Reeves]

I wrote Ittyon  a little while ago,
which is a database partially inspired by the entity-component model, but
uses a more clojurey architecture.

There are also experiments with trying to make rule systems like Clara fast
enough to use in games.

On 16 August 2017 at 02:05, Jeaye  wrote:

> Alex Kehayias gave a talk about designing a functional game engine in
> ClojureScript, using components, here: https://www.youtube.com/watch?
> v=TW1ie0pIO_E I thought it was a superb talk.
>
> There's also Arcadia, here: https://github.com/arcadia-unity/Arcadia
> which wrap's Unity3D in Clojure, but Unity takes about the most imperative
> approach to components as possible.
>
> In general, and as Alex shows, the entity-component approach can work very
> well with game engines. The issues of coupling can either be tackled with
> explicit dependency declaration or by a more flexible async
> notification/inbox system. I haven't yet built something like this, though
> I'd like to, but, if/when I do, my design would be very much along the
> lines of Alex's.
>
> J
>
> On Tue, Aug 15, 2017 at 05:52:38PM -0700, Didier wrote:
> > I recently stumbled upon the entity-component-system design pattern which
> > is popular in game engine
> > design: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%
> 80%93system,
> > and really liked what I saw, thought it could be a good fit for Clojure.
> >
> > Basically, it has three concepts:
> >
> > 1) Components are pure data grouped together as per a given domain. In a
> > game engine that would be for example the 3D positional data related to
> > positioning of objects in the 3D scene. So one component would be
> > PositionComponent and it would have :X, :Y.
> >
> > 2) Entities are collections of Components with a unique ID.
> >
> > 3) Systems are processing functions that take an entity, transforming
> their
> > components' data, or performing side effects from them.
> >
> > Generally, in games, they inverse the entities, so instead of having
> > entities contain components, they have components stored in an array with
> > the index being the entity ID, and another array which contains the set
> of
> > components for the entity at that index. All of this is kept track of by
> a
> > world container.
> >
> > (def world
> >   {:entities []
> >:comp1 []
> >:comp2 []
> >...})
> >
> >
> > So say you want to create an entity which is composed of comp1 and comp2,
> > you would just add to the world :entities at index 0 a set #{:comp1
> > :comp2}, and to the world :comp1 and :comp2 vectors at index 0 an initial
> > component1 and component2 data structure. In games, for performance, they
> > use a bitmask instead of a set for the entry of :entities.
> >
> >
> > I'm not sure this structure is necessary if trying to use the pattern not
> > for game, but it doesn't hurt either I think.
> >
> > What I like about this, is I'm thinking its possible to use it to do
> > data-driven functional object modeling in Clojure. A problem I face, and
> I
> > feel other faces in Clojure, is how do you model entities without OOP? I
> > find this creates a kind of OO that is functional and data driven.
> >
> > You would spec a bunch of component, they're pure data. Then you'd define
> > systems (aka functions) which take an entity, and operate on the entity's
> > components (aka its data). At first glance, this appears to just be OOP,
> > but there's no inheritance here, and functions that operate or related
> data
> > are decoupled from the data. Systems are implicitly mapped to components,
> > based on what they work on. So you can extend all entities with more
> > functionality easily. You can also create entities from components on the
> > fly.
> >
> > On second glance, I wonder what's different about this from just
> functions
> > operating over data. I think its just a more rigid means to do so when
> you
> > need the concept of entities. In a way, entities act as a class, in that
> > they're a template of data. A system works over that template.
> >
> > Has anyone experimented with this in Clojure?
> >
> > --
> > 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.
> 

Re: Entity–component–system and Clojure

[Jeaye]

Alex Kehayias gave a talk about designing a functional game engine in 
ClojureScript, using components, here: 
https://www.youtube.com/watch?v=TW1ie0pIO_E I thought it was a superb talk.

There's also Arcadia, here: https://github.com/arcadia-unity/Arcadia which 
wrap's Unity3D in Clojure, but Unity takes about the most imperative approach 
to components as possible.

In general, and as Alex shows, the entity-component approach can work very well 
with game engines. The issues of coupling can either be tackled with explicit 
dependency declaration or by a more flexible async notification/inbox system. I 
haven't yet built something like this, though I'd like to, but, if/when I do, 
my design would be very much along the lines of Alex's.

J

On Tue, Aug 15, 2017 at 05:52:38PM -0700, Didier wrote:
> I recently stumbled upon the entity-component-system design pattern which 
> is popular in game engine 
> design: 
> https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system, 
> and really liked what I saw, thought it could be a good fit for Clojure.
> 
> Basically, it has three concepts:
> 
> 1) Components are pure data grouped together as per a given domain. In a 
> game engine that would be for example the 3D positional data related to 
> positioning of objects in the 3D scene. So one component would be 
> PositionComponent and it would have :X, :Y.
> 
> 2) Entities are collections of Components with a unique ID.
> 
> 3) Systems are processing functions that take an entity, transforming their 
> components' data, or performing side effects from them.
> 
> Generally, in games, they inverse the entities, so instead of having 
> entities contain components, they have components stored in an array with 
> the index being the entity ID, and another array which contains the set of 
> components for the entity at that index. All of this is kept track of by a 
> world container.
> 
> (def world
>   {:entities []
>:comp1 []
>:comp2 []
>...})
> 
> 
> So say you want to create an entity which is composed of comp1 and comp2, 
> you would just add to the world :entities at index 0 a set #{:comp1 
> :comp2}, and to the world :comp1 and :comp2 vectors at index 0 an initial 
> component1 and component2 data structure. In games, for performance, they 
> use a bitmask instead of a set for the entry of :entities.
> 
> 
> I'm not sure this structure is necessary if trying to use the pattern not 
> for game, but it doesn't hurt either I think.
> 
> What I like about this, is I'm thinking its possible to use it to do 
> data-driven functional object modeling in Clojure. A problem I face, and I 
> feel other faces in Clojure, is how do you model entities without OOP? I 
> find this creates a kind of OO that is functional and data driven.
> 
> You would spec a bunch of component, they're pure data. Then you'd define 
> systems (aka functions) which take an entity, and operate on the entity's 
> components (aka its data). At first glance, this appears to just be OOP, 
> but there's no inheritance here, and functions that operate or related data 
> are decoupled from the data. Systems are implicitly mapped to components, 
> based on what they work on. So you can extend all entities with more 
> functionality easily. You can also create entities from components on the 
> fly.
> 
> On second glance, I wonder what's different about this from just functions 
> operating over data. I think its just a more rigid means to do so when you 
> need the concept of entities. In a way, entities act as a class, in that 
> they're a template of data. A system works over that template.
> 
> Has anyone experimented with this in Clojure?
> 
> -- 
> 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 

Entity–component–system and Clojure

[Didier]

I recently stumbled upon the entity-component-system design pattern which 
is popular in game engine 
design: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system, 
and really liked what I saw, thought it could be a good fit for Clojure.

Basically, it has three concepts:

1) Components are pure data grouped together as per a given domain. In a 
game engine that would be for example the 3D positional data related to 
positioning of objects in the 3D scene. So one component would be 
PositionComponent and it would have :X, :Y.

2) Entities are collections of Components with a unique ID.

3) Systems are processing functions that take an entity, transforming their 
components' data, or performing side effects from them.

Generally, in games, they inverse the entities, so instead of having 
entities contain components, they have components stored in an array with 
the index being the entity ID, and another array which contains the set of 
components for the entity at that index. All of this is kept track of by a 
world container.

(def world
  {:entities []
   :comp1 []
   :comp2 []
   ...})


So say you want to create an entity which is composed of comp1 and comp2, 
you would just add to the world :entities at index 0 a set #{:comp1 
:comp2}, and to the world :comp1 and :comp2 vectors at index 0 an initial 
component1 and component2 data structure. In games, for performance, they 
use a bitmask instead of a set for the entry of :entities.


I'm not sure this structure is necessary if trying to use the pattern not 
for game, but it doesn't hurt either I think.

What I like about this, is I'm thinking its possible to use it to do 
data-driven functional object modeling in Clojure. A problem I face, and I 
feel other faces in Clojure, is how do you model entities without OOP? I 
find this creates a kind of OO that is functional and data driven.

You would spec a bunch of component, they're pure data. Then you'd define 
systems (aka functions) which take an entity, and operate on the entity's 
components (aka its data). At first glance, this appears to just be OOP, 
but there's no inheritance here, and functions that operate or related data 
are decoupled from the data. Systems are implicitly mapped to components, 
based on what they work on. So you can extend all entities with more 
functionality easily. You can also create entities from components on the 
fly.

On second glance, I wonder what's different about this from just functions 
operating over data. I think its just a more rigid means to do so when you 
need the concept of entities. In a way, entities act as a class, in that 
they're a template of data. A system works over that template.

Has anyone experimented with this in Clojure?

-- 
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.

[ANN] martian 0.1.5 - now with bindings for re-frame

[Oliver Hine]

Hi everyone,

I have just released martian 0.1.5 
 which includes a new 
library called martian-re-frame 
.

Martian provides an abstraction allowing you to describe the HTTP endpoints 
that you call without methods, urls and query parameters leaking into your 
application code, allowing you to work with pure Clojure data. It builds on 
the flexible interceptor pattern familiar to users of pedestal and supports 
APIs described with Swagger.

The new support for re-frame lets you use martian to consume APIs in your 
Clojurescript app with calls modelled as effects and responses dispatched 
as events as encouraged by re-frame.

Enjoy!

Cheers,
Oliy

-- 
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.

Re: Clojure rookie vs parsing

[Gary Trakhman]

I enjoyed working with clj-antlr recently, it's a wrapper over a java
library, but gives you a fast feedback loop with an interpreter instead of
generated java code.  The 'clojurey' part is that the output is a nested
sequence, from there it's really effective to use tree zippers and
core.match to transform the parse-tree into the data structure you need.

Take a look at:
https://github.com/clojure/core.match
https://github.com/aphyr/clj-antlr
https://www.ibm.com/developerworks/library/j-treevisit/
https://github.com/akhudek/zip-visit

On Tue, Aug 15, 2017 at 9:56 AM Laurens Van Houtven <_...@lvh.cc> wrote:

> Hi,
>
>
> Instaparse is a great parser generator, especially if you already have a
> BNF.
>
> Sent from my iPhone
>
> On Aug 15, 2017, at 08:44, sventrax...@gmail.com wrote:
>
> Thanks for your input. LFE is quite an unexpected "thing".
>
> What I'm trying to do, is just a "lunch time project"; something that I
> can target without corporate constrains just as a learning exercise.
> Furthermore I can test the Clojure version against my old working Java
> version.
>
> As I was saying, while experimenting with Instaparse, I'm having the
> feeling it is not the correct Clojure tool for this type of development
>
>
>
> On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:
>>
>> If you need the features of Erlang but would like that in a Lisp (not
>> Common Lisp, though) environment, have you taken a look at LFE (Lisp
>> Flavored Erlang)? I'm not trying to discourage you from looking at Clojure,
>> but if you need/depend on some of the features of Erlang, LFE might be a
>> closer fit.
>>
>> http://lfe.io
>>
>> On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com
>> wrote:
>>>
>>>
>>> Hi
>>>
>>> Months ago I read a review that praised Clojure's clean approach and use
>>> of JVM that is almost always available in my deployments.
>>>
>>> My background: started with 370 assembly ( so I'm not young!!!) and
>>> during the last four years I've been using Erlang for network applications.
>>> For my type of work the functional approach, concurrency and bit handling
>>> of Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an
>>> exercise I would like to re implement something I did years ago in Java,
>>> i.e. a sort of parser. What I have on my hands is a DSL like this
>>>
>>> HeaderRule=hr-ftp
>>>Term=100
>>>   name="ftp"
>>>   From=1
>>>  networkPort="21"
>>>  Protocol=1
>>> Tcp=1
>>>up
>>> up
>>>  up
>>>   Then=1
>>>  ProtocolInspection=1
>>> ftpRuleSet="frs-ftp"
>>> up
>>>  ServiceDataFlowId=1
>>> payload=99
>>> up
>>>  up
>>>   up
>>>up
>>> HeaderRule=hr-http
>>>   ..
>>>
>>> For my old Java implementation I used state machines to build an
>>> internal representation, sort of an AST, that would be used to analyze pcap
>>> files. In my Clojure challenge, I would like to have a different approach.
>>> Googling around I've found many options: Parsley, Instaparse, cljcc and
>>> more. Some mentioned on www.clojure-toolbox.com seem to be more
>>> abandonware.
>>> At the moment I'm focusing on Instaparse. However, maybe due to the
>>> previous implementation, I feel that this is not the best approach with
>>> Clojure. Certainly my rookie state is leading me the wrong way.
>>>
>>> Comments and feedback will be greatly appreciated
>>>
>>> Fred
>>>
>>>
>>>
>>>
>>>
>>> --
> 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 

Re: Clojure rookie vs parsing

[Laurens Van Houtven]

Hi,


Instaparse is a great parser generator, especially if you already have a BNF.

Sent from my iPhone

> On Aug 15, 2017, at 08:44, sventrax...@gmail.com wrote:
> 
> Thanks for your input. LFE is quite an unexpected "thing".
> 
> What I'm trying to do, is just a "lunch time project"; something that I can 
> target without corporate constrains just as a learning exercise. Furthermore 
> I can test the Clojure version against my old working Java version.
> 
> As I was saying, while experimenting with Instaparse, I'm having the feeling 
> it is not the correct Clojure tool for this type of development
> 
> 
> 
>> On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:
>> If you need the features of Erlang but would like that in a Lisp (not Common 
>> Lisp, though) environment, have you taken a look at LFE (Lisp Flavored 
>> Erlang)? I'm not trying to discourage you from looking at Clojure, but if 
>> you need/depend on some of the features of Erlang, LFE might be a closer fit.
>> 
>> http://lfe.io
>> 
>>> On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com wrote:
>>> 
>>> Hi
>>> 
>>> Months ago I read a review that praised Clojure's clean approach and use of 
>>> JVM that is almost always available in my deployments. 
>>> 
>>> My background: started with 370 assembly ( so I'm not young!!!) and during 
>>> the last four years I've been using Erlang for network applications. For my 
>>> type of work the functional approach, concurrency and bit handling of 
>>> Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an 
>>> exercise I would like to re implement something I did years ago in Java, 
>>> i.e. a sort of parser. What I have on my hands is a DSL like this
>>> 
>>> HeaderRule=hr-ftp
>>>Term=100
>>>   name="ftp"
>>>   From=1
>>>  networkPort="21"
>>>  Protocol=1
>>> Tcp=1
>>>up
>>> up
>>>  up
>>>   Then=1
>>>  ProtocolInspection=1
>>> ftpRuleSet="frs-ftp"
>>> up
>>>  ServiceDataFlowId=1
>>> payload=99
>>> up
>>>  up
>>>   up
>>>up
>>> HeaderRule=hr-http
>>>   ..
>>> 
>>> For my old Java implementation I used state machines to build an internal 
>>> representation, sort of an AST, that would be used to analyze pcap files. 
>>> In my Clojure challenge, I would like to have a different approach. 
>>> Googling around I've found many options: Parsley, Instaparse, cljcc and 
>>> more. Some mentioned on www.clojure-toolbox.com seem to be more 
>>> abandonware. 
>>> At the moment I'm focusing on Instaparse. However, maybe due to the 
>>> previous implementation, I feel that this is not the best approach with 
>>> Clojure. Certainly my rookie state is leading me the wrong way.
>>> 
>>> Comments and feedback will be greatly appreciated
>>> 
>>> Fred
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> -- 
> 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.

Re: Clojure rookie vs parsing

[sventrax001]

Thanks for your input. LFE is quite an unexpected "thing".

What I'm trying to do, is just a "lunch time project"; something that I can 
target without corporate constrains just as a learning exercise. 
Furthermore I can test the Clojure version against my old working Java 
version.

As I was saying, while experimenting with Instaparse, I'm having the 
feeling it is not the correct Clojure tool for this type of development



On Tuesday, August 15, 2017 at 2:17:50 PM UTC+1, adrians wrote:
>
> If you need the features of Erlang but would like that in a Lisp (not 
> Common Lisp, though) environment, have you taken a look at LFE (Lisp 
> Flavored Erlang)? I'm not trying to discourage you from looking at Clojure, 
> but if you need/depend on some of the features of Erlang, LFE might be a 
> closer fit.
>
> http://lfe.io
>
> On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com wrote:
>>
>>
>> Hi
>>
>> Months ago I read a review that praised Clojure's clean approach and use 
>> of JVM that is almost always available in my deployments. 
>>
>> My background: started with 370 assembly ( so I'm not young!!!) and 
>> during the last four years I've been using Erlang for network applications. 
>> For my type of work the functional approach, concurrency and bit handling 
>> of Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an 
>> exercise I would like to re implement something I did years ago in Java, 
>> i.e. a sort of parser. What I have on my hands is a DSL like this
>>
>> HeaderRule=hr-ftp
>>Term=100
>>   name="ftp"
>>   From=1
>>  networkPort="21"
>>  Protocol=1
>> Tcp=1
>>up
>> up
>>  up
>>   Then=1
>>  ProtocolInspection=1
>> ftpRuleSet="frs-ftp"
>> up
>>  ServiceDataFlowId=1
>> payload=99
>> up
>>  up
>>   up
>>up
>> HeaderRule=hr-http
>>   ..
>>
>> For my old Java implementation I used state machines to build an internal 
>> representation, sort of an AST, that would be used to analyze pcap files. 
>> In my Clojure challenge, I would like to have a different approach. 
>> Googling around I've found many options: Parsley, Instaparse, cljcc and 
>> more. Some mentioned on www.clojure-toolbox.com seem to be more 
>> abandonware. 
>> At the moment I'm focusing on Instaparse. However, maybe due to the 
>> previous implementation, I feel that this is not the best approach with 
>> Clojure. Certainly my rookie state is leading me the wrong way.
>>
>> Comments and feedback will be greatly appreciated
>>
>> Fred
>>
>>
>>
>>
>>
>>

-- 
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.

Re: Clojure rookie vs parsing

[adrians]

If you need the features of Erlang but would like that in a Lisp (not 
Common Lisp, though) environment, have you taken a look at LFE (Lisp 
Flavored Erlang)? I'm not trying to discourage you from looking at Clojure, 
but if you need/depend on some of the features of Erlang, LFE might be a 
closer fit.

http://lfe.io

On Tuesday, August 15, 2017 at 8:11:53 AM UTC-4, svent...@gmail.com wrote:
>
>
> Hi
>
> Months ago I read a review that praised Clojure's clean approach and use 
> of JVM that is almost always available in my deployments. 
>
> My background: started with 370 assembly ( so I'm not young!!!) and during 
> the last four years I've been using Erlang for network applications. For my 
> type of work the functional approach, concurrency and bit handling of 
> Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an 
> exercise I would like to re implement something I did years ago in Java, 
> i.e. a sort of parser. What I have on my hands is a DSL like this
>
> HeaderRule=hr-ftp
>Term=100
>   name="ftp"
>   From=1
>  networkPort="21"
>  Protocol=1
> Tcp=1
>up
> up
>  up
>   Then=1
>  ProtocolInspection=1
> ftpRuleSet="frs-ftp"
> up
>  ServiceDataFlowId=1
> payload=99
> up
>  up
>   up
>up
> HeaderRule=hr-http
>   ..
>
> For my old Java implementation I used state machines to build an internal 
> representation, sort of an AST, that would be used to analyze pcap files. 
> In my Clojure challenge, I would like to have a different approach. 
> Googling around I've found many options: Parsley, Instaparse, cljcc and 
> more. Some mentioned on www.clojure-toolbox.com seem to be more 
> abandonware. 
> At the moment I'm focusing on Instaparse. However, maybe due to the 
> previous implementation, I feel that this is not the best approach with 
> Clojure. Certainly my rookie state is leading me the wrong way.
>
> Comments and feedback will be greatly appreciated
>
> Fred
>
>
>
>
>
>

-- 
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.

Clojure rookie vs parsing

[sventrax001]

Hi

Months ago I read a review that praised Clojure's clean approach and use of 
JVM that is almost always available in my deployments. 

My background: started with 370 assembly ( so I'm not young!!!) and during 
the last four years I've been using Erlang for network applications. For my 
type of work the functional approach, concurrency and bit handling of 
Erlang are life savings. Nonetheless I feel "the call" of Clojure. As an 
exercise I would like to re implement something I did years ago in Java, 
i.e. a sort of parser. What I have on my hands is a DSL like this

HeaderRule=hr-ftp
   Term=100
  name="ftp"
  From=1
 networkPort="21"
 Protocol=1
Tcp=1
   up
up
 up
  Then=1
 ProtocolInspection=1
ftpRuleSet="frs-ftp"
up
 ServiceDataFlowId=1
payload=99
up
 up
  up
   up
HeaderRule=hr-http
  ..

For my old Java implementation I used state machines to build an internal 
representation, sort of an AST, that would be used to analyze pcap files. 
In my Clojure challenge, I would like to have a different approach. 
Googling around I've found many options: Parsley, Instaparse, cljcc and 
more. Some mentioned on www.clojure-toolbox.com seem to be more 
abandonware. 
At the moment I'm focusing on Instaparse. However, maybe due to the 
previous implementation, I feel that this is not the best approach with 
Clojure. Certainly my rookie state is leading me the wrong way.

Comments and feedback will be greatly appreciated

Fred





-- 
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.