Can anyone recommend a tutorial or blog post on porting existing Clojure program to ClojureScript?

[Simon Brooke]

Hi

I have an existing Clojure program which is intended for use in classroom 
situations to teach kids about ecology and computer science. You can see it 
in action here  (but please don't use 
any but the basic map, since several users using bigger maps at once breaks 
my poor server); source code is here: engine 
, parser 
, user interface 
.

The problem with it is that it runs server side, and is fairly compute 
intensive - especially if many users connect at once. Furthermore, one user 
with a large map or a really complex rule can kill the performance of the 
server for everyone else. If I could move the engine client side it would 
enable one server to easily support a full classroom of users, which would 
make it far more practical; if I could move the parser client side as well 
one server could support very large numbers of users.

So I'm looking for something which gives me a 'how-to' on porting the code 
across. Any recommendations?

Thanks

Simon

-- 
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: Can anyone recommend a tutorial or blog post on porting existing Clojure program to ClojureScript?

[Pedro Santos]

Hello,

I did something similar, but my engine is pure clojure (no IO).
https://medium.com/@donbonifacio/running-clojure-code-on-javascript-e1f37071e69e

Best regards

On Thu, Aug 6, 2015 at 8:01 AM, Simon Brooke 
wrote:

> Hi
>
> I have an existing Clojure program which is intended for use in classroom
> situations to teach kids about ecology and computer science. You can see it
> in action here  (but please don't
> use any but the basic map, since several users using bigger maps at once
> breaks my poor server); source code is here: engine
> , parser
> , user interface
> .
>
> The problem with it is that it runs server side, and is fairly compute
> intensive - especially if many users connect at once. Furthermore, one user
> with a large map or a really complex rule can kill the performance of the
> server for everyone else. If I could move the engine client side it would
> enable one server to easily support a full classroom of users, which would
> make it far more practical; if I could move the parser client side as well
> one server could support very large numbers of users.
>
> So I'm looking for something which gives me a 'how-to' on porting the code
> across. Any recommendations?
>
> Thanks
>
> Simon
>
> --
> 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.
>



-- 
Pedro Santos
Home - http://psantos.zi-yu.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.

Re: Clojure, WEB and Enterprise development

[Gary Verhaegen]

I'm not sure I understand the problems here, but if you really want to wrap
a Java library that generates a "web layer", I'd suggest looking at Vaadin
rather than GWT.

Though as others have said I do not clearly see what kind of problems you
have with the current solutions (immutant, om, etc.).

On Thursday, 6 August 2015, Alexander Hudek  wrote:

> Immutant provides a lot of "enterprisy" things out of the box.
>
> On Wednesday, August 5, 2015 at 5:28:02 PM UTC-4, Olek wrote:
>>
>> Hi!
>>
>> I was using Clojure for a long time. It has been used for private and
>> commercial projects (sniffed by me and hated by others).
>>
>> Now it has been abandoned. It's not giving me any money nor there is no
>> agreement in peers to use it.
>>
>> But...
>>
>>
>> I think that Clojure has a future. Datomic is ready for new Intel mass
>> storage (which is 1000 times faster than current SSD). Clojure as lisp is a
>> head of time for most today programing paradigms.
>>
>> But
>>
>>
>> I'm disappointed by few things:
>>
>>
>> Problem: there is no a bind for the JEE servers - they should be treated
>> as the SQL - you will never reach its maturity
>>
>> Solution: so you should parasite it and make a wrapper around timed
>> services, jms queues, web services, ejb, jpa (with changed semantic fitting
>> to clojure style)
>>
>> My try: I have already build some prototype for building web services in
>> runtime (with build in http server in jdk)
>>
>>
>> Problem: there is still no true web layer - all what you can see is a
>> wrap around Servlet and HTTP protocol concept or own semantic around WWW
>>
>> Solution: you should try to build a layer around GWT or Java Prime Faces,
>> I know that now it is not possible, but you should think what steps are
>> needed to achive that
>>
>> My try: I have build and framework which abstracts from the system domain
>> in GUI and the server side conforms it's protocol (what contexts as tabs,
>> CRUD, contextual operations, elastic permissions - tab context and data
>> context, dialogs for CRUD, filters for listing, tables, dynamic forms
>> modification, validation) all was made first in Clojure and the spec of DSL
>> could produce Swing app, the same spec later could produce GWT app (for
>> known reasons the engine had to be rewritten in Java but spec could be
>> still Clojure data or XML)
>>
>> The GUI engine is so abstract that Web Layer could switch between backend
>> system and provide all the GUI functionality as needed - the limit is that
>> it was ordinary a CRUD app (card management system; football cards
>> management and bans system; CAR system with conjunction with EJBCA; user
>> and persmission managment system; lottery systems - all there where
>> registration system fits)
>>
>>
>> Let the big business promote you potential and left for yourself only the
>> evangelism of the Clojure language...
>>
>> --
> 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: New version of core.async?

[Alex Miller]

I don't know about that particular ticket but I expect to spend some time on 
async in the near future and get a release out.

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

Should the Cheat Sheet mention assoc-in for vectors?

[Carl Smotricz]

Dunno if this is the correct place and way to suggest a correction: 

Someone just mentioned to me that (assoc-in) seems to only work for maps, 
as the Cheat Sheet section on vectors doesn't mention it. I was able to 
show him otherwise, but maybe this is something the CS should pick up?

-- 
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: Should the Cheat Sheet mention assoc-in for vectors?

[Francis Avila]

assoc-in "works" for vectors in the sense that both vectors and maps 
implement ILookup (get) and IAssoc (assoc). assoc-in can navigate any 
collection that understands "get" (including sets!), and add to any 
collection that understands "assoc".

However, assoc-in will *always* create *maps* when it encounters missing 
keys. This is unlikely to be what you want most of the time when working 
with a vector structure. Examples:

(assoc-in [:a [:b [:c :d] :e]] [1 1 1] :f)
;=> [:a [:b [:c :f] :e]]
(assoc-in [] [0] :a)
;=> [:a]
(assoc-in [] [1] :a)
;IndexOutOfBoundsException   clojure.lang.PersistentVector.assocN 
(PersistentVector.java:183)
(assoc-in [] [0 0] :a)
;=> [{0 :a}]
(assoc-in [] [0 0 0] :a)
;=> [{0 {0 :a}}]
(assoc-in [] [0 0 1] :a)
;=> [{0 {1 :a}}]



On Thursday, August 6, 2015 at 7:29:04 AM UTC-5, Carl Smotricz wrote:
>
> Dunno if this is the correct place and way to suggest a correction: 
>
> Someone just mentioned to me that (assoc-in) seems to only work for maps, 
> as the Cheat Sheet section on vectors doesn't mention it. I was able to 
> show him otherwise, but maybe this is something the CS should pick up?
>

-- 
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] clj-xpath 1.4.5 OWASP XXE Vulnerability Fix

[Kyle R. Burton]

clj-xpath is a library for working with XML and XPath in Clojure.

This release [1] addresses an issue reported by Louis Nyffenegger [2].
This release changes the default features enabled in the XML parser to
improve security - see the bug for a link to hte OWASP vulnerability.


Best Regards,

Kyle Burton


[1] https://github.com/kyleburton/clj-xpath/releases/tag/clj-xpath-1.4.5

[2] https://github.com/kyleburton/clj-xpath/issues/25

-- 
Twitter: @kyleburton
Github: https://github.com/kyleburton
Blog: http://asymmetrical-view.com/
Fun: http://snapclean.me/

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

Strictly tagged clojure

[Reid McKenzie]

Hello all,

Alan Malloy and I recently implemented[1] and contributed[2] an opt-in
strict tags mode to Alexander Yakushev's Skummet compiler. To
summarize the linked blog post and merge request, we created the
`clojure.core/*strict-tags*` dynamic var which may either be set by
users at the namespace level a la `clojure.core/*warn-on-reflection*`
or set on a per-fn basis with the `^:strict` metadata annotation. When
in strict mode, type hints are interpreted not as optional and late
checked hints (the Clojure default) but as eagerly checked static
types on tagged locals and expressions.

The effect of these changes is to greatly reduce the number of
checkcast instructions emitted when performing tagged interop should
users opt into using strict mode and accept the requisite
responsibility for managing their types.

While the odds that these changes will be accepted as-is are slim, we
think they represent a valuable addition to the language and so
present them for your consideration.

- Reid

[1] - http://blog.factual.com/strictly-tagged-clojure
[2] - https://github.com/alexander-yakushev/clojure/pull/1

-- 
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: Using a dynamic var for my database connection for implicit connections+transactions

[J . Pablo Fernández]

On 5 August 2015 at 19:33, James Reeves  wrote:

> So when you're testing, presumably you use a dynamic binding to override
> the global connection to the test database?
>

The wrap transaction always overrides the dynamic binding, whether it's in
tests or not.

-- 
J. Pablo Fernández  (http://pupeno.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.

no set-car! in clojure

[杨旸]

Hi everyone,
I am current trying to implement a scheme interpreter in clojure following 
the instruction on SICP chap4.

Where I encounter a problem with adding/modifying a def var/fn in 
enviroment.

according to chap4  4.1.3 the set-variable-value! function looks like the 
following in scheme:
(define (set-variable-value! var val env)
  (define (env-loop env)
(define (scan vars vals)
  (cond ((null? vars)
 (env-loop (enclosing-environment env)))
((eq? var (car vars))
 (set-car! vals val))
(else (scan (cdr vars) (cdr vals)
(if (eq? env the-empty-environment)
(error "Unbound variable -- SET!" var)
(let ((frame (first-frame env)))
  (scan (frame-variables frame)
(frame-values frame)
  (env-loop env))




But I found there's no set-car! in clojure, which make me have to re-create 
the env while loop though the defied variables like:
*https://github.com/zacyang/sicp-in-clj/blob/master/src/sicp/ch4/core.clj 
line #348*


(defn set-variable-value!
  [var-looking-for val-to-be-set env]


  (defn find-and-change [vars vals]
(cond
 (empty? vars)   '()
 (= (first vars) var-looking-for)  (conj (find-and-change (rest vars) 
(rest vals))  val-to-be-set) 
 :else (conj (find-and-change (rest vars) (rest vals)) (first vals


  (defn env-loop
[e]

(if (= @env @the-empty-environment) 
  :ERROR-TRY-SET-UNBOUND-VARIABLE
  (let  [frame (first-frame e)
 frame-vars (frame-variables frame)
 frame-vals (frame-values frame)]

(if (not= @(enclosing-enviroment e) @the-empty-environment)
  (extend-enviroment frame-vars frame-vals (env-loop 
(enclosing-enviroment e)))
  (extend-enviroment 
   frame-vars
   (find-and-change frame-vars frame-vals)
   the-empty-environment)


  (env-loop env)
)

My question is, is there any good substitution for set-car! in scenarios 
where I need just *change* the car and cdr of something created by cons??

PS: tried swap! atom , but it will also need to change the whole 
environment structure. 



  

-- 
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: My first Clojure program (and blog post about it)

[kirby urner]

On Thursday, July 30, 2015 at 6:38:11 PM UTC-7, kirby urner wrote:
>
>
>
> On Thu, Jul 30, 2015 at 6:14 PM, Leif wrote:
>
>> This still seems very verbose to me.  I think it is because the 
>> definition of "open," "opposite," and "closed" are implicit in the great 
>> big blocks of arithmetic you are doing.  I think a useful exercise would be 
>> to define edges in terms of points, and maybe faces in terms of edges and 
>> an `face?` function.  Then define different properties like `open?` in 
>> terms of functions on edges.
>>
>>
> Yes, in the ecosystem I'm coming from, edges are indeed defined by two 
> points, points being likewise vectors (in the coordinate system sense).  
>
> An Edge is defined by two Vectors e.g.  (def a (length (Edge v0 v1))).  
> For vectors, I sometimes use non-XYZ 4-tuples called Quadrays (check 
> Wikipedia).  
>
>
Since last week I've been studying defrecord and defprotocol.  

Again, I expect this is overly verbose, any feedback welcome.  

I posted a link to the Python version I'm working from at the end.

"""
(cl) K. Urner, MIT License 2015
Python -> Java -> Clojure curriculum
2D + 3D Graphics:  Martian Math
Topic:  Quadrays
http://www.grunch.net/synergetics/quadintro.html

*https://en.wikipedia.org/wiki/Quadray_coordinates*


*Asynchronous Learning Engine (Open Source project)*


*http://controlroom.blogspot.com/2015/08/asynchronous-learning-engine-ale.html*""";

(ns test-project.quadrays)

(defprotocol Ops
  (q-add [this other])
  (q-sub [this other])
  (q-len [this])
  (q-neg [this])
  (q-norm [this]))

(defrecord Quadray [OA OB OC OD]
  Ops
  (q-norm [this]
(let [[a b c d] [(:OA this) (:OB this) (:OC this) (:OD this)]
  [x] [(min a b c d)]]
  (Quadray. (- a x) (- b x) (- c x) (- d x

  (q-neg [this] (q-norm (Quadray. (- 0 (:OA this))
  (- 0 (:OB this) )
  (- 0 (:OC this))
  (- 0 (:OD this)

  (q-len [this] (let [[a b c d] [(:OA this) (:OB this) (:OC this) (:OD this)]
  [k] [(/ (+ a b c d) 4)]
  [t0 t1 t2 t3] [(- a k) (- b k) (- c k) (- d k)]]
  (* (Math/sqrt 2.0)
 (Math/sqrt (+  (* t0 t0) (* t1 t1) (* t2 t2) (* t3 t3))

  (q-add [this other]
(q-norm (Quadray. (+ (:OA this) (:OA other))
  (+ (:OB this) (:OB other))
  (+ (:OC this) (:OC other))
  (+ (:OD this) (:OD other)

  (q-sub [this other] (q-add this (q-neg other

(def v0 (Quadray. 1 0 0 0))
(def v1 (Quadray. 0 1 0 0))
(println str (q-sub v0 v1))
(println str (q-add v0 v1))
(println str (q-neg v1))
(println str (q-len v1))


Link to Python version: 
  https://mail.python.org/pipermail/edu-sig/2015-August/011291.html

Kirby


>

-- 
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: Should the Cheat Sheet mention assoc-in for vectors?

[Andy Fingerhut]

I have added assoc-in to the Vectors/'Change' section of the cheat sheet
that is available here: http://jafingerhut.github.io

That is where the latest version is published.  The version at
clojure.org/cheatsheet gets updated less frequently -- typically a couple
of times a year, when there are more significant updates (e.g. a new
Clojure version release).

I would not recommend using the cheat sheet to tell you everything that is
or is not possible in Clojure.  By design, it is limited in the amount of
information it can give you.  The doc strings, and/or trying it out or
reading the source code, are better indications of what is possible.

Andy

On Thu, Aug 6, 2015 at 5:29 AM, Carl Smotricz 
wrote:

> Dunno if this is the correct place and way to suggest a correction:
>
> Someone just mentioned to me that (assoc-in) seems to only work for maps,
> as the Cheat Sheet section on vectors doesn't mention it. I was able to
> show him otherwise, but maybe this is something the CS should pick up?
>
> --
> 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: Should the Cheat Sheet mention assoc-in for vectors?

[Carl Smotricz]

Thank you both, Francis and Andy! :)

On Thu, Aug 6, 2015 at 7:54 PM, Andy Fingerhut 
wrote:

> I have added assoc-in to the Vectors/'Change' section of the cheat sheet
> that is available here: http://jafingerhut.github.io
>
> That is where the latest version is published.  The version at
> clojure.org/cheatsheet gets updated less frequently -- typically a couple
> of times a year, when there are more significant updates (e.g. a new
> Clojure version release).
>
> I would not recommend using the cheat sheet to tell you everything that is
> or is not possible in Clojure.  By design, it is limited in the amount of
> information it can give you.  The doc strings, and/or trying it out or
> reading the source code, are better indications of what is possible.
>
> Andy
>
> On Thu, Aug 6, 2015 at 5:29 AM, Carl Smotricz 
> wrote:
>
>> Dunno if this is the correct place and way to suggest a correction:
>>
>> Someone just mentioned to me that (assoc-in) seems to only work for maps,
>> as the Cheat Sheet section on vectors doesn't mention it. I was able to
>> show him otherwise, but maybe this is something the CS should pick up?
>>
>> --
>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ScfNTwBtS9A/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Can anyone recommend a tutorial or blog post on porting existing Clojure program to ClojureScript?

[Simon Brooke]

Thank you, that's very helpful.

On Thursday, 6 August 2015 08:50:01 UTC+1, Pedro Pereira Santos wrote:
>
> Hello,
>
> I did something similar, but my engine is pure clojure (no IO).
>
> https://medium.com/@donbonifacio/running-clojure-code-on-javascript-e1f37071e69e
>
> Best regards
>
> On Thu, Aug 6, 2015 at 8:01 AM, Simon Brooke  > wrote:
>
>> Hi
>>
>> I have an existing Clojure program which is intended for use in classroom 
>> situations to teach kids about ecology and computer science. You can see it 
>> in action here  (but please don't 
>> use any but the basic map, since several users using bigger maps at once 
>> breaks my poor server); source code is here: engine 
>> , parser 
>> , user interface 
>> .
>>
>> The problem with it is that it runs server side, and is fairly compute 
>> intensive - especially if many users connect at once. Furthermore, one user 
>> with a large map or a really complex rule can kill the performance of the 
>> server for everyone else. If I could move the engine client side it would 
>> enable one server to easily support a full classroom of users, which would 
>> make it far more practical; if I could move the parser client side as well 
>> one server could support very large numbers of users.
>>
>> So I'm looking for something which gives me a 'how-to' on porting the 
>> code across. Any recommendations?
>>
>> Thanks
>>
>> Simon
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Pedro Santos
> Home - http://psantos.zi-yu.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.

Re: no set-car! in clojure

[James Reeves]

As with all Clojure data structures, lists in Clojure are immutable, so
they cannot be modified in place.

Also, defs in Clojure are always global to the current namespace, no matter
where they are. For this reason, it's generally not a good idea to nest
defns.

You may want to refer to how other people have approached these problems.
For instance:
https://github.com/gregsexton/SICP-Clojure/blob/master/src/sicp/ch4.clj

- James

On 6 August 2015 at 16:40, 杨旸  wrote:

> Hi everyone,
> I am current trying to implement a scheme interpreter in clojure following
> the instruction on SICP chap4.
>
> Where I encounter a problem with adding/modifying a def var/fn in
> enviroment.
>
> according to chap4  4.1.3 the set-variable-value! function looks like the
> following in scheme:
> (define (set-variable-value! var val env)
>   (define (env-loop env)
> (define (scan vars vals)
>   (cond ((null? vars)
>  (env-loop (enclosing-environment env)))
> ((eq? var (car vars))
>  (set-car! vals val))
> (else (scan (cdr vars) (cdr vals)
> (if (eq? env the-empty-environment)
> (error "Unbound variable -- SET!" var)
> (let ((frame (first-frame env)))
>   (scan (frame-variables frame)
> (frame-values frame)
>   (env-loop env))
>
>
>
>
> But I found there's no set-car! in clojure, which make me have to
> re-create the env while loop though the defied variables like:
> *https://github.com/zacyang/sicp-in-clj/blob/master/src/sicp/ch4/core.clj
> 
> line #348*
>
>
> (defn set-variable-value!
>   [var-looking-for val-to-be-set env]
>
>
>   (defn find-and-change [vars vals]
> (cond
>  (empty? vars)   '()
>  (= (first vars) var-looking-for)  (conj (find-and-change (rest vars)
> (rest vals))  val-to-be-set)
>  :else (conj (find-and-change (rest vars) (rest vals)) (first vals
>
>
>   (defn env-loop
> [e]
>
> (if (= @env @the-empty-environment)
>   :ERROR-TRY-SET-UNBOUND-VARIABLE
>   (let  [frame (first-frame e)
>  frame-vars (frame-variables frame)
>  frame-vals (frame-values frame)]
>
> (if (not= @(enclosing-enviroment e) @the-empty-environment)
>   (extend-enviroment frame-vars frame-vals (env-loop
> (enclosing-enviroment e)))
>   (extend-enviroment
>frame-vars
>(find-and-change frame-vars frame-vals)
>the-empty-environment)
>
>
>   (env-loop env)
> )
>
> My question is, is there any good substitution for set-car! in scenarios
> where I need just *change* the car and cdr of something created by cons??
>
> PS: tried swap! atom , but it will also need to change the whole
> environment structure.
>
>
>
>
>
> --
> 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: no set-car! in clojure

[Francis Avila]

There is no equivalent to set-car!, because conses are not mutable. Only 
vars, refs, atoms, and agents are mutable, and they are simply containers 
for immutable values.  You could put a cons inside an atom and put a new 
transformed list into the atom. (Note even among schemes set-car! is highly 
discouraged, and I don't think Racket even has it in core 
anymore: 
http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html)

The idiomatic Clojure way of handling this is to always have an immutable 
environment and contain it in a single environment atom.  When you change 
the environment, you return a new copy of it with your change and put it in 
to the global env atom. The SICP mutates the environment instead. There's 
probably a reason for this (late/dynamic binding?) which would have a 
completely different approach in Clojure.

Some more notes:

(empty? nil) ;=> true

def and defn create namespace-global vars as a side effect--the vars are 
not lexically scoped! This is NOT like scheme's "define." I suspect all of 
your inner uses of def and defn should be let and letfn instead. def and 
defn are used at the top level or (rarely) are used a level or two down to 
close over some private data (e.g. a def inside a let). However, defs are 
practically never inside other defs.

On Thursday, August 6, 2015 at 12:36:20 PM UTC-5, 杨旸 wrote:
>
> Hi everyone,
> I am current trying to implement a scheme interpreter in clojure following 
> the instruction on SICP chap4.
>
> Where I encounter a problem with adding/modifying a def var/fn in 
> enviroment.
>
> according to chap4  4.1.3 the set-variable-value! function looks like the 
> following in scheme:
> (define (set-variable-value! var val env)
>   (define (env-loop env)
> (define (scan vars vals)
>   (cond ((null? vars)
>  (env-loop (enclosing-environment env)))
> ((eq? var (car vars))
>  (set-car! vals val))
> (else (scan (cdr vars) (cdr vals)
> (if (eq? env the-empty-environment)
> (error "Unbound variable -- SET!" var)
> (let ((frame (first-frame env)))
>   (scan (frame-variables frame)
> (frame-values frame)
>   (env-loop env))
>
>
>
>
> But I found there's no set-car! in clojure, which make me have to 
> re-create the env while loop though the defied variables like:
> *https://github.com/zacyang/sicp-in-clj/blob/master/src/sicp/ch4/core.clj 
>  
> line #348*
>
>
> (defn set-variable-value!
>   [var-looking-for val-to-be-set env]
>
>
>   (defn find-and-change [vars vals]
> (cond
>  (empty? vars)   '()
>  (= (first vars) var-looking-for)  (conj (find-and-change (rest vars) 
> (rest vals))  val-to-be-set) 
>  :else (conj (find-and-change (rest vars) (rest vals)) (first vals
>
>
>   (defn env-loop
> [e]
> 
> (if (= @env @the-empty-environment) 
>   :ERROR-TRY-SET-UNBOUND-VARIABLE
>   (let  [frame (first-frame e)
>  frame-vars (frame-variables frame)
>  frame-vals (frame-values frame)]
> 
> (if (not= @(enclosing-enviroment e) @the-empty-environment)
>   (extend-enviroment frame-vars frame-vals (env-loop 
> (enclosing-enviroment e)))
>   (extend-enviroment 
>frame-vars
>(find-and-change frame-vars frame-vals)
>the-empty-environment)
>
>
>   (env-loop env)
> )
>
> My question is, is there any good substitution for set-car! in scenarios 
> where I need just *change* the car and cdr of something created by cons??
>
> PS: tried swap! atom , but it will also need to change the whole 
> environment structure. 
>
>
>
>   
>

-- 
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: no set-car! in clojure

[Herwig Hochleitner]

You could define your own cons type, like Bodil Stokke did for her
microkanren
https://github.com/bodil/microkanrens/blob/77dbdc34cde580e26765138102cbdabbfad85b9d/mk.clj#L13
If you mark its fields with ^:volatile-mutable, you can call (set! (.-a
lst) new-car) on a cons instance.

cheers

-- 
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: My first Clojure program (and blog post about it)

[Mark Engelberg]

On Thu, Aug 6, 2015 at 10:39 AM, kirby urner  wrote:

> (ns test-project.quadrays)
>
> (defprotocol Ops
> (q-add [this other])
> (q-sub [this other])
> (q-len [this])
> (q-neg [this])
> (q-norm [this]))
>
> (defrecord Quadray [OA OB OC OD]
> Ops
> (q-norm [this]
> (let [[a b c d] [(:OA this) (:OB this) (:OC this) (:OD this)]
> [x] [(min a b c d)]]
> (Quadray. (- a x) (- b x) (- c x) (- d x
>
> (q-neg [this] (q-norm (Quadray. (- 0 (:OA this))
> (- 0 (:OB this) )
> (- 0 (:OC this))
> (- 0 (:OD this)
>
> (q-len [this] (let [[a b c d] [(:OA this) (:OB this) (:OC this) (:OD
> this)]
> [k] [(/ (+ a b c d) 4)]
> [t0 t1 t2 t3] [(- a k) (- b k) (- c k) (- d k)]]
> (* (Math/sqrt 2.0)
> (Math/sqrt (+ (* t0 t0) (* t1 t1) (* t2 t2) (* t3 t3))
>

Inside the implementation of a record definition, you can refer to all the
parts of a record more simply.
(:OA this) can just be OA and so on.
That means the `let` is also unnecessary here.

Note that `Quadray.` could be replaced by `->Quadray`.  Both forms are
acceptable, but the latter is a true function and can be passed to
higher-order functions.

Also, note that `-` can be used as a unary function.  `(- 0 x)` can just be
replaced with `(- x)`.

The larger question here is whether records/protocols are really the right
tool for the job here.  Clojure gives you a lot of ways to do a given
thing; newcomers are often attracted to records/protocols as one of the
more familiar OO-like constructs, but that doesn't mean they are always the
right fit.

Protocols are valuable for polymorphism, i.e., implementing the same
functions over several different concrete representations.  So unless you
plan to have multiple representations of Quadrays, there's no real reason
to use protocols.  And based on your naming scheme, there's absolutely no
indication that you have any intention of having these functions ever apply
to other data structures.  Remember, Clojure eschews encapsulation (no
reason for it, since everything is immutable), therefore, a function can
get exactly the same access to the so-called "privileged bits".  All your
protocol definitions as written above could simply be regular functions.

A related choice is whether to implement Quadray as a record, or just a
function that builds a map, i.e.,
(defn quadray [oa ob oc od] {:oa oa :ob ob :oc oc :od od})
or if you need a "type" to contrast it with other structures
(defn quadray [oa ob oc od] {:tag :quadray :oa oa :ob ob :oc oc :od od})

The tradeoffs are subtle.  Records give you improved performance when
accessing the "member variables", the ability to type hint the members
(which you arguably want to do here, since all the members are doubles, and
that typing the members could potentially improve your arithmetic
performance).  But records currently have a "performance bug" in 1.7 that
makes them slower than plain maps when used as keys in other maps or sets,
because they don't cache their hash values the way regular maps do.
Records are almost interchangeable with maps, but there are a few ways they
are not -- for example, records by default can't be used as a function of
their keys the way maps can.  Using plain maps also gives you a simpler
serialization story.

So, there's nothing really wrong with using records/protocols, but be aware
that there are other choices with other strengths/weaknesses.

Also, don't forget to explore the test framework versus global defs and
print statements.

-- 
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: My first Clojure program (and blog post about it)

[kirby urner]

>
>
> Also, don't forget to explore the test framework versus global defs and
> print statements.
>
> --
>


Excellent feedback Mark, thank you so much!

This is exactly what I was hoping for.  I will be simplifying said code
accordingly and posting it back.

A great way to learn!

I do think I might add the same protocol to a regular XYZ Vector defrecord
type, but then that would mean changing the names maybe to v-add, v-sub
etc. v for vector.

I have intra-conversion twixt these exotic Quadray and XYZ coordinates,
already in Python.

Plus with vectors ** we expect:  angles between any two; polar coords;
scalar grow-shrink; something like dot and cross product

So I could flesh out the one protocol (inherits from Java interface I
understand) and show how both vector notations share the same API.  That
would seem an appropriate use of the syntax maybe?

Related literature:  http://www.dividedspheres.com/

Kirby


** in this implementation a "vector" is always tail-originating at some
place we locally define as "the origin", so any to vectors will have the
same origination point, meaning a "central angle" is implied.  For
polyhedrons around the origin we build with Edges, each defined with two
vectors; and with Faces (sets of Edges).  A similar notion of vector (vs.
line segment) is found in
http://www.amazon.com/Elementary-Linear-Algebra-Stewart-Venit/dp/0534951902






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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/RvHQPfBKJuM/unsubscribe.
> To unsubscribe from this group and all its topics, 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: My first Clojure program (and blog post about it)

[Mark Engelberg]

Right, so if you use protocols, you'd just have one name:
add, sub, norm, len, neg
and use for both vectors and quadrays, rather than a v-add / q-add, etc.

If there are things that apply only to vectors and not quadrays, you could
make those their own protocol (or individual functions).

And of course, multimethods are yet another way to achieve polymorphism in
Clojure.  Multimethods would really shine if you want to get into
complicated mixtures of adding vectors and quadrays, etc., or dispatch on
something other than the type (e.g., maybe pre-normalized quadrays dispatch
to something more efficient).  Protocols (like traditional OO) can only
dispatch on the type of the first input.

One other code simplification tip: you can destructure in the parameter,
e.g., if you were to rewrite q-neg to be a plain function as opposed to a
protocol, you could still get convenient access to the member variables by
writing it like this:
(defn q-neg [{:keys [OA OB OC OD]}] (->Quadray (- OA)(- OB)(- OC) (- OD)))

http://www.john2x.com/blog/clojure-destructuring/



On Thu, Aug 6, 2015 at 1:52 PM, kirby urner  wrote:

>
>> Also, don't forget to explore the test framework versus global defs and
>> print statements.
>>
>> --
>>
>
>
> Excellent feedback Mark, thank you so much!
>
> This is exactly what I was hoping for.  I will be simplifying said code
> accordingly and posting it back.
>
> A great way to learn!
>
> I do think I might add the same protocol to a regular XYZ Vector defrecord
> type, but then that would mean changing the names maybe to v-add, v-sub
> etc. v for vector.
>
> I have intra-conversion twixt these exotic Quadray and XYZ coordinates,
> already in Python.
>
> Plus with vectors ** we expect:  angles between any two; polar coords;
> scalar grow-shrink; something like dot and cross product
>
> So I could flesh out the one protocol (inherits from Java interface I
> understand) and show how both vector notations share the same API.  That
> would seem an appropriate use of the syntax maybe?
>
> Related literature:  http://www.dividedspheres.com/
>
> Kirby
>
>
> ** in this implementation a "vector" is always tail-originating at some
> place we locally define as "the origin", so any to vectors will have the
> same origination point, meaning a "central angle" is implied.  For
> polyhedrons around the origin we build with Edges, each defined with two
> vectors; and with Faces (sets of Edges).  A similar notion of vector (vs.
> line segment) is found in
> http://www.amazon.com/Elementary-Linear-Algebra-Stewart-Venit/dp/0534951902
>
>
>
>
>
>
> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/RvHQPfBKJuM/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>

-- 
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: [ANN] suchwow: a grab-bag library with some twists

[Brian Marick]

Colin Fleming wrote:

I think that would be great. It would be preferable to have a single
repo for docstring improvements so that tools can obtain them without
bringing in other things from e.g. such-wow.


Note that everything in suchwow is public domain, so the docstrings 
there can be grabbed at will and incorporated wherever.


--
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: clj-soap (was: Beginner question

[blake watson]

We did some soap as well, and found the same thing, except in our case,
SOAP was merely a formality. In other words, it seems some people are using
only the barest of SOAP features, and wrapping up the meat up in a SOAP
envelope.

In other words, we were able to just generate a skeleton in Soap-UI and
then parse out the contents with clojure.xml/parse.

On Thu, Jul 30, 2015 at 3:36 PM, Sean Corfield  wrote:

> On Jul 29, 2015, at 7:47 PM, Mike  wrote:
>
> I have done some searching, and there is an old clj-soap library which
> Sean Corfield has mostly abandoned.
>
>
> Just to clarify: I too had started down the path of trying to find a way
> to do SOAP via Clojure and came across the old and *already abandoned*
> clj-soap library so I forked it and got it "working" with Clojure 1.3.0
> (since it was built for 1.2.0) and whilst I could get a few basic SOAP
> services working with it, nothing complex actually worked at all.
>
> At that point I tried a different approach using wsdl2java, compiling the
> generated Java, and then calling that directly and using the Axis libraries
> via Java interop from Clojure. That worked for the complex SOAP service I
> needed and took a lot less time than figuring our how to make clj-soap work
> generically.
>
> As it says on the repo:
>
> I forked it purely to get it running on Clojure 1.3 and then found it
> didn't do what I needed anyway.
>
> If you think it might be useful to you, please fork it and maintain it
> yourself. If you decide to take over as lead maintainer, let me know and
> I'll update this readme to point to your new fork.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> 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.

[ANN] Release 0.33.0 of Counterclockwise

[Laurent PETIT]

Counterclockwise, the Eclipse Clojure development tool.

Counterclockwise 0.33.0 has been released.

Highlights:

- double-click in front of forms select the whole form
- double-click inside a symbol selects the whole symbol (does not stop at
hyphens)
- Outline accepts tagged litterals
- Load file in REPL loads again the file's content in the REPL and
automatically switches it to the REPL (regression in 0.32.0)
- On OS X, $PATH passed to Leiningen is fixed (addition of missing
/usr/local/bin) so that e.g. phantomjs &al can be used in cljs tests
- Build pipeline of CCW binaries ported back to Travis CI (including UI
tests, and on their new Docker-based platform) => will simplify builds,
help with the build of Pull Requests, and cut down costs by allowing
removal of the jenkins server, eventually.
- enhancements to the `ccw.api.markers` API: made both more robust and
easier to use. The `ccw-plugin-eastwood` plugin has been adapted to these
changes. Will probably be shipped out-of-the-box in future releases of CCW.
Please test it! https://github.com/ccw-ide/ccw-plugin-eastwood/
- fix Preference Settings concerning Colors (was a regression in 0.32.0)


ChangeLog
=

http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_32_0_and_0_33_0

Installation instructions
==

http://doc.ccw-ide.org/documentation.html#_install_counterclockwise

Cheers,

-- 
Laurent Petit

-- 
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: Reality check: EC2 + Ubuntu + Atom (from GitHub) + Clojure?

[kirby urner]

To recap this thread:  I started by looking at GitHub's Atom as an IDE for 
Asynchronous Learning Engine (ALE), a name I'm using for an 
Open Source project.  I'm interested in Clojure + Java + Python as
an example "flight path" through our "curriculum space".

Turns out Eclipse is a strong candidate if a single IDE is required.  

IntelliJ with Cursive is where I'm starting, great beginning!  I use
PyCharm at work.

I now have Python and Clojure both implementing a special kind 
of vector class using PyDev for Python and CounterClockwise 
for Clojure:

http://mybizmo.blogspot.com/2015/08/eclipse-for-python-java-clojure.html

Just screen shots at this point.  

I'm finding much to like in the ease of use department.  

Eclipse remains a strong contender though of course Emacs can do all this 
too.

Kirby
 

-- 
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: Can anyone recommend a tutorial or blog post on porting existing Clojure program to ClojureScript?

[Sebastian Bensusan]

 Hi Simon,

Not exactly what you are asking, but a guide to Using cljc might be helpful:

https://github.com/clojure/clojurescript/wiki/Using-cljc

Hope this helps,

Sebastian

-- 
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: ANN: ClojureScript 1.7.28 - Optional Self Hosting

[Matthew Molloy]

Hi David,

Are macros supported directly within clojurescript then?  I'm having some 
trouble compiling a macro via defmacro.

Matt

On Saturday, August 1, 2015 at 1:52:23 AM UTC+8, David Nolen wrote:
> 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.7.28"]
> 
> 
> ClojureScript now has a proper version number. This version number is
> designed to reflect feature parity with Clojure.
> 
> 
> The primary new feature of this release is optional
> self hosting. ClojureScript can now run either on the JVM or directly on
> JavaScript. Please refer to the docstrings in the new cljs.js
> namespace for details on this functionality. cljs.js is designed to
> enable new use cases (iOS, Android, interactive tutorials, snippet
> sharing) not well served by the default compilation model.
> 
> 
> The release also includes numerous bug fixes and enhancements.
> 
> 
> This release also bumps the Clojure dependency to 1.7.0 and
> tools.reader to 0.10.0-alpha3.
> 
> 
> As always feedback welcome!
> 
> 
> ## 1.7.28
> 
> 
> ## Enhancements
> * New namespace cljs.js provides analysis, compilation, and eval
> * CLJS-1360: Refactor JS module processing to work with recent Google Closure 
> compiler changes
> * CLJS-1282: Add a :pprint option to the default reporter in cljs.test
> * CLJS-1308: :analyze-path should be extended to take a vector of paths
> * CLJS-1230: ES 2015 Module Processing
> * CLJS-1231: AMD Module Processing
> * CLJS-1092: CommonJS Module processing
> 
> 
> ## Changes
> * CLJS-1376: Printing in a tagged literal data form
> * CLJS-836: Replace seq-based iterators with direct iterator for all non-seq 
> collections that use SeqIterator
> * CLJS-1367: Expose default-warning-handler and warning-enabled?
> * CLJS-1267: Added the :end-test-all-vars and :end-test-vars events to have 
> end events for all cljs.test api functions
> * CLJS-1337: Move parse ns side-effects into a separate compiler pass
> * CLJS-1247: Split out error printing from regular printing
> * CLJS-1329: Support for reading #js tagged literals in bootstrap
> * CLJS-1191: rebased patch Update clojure.walk to the current version on 
> clojure
> * CLJS-1321: remove getNamespace & getName method calls from defrecord
> * CLJS-1281: Preserve test order
> * CLJS-934: In the REPL return vars after defs
> 
> 
> ## Fixes
> * CLJS-1316 let does not detect invalid binding vector when it contains 
> destructuring
> * CLJS-1033: take a drop accept nil as n argument
> * CLJS-1324: Compiler fails to raise warning/error when invoking a keyword 
> without arguments
> * CLJS-1352: cljs.js: Allow conditional readers
> * CLJS-1348: meta is printing for def at REPL
> * CLJS-1342: cljs.reader/read-string should throw Error when not called with 
> string
> * CLJS-1341: Fix CommonJS conversion bug
> * CLJS-1333: Analyze meta on quoted symbols
> * CLJS-1210: Javascript built-in arguments replaces nil arguments locally 
> defined by let
> * CLJS-1248: alter-meta! does not work on vars
> * CLJS-1276: var equality differs from Clojure
> * CLJS-1310: ns libspec error message misses :import
> * CLJS-428: Added step to escape docstrings with */ and associated test
> * CLJS-1331: Regex literal emits invalid JS
> * CLJS-1338: NPE in confirm-var-exists if suffix is ".."
> * CLJS-1319: Cannot locate module namespace when filename contains dash
> * CLJS-1317: Incremental compilation issues for :nodejs target
> * CLJS-1227 Raise error when if form has more than 4 statements
> * CLJS-1306: Browser REPL :asset-path with leading slash breaks source map 
> support
> * CLJS-1290: :refer does not work with Closure JS namespaces
> * CLJS-1307: Doc for ns missing
> * CLJS-1301: local :foreign-libs are not picked up the first time browser 
> REPL is started

-- 
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: Using a dynamic var for my database connection for implicit connections+transactions

[Eric Normand]

Hi Pablo

I think the reason you've got so many responses is because most people 
share the same problem. I do think this is a fruitful area of discussion. 
There are multiple ways to go about it.

Based on your original post, I'll share my two cents:

In my experience, mixing an atom and dynamic vars is unnecessary and brings 
complexity that is not worth it. It would be better to separate the two. 
That is, use the atom, which would allow you to change the state (to 
reconnect, etc). But also use the dynamic var so that the dynamic scope is 
changed. That means that you may want to define a macro (but may also do 
without);

(def current-connection (atom nil))
(def ^:dynamic db nil)

;; somewhere later
(binding [db @current-connection]
  (do-some-db-operations))

Transactions could re-bind `db` in their dynamic scope.

Rebinding a dynamic var to a new atom is a little weird. It mixes mutation 
with dynamic scope. I'm sure there are weird edge cases that are hard to 
reason about. This way unifies the operations (even the first db operation 
needs a binding) and separates it from mutation, which appears necessary in 
your code.

The other thing is that you can make a nice Ring middleware like this:

(defn wrap-db [handler]
  (fn [req]
(binding [db @current-connection]
  (handler req

The connection it gets at the beginning will be with it throughout, so you 
won't ever have a weird case where the connection atom is changed in the 
middle.

Thanks
Eric

On Thursday, August 6, 2015 at 11:56:49 AM UTC-5, J. Pablo Fernández wrote:
>
>
> On 5 August 2015 at 19:33, James Reeves  > wrote:
>
>> So when you're testing, presumably you use a dynamic binding to override 
>> the global connection to the test database?
>>
>
> The wrap transaction always overrides the dynamic binding, whether it's in 
> tests or not.
>
> -- 
> J. Pablo Fernández > (http://pupeno.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.

Re: [ANN] suchwow: a grab-bag library with some twists

[Reid McKenzie]

Awesome. Thanks for doing this Brian.

Reid

-- 
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: Strictly tagged clojure

[Alex Miller]

Hey Reid, 

I've forwarded this over to Rich and Stu to take a look at.

Alex

On Thursday, August 6, 2015 at 11:46:09 AM UTC-5, Reid McKenzie wrote:
>
> Hello all,
>
> Alan Malloy and I recently implemented[1] and contributed[2] an opt-in
> strict tags mode to Alexander Yakushev's Skummet compiler. To
> summarize the linked blog post and merge request, we created the
> `clojure.core/*strict-tags*` dynamic var which may either be set by
> users at the namespace level a la `clojure.core/*warn-on-reflection*`
> or set on a per-fn basis with the `^:strict` metadata annotation. When
> in strict mode, type hints are interpreted not as optional and late
> checked hints (the Clojure default) but as eagerly checked static
> types on tagged locals and expressions.
>
> The effect of these changes is to greatly reduce the number of
> checkcast instructions emitted when performing tagged interop should
> users opt into using strict mode and accept the requisite
> responsibility for managing their types.
>
> While the odds that these changes will be accepted as-is are slim, we
> think they represent a valuable addition to the language and so
> present them for your consideration.
>
> - Reid
>
> [1] - http://blog.factual.com/strictly-tagged-clojure
> [2] - https://github.com/alexander-yakushev/clojure/pull/1
>
>

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