[ANN] Ultra 0.2.1 - pprint-source, and playing nicely with CIDER
*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
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 timothyprat...@gmail.com
wrote:
Hi Andy,
On Fri, Feb 20, 2015 at 5:51 PM, Andy Fingerhut andy.finger...@gmail.com
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: No such var during runtime
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 sve...@googlemail.com javascript: 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.
Re: Is there a way to stop a long running expression in the REPL
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 a2093...@trbvm.com 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: Default values
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 cldwester...@gmail.com 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.
Re: Default values
2015-02-21 11:03 GMT+01:00 Ulises ulises.cerv...@gmail.com: 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 cldwester...@gmail.com 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.
Default values
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.
Is there a way to stop a long running expression in the REPL
Sometimes I execute something that takes to long. With Ctrl-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.
ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support
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: Workaround for CLJ-1604?
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 adamm...@gmail.com javascript: wrote: I'm running into what appears to be the same issue described in CLJ-1604 http://dev.clojure.org/jira/browse/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 javascript: 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 javascript: 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 javascript:. 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: Default values
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
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: Using type to change the behaviour of a function
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
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
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 cldwester...@gmail.com wrote: Sometimes I execute something that takes to long. With Ctrl-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.
Re: Is there a way to stop a long running expression in the REPL
2015-02-21 13:28 GMT+01:00 Lucas Bradstreet lucasbradstr...@gmail.com:
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 cldwester...@gmail.com
wrote:
Sometimes I execute something that takes to long. With Ctrl-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: ANN: ClojureScript 0.0-2913, Google Closure Modules, improved nREPL support
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
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 lucasbradstr...@gmail.com 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 cldwester...@gmail.com wrote: Sometimes I execute something that takes to long. With Ctrl-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: Is there a way to stop a long running expression in the REPL
Using Lein 2's REPL, Ctrl-C doesn't cancel the REPL itself. On Sat, Feb 21, 2015 at 4:45 PM, Cecil Westerhof cldwester...@gmail.com wrote: Sometimes I execute something that takes to long. With Ctrl-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.
