Re: [ccw-users] Re: [ANN] New release 0.28.1 of Counterclockwise
What would this mean in practice for using the new drag/drop functionality to open Clojure projects, regardless of origin or history? Would some require an additional manual step to behave as proper Leiningen projects? This new functionality has been making life *much* better for me and for my students in the short time that it has existed, and it'd be a shame to lose some of the new functionality. I don't even know if/when there is a .classpath or .project or any of other hidden files in the projects I've been opening and sharing, and I'd love to never have to worry about that again. Being able to drag anything with a project.clj to CCW and having it open and run correctly is just wonderful, and I think it greatly improves the usability of CCW, especially for newcomers to the ecosystem. Maybe if some of that would no longer work automatically after the change that you are contemplating then the system could be made to ask whether to do the full conversion (what it does now in 0.28.1) or not in a dialog, rather than just doing or not doing it automatically and requiring a manual step later in some cases? -Lee On Oct 4, 2014, at 2:10 AM, Laurent PETIT wrote: > Points taken. > After rethinking about this, thanks to your feedback, it seems indeed really > wrong to silently automatically override existing Java build paths. > > I think I will confine the automatic leiningen conversion only for projects > which do not yet appear to be Java/just projects - those without a .classpath > file yet. > > What do you think? > > Le samedi 4 octobre 2014, Howard Green a écrit : > So, I did the upgrade from 0.27.0 to 0.28.1 several hours ago... and > immediately made the startling discovery that every project in my workspace > with a project.clj file had been auto-converted to a Leiningen project! > > Under ideal circumstances, this would not have bothered me, as I like the > Lein support a lot; but a number of my long-running projects had substantial > discrepancies between the Eclipse build information and what was in > project.clj. Fortunately, my backup is pretty good... :-) > > I assume the problem arose here because the (innocuous) "Automatic detection > of Clojure project" option turned into the (dangerous) "Automatic detection > of Clojure / Leiningen projects"... and I did indeed have the former option > checked. It might be nice to forcibly un-check the option as part of an > upgrade, as a way of preventing unforeseen consequences. > > Anyway, no real harm done. However, I think I'd suggest that during > conversion process it would be a good idea to retain the old .classpath file, > so there's an easy way to fully reverse the effects of a conversion, or maybe > abort the conversion if the Eclipse and Lein content didn't agree. > > --- Howard > > > On Sunday, September 28, 2014 12:50:58 PM UTC-7, laurent.petit wrote: > Counterclockwise, the Eclipse Clojure development tool. > > Counterclockwise 0.28.1 has been released. > > Improvement over 0.28.0 based on user feedback. Thanks to all who helped > improve Counterclockwise by their constructive comments! > > - Drag & Drop from Github / Bitbucket / Google Code URLs works in Linux > - Better User feedback for Drag & Drop folder actions > - Added a check for missing `.classpath` file for Leiningen projects. > Automatically reconstruct the java build path if it is missing. > > > ChangeLog > = > > http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_28_0_and_0_28_1 > > Installation instructions > == > > http://doc.ccw-ide.org/documentation.html#_install_counterclockwise > > Cheers, > > -- > Laurent Petit > > -- > You received this message because you are subscribed to the Google Groups > "counterclockwise-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojuredev-users+unsubscr...@googlegroups.com. > To post to this group, send email to clojuredev-us...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojuredev-users. > 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] New release 0.28.1 of Counterclockwise
Hello lee, The drag and drop of projects with a project.clj file should not be affected : - if the project already has eclipse metadata (that's what .project and .classpath files are), then ccw will rely on them and not try to overwrite them. - if the project has no eclipse metadata (or no metadata declaring a classpath), then adding Lein support can only improve the situation, so it would be done automatically. So for projects imported from github wih no eclipse specific files, it will continue to do the magic. Le samedi 4 octobre 2014, Lee Spector a écrit : > > What would this mean in practice for using the new drag/drop functionality > to open Clojure projects, regardless of origin or history? Would some > require an additional manual step to behave as proper Leiningen projects? > > This new functionality has been making life *much* better for me and for > my students in the short time that it has existed, and it'd be a shame to > lose some of the new functionality. > > I don't even know if/when there is a .classpath or .project or any of > other hidden files in the projects I've been opening and sharing, and I'd > love to never have to worry about that again. Being able to drag anything > with a project.clj to CCW and having it open and run correctly is just > wonderful, and I think it greatly improves the usability of CCW, especially > for newcomers to the ecosystem. > > Maybe if some of that would no longer work automatically after the change > that you are contemplating then the system could be made to ask whether to > do the full conversion (what it does now in 0.28.1) or not in a dialog, > rather than just doing or not doing it automatically and requiring a manual > step later in some cases? > > -Lee > > On Oct 4, 2014, at 2:10 AM, Laurent PETIT > wrote: > > > Points taken. > > After rethinking about this, thanks to your feedback, it seems indeed > really wrong to silently automatically override existing Java build paths. > > > > I think I will confine the automatic leiningen conversion only for > projects which do not yet appear to be Java/just projects - those without a > .classpath file yet. > > > > What do you think? > > > > Le samedi 4 octobre 2014, Howard Green > > a écrit : > > So, I did the upgrade from 0.27.0 to 0.28.1 several hours ago... and > immediately made the startling discovery that every project in my workspace > with a project.clj file had been auto-converted to a Leiningen project! > > > > Under ideal circumstances, this would not have bothered me, as I like > the Lein support a lot; but a number of my long-running projects had > substantial discrepancies between the Eclipse build information and what > was in project.clj. Fortunately, my backup is pretty good... :-) > > > > I assume the problem arose here because the (innocuous) "Automatic > detection of Clojure project" option turned into the (dangerous) "Automatic > detection of Clojure / Leiningen projects"... and I did indeed have the > former option checked. It might be nice to forcibly un-check the option as > part of an upgrade, as a way of preventing unforeseen consequences. > > > > Anyway, no real harm done. However, I think I'd suggest that during > conversion process it would be a good idea to retain the old .classpath > file, so there's an easy way to fully reverse the effects of a conversion, > or maybe abort the conversion if the Eclipse and Lein content didn't agree. > > > > --- Howard > > > > > > On Sunday, September 28, 2014 12:50:58 PM UTC-7, laurent.petit wrote: > > Counterclockwise, the Eclipse Clojure development tool. > > > > Counterclockwise 0.28.1 has been released. > > > > Improvement over 0.28.0 based on user feedback. Thanks to all who helped > improve Counterclockwise by their constructive comments! > > > > - Drag & Drop from Github / Bitbucket / Google Code URLs works in Linux > > - Better User feedback for Drag & Drop folder actions > > - Added a check for missing `.classpath` file for Leiningen projects. > Automatically reconstruct the java build path if it is missing. > > > > > > ChangeLog > > = > > > > > http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_28_0_and_0_28_1 > > > > Installation instructions > > == > > > > http://doc.ccw-ide.org/documentation.html#_install_counterclockwise > > > > Cheers, > > > > -- > > Laurent Petit > > > > -- > > You received this message because you are subscribed to the Google > Groups "counterclockwise-users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to clojuredev-users+unsubscr...@googlegroups.com . > > To post to this group, send email to clojuredev-us...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/clojuredev-users. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "counterclockwise-users" group. > To unsubscribe from thi
[ANN] rmap - define lazy, recursive maps
I would like to announce a very little utility library for defining
recursive maps in Clojure, called rmap.
For example:
(def m
(rmap X
{:what "awesome!"
:clj (str "Clojure is " (:what X))})
(:clj m)
;=> "Clojure is awesome!"
An object of type IFn + ILookup + Seqable is currently returned, which
means it can be used with the core get function, as a function itself
(taking one or two arguments), with keyword lookups, and all functions
using seq, such as into. Please let me know (or send a pull request) when
you need another protocol or interface implemented.
On Clojars: [functionalbytes/rmap "0.1.2"]
On Github: https://github.com/aroemers/rmap
--
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: For async, expose the channel directly or expose a function?
On Sat, Oct 4, 2014 at 12:31 AM, Brian Guthrie wrote: > But I'm troubled by the idea of accepting channels as arguments, even > though there's a lot to be said for consumer control of buffer sizes (to > say nothing of providing potential fakes for test purposes). In that > scenario you'd essentially be *mutating* the input when you set up the > go-loop that feeds (or takes input from) the channel, yes? So in effect > they become out-params. > Once you start messing around with channels, you're no longer in the pure-functional business. Channels aren't values. Things which use channels are processes, not functions. -S -- 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] New release 0.28.1 of Counterclockwise
Sounds great -- thanks Laurent. -Lee On Oct 4, 2014, at 10:24 AM, Laurent PETIT wrote: > Hello lee, > > The drag and drop of projects with a project.clj file should not be affected : > > - if the project already has eclipse metadata (that's what .project and > .classpath files are), then ccw will rely on them and not try to overwrite > them. > - if the project has no eclipse metadata (or no metadata declaring a > classpath), then adding Lein support can only improve the situation, so it > would be done automatically. > > So for projects imported from github wih no eclipse specific files, it will > continue to do the magic. > > Le samedi 4 octobre 2014, Lee Spector a écrit : > > What would this mean in practice for using the new drag/drop functionality to > open Clojure projects, regardless of origin or history? Would some require an > additional manual step to behave as proper Leiningen projects? > > This new functionality has been making life *much* better for me and for my > students in the short time that it has existed, and it'd be a shame to lose > some of the new functionality. > > I don't even know if/when there is a .classpath or .project or any of other > hidden files in the projects I've been opening and sharing, and I'd love to > never have to worry about that again. Being able to drag anything with a > project.clj to CCW and having it open and run correctly is just wonderful, > and I think it greatly improves the usability of CCW, especially for > newcomers to the ecosystem. > > Maybe if some of that would no longer work automatically after the change > that you are contemplating then the system could be made to ask whether to do > the full conversion (what it does now in 0.28.1) or not in a dialog, rather > than just doing or not doing it automatically and requiring a manual step > later in some cases? > > -Lee > > On Oct 4, 2014, at 2:10 AM, Laurent PETIT wrote: > > > Points taken. > > After rethinking about this, thanks to your feedback, it seems indeed > > really wrong to silently automatically override existing Java build paths. > > > > I think I will confine the automatic leiningen conversion only for projects > > which do not yet appear to be Java/just projects - those without a > > .classpath file yet. > > > > What do you think? > > > > Le samedi 4 octobre 2014, Howard Green a écrit : > > So, I did the upgrade from 0.27.0 to 0.28.1 several hours ago... and > > immediately made the startling discovery that every project in my workspace > > with a project.clj file had been auto-converted to a Leiningen project! > > > > Under ideal circumstances, this would not have bothered me, as I like the > > Lein support a lot; but a number of my long-running projects had > > substantial discrepancies between the Eclipse build information and what > > was in project.clj. Fortunately, my backup is pretty good... :-) > > > > I assume the problem arose here because the (innocuous) "Automatic > > detection of Clojure project" option turned into the (dangerous) "Automatic > > detection of Clojure / Leiningen projects"... and I did indeed have the > > former option checked. It might be nice to forcibly un-check the option as > > part of an upgrade, as a way of preventing unforeseen consequences. > > > > Anyway, no real harm done. However, I think I'd suggest that during > > conversion process it would be a good idea to retain the old .classpath > > file, so there's an easy way to fully reverse the effects of a conversion, > > or maybe abort the conversion if the Eclipse and Lein content didn't agree. > > > > --- Howard > > > > > > On Sunday, September 28, 2014 12:50:58 PM UTC-7, laurent.petit wrote: > > Counterclockwise, the Eclipse Clojure development tool. > > > > Counterclockwise 0.28.1 has been released. > > > > Improvement over 0.28.0 based on user feedback. Thanks to all who helped > > improve Counterclockwise by their constructive comments! > > > > - Drag & Drop from Github / Bitbucket / Google Code URLs works in Linux > > - Better User feedback for Drag & Drop folder actions > > - Added a check for missing `.classpath` file for Leiningen projects. > > Automatically reconstruct the java build path if it is missing. > > > > > > ChangeLog > > = > > > > http://doc.ccw-ide.org/ChangeLog.html#_changes_between_counterclockwise_0_28_0_and_0_28_1 > > > > Installation instructions > > == > > > > http://doc.ccw-ide.org/documentation.html#_install_counterclockwise > > > > Cheers, > > > > -- > > Laurent Petit > > > > -- > > You received this message because you are subscribed to the Google Groups > > "counterclockwise-users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to clojuredev-users+unsubscr...@googlegroups.com. > > To post to this group, send email to clojuredev-us...@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojuredev-users. > > For more o
Re: Getting rid of boxing and reflection when working with characters
On Friday, October 3, 2014 2:45:09 PM UTC-4, adrian...@mail.yu.edu wrote: > > You can also call (.getNumericValue (.charAt "foo" 0)) to get the int the > static Character isX methods expect. >> >> >>> Boxing, boxing, boxing! Apparently it did not occur to the Clojure developers that tight loops sometimes also deal with (sometimes large amounts of) String data. Meanwhile, I stumbled onto an odd-seeming solution. If I call my long-accepting function with (int (.charAt ... )) everything seems to work, with no exceptions or reflection warnings and sensible output. I am still concerned that things are getting unnecessarily boxed and unboxed, but at least it works, and without reflection. I still think I have optimization opportunities in this code, but still have not received the requested information about profiling in counterclockwise. The most obvious optimization that occurred to me shaved only a few percent off the running time of the test case I just ran. -- 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] rmap - define lazy, recursive maps
This looks amazing!
Could you write a blog post explaining in detail your thought process,
what inspired you, and walking through what you have written?
Thanks! This is beautiful! :D
On Sat, Oct 4, 2014 at 8:57 PM, Arnout Roemers <
goo...@company.romeinszoon.nl> wrote:
> I would like to announce a very little utility library for defining
> recursive maps in Clojure, called rmap.
>
> For example:
>
> (def m
> (rmap X
> {:what "awesome!"
> :clj (str "Clojure is " (:what X))})
> (:clj m)
> ;=> "Clojure is awesome!"
>
> An object of type IFn + ILookup + Seqable is currently returned, which
> means it can be used with the core get function, as a function itself
> (taking one or two arguments), with keyword lookups, and all functions
> using seq, such as into. Please let me know (or send a pull request) when
> you need another protocol or interface implemented.
>
> On Clojars: [functionalbytes/rmap "0.1.2"]
> On Github: https://github.com/aroemers/rmap
>
> --
> 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: [Job spam] Write Clojure in your pajamas, for decent money in a pleasant company, remote pairing all the time
At a sort of leisurely pace, but yes, we are. We have quite a few members of this list on our dev team these days :) Please reply off list. --Alex On Fri, Oct 3, 2014 at 9:20 PM, Lucas Daniel wrote: > Hey Alex are you still looking for devs? > Cheers! > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/WgEG5woJDvw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Alex Verkhovsky -- 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.
unknown recursion
Hi, I am trying to write a function to return a boolean as to whether parenthesis are balanced or not? (defn bal-parens? [parens] (let [replaced (clojure.string/replace parens "()" "") checked (re-seq #"\(\)" replaced)] (println checked) (if-not (nil? checked) (bal-parens? replaced)) (println (str "replaced is " replaced)) (if (empty? replaced) true false))) (bal-parens? "(()())") I'd expect to see true here. But my output is: (()) nil replaced is replaced is () false I can't for the life of me think why, that when checked is nil and replaced is empty the function doesn't terminate! Many Thanks Aidy -- 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: unknown recursion
A single issue here: This (defn bal-parens? [parens] (let [replaced (clojure.string/replace parens "()" "") checked (re-seq #"\(\)" replaced)] (println checked) (if-not (nil? checked) (bal-parens? replaced) (do (println (str "replaced is " replaced)) (empty? replaced) is closer to what you'd expect (note I added "do" in the if-not clause). An other flaw is using bal-parens? inside of bal-parens? which will not get translated into tail-recursion. Below you'll find a solution using loop-recur construct - the Clojure way of providing tail-recursion. (defn bal-parens? [parens] (loop [str parens] (if (= -1 (.indexOf str "()")) (empty? str) (let [replaced (clojure.string/replace str "()" "")] (recur replaced) Best, Maciej On 5 October 2014 00:02, wrote: > Hi, > > I am trying to write a function to return a boolean as to whether > parenthesis are balanced or not? > > (defn bal-parens? [parens] > (let [replaced (clojure.string/replace parens "()" "") > checked (re-seq #"\(\)" replaced)] >(println checked) > (if-not (nil? checked) (bal-parens? replaced)) >(println (str "replaced is " replaced)) >(if (empty? replaced) true false))) > > (bal-parens? "(()())") > > I'd expect to see true here. > > But my output is: > > (()) > nil > replaced is > replaced is () > false > > I can't for the life of me think why, that when checked is nil and replaced > is empty the function doesn't terminate! > > Many Thanks > > Aidy > > -- > 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.
`as->` does not work with `recur`.
Hey, I just noticed that while recur can be the last statement in most threading macros, it can't be used within an `as->` macro. user=> (macroexpand '(-> x (recur))) (recur x) user=> (macroexpand '(as-> x % (recur %))) (let* [% x % (recur %)] %) This means that a recur within a `as->` will cause a CompilerException, because it is not at the tail position. Thoughts? Cheers, Jan-Paul -- 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: `as->` does not work with `recur`.
Thought: (defmacro as-> [expr name & forms] `(let [~name ~expr ~@(interleave (repeat name) (butlast forms))] ~(last forms))) On Sunday, October 5, 2014 1:02:50 AM UTC+2, Jan-Paul Bultmann wrote: > > Hey, > I just noticed that while recur can be the last statement in most > threading macros, > it can’t be used within an `as->` macro. > > user=> (macroexpand '(-> x (recur))) > (recur x) > > user=> (macroexpand '(as-> x % (recur %))) > (let* [% x % (recur %)] %) > > This means that a recur within a `as->` will cause a CompilerException, > because it is not at the tail position. > > Thoughts? > > Cheers, > Jan-Paul -- 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: core.async: peek the next value from a channel without consuming it
Why would you want this? To leave the value inside the channel for other consumers? In that case there would be no guarantee that the value returned by the peek operation is the next value in the channel, because it might have been consumed already. Best regards, Leon On Monday, September 29, 2014 12:12:33 PM UTC+2, Nahuel Greco wrote: > > Currently if you block/park on a channel reading it by using alts!/alts!! the value will be consumed when it appears, so there is no way > to block/park waiting a new value without removing it from the channel. > There is a non-consuming peek operation planned in the core.async roadmap > or a design rationale exists for not including that operation? > > Saludos, > Nahuel Greco. > -- 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: `as->` does not work with `recur`.
This issue has been reported May be you should upvote this.. http://dev.clojure.org/jira/browse/CLJ-1418 On Sun, Oct 5, 2014 at 4:56 AM, Leon Grapenthin wrote: > Thought: > > (defmacro as-> > [expr name & forms] > `(let [~name ~expr >~@(interleave (repeat name) (butlast forms))] >~(last forms))) > > > > > On Sunday, October 5, 2014 1:02:50 AM UTC+2, Jan-Paul Bultmann wrote: >> >> Hey, >> I just noticed that while recur can be the last statement in most >> threading macros, >> it can’t be used within an `as->` macro. >> >> user=> (macroexpand '(-> x (recur))) >> (recur x) >> >> user=> (macroexpand '(as-> x % (recur %))) >> (let* [% x % (recur %)] %) >> >> This means that a recur within a `as->` will cause a CompilerException, >> because it is not at the tail position. >> >> Thoughts? >> >> Cheers, >> Jan-Paul > > -- > 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] rmap - define lazy, recursive maps
On Sun, Oct 5, 2014 at 1:17 AM, Mayank Jain wrote:
> This looks amazing!
> Could you write a blog post explaining in detail your thought process,
> what inspired you, and walking through what you have written?
>
+1 for usage patterns that motivated this...
>
> Thanks! This is beautiful! :D
>
> On Sat, Oct 4, 2014 at 8:57 PM, Arnout Roemers <
> goo...@company.romeinszoon.nl> wrote:
>
>> I would like to announce a very little utility library for defining
>> recursive maps in Clojure, called rmap.
>>
>> For example:
>>
>> (def m
>> (rmap X
>> {:what "awesome!"
>> :clj (str "Clojure is " (:what X))})
>> (:clj m)
>> ;=> "Clojure is awesome!"
>>
>> An object of type IFn + ILookup + Seqable is currently returned, which
>> means it can be used with the core get function, as a function itself
>> (taking one or two arguments), with keyword lookups, and all functions
>> using seq, such as into. Please let me know (or send a pull request)
>> when you need another protocol or interface implemented.
>>
>> On Clojars: [functionalbytes/rmap "0.1.2"]
>> On Github: https://github.com/aroemers/rmap
>>
>> --
>> 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: core.async: peek the next value from a channel without consuming it
I was thinking in a single-consumer scenario with a buffered chan, in which you want to check if you can consume the value before effectively consuming it. As you said, a peek operation has no sense if the channel has multiple consumers. Saludos, Nahuel Greco. On Sat, Oct 4, 2014 at 9:17 PM, Leon Grapenthin wrote: > Why would you want this? To leave the value inside the channel for other > consumers? > > In that case there would be no guarantee that the value returned by the > peek operation is the next value in the channel, because it might have been > consumed already. > > > Best regards, Leon > > > On Monday, September 29, 2014 12:12:33 PM UTC+2, Nahuel Greco wrote: >> >> Currently if you block/park on a channel reading it by using > alts!/alts!! the value will be consumed when it appears, so there is no way >> to block/park waiting a new value without removing it from the channel. >> There is a non-consuming peek operation planned in the core.async roadmap >> or a design rationale exists for not including that operation? >> >> Saludos, >> Nahuel Greco. >> > -- > 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: What is the best setup to program Clojurescript IF...
LighTable is really friction less. On Thursday, October 2, 2014 9:13:14 PM UTC+2, Peter Mancini wrote: > > What is the best setup to program Clojurescript IF: > >- you hate EMACS >- use linux or windows > > Any suggestions? > -- 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] rmap - define lazy, recursive maps
Wonderful!
It would be interesting to compare this with the syntax choices of
Prismatic's Graph:
https://github.com/Prismatic/plumbing/tree/master/src/plumbing/fnk
.
On Sunday, October 5, 2014 6:08:59 AM UTC+3, Sunil Nandihalli wrote:
>
>
> On Sun, Oct 5, 2014 at 1:17 AM, Mayank Jain > wrote:
>
>> This looks amazing!
>> Could you write a blog post explaining in detail your thought process,
>> what inspired you, and walking through what you have written?
>>
> +1 for usage patterns that motivated this...
>
>>
>> Thanks! This is beautiful! :D
>>
>> On Sat, Oct 4, 2014 at 8:57 PM, Arnout Roemers <
>> goo...@company.romeinszoon.nl > wrote:
>>
>>> I would like to announce a very little utility library for defining
>>> recursive maps in Clojure, called rmap.
>>>
>>> For example:
>>>
>>> (def m
>>> (rmap X
>>> {:what "awesome!"
>>> :clj (str "Clojure is " (:what X))})
>>> (:clj m)
>>> ;=> "Clojure is awesome!"
>>>
>>> An object of type IFn + ILookup + Seqable is currently returned, which
>>> means it can be used with the core get function, as a function itself
>>> (taking one or two arguments), with keyword lookups, and all functions
>>> using seq, such as into. Please let me know (or send a pull request)
>>> when you need another protocol or interface implemented.
>>>
>>> On Clojars: [functionalbytes/rmap "0.1.2"]
>>> On Github: https://github.com/aroemers/rmap
>>>
>>> --
>>> 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 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.
