[ANN] Ultra 0.2.1 - pprint-source, and playing nicely with CIDER

[W. David Jarvis]

*Ultra: a Leiningen plugin for a superior development environment.*
Release 0.2.1 comes with two changes - one feature, one (major) bugfix.


*First, the feature: pprint-source*
Ultra now has a function for pretty-printing source at the REPL - like 
`source`, but nice looking. At the moment it's squirreled away in 
`ultra.repl/pprint-source` since it uses `read-string`, which is unsafe. At 
some point I might hook it into clojure.repl/source (since - as far as the 
unsafeness goes - you'd already have to have the code in question on your 
classpath), but I'm still weighing the pros and cons there.


*Second, the bugfix: playing nicely with CIDER*
Ultra's been responsible for an unfortunate nREPL middleware ordering bug 
ever since it was open sourced. The effect of this bug (documented here: 
https://github.com/clojure-emacs/cider/issues/961) was to really screw up a 
lot of the CIDER middleware. This latest release forces the nREPL 
middleware Ultra depends on to load first, which gets rid of the problem. 

<3 to the emacs community.

-- 
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: [BUG] : clojure.data/diff handles nested empty collections incorrectly

[Andy Fingerhut]

Sorry if you've already explained this and I'm missing it, but for example,
suppose the current state on both sides is {:x {:y 1}}, and the 'sender'
wants to change to one of these states:

(a) {:x nil}
(b) {:x {}}
(b) {:x []}
(c) {:x {:y nil}}

Do you plan to support sending a different 'diff' in each of these cases,
such that the 'receiver' can end up in the same final state, for each of
these case?

Or perhaps the idea is that some of those are not supported?

Thanks,
Andy

On Fri, Feb 20, 2015 at 8:13 PM, Timothy Pratley 
wrote:

> Hi Andy,
>
>
> On Fri, Feb 20, 2015 at 5:51 PM, Andy Fingerhut 
> wrote:
>
>> The goal with your library is to transmit deltas between two systems, and
>> then apply those deltas to the other system to make them match, yes?
>>
>
> Correct, it works well for what I need it to do. :)
>
>
>> How would you use the diff return value ({:x {:y 1}} nil nil) to cause a
>> system that currently has {:x {:y 1}} to change to {:x {}}, as opposed to
>> some other state?  That is, how would it know it needs to change the value
>> associated with :x to {} as opposed to removing the key :x and its value
>> entirely?
>>
>
> The short answer is (update-in state [:x] dissoc :y).
> Which is identical in result to (assoc state :x {}).
> So either representation could be used to accomplish the goal, and can be
> interchanged.
>
> As such I think either solution would be great! (and am happy to provide a
> patch either way).
>
>
> Below digresses from clojure.core/diff concerns, but I'm including it to
> more fully answer your question.
>
> I'll expand a little on the way patchin currently works. The second
> clojure.data/diff return value is used as replacements. The first item
> returned from clojure.data/diff is used as the keys to dissoc, excluding
> things that would be replaced anyway. If the patch size is greater than the
> target, just the target is sent. So in the end it constructs the same patch
> you described (as it is smaller). Valid patches look like either:
> [x]
> [diss replace]
> So the patch sent is
> [{:x {}}]
> Which means "replace the state with {:x {}}
> but for {:x {:y "foo", z "bar", w "baz"}} -> {:x {:z "bar", w "baz", q
> "bonza"}} the patch sent is
> [{:x {:y 1}} {:x {:q "bonza"}}]
> Which means "replace in state [:x :q] bonza, and strip out [:x :y].
> Plus some minor tricks to handle sets, and treat sequences as values.
> There are good resources for sequence diff compression but haven't thought
> of a good way to represent them in the same patch as a structural diff, and
> haven't had the need.
>
> I do not think clojure.data/diff need concern itself with optimization, as
> it currently serves the purpose of identifying differences very well, and
> optimization comes with calculation/size tradeoffs specific to the usage.
>
>
> Regards,
> Timothy
>
>  --
> 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: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

[Boris Kourtoukov]

On Saturday, February 21, 2015 at 1:01:39 PM UTC-5, David Nolen wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
> 
> 
> README and source code: https://github.com/clojure/clojurescript
> 
> 
> New release version: 0.0-2913
> 
> 
> Leiningen dependency information:
> 
> 
>     [org.clojure/clojurescript "0.0-2913"]
> 
> 
> This release comes with two very big enhancements.
> 
> 
> The first is support for Google Closure Modules via the :modules build
> option. Google Closure Modules permits splitting advanced compiled
> builds into optimal smaller pieces for faster page
> loads. ClojureScript's Google Closure Module support is fully
> :foreign-libs aware. Source mapping for modules is also fully
> supported.
> 
> 
> The feature is described in more detail here:
> https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules
> 
> 
> The second big change is a fundamental rearchitecting of ClojureScript
> REPLs. ClojureScript REPLs now support a set of options similar to
> those taken by `clojure.main/repl` with small changes to account for
> different JavaScript evaluation environments. Many third party REPLs
> like Figwheel, Weasel, and Ambly are either unaffected or have already
> accounted for these changes. However current tooling leveraging
> Piggieback will likely present an inferior experience as Piggieback was
> designed to work around the previous limitations of ClojureScript
> REPLs. Now that ClojureScript REPLs are more like the standard Clojure
> REPL it should be far simpler to add proper interruptible-eval and
> load-file nREPL middleware so that existing tooling around nREPL can
> more easily integrate ClojureScript REPLs as first class citizens.
> 
> 
> Feedback on both of these enhancements is very welcome!
> 
> 
> 
> There are also many smaller fixes around REPL command line behavior,
> the Nashorn REPL, :foreign-libs resource finding issues, the full
> list follows:
> 
> 
> ## 0.0-2913
> * Support custom :output-to for :cljs-base module
> 
> 
> ## 0.0-2911
> 
> 
> ### Enhancements
> * CLJS-1042: Google Closure Modules :source-map support
> * CLJS-1041: Google Closure Modules :foreign-libs support
> * Google Closure Modules support via :modules
> * CLJS-1040: Source-mapped script stack frames for the Nashorn repl
> 
> 
> ### Changes
> * CLJS-960: On carriage return REPLs should always show new REPL prompt
> * CLJS-941: Warn when a symbol is defined multiple times in a file
> * REPLs now support parameterization a la clojure.main/repl
> * all REPLs analyze cljs.core before entering loop
> * can emit :closure-source-map option for preserving JS->JS map
> * REPLs can now merge new REPL/compiler options via -setup
> 
> 
> ### Fixes
> * CLJS-998: Nashorn REPL does not support require special fn
> * CLJS-1052: Cannot require ns from within the ns at the REPL for reloading 
> purposes
> * CLJS-975: preserve :reload & :reload-all in ns macro sugar
> * CLJS-1039: Under Emacs source directory watching triggers spurious 
> recompilation
> * CLJS-1046: static vars do not respect user compile time metadata
> * CLJS-989: ClojureScript REPL loops on EOF signal
> * fix DCE regression for trivial programs
> * CLJS-1036: use getResources not findResources in get-upstream-deps*

Closure Module support is an amazing  addition, thank you for implementing it. 
It is something that has always been nagging at me when building multi 
page/multi ui applications with CLJS.

-- 
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: Is there a way to stop a long running expression in the REPL

[Shawn Rasheed]

Using Lein 2's REPL, Ctrl-C doesn't cancel the REPL itself.

On Sat, Feb 21, 2015 at 4:45 PM, Cecil Westerhof 
wrote:

> Sometimes I execute something that takes to long. With -C I can
> cancel it, but this also cancels the REPL itself. Is there a way to
> terminate the running command without terminating the running REPL?
>
> --
> Cecil Westerhof
>
> --
> 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.
>



-- 
---sr

-- 
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: Is there a way to stop a long running expression in the REPL

[Shawn Rasheed]

If it's the clojure repl this might work:
https://clojuredocs.org/clojure.repl/set-break-handler!

On Sat, Feb 21, 2015 at 5:28 PM, Lucas Bradstreet  wrote:

> Which repl are you using? In lein repl, this does not happen to me, it
> just terminates the expression.
>
> On 21 February 2015 at 19:45, Cecil Westerhof 
> wrote:
> > Sometimes I execute something that takes to long. With -C I can
> cancel
> > it, but this also cancels the REPL itself. Is there a way to terminate
> the
> > running command without terminating the running REPL?
> >
> > --
> > Cecil Westerhof
> >
> > --
> > 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.
>



-- 
---sr

-- 
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: Workaround for CLJ-1604?

[Adam Krieg]

I did build with the latest version of Clojure with the patch.  I still run 
into the issue, although there is a twist, which could be a maven issue.  I 
will post the details to Jira.

Thanks

On Friday, February 20, 2015 at 12:04:59 AM UTC-5, Andy Fingerhut wrote:
>
> You could build your own patched version of Clojure, with the proposed 
> patch from the ticket, and use that.  If you try that, it would be good to 
> add a comment to the ticket of whether it fixed the problem for you, too.
>
> Note: I fully understand if you'd prefer not to do this.  Simply giving 
> another alternative to the ones you mentioned.
>
> Andy
>
> On Thu, Feb 19, 2015 at 8:10 PM, Adam Krieg  > wrote:
>
>> I'm running into what appears to be the same issue described in CLJ-1604 
>> , where a library that I'm 
>> using (Korma) has a function that clashes with a new function in Clojure 
>> core with 1.7, update.
>>
>> At the point of invocation, I get the compilation exception:
>> Exception in thread "main" java.lang.RuntimeException: No such var: 
>> korma.core/update, 
>>
>> Other than ripping out Korma or downgrading to 1.6, is there anything I 
>> can do to avoid this issue?
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support

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

Leiningen dependency information:

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

This release comes with two very big enhancements.

The first is support for Google Closure Modules via the :modules build
option. Google Closure Modules permits splitting advanced compiled
builds into optimal smaller pieces for faster page
loads. ClojureScript's Google Closure Module support is fully
:foreign-libs aware. Source mapping for modules is also fully
supported.

The feature is described in more detail here:
https://github.com/clojure/clojurescript/wiki/Compiler-Options#modules

The second big change is a fundamental rearchitecting of ClojureScript
REPLs. ClojureScript REPLs now support a set of options similar to
those taken by `clojure.main/repl` with small changes to account for
different JavaScript evaluation environments. Many third party REPLs
like Figwheel, Weasel, and Ambly are either unaffected or have already
accounted for these changes. However current tooling leveraging
Piggieback will likely present an inferior experience as Piggieback was
designed to work around the previous limitations of ClojureScript
REPLs. Now that ClojureScript REPLs are more like the standard Clojure
REPL it should be far simpler to add proper interruptible-eval and
load-file nREPL middleware so that existing tooling around nREPL can
more easily integrate ClojureScript REPLs as first class citizens.

Feedback on both of these enhancements is very welcome!

There are also many smaller fixes around REPL command line behavior,
the Nashorn REPL, :foreign-libs resource finding issues, the full
list follows:

## 0.0-2913
* Support custom :output-to for :cljs-base module

## 0.0-2911

### Enhancements
* CLJS-1042: Google Closure Modules :source-map support
* CLJS-1041: Google Closure Modules :foreign-libs support
* Google Closure Modules support via :modules
* CLJS-1040: Source-mapped script stack frames for the Nashorn repl

### Changes
* CLJS-960: On carriage return REPLs should always show new REPL prompt
* CLJS-941: Warn when a symbol is defined multiple times in a file
* REPLs now support parameterization a la clojure.main/repl
* all REPLs analyze cljs.core before entering loop
* can emit :closure-source-map option for preserving JS->JS map
* REPLs can now merge new REPL/compiler options via -setup

### Fixes
* CLJS-998: Nashorn REPL does not support require special fn
* CLJS-1052: Cannot require ns from within the ns at the REPL for reloading
purposes
* CLJS-975: preserve :reload & :reload-all in ns macro sugar
* CLJS-1039: Under Emacs source directory watching triggers spurious
recompilation
* CLJS-1046: static vars do not respect user compile time metadata
* CLJS-989: ClojureScript REPL loops on EOF signal
* fix DCE regression for trivial programs
* CLJS-1036: use getResources not findResources in get-upstream-deps*

-- 
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: Default values

[Jeremy Heiler]

On 2/21/15 4:57 AM, Cecil Westerhof wrote:

I want to work with default values. For this I use:
 [& nr]

This gives the value null to nr. So far so good.

But I want to propagate the value, because I want to fill the default at a
higher level.

​I have:
 (defn test-lucky-numbers-all
   "Test all lucky number performance"
   [& nr]
 (printf "all: %s\n\n" nr)
   (time
(do (test-lucky-numbers-first   nr)
and:
 (defn test-lucky-numbers-first
   "Performance test of lucky numbers (first)"
   [& nr]
 (printf "first: %s\n\n" nr)

>

When I do:
 (test-lucky-numbers-all)
The first prints:
 all: null
but the second prints:
 first: (nil)

And when I do:
 (test-lucky-numbers-all 1)​
​The first prints:
 all: (1)
and the second prints:
 first: ((1))

What is happening here and what can I do about it?



You can "unwrap" the varargs by destructuring them like so:

  (defn foo [a b & [c d]]
(list a b (+ c d)))

  (foo 1 2 3 4) ;; => (1 2 7)

This is possible because the varargs are provided as a seq.

--
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] Sweet Liberty: Set Your Data Free with Clojure and REST

[Andy Chambers]

On Tuesday, February 17, 2015 at 11:24:48 AM UTC-5, Bill Piel wrote:
>
> Blog post: 
> https://blog.rjmetrics.com/2015/02/15/sweet-liberty-set-your-data-free-with-clojure-and-rest/
>
>
> Sweet-Liberty is a library for building database-backed RESTful services 
> using Clojure. You can think of it as a means to build and configure 
> components that translate between REST and SQL. Or, you might say that it 
> helps you wrap a REST interface around a relational database. Besides 
> standard CRUD operations (available via appropriate HTTP methods), it also 
> supports some other features through query parameters, such as: filtering, 
> paging and returning a subset of fields. 
>
>
> Feedback is welcome and appreciated. Thanks
>

It looks cool!

I started out on a similar track but using datomic as the storage and ended 
up with http://github.com/cddr/crud 

Since you have implemented paging, you might be interested in 
reading http://use-the-index-luke.com/sql/partial-results/fetch-next-page 
which provides a method of paging with different (IMO better) trade-offs to 
the method you see in most tutorials.

Cheers,
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: Is there a way to stop a long running expression in the REPL

[Lee Spector]

In case anybody is developing tools for this kind of thing, one of the things I 
most miss from Common Lisp is the ability to interrupt a running expression AND 
see the values of locals at the point of interruption. Fantastically useful for 
debugging. As far as I know there's no environment that lets you do this for 
Clojure. Seeing locals at the context of an exception (for each stack frame) is 
also fantastically useful and at the top of my wish list for the ecosystem... 
and while I've heard tell that there's a way to do this (Ritz?) if you run 
within emacs, I've never actually seen this in action and would love it if 
there was a more broadly accessible way to do this.

 -Lee



> On Feb 21, 2015, at 8:59 AM, Fluid Dynamics  wrote:
> 
> It depends on what REPL/IDE you are using. In Counterclockwise there's an 
> icon on the REPL pane's upper right with a red box near a gear, third from 
> the left, which interrupts the currently running expression. Some other REPL 
> environments provide similar functionality, as other people have noted in 
> this thread, while others unfortunately don't provide a way short of 
> restarting the REPL (and losing anything you've def'd or defn'd at the REPL 
> in the process -- it's a good idea to keep a scratch file in Notepad or 
> somewhere and paste things there that don't belong in your source code but 
> which are convenient to run from time to time in the REPL, such as ad hoc 
> tests or convenience functions and defs for during development).

-- 
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: Is there a way to stop a long running expression in the REPL

[Fluid Dynamics]

It depends on what REPL/IDE you are using. In Counterclockwise there's an 
icon on the REPL pane's upper right with a red box near a gear, third from 
the left, which interrupts the currently running expression. Some other 
REPL environments provide similar functionality, as other people have noted 
in this thread, while others unfortunately don't provide a way short of 
restarting the REPL (and losing anything you've def'd or defn'd at the REPL 
in the process -- it's a good idea to keep a scratch file in Notepad or 
somewhere and paste things there that don't belong in your source code but 
which are convenient to run from time to time in the REPL, such as ad hoc 
tests or convenience functions and defs for during development).

-- 
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 type to change the behaviour of a function

[Leon Grapenthin]

You don't increase the performance by limiting the input value range in a 
pre-condition.

On Thursday, February 19, 2015 at 12:52:38 PM UTC+1, Cecil Westerhof wrote:
>
> I have the following function:
> (defn lucky-numbers
>   "Lucky numbers from 1 up-to upto-value.
>   1 <= upto-value <= 10.000.000
>   http://en.wikipedia.org/wiki/Lucky_number";
>   ; doc-string and pre-condition should match
>   [upto]
>   {:pre [(>= upto 1)
>  (<= upto (* 10 1000 1000))]}
>   (if (< upto 3)
>   ; for 1 and 2 the algorithm does not work, so return value 
> manually
>   (list 1)
> (loop [coll (range 1 (inc upto) 2), survivor-idx 1]
>   (let [i (nth coll survivor-idx)]
> (if (> (count coll) i)
> (recur (drop-every-nth coll i) (inc survivor-idx))
>   coll)
>
> ​In this function I limit the maximum value that ​can be given to the 
> function. But this is pure for performance reasons. So I would like to have 
> the possibility to disable it. I read somewhere that you can use types for 
> this. Sadly I do not remember where.
>
> At the moment the following:
> (lucky-numbers 1001)
> gives:
> AssertionError Assert failed: (<= upto (* 10 1000 1000))  
> user/lucky-numbers
>
> But I would like the following to be executed:
> (lucky-numbers :no-max-check 1001)
>
> ​How would I implement that?
>
> -- 
> Cecil Westerhof
>  

-- 
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: Is there a way to stop a long running expression in the REPL

[Cecil Westerhof]

2015-02-21 13:28 GMT+01:00 Lucas Bradstreet :

> Which repl are you using? In lein repl, this does not happen to me, it
> just terminates the expression.
>

​I am using:
rlwrap java -cp "${CP}" clojure.main --init "${CLOJURE_INIT}" --repl

But maybe it is time to switch. ;-)​



> On 21 February 2015 at 19:45, Cecil Westerhof 
> wrote:
> > Sometimes I execute something that takes to long. With -C I can
> cancel
> > it, but this also cancels the REPL itself. Is there a way to terminate
> the
> > running command without terminating the running REPL?
>

-- 
Cecil Westerhof

-- 
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: Is there a way to stop a long running expression in the REPL

[Lucas Bradstreet]

Which repl are you using? In lein repl, this does not happen to me, it
just terminates the expression.

On 21 February 2015 at 19:45, Cecil Westerhof  wrote:
> Sometimes I execute something that takes to long. With -C I can cancel
> it, but this also cancels the REPL itself. Is there a way to terminate the
> running command without terminating the running REPL?
>
> --
> Cecil Westerhof
>
> --
> 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.

Is there a way to stop a long running expression in the REPL

[Cecil Westerhof]

Sometimes I execute something that takes to long. With -C I can
cancel it, but this also cancels the REPL itself. Is there a way to
terminate the running command without terminating the running REPL?

-- 
Cecil Westerhof

-- 
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: Default values

[Cecil Westerhof]

2015-02-21 11:03 GMT+01:00 Ulises :

> What's happening is that you have multiple optional arguments chained
> together. Optional arguments are passed as a list (or seq?) of arguments,
> so if you pass them down to another function that also takes optional
> arguments they get wrapped in yet another list. An option to stop this is
> to use apply, e.g.:
>
> user=> (defn foo [& stuff] stuff)
> #'user/foo
> user=> (defn bar [& things] (apply foo things))
> #'user/bar
> user=> (bar 1 2 3)
> (1 2 3)
>

​That works, but the problem is that the function also accepts two
parameters. (I understood optional parameters wrongly.) I should probably
go back to my first option of a multi-arity function.

Would a be possibly to define a value that is only known in the local
source file?



> On Sat Feb 21 2015 at 9:58:00 AM Cecil Westerhof 
> wrote:
>
>> I want to work with default values. For this I use:
>> [& nr]
>>
>> This gives the value null to nr. So far so good.
>>
>> But I want to propagate the value, because I want to fill the default at
>> a higher level.
>>
>> ​I have:
>> (defn test-lucky-numbers-all
>>   "Test all lucky number performance"
>>   [& nr]
>> (printf "all: %s\n\n" nr)
>>   (time
>>(do (test-lucky-numbers-first   nr)
>> and:
>> (defn test-lucky-numbers-first
>>   "Performance test of lucky numbers (first)"
>>   [& nr]
>> (printf "first: %s\n\n" nr)
>>
>> When I do:
>> (test-lucky-numbers-all)
>> The first prints:
>> all: null
>> but the second prints:
>> first: (nil)
>>
>> And when I do:
>> (test-lucky-numbers-all 1)​
>> ​The first prints:
>> all: (1)
>> and the second prints:
>> first: ((1))
>>
>> What is happening here and what can I do about it?
>>
>> I could write a general function to translate the nil, but I was
>> wondering if there is a better option.​
>>
>
-- 
Cecil Westerhof

-- 
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: Default values

[Ulises]

What's happening is that you have multiple optional arguments chained
together. Optional arguments are passed as a list (or seq?) of arguments,
so if you pass them down to another function that also takes optional
arguments they get wrapped in yet another list. An option to stop this is
to use apply, e.g.:

user=> (defn foo [& stuff] stuff)
#'user/foo
user=> (defn bar [& things] (apply foo things))
#'user/bar
user=> (bar 1 2 3)
(1 2 3)


On Sat Feb 21 2015 at 9:58:00 AM Cecil Westerhof 
wrote:

> I want to work with default values. For this I use:
> [& nr]
>
> This gives the value null to nr. So far so good.
>
> But I want to propagate the value, because I want to fill the default at a
> higher level.
>
> ​I have:
> (defn test-lucky-numbers-all
>   "Test all lucky number performance"
>   [& nr]
> (printf "all: %s\n\n" nr)
>   (time
>(do (test-lucky-numbers-first   nr)
> and:
> (defn test-lucky-numbers-first
>   "Performance test of lucky numbers (first)"
>   [& nr]
> (printf "first: %s\n\n" nr)
>
> When I do:
> (test-lucky-numbers-all)
> The first prints:
> all: null
> but the second prints:
> first: (nil)
>
> And when I do:
> (test-lucky-numbers-all 1)​
> ​The first prints:
> all: (1)
> and the second prints:
> first: ((1))
>
> What is happening here and what can I do about it?
>
> I could write a general function to translate the nil, but I was wondering
> if there is a better option.​
>
> --
> Cecil Westerhof
>
> --
> 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.

Default values

[Cecil Westerhof]

I want to work with default values. For this I use:
[& nr]

This gives the value null to nr. So far so good.

But I want to propagate the value, because I want to fill the default at a
higher level.

​I have:
(defn test-lucky-numbers-all
  "Test all lucky number performance"
  [& nr]
(printf "all: %s\n\n" nr)
  (time
   (do (test-lucky-numbers-first   nr)
and:
(defn test-lucky-numbers-first
  "Performance test of lucky numbers (first)"
  [& nr]
(printf "first: %s\n\n" nr)

When I do:
(test-lucky-numbers-all)
The first prints:
all: null
but the second prints:
first: (nil)

And when I do:
(test-lucky-numbers-all 1)​
​The first prints:
all: (1)
and the second prints:
first: ((1))

What is happening here and what can I do about it?

I could write a general function to translate the nil, but I was wondering
if there is a better option.​

-- 
Cecil Westerhof

-- 
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 such var during runtime

[Sven Richter]

Hm,

I cannot imagine how this might come into play, but in the end. I don't 
know. I just set the clojure version of closp to 1.7.0-alpha5, built a new 
jar and it still works for me.
I just cannot find a way to reproduce it on my local workstation, neither 
on my second one where I do code from time to time.

Thanks,
Sven

Am Samstag, 21. Februar 2015 08:07:26 UTC+1 schrieb Sean Corfield:
>
> Could it perhaps be this bug at work?
>
> http://dev.clojure.org/jira/browse/CLJ-1604
>
> Sean
>
> On Feb 20, 2015, at 1:31 PM, Sven Richter  > wrote:
>
> A user reported an error for closp which I cannot make sense of: 
> java.lang.RuntimeException: No such var: t-cli/parse-opts, 
> compiling:(leiningen/new/closp.clj:102:52)
> This is the issue: https://github.com/sveri/closp/issues/1
> The code is here: 
> https://github.com/sveri/closp/blob/master/src/leiningen/new/closp.clj
>
> Interpreting the error message I would say that t-cli is not required in 
> the namespace, but looking at line 6 I see this: [clojure.tools.cli :as 
> t-cli]. Also I can execute the same command again and again and it just 
> works.
>
> Any ideas what might be causing this?
>
>
>

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