Re: Compile time binding for macros

[Jason Felice]

Better is subjective, but you could use macrolet from
https://github.com/clojure/tools.macro .


On Wed, Apr 2, 2014 at 9:14 PM, Gal Dolber  wrote:

> Is there a better way to achieve this?
>
> https://gist.github.com/galdolber/9946533
>
> Thanks!
>
> --
> 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.

Compile time binding for macros

[Gal Dolber]

Is there a better way to achieve this?

https://gist.github.com/galdolber/9946533

Thanks!

-- 
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: remove first?

[Alan Forrester]

(remove pred coll)

removes all of the items in coll satisfying pred. rest just removes
the first element of coll, not the first satisfying pred.

Alan

On 2 April 2014 21:36, Chris Lappe  wrote:
> Wouldn't just calling rest on your collection do what you want?
>
>
> On Wed, Apr 2, 2014 at 1:07 PM, Timothy Baldridge 
> wrote:
>>
>> I don't know of anything built-in, but this should do the trick:
>>
>> (defn remove-first [f [head & tail]]
>>   (if (f head)
>>   tail
>>   (cons head (lazy-seq (remove-first f tail)
>>
>> Timothy
>>
>>
>> On Wed, Apr 2, 2014 at 1:44 PM, Christopher Howard 
>> wrote:
>>>
>>> Is there some like "remove", but only removing the first item found?
>>> Not exactly an incredibly hard problem, but with all this clojure
>>> stuff about collections and sequences, I'm not quite sure what the
>>> appropriate way is to implement it.
>>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> "One of the main causes of the fall of the Roman Empire was that-lacking
>> zero-they had no way to indicate successful termination of their C
>> programs."
>> (Robert Firth)
>>
>> --
>> 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.

-- 
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: How to troubleshoot FileNotFoundException: Could not locate clojure/tools/namespace/parse...?

[Sean Corfield]

On Apr 2, 2014, at 4:49 AM, Jakub Holy  wrote:
> The problem is that the stack trace contains no indication that it is 
> clj-ns-browser that is causing the problem. I would like to know if there are 
> any tricks to troubleshoot these problems other than binary search through 
> deps/plugins in profile.clj.

Well you can use: lein deps :tree

That will show you any version conflicts as well as the paths by which those 
conflicts are reached - and it will suggest exclusions to resolve the conflicts 
(although some version conflicts can't be resolved as-is - you must upgrade one 
or other of your dependencies to get things working).

But if you want to start from the stack trace...

A lot of the stack trace can be thrown away / ignored which helps narrow things 
down...

> $ lein ring server
> Exception in thread "main" java.io.FileNotFoundException: Could not locate 
> clojure/tools/namespace/parse__init.class or 
> clojure/tools/namespace/parse.clj on classpath: , 
> compiling:(ns_tracker/parse.clj:1:1)

^^^ This tells us it failed to load clojure.tools.namespace.parse while 
compiling ns-tracker.parse...

>   at ns_tracker.core$eval514$loading__4958__auto515.invoke(core.clj:1)
>   at ns_tracker.core$eval514.invoke(core.clj:1)

^^^ ...which it found in ns-tracker.core...

>   at 
> ring.middleware.reload$eval508$loading__4958__auto509.invoke(reload.clj:1)
>   at ring.middleware.reload$eval508.invoke(reload.clj:1)

^^^ ...which it found in ring.middleware.reload...

>   at 
> ring.server.standalone$eval15$loading__4958__auto16.invoke(standalone.clj:1)
>   at ring.server.standalone$eval15.invoke(standalone.clj:1)

^^^ ...which it found in ring.server.standalone...

>   at 
> ring.server.leiningen$eval9$loading__4958__auto10.invoke(leiningen.clj:1)
>   at ring.server.leiningen$eval9.invoke(leiningen.clj:1)

^^^ ...and now we're at the top-level (since this was invoked from the user 
namespace):

>   at user$eval5.invoke(form-init6357505187919130689.clj:1)

And because all these seem to be at line 1, they're likely the (ns ...) forms 
and so we have part of the dependency chain. I mostly just skipped over all the 
clojure.* stuff except for noting (in my head) that clojure.core/load and 
clojure.core/use were called along that path.

Does that help at all?

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)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: remove first?

[Ben Wolfson]

On Wed, Apr 2, 2014 at 1:36 PM, Chris Lappe  wrote:

> Wouldn't just calling rest on your collection do what you want?
>

(remove-first #(= % 3) [1 2 3 4 3 5]) should return [1 2 4 3 5].


-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
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: remove first?

[Chris Lappe]

Wouldn't just calling rest on your collection do what you want?


On Wed, Apr 2, 2014 at 1:07 PM, Timothy Baldridge wrote:

> I don't know of anything built-in, but this should do the trick:
>
> (defn remove-first [f [head & tail]]
>   (if (f head)
>   tail
>   (cons head (lazy-seq (remove-first f tail)
>
> Timothy
>
>
> On Wed, Apr 2, 2014 at 1:44 PM, Christopher Howard 
> wrote:
>
>> Is there some like "remove", but only removing the first item found?
>> Not exactly an incredibly hard problem, but with all this clojure
>> stuff about collections and sequences, I'm not quite sure what the
>> appropriate way is to implement it.
>>
>> --
>> 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.
>>
>
>
>
> --
> "One of the main causes of the fall of the Roman Empire was that-lacking
> zero-they had no way to indicate successful termination of their C
> programs."
> (Robert Firth)
>
> --
> 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: rant / cljs in cljs ? :-)

[lypanov]

I hate REPLs. I also hate large compile times.
For me the hardest part of the ~5s compile time is not waiting, it's the 
watching of the progress of the auto build and waiting until exactly that 
moment
before pressing reload in the browser.

That being said, I find "run this currently selected code block in my 
connected browser" functionality in editors (lighttable is the one I 
use/know) to be
the best solution to this problem. It's painful as hell at first though.

I had a work around in the past via a fork of noir-cljs which would delay 
the load of the .js files until compile completed via some hacks but
now that I've switched to a browser <> editor work flow I find myself doing 
as much work as possible in the editor via the "run it in the browser REPL"
script tag trick from  lighttable that I'm no longer even noticing compile 
times. I leave them to the end of the pomodoro.

On Friday, March 21, 2014 7:48:59 AM UTC+1, t x wrote:

> Hi, 
>
> *  I'm already using: 
>
>   :incremental true 
>   :compiler { :optimizations :none } 
>
> * I'm also aware of cljs brepl 
>
>
> However: 
>
> 1) the cljs compiler is still too slow for my liking (even though it's 
> not calling closure) 
>
> 2) I don't like the cljs repl nearly as much as I like the clj repl 
>
>
> Now, my dumb/stupid question: 
>
>   Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy 
> with an interpreter that runs 10x slower, if, in exchange, I get to 
> hit "refresh" and my new code starts running. 
>
>   Furthermore, I'm _okay_ with their being a big delay every time I 
> introduce a new macro from clj land. 
>
>
>   I realize this sounds spoiled -- but -- the cljs compiler delays are 
> really really breaking my flow. 
>
>
> Thanks! 
>

-- 
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: remove first?

[A. Webb]

On Wednesday, April 2, 2014 3:39:47 PM UTC-5, Christopher Howard wrote:
>
> On Wed, 2 Apr 2014 14:07:47 -0600 
> Timothy Baldridge > wrote: 
>
> > I don't know of anything built-in, but this should do the trick: 
> > 
> > (defn remove-first [f [head & tail]] 
> >   (if (f head) 
> >   tail 
> >   (cons head (lazy-seq (remove-first f tail) 
> > 
> > Timothy 
> > 
> > 
>
> Thanks. This seems to work for my purposes, although I modified it to 
> handle the empty vector: 
>
> (defn remove-first [f [head & tail]] 
>   (if (not head) [] 
>   (if (f head) 
>   tail 
>   (cons head (lazy-seq (remove-first f tail)) 
>
> This implementation doesn't seem to work on everything that "remove" 
> works on: 
>
> com.example.myapp=> (remove #(= [1 2] %) {1 2 3 4}) 
> ([3 4]) 
> com.example.myapp=> (remove-first #(= [1 2] %) {1 2 3 4}) 
> UnsupportedOperationException nth not supported on this type: 
> PersistentArrayMap  clojure.lang.RT.nthFrom (RT.java:835) 
>
 
To fix that, use `seq` on the collection argument. Also, if you want a 
emtpy sequence as a result instead of nil, just move the lazy-seq up since 
(lazy-seq nil) is an empty sequence.
 
(lazy-seq (when-let [[head & tail] (seq coll)] ...)

-- 
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] - lein-repack 0.1.0 - Repack your project for deployment and distribution

[zcaudate]

lein-repack

Repack your project for deployment and distribution
Motivation

lein-repack was written to solve a problem I had with utilities and general 
purpose libraries. In my experience, clojure libraries are much better when 
they are distributed in small packages. However, functionality is much 
easier to develop when the project is big: when we try to build our general 
purpose libaries in small packages, they become a nightmare to test and 
deploy.

lein-repack redistributes your code base into managable, deployable chunks 
and analyses your source files to automatically resolve internal and 
external dependencies. It this way, a big clojure project can now be broken 
up into sub-packages for deployment and redistribution.

The plugin will:

   - Create sub-projects for all sub-namespaces in a project
   - Will look through source files and figure out project dependencies
   - Will repackage a project into many smaller artifacts for easier 
   deployment and distribution


--
Walkthrough

For example, if there were a project called lama at version 0.1.0 and the 
files were organised like this:

- src
   - lama
   - weapons
  - gun.clj
   - food
  - prepare.clj
   - food.clj
   - core.clj

Running lein repack install will split the project into four jars and 
install them in maven.

lama-0.1.0.jar
lama-core-0.1.0.jar
lama-food-0.1.0.jar
lama-weapons-0.1.0.jar

Running lein repack deploy will deploy all four artifacts to clojars.

Once the artifacts are installed/deployed, they are now ready to be used. 
For example, if only the functionality for lama.weapons were required for 
another project, it can be imported individually in the project by adding 
[lama.weapons 
"0.1.0"] to project dependencies. The entire project can be imported my 
adding [lama "0.1.0"] to project dependencies.

-

More on the github page - https://github.com/zcaudate/lein-repack

-- 
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: remove first?

[Christopher Howard]

On Wed, 2 Apr 2014 14:07:47 -0600
Timothy Baldridge  wrote:

> I don't know of anything built-in, but this should do the trick:
> 
> (defn remove-first [f [head & tail]]
>   (if (f head)
>   tail
>   (cons head (lazy-seq (remove-first f tail)
> 
> Timothy
> 
> 

Thanks. This seems to work for my purposes, although I modified it to
handle the empty vector:

(defn remove-first [f [head & tail]]
  (if (not head) []
  (if (f head)
  tail
  (cons head (lazy-seq (remove-first f tail))

This implementation doesn't seem to work on everything that "remove"
works on:

com.example.myapp=> (remove #(= [1 2] %) {1 2 3 4})
([3 4])
com.example.myapp=> (remove-first #(= [1 2] %) {1 2 3 4})
UnsupportedOperationException nth not supported on this type: 
PersistentArrayMap  clojure.lang.RT.nthFrom (RT.java:835)

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

Meta-eX - The Music of Code

[Samuel Aaron]

Howdy there Clojuristaritorians!

For those of you that enjoy seeing applications of code in none-business 
contexts, you might be excited to see Clojure being mentioned in Imperica - a 
Digital Arts & Culture Magazine:

http://www.imperica.com/en/in-conversation-with/meta-ex-the-music-of-code

Enjoy, and happy (arts) hacking!

Sam

---
http://sam.aaron.name

-- 
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: remove first?

[Timothy Baldridge]

I don't know of anything built-in, but this should do the trick:

(defn remove-first [f [head & tail]]
  (if (f head)
  tail
  (cons head (lazy-seq (remove-first f tail)

Timothy


On Wed, Apr 2, 2014 at 1:44 PM, Christopher Howard wrote:

> Is there some like "remove", but only removing the first item found?
> Not exactly an incredibly hard problem, but with all this clojure
> stuff about collections and sequences, I'm not quite sure what the
> appropriate way is to implement it.
>
> --
> 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.
>



-- 
"One of the main causes of the fall of the Roman Empire was that-lacking
zero-they had no way to indicate successful termination of their C
programs."
(Robert Firth)

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

remove first?

[Christopher Howard]

Is there some like "remove", but only removing the first item found?
Not exactly an incredibly hard problem, but with all this clojure
stuff about collections and sequences, I'm not quite sure what the
appropriate way is to implement it.

-- 
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 Langohr 2.8 is released

[Michael Klishin]

Langohr [1] is a small, feature complete Clojure RabbitMQ client.

Release notes:
http://blog.clojurewerkz.org/blog/2014/04/02/langohr-2-dot-8-1-is-released/

1. http://clojurerabbitmq.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: ClojureScript 0.0-2202

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

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

New release version: 0.0-2202

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2202"]

This release is similar to 0.0-2199, it just addresses an issue that
cropped up with the latest Google Closure Library Third Party release.

David

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

[Michael Klishin]

Propertied [1] is a tiny library for working with property files
and java.util.Properties.

Release notes:
http://blog.clojurewerkz.org/blog/2014/04/02/propertied-1-dot-2-0-is-released/

1. https://github.com/michaelklishin/propertied
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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 Validateur 2.0.0 is released

[Michael Klishin]

Validateur [1] is a small validation library for Clojure and ClojureScript.

Release notes:
http://blog.clojurewerkz.org/blog/2014/04/02/validateur-2-dot-0-0-is-released/

1. http://clojurevalidations.info
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
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: Basic string modification question

[Jozef Wagner]

No. IMO this is not a common operation and should not be in core. If you
need do it a lot, you should not use java string in the first place.

What should be included in core is a transient string, with support for
assoc!.

Jozef


On Wed, Apr 2, 2014 at 7:49 PM, Andy Smith wrote:

> just a shame its not in the core, no?
>
>
> On Wednesday, 2 April 2014 18:06:03 UTC+1, A. Webb wrote:
>>
>> Using subs (no need for join) is the way I would go, just define
>>
>>
>> (defn replace-at [s n c] (str (subs s 0 n) c (subs s (inc n
>>
>> (replace-at "hello" 1 "a") ;=> "hallo"
>>
>> and carry on.
>>
>>
>>
>  --
> 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: Basic string modification question

[Andy Smith]

just a shame its not in the core, no?

On Wednesday, 2 April 2014 18:06:03 UTC+1, A. Webb wrote:
>
> Using subs (no need for join) is the way I would go, just define
>  
>
> (defn replace-at [s n c] (str (subs s 0 n) c (subs s (inc n
>
> (replace-at "hello" 1 "a") ;=> "hallo"
>
> and carry on.
>
>  
>

-- 
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: REPL Reloaded

[david]

BTW, I'm currently looking for work as a Clojure developer.  If you like 
what you see, please hit me up.

David

-- 
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: Basic string modification question

[A. Webb]

Using subs (no need for join) is the way I would go, just define
 

(defn replace-at [s n c] (str (subs s 0 n) c (subs s (inc n

(replace-at "hello" 1 "a") ;=> "hallo"

and carry on.

 

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

REPL Reloaded

[david]

I'd like to introduce stch.ns.  What is stch.ns?  In short, it's a 
namespace utility for reloading modified files that's designed to be used 
in a REPL.  Now you may be thinking we already have tools.namespace, so 
what's the big deal.  Here are some differences:

1. Aliased namespaces are preserved upon reloading.
2. If you 'use'd a namespace previously, stch.ns attempts to reload the 
namespaces using 'use' instead of 'require.'
3. Only the project's src directory is checked by default.  This can be 
modified, of course.
4. Any exceptions that are thrown while trying to reload a namespace are 
return in the result map under the 'exceptions' key.  Each key/value pair 
represents the namespace and the corresponding exception message.  This 
turns out to be really convenient, alleviates a call to clojure.repl/pst, 
and also allows for multiple exceptions to be caught in namespaces that 
don't depend on one another.

All the features that make tools.namespace great, like generating a 
dependency graph are still there.  As are some of the issues inherent in 
reloading namespaces (e.g., records and protocol fns).

Project page can be found here: https://github.com/stch-library/ns

To use, add the following as a dependency to your lein user profile in 
~/.lein/profiles.clj:

[stch-library/ns "0.3.0"]


Enjoy.

-- 
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: Basic string modification question

[Andy Smith]

I guess my point is that if the java function is so good, then why doesnt 
the clojure library thinly wrap it, so that your code remains portable 
clojure?


On Wednesday, 2 April 2014 12:50:00 UTC+1, guns wrote:
>
> On Wed  2 Apr 2014 at 04:06:40AM -0700, Andy Smith wrote: 
>
> > If there is nothing better then I wonder why there isn't something 
> > like this in the clojure standard libraries (must be a good reason I 
> > suppose)? Its a fairly standard function for a string library isnt it? 
>
> It would be a terrible function for an immutable string library. 
> StringBuilder and StringBuffer are solid, fast, and working with them in 
> Clojure is painless. 
>
>

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

self-evaluation of record instances

[Greg D]

Greetings,

The nuance below took a long time to identify and reduce from a test 
failure. Should it be considered a bug?

$ lein repl
nREPL server started on port 52758 on host 127.0.0.1
REPL-y 0.3.0
Clojure 1.6.0


user=> (defrecord Fields0 [])  ; record with 0 fields
user.Fields0
user=> (defrecord Fields1 [f]) ; record with 1 field
user.Fields1
user=> (def f0 (->Fields0)); instance with empty map
#'user/f0
user=> (def f0x (map->Fields0 {:x 0})) ; instance with not-empty map, due 
to extra field
#'user/f0x
user=> (def f1 (map->Fields1 {}))  ; instance with not-empty map, 
declared field is nil
#'user/f1
user=> f0
#user.Fields0{}
user=> f0x
#user.Fields0{:x 0}
user=> f1
#user.Fields1{:f nil}
user=> (eval f0)   ; *** morphs to empty map on eval ***
{}
user=> (eval f0x)  ; self-evaluates when non-empty map, 
field added
#user.Fields0{:x 0}
user=> (eval f1)   ; self-evaluates when non-empty map, 
declared field
#user.Fields1{:f nil}
user=> 

Greg

p.s. A little help with "not quite getting 
refs", 
please? Or is this the wrong forum for such a question?

-- 
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: om: state management considerations

[David Nolen]

On Wed, Apr 2, 2014 at 3:42 AM, rlewczuk  wrote:

>
> First one is about object created by (om/build ...) - in all tutorials
> these objects are always created on the fly in (render ...) functions. So
> if some component disappears from view for some time, it loses its state.
> This might be the case in tab panels for example: views representing
> individual tabs disappear when user switches onto another tab. Is it safe
> to retain reference to such view created by om/build or should it be build
> from scratch every time ?
>

In the case of tabs I would generally not destroy the view but simply hide
it with styling. Views should always be built from scratch every time - it
is not expensive :) Virtual DOM FTW.


> Second thing is inter-component communication. I assume that meddling with
> state of one component from another component (eg. reading data from edited
> row by data grid) is considered harmful and core.async channel should be
> used in such cases which implies actor model for UI app. Is it safe to
> assume that om is opinionated in this regard (using actor model for
> communication) ? If so, are there materials regarding proper design and
> structuring of actors and their communication (think: GoF-like 'design
> patterns' for actor model) ? I've read some parts of a few  Erlang books
> regarding some of it but it seems to cover only basics and simple cases.
>

Yes for coordination between components I would use either callbacks in the
simple case and channels in the complex one.

David

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

Integration with Mutable Object-Oriented Eventing Hell

[Christian Eitner]

Hello everybody,

Given an enormous network of inter-referenced, mutable objects which have 
to change in-place driven by events (= the OO system).

Which strategy would you recommend to plug into such a system with Clojure, 
building an island of immutable functional programming saneness? How to 
build this famous 'stateful bridge' that I have read about here and there, 
but have not found concrete examples for?

Or would you really dissuade me from trying anything like that, and treat 
Clojure's 'hostedness' as simply a way to use the host's array of libraries?

Any hints or references to further literature would be welcome.

Thanks for your consideration,

Christian

-- 
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: Basic string modification question

[guns]

On Wed  2 Apr 2014 at 04:06:40AM -0700, Andy Smith wrote:

> If there is nothing better then I wonder why there isn't something
> like this in the clojure standard libraries (must be a good reason I
> suppose)? Its a fairly standard function for a string library isnt it?

It would be a terrible function for an immutable string library.
StringBuilder and StringBuffer are solid, fast, and working with them in
Clojure is painless.

> the first isnt pure clojure wo I would probably try to avoid this...
> e.g. what if I want to port to clojureCLR?

There are languages that attempt to be multiplatform (e.g. Haxe), but
Clojure is not one of them. Seamless interaction with the host platform
is an explicit goal.

This is an easy trade-off IMO; you give up the hypothetical freedom of
switching to entirely new OS/runtime in the future for access to more
features and better performance now.

guns


pgpQEvfXJVwDk.pgp
Description: PGP signature

How to troubleshoot FileNotFoundException: Could not locate clojure/tools/namespace/parse...?

[Jakub Holy]

When starting lein (namely lein ring server) I got a little helpful 
exception and stack trace with the key line being:

FileNotFoundException: Could not locate 
clojure/tools/namespace/parse__init.class or 
clojure/tools/namespace/parse.clj on classpath

I have narrowed it down to the dependency [clj-ns-browser "1.3.1"] in 
myprofile.clj.

*The problem is that the stack trace contains no indication that it is 
clj-ns-browser that is causing the problem.* I would like to know if there 
are any tricks to troubleshoot these problems other than binary search 
through deps/plugins in profile.clj.

Thank you!

Here is the full stack trace:

$ lein ring server
Exception in thread "main" java.io.FileNotFoundException: Could not locate 
clojure/tools/namespace/parse__init.class or 
clojure/tools/namespace/parse.clj on classpath: , 
compiling:(ns_tracker/parse.clj:1:1)
at clojure.lang.Compiler.load(Compiler.java:7142)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$use.doInvoke(core.clj:5618)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at ns_tracker.core$eval514$loading__4958__auto515.invoke(core.clj:1)
at ns_tracker.core$eval514.invoke(core.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6692)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$use.doInvoke(core.clj:5618)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at 
ring.middleware.reload$eval508$loading__4958__auto509.invoke(reload.clj:1)
at ring.middleware.reload$eval508.invoke(reload.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6692)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:628)
at clojure.core$use.doInvoke(core.clj:5618)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at 
ring.server.standalone$eval15$loading__4958__auto16.invoke(standalone.clj:1)
at ring.server.standalone$eval15.invoke(standalone.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6692)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at 
ring.server.leiningen$eval9$loading__4

Re: Basic string modification question

[Max Penet]

about 1. if that's meant to be portable, yes, not the best indeed, but if 
you look at c.c.string/* or even c.c/str, most of the functions use 
stringbuilder I think.
about 2. probably slower than subs, these are just alternatives to what you 
suggested

On Wednesday, April 2, 2014 1:06:40 PM UTC+2, Andy Smith wrote:
>
> the first isnt pure clojure wo I would probably try to avoid this... e.g. 
> what if I want to port to clojureCLR?
>
> The second 'looks' quite a roundabout way of simply manipulating a string?
>
> How would the following compare for performance?
>
> (defn replace-substring [s r start len] (str (subs s 0 start) r (subs s (+ 
> len start
>
> If there is nothing better then I wonder why there isn't something like 
> this in the clojure standard libraries (must be a good reason I suppose)? 
> Its a fairly standard function for a string library isnt it?
>
> Andy
>
>

-- 
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: Basic string modification question

[Andy Smith]

the first isnt pure clojure wo I would probably try to avoid this... e.g. 
what if I want to port to clojureCLR?

The second 'looks' quite a roundabout way of simply manipulating a string?

How would the following compare for performance?

(defn replace-substring [s r start len] (str (subs s 0 start) r (subs s (+ 
len start

If there is nothing better then I wonder why there isn't something like 
this in the clojure standard libraries (must be a good reason I suppose)? 
Its a fairly standard function for a string library isnt it?

Andy

-- 
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: Basic string modification question

[Max Penet]

There are many ways to do this, these 2 come to mind: 

(doto (StringBuilder. "abc") (.setCharAt 2 \d))

(apply str (assoc (vec "abc") 2 "d"))

The former is probably a lot faster (uglier too)...

On Wednesday, April 2, 2014 12:10:48 PM UTC+2, Andy Smith wrote:
>
> Hi,
>
> I see there are a lot of functions strings, but nothing that allows me to 
> create a new string with a character replaced at a given index? Am I meant 
> to use subs and join to do this? It seems a bit long-winded? I wonder why 
> there isnt a helper function out of the box to do this (or is there?)
>
> Thanks
>
> Andy
>

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

Basic string modification question

[Andy Smith]

Hi,

I see there are a lot of functions strings, but nothing that allows me to 
create a new string with a character replaced at a given index? Am I meant 
to use subs and join to do this? It seems a bit long-winded? I wonder why 
there isnt a helper function out of the box to do this (or is there?)

Thanks

Andy

-- 
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: REPL: viewing data structures containing infinite lists

[Phillip Lord]

Maik Schünemann  writes:

> There is real no sensible default value rather than the current.


I would say that there is no sensible default value *including* the
current. Certainly at REPL usage, the current value is probably the
least sensible.

My sensible default is 32.

Phil

-- 
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: REPL: viewing data structures containing infinite lists

[Phillip Lord]

kovas boguta  writes:
> Chalk this up as another cautionary tale about global singletons.

It's dynamic, so it can be bound for a repl thread!

> What we need is a parameterizable write-edn function, mirroring the
> already extant read-edn. The function should guarantee it will either
> write valid EDN, or throw an exception. It should also take as an
> argument a map that allows one to specify the printing function for
> any datatype.

I think this makes sense as well. On casual reading it's not at all
obvious why clojure.edn has a read function but no write.

> With write-edn out of the way, we need a similar function optimized
> for printing forms at the repl (with no guarantee that its output is
> itself readable), and make it the default for the various repls.


Agreed.

Phil

-- 
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: REPL: viewing data structures containing infinite lists

[Phillip Lord]

Andy mentioned files, but yes, in a pipe this is true. Still, it's not
true on the REPL; I can't think of an obvious use case there, and if
there is one then having the programmer work around something like
*interactive-print-length* would be reasonable.

Note that we are talking about an infinite data structure here, not an
infinite loop. As a specific example, say we wanted to produce a
/dev/random like command, you would not achieve this by printing an
infinite random list because you'd get a "(" a the beginning which was
never closed. You'd loop. So, this would not be affected by a limit on
the size of a single data structure.

Gary Trakhman  writes:

> It's possible for an infinite print to be just fine, it's a streaming API
> after all, consider invoking a clojure program in the middle of some unix
> pipes.
>
>
> On Tue, Apr 1, 2014 at 12:58 PM, Phillip Lord
> wrote:
>
>>
>> Of course, in this circumstances, infinitely long lists are not going to
>> behave well either.
>>
>> But, it seems to me, that this is (or should be) independent of
>> interactive use in the REPL. The current behaviour is never nice.
>> Probably, there needs to be a *interactive-print-length* var or
>> equivalent.
>>
>> Andy Fingerhut  writes:
>>
>> > One argument for default value of *print-length* being nil: Plenty of
>> > people print Clojure data structures to files and later read them back
>> in.
>> > The data would be corrupted if *print-length* was a too-small numeric
>> value
>> > for your particular data.  It might not be obvious until much later that
>> > you have lost data.
>> >
>> > Andy
>> >
>> >
>> > On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist 
>> wrote:
>> >
>> >> Is there any good reason for not providing a default value for
>> >> *print-length*?
>> >> I think that if you *really* want to print a list containing 100K items,
>> >> you would have to set *print-length*.
>> >>
>> >> Basically it seems less harmful to set it to a nice value by
>> default(42?)
>> >> than possible locking up the REPL.
>> >>
>> >>
>> >> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman > >wrote:
>> >>
>> >>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>> >>>
>> >>>
>> >>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard <
>> cmhowa...@alaska.edu
>> >>> > wrote:
>> >>>
>>  Is there some kind of "safe" function for printing representations of
>>  lazy, infinite data structures? I'm finding I like using them inside
>>  other data structures here and there. However, when I go to play
>>  around with things in the REPL, sooner or later my workflow is
>>  interrupted by 3 million characters streaming across the console.
>> 
>>  I don't imagine there would be any way for the REPL to detect that a
>>  lazy sequence was infinite. However, if it would simply refuse to
>>  evaluate lazy sequence (say, represent them by some special
>> identifier)
>>  that
>>  would be good enough for 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.
>> 
>> >>>
>> >>>  --
>> >>> 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...@googlegrou

Re: Porting parsley & paredit.clj to Clojurescript: Crazy, or inevitable?

[Christophe Grand]

Hi Kovas,

On Wed, Apr 2, 2014 at 3:26 AM, kovas boguta  wrote:

> Looking through the source for parsley & paredit.clj, I'm halfway
> convinced that maybe its not so hard to port these to clojurescript.
>
> Anyone have input in either direction?
>

We (Laurent and me) are planning an overhaul of paredit.clj.


>
> Most of the Java interop seems to be
> 1. ArrayList (in parsley)
> 2. Various string methods (.endsWith, .indexOf, etc)
> 3. Regular expressions
>
> Is there something I'm missing that would require structural change?
>

Apart from the fact that I'm far from being satisfied by the state of
parsley, none I can think of.


Rant on the state of parsley;
1/ what I think is mostly right with it: true total incremental lexerless
parsing updating multiple views ("functional trees").
2/ what I think is wrong with it: its expressive power -- switching to more
lookahead would be doable but a meager gain for a sizeable effort -- I'd
like to bring incrementalism to a parser capable of handling any CFG but I
fail to find a sensible[1] way to make a CFG-class parser to be total while
not realizing most of the parse forrest

[1] one that nearly minimize the ignored input length and is stateless (a
parsing from scratch should return the same ignored spans)


Christophe
-- 
On Clojure http://clj-me.cgrand.net/
Clojure Programming http://clojurebook.com
Training, Consulting & Contracting http://lambdanext.eu/

-- 
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: REPL: viewing data structures containing infinite lists

[Ragnar Dahlén]

If you're using cider (https://github.com/clojure-emacs/cider), there's a 
convenience function for controlling the value of *print-length*, including 
giving it a default value for new nrepl instances:

https://github.com/clojure-emacs/cider#limiting-printed-output-in-the-repl

/Ragnar

On Tuesday, 1 April 2014 01:49:57 UTC+1, Christopher Howard wrote:
>
> Is there some kind of "safe" function for printing representations of 
> lazy, infinite data structures? I'm finding I like using them inside 
> other data structures here and there. However, when I go to play 
> around with things in the REPL, sooner or later my workflow is 
> interrupted by 3 million characters streaming across the console. 
>
> I don't imagine there would be any way for the REPL to detect that a 
> lazy sequence was infinite. However, if it would simply refuse to 
> evaluate lazy sequence (say, represent them by some special identifier) 
> that 
> would be good enough for 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.

Re: om: state management considerations

[rlewczuk]

Hi,

Thank you for all answers, as I did my homework (reading overview sent by 
Jeff and applying Luca's suggestions), things have improved quite a bit. 
Yet there are still some things I'm not fully grasping, so I have more 
questions :) 

First one is about object created by (om/build ...) - in all tutorials 
these objects are always created on the fly in (render ...) functions. So 
if some component disappears from view for some time, it loses its state. 
This might be the case in tab panels for example: views representing 
individual tabs disappear when user switches onto another tab. Is it safe 
to retain reference to such view created by om/build or should it be build 
from scratch every time ? 

Second thing is inter-component communication. I assume that meddling with 
state of one component from another component (eg. reading data from edited 
row by data grid) is considered harmful and core.async channel should be 
used in such cases which implies actor model for UI app. Is it safe to 
assume that om is opinionated in this regard (using actor model for 
communication) ? If so, are there materials regarding proper design and 
structuring of actors and their communication (think: GoF-like 'design 
patterns' for actor model) ? I've read some parts of a few  Erlang books 
regarding some of it but it seems to cover only basics and simple cases.

Thenk you and Regards,
rle


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