ANN: ClojureScript 1.9.908

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

Leiningen dependency information:

[org.clojure/clojurescript "1.9.908"]

This release includes a number of bug fixes and changes based on feedback
from the 1.9.854 release. For high level details please refer to the
announcement on the official site
https://clojurescript.org/news/2017-08-16-release

As always feedback welcome!

## 1.9.908

### Enhancements
* CLJS-2323: data readers support for records

### Changes
* CLJS-2322: Require only `@cljs-oss/module-deps` to be installed to figure
out Node.js dep graph
* CLJS-2321: Do not automatically call `set-loaded!` on the user's behalf
* CLJS-2316: Upgrade Closure Compiler to August release
* CLJS-2317: Upgrade Google Closure Library
* CLJS-2234: Make build scripts optionally less verbose
* CLJS-2314: Eliminate str call on literal strings in str macro
* CLJS-2291: Set up Windows CI
* CLJS-2286: Simplify JS module processing

### Fixes
* CLJS-2324: module-graph doesn't munge :requires when indexing inputs
* CLJS-2309: :module foreign-libs order not preserved
* CLJS-2318: module-deps.js doesn't respect the package.json `module` field
* CLJS-2312: Miss-compile: Uncaught SyntaxError: Unexpected token default
* CLJS-2315: module_deps.js can't resolve JSON modules
* CLJS-2313: :language-out is a build affecting option
* CLJS-2306: Provide better warning message when namespace can't be found
* CLJS-2303: Disable duplicate alias checking for self-host
* CLJS-2307: Closure warns on unreachable checked array code
* CLJS-2305 Tests: Unable to resolve symbol: opts in this context
* CLJS-2299: Failure with alias and bad require of clojure.spec
* CLJS-2302: Disable process-shim by default in Node.js targets
* CLJS-2266: Self-host: Cannot require clojure.x where clojure.x has no
macros namespace
* CLJS-2304: Fix compiler infrastructure tests on Windows
* CLJS-2261: Issue using interop record constructors in macros namespaces
* CLJS-2296: Foreign libs that expose modules are not being processed under
target nod
* CLJS-2293: Self-host: Can't load cljs.js owing to set alias
* CLJS-2295: `index-node-modules-dir` can't determine :main for
package.json files that have `.` in the string
* CLJS-1620: In JavaScript ES2015 modules default export name is munged to
default$
* CLJS-2287: Self-host: `require` prints result of loading node deps /
global exports
* CLJS-2290: Node packages using require('assert') fail compilation
* CLJS-2281: module_deps.js cannot compute inputs for ES6 sources
* CLJS-2284: Fix build API tests not to pollute `out` in the current
directory
* CLJS-2282: Some valid keywords are strings in JS object literals
* CLJS-2283: Regression with js-obj and gobject alias?

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

[Gregg Reynolds]

On Aug 15, 2017 7:11 AM,  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


hoorah!  HCF!  (check out boot - JCL, done right!)

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


are you sure you need a DSL?  dunno what "up" means here but fwiw i've
found that plain ol' clojure data often does the trick, maps, vectors, etc.

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

[Alan Thompson]

While Instaparse is (IMHO) the best parser for use with Clojure, you don't
have to start from such a low level (i.e. parsing a char stream text
file).  Just re-write your original problem a little and you can skip
writing a custom parser.

In Clojure, perhaps the most popular format (certainly the tersest format) is
Hiccup .  It is written as a series
of nested vectors, where the *tag* is the first item and any *attributes* are
in a map that is the 2nd item.  We choose the keyword *:value* to label
anything on the right of the equals sign in your original data.  You thus
end up with this:



(def ast-hiccup
  [:HeaderRule {:value :hr-ftp}
[:Term {:value 100}
  [:name {:value "ftp"}]
  [:From {:value 1}
[:networkPort {:value "21"}]
[:Protocol {:value 1}
  [:Tcp {:value 1}]]]
  [:Then {:value 1}
[:ProtocolInspection {:value 1}
  [:ftpRuleSet {:value "frs-ftp"}]]
[:ServiceDataFlowId {:value 1}
  [:payload {:value 99}] )

Using the tupelo.forest library
, we can easily
parse this tree of data and then issue queries on it:


(ns tst.demo.core
  (:use demo.core tupelo.test)
  (:require
[tupelo.core :as t]
[tupelo.forest :as tf] ))
(t/refer-tupelo)

(dotest
  (tf/with-forest(tf/new-forest)
(let [root-hid   (tf/add-tree-hiccup ast-hiccup)
  tree-1 (tf/hid->tree root-hid)
  bush-1 (tf/hid->bush root-hid)
  >> (spyx-pretty bush-1)   ; print the AST in "bush"
format (similar to hiccup)

  networkPort-hid (tf/find-hid root-hid [:** :From :networkPort])
  ; find the :networkPort node
  networkPort-value   (spyx (grab :value (tf/hid->node
networkPort-hid)))   ; extract the :value from it
]
  (is= bush-1
[{:value :hr-ftp, :tag :HeaderRule}
  [{:value 100, :tag :Term}
[{:value "ftp", :tag :name}]
[{:value 1, :tag :From}
  [{:value "21", :tag :networkPort}]
  [{:value 1, :tag :Protocol}
[{:value 1, :tag :Tcp}]]]
[{:value 1, :tag :Then}
  [{:value 1, :tag :ProtocolInspection}
[{:value "frs-ftp", :tag :ftpRuleSet}]]
  [{:value 1, :tag :ServiceDataFlowId}
[{:value 99, :tag :payload}] )

  (is= networkPort-value "21" ;  verify we found the value "21"

For more examples please see the forest-examples.cljc file

and the API docs .
More documentation forthcoming.

Enjoy!
Alan



On Tue, Aug 15, 2017 at 7:11 PM, dennis zhuang  wrote:

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

Re: Entity–component–system and Clojure

[Thomas]

If I am not mistaken Lightable uses it as well. There is also a plug in for 
it which helps with the ECS.

Hope that helps.

Thomas

On Wednesday, 16 August 2017 02:52:38 UTC+2, 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.