[ANN] CRNTL-iOS: Swift reader for Clojure

[Edwin Watkeys]

Hi again all,

I'm all packed and had some free time, so I built CRNTL-iOS, a Swift 
wrapper for CRNTL:

https://github.com/thunknyc/crntl-ios

Some sample code:

public func test_parse() {


let values = parse(string: "{:answer 42}")
for v in values {
print("Value: \(v)")
}
}


Output:

Value: DictionaryValue<[DictionaryEntryValue,IntValue<
42>>]>

MIT licensed. Enjoy.

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

[ANN] CRNTL: An ANSI C reader for Clojure/EDN content

[Edwin Watkeys]

Hey all,

Have you ever wanted to read Clojure or EDN without using Clojure(Script)? 
If so, feel free to check out CRNTL (C Reader for the Next Thousand Lisps) 
at:

https://github.com/thunknyc/crntl

CRNTL is a new project and is incomplete, but I hope some will find it 
useful as-is. I wrote it because it irked me that I was using PEG.js inside 
JavaScriptCore to parse the iOS-hosted Lisp we're developing. CRNTL is 
written in ANSI C, has no external dependencies, and is thread-safe i.e. it 
doesn't use any static variables. CRNTL is available under an MIT-style 
license.

Pull requests and new issues are welcome. If you have questions or 
comments, please contact me directly for now; I am about to head out on a 
~4,500mi (7,200km) motorcycle ride and won't be scanning posts here for a 
few weeks.

Regards,
Edwin

-- 
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: Navigators and lenses

[Edwin Watkeys]

Nathan,

I am deeply sorry for offending you. Truly. It was not my intent. My entire 
argument can be boiled down to Specter reminds me of the Common Lisp LOOP 
macro. Is that like saying "I don't like parentheses"? Maybe.

Again, I apologize.

Edwin

On Thursday, March 9, 2017 at 10:15:55 AM UTC-5, Nathan Marz wrote:
>
> Edwin, these personal comments about me are extremely inappropriate. Your 
> claim that I ignore the work of others is just plain wrong, and that you 
> would make such comments out of the blue is truly incomprehensible.
>
> You claim Specter is "deeply un-Clojure-y" without providing a single 
> example. This makes your argument boil down to "I don't like the way 
> Specter makes me feel", which is no different than the complaints 
> non-Lispers make about Lisp's parentheses.
>
> Specter's core is just a simple interface and a high-performance way of 
> composing implementations of that interface together. Everything else in 
> Specter (the navigators) is built on top of that interface. So if you only 
> want to use the "lens-like" functionality, you can literally ignore 
> everything else because it doesn't affect you in any way. Additionally, 
> supporting those other use cases does not make the basic use cases more 
> complex or verbose.
>
> I've found that Clojure programmers find Specter to be very intuitive. 
> What they have trouble grasping is the full scope with which Specter can be 
> applied, because thinking about data structures in terms of navigation is a 
> new mindset. This is exactly the blub paradox as famously written about by 
> Paul Graham back in the day. 
>
> Finally, suggestions that more research and experimentation is needed in 
> this area must be paired with at least one example of how Specter is 
> deficient. Otherwise, it's an empty discussion. 
>
>
> On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote:
>>
>> puzzler,
>>
>> I guess I haven't said this, but I think it's worth saying that I have 
>> nothing against Specter. Godspeed to people who want to use it. And I don't 
>> think it should be judged against some other facility in another language; 
>> human progress would cease if for every Y, Y has to be a better X than X. 
>> Lenses, though, are one way that humans have tried to cope with accessing 
>> and updating nested data structures, and they're worth thinking about. 
>> Rich's hammock driven development talk influenced me powerfully because his 
>> espoused methodology ran so counter to my code-first-think-later instincts, 
>> and so I have the zeal of the converted with respect to the "do some 
>> research" step of HDD.
>>
>> What you point out—the power and expressiveness of Specter—some people 
>> might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
>> with the 90% of situations where something like Specter might be used and 
>> making them as ridiculously simple and Clojure-y as possible. That 90% of 
>> usage maps to, in my experience, maybe 25% of the feature set of Specter. 
>> (YMMV, of course.) I want to facilitate the writing of code that a typical 
>> Clojure developer will intuitively understand.
>>
>> Edwin
>>
>> On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>>>
>>> Just finished reading through Racket's lens library to compare.  Specter 
>>> can do everything that Racket's lens library can do, but the converse is 
>>> not true.  Specter's navigators can do more than lenses.
>>>
>>> The lens-like navigators are the most obviously useful parts of Specter, 
>>> and maybe for some people that's all they need and they would prefer to 
>>> hide the other functionality.  If so, it looks to me like it would be 
>>> trivial to build a lens library like Racket's out of Specter, and it would 
>>> almost certainly be higher performance than the "obvious" implementation of 
>>> lenses.
>>>
>>> But I don't agree at all with the claim that Specter is some sort of 
>>> offbeat, ill-researched version of lenses.  It is something more advanced.  
>>> If Nathan had constrained his thinking to these other approaches, Specter 
>>> wouldn't have such richness of functionality and pragmatic performance 
>>> considerations.  
>>>
>>>
>>> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom <brandon...@gmail.com> 
>>> wrote:
>>>
>>>> Responsible adults sometimes needs to access and modify deeply nested 
>>>>> data structures
>>>>
>>>>
>>>> So far, 

Re: Navigators and lenses

[Edwin Watkeys]

puzzler,

I guess I haven't said this, but I think it's worth saying that I have 
nothing against Specter. Godspeed to people who want to use it. And I don't 
think it should be judged against some other facility in another language; 
human progress would cease if for every Y, Y has to be a better X than X. 
Lenses, though, are one way that humans have tried to cope with accessing 
and updating nested data structures, and they're worth thinking about. 
Rich's hammock driven development talk influenced me powerfully because his 
espoused methodology ran so counter to my code-first-think-later instincts, 
and so I have the zeal of the converted with respect to the "do some 
research" step of HDD.

What you point out—the power and expressiveness of Specter—some people 
might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
with the 90% of situations where something like Specter might be used and 
making them as ridiculously simple and Clojure-y as possible. That 90% of 
usage maps to, in my experience, maybe 25% of the feature set of Specter. 
(YMMV, of course.) I want to facilitate the writing of code that a typical 
Clojure developer will intuitively understand.

Edwin

On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>
> Just finished reading through Racket's lens library to compare.  Specter 
> can do everything that Racket's lens library can do, but the converse is 
> not true.  Specter's navigators can do more than lenses.
>
> The lens-like navigators are the most obviously useful parts of Specter, 
> and maybe for some people that's all they need and they would prefer to 
> hide the other functionality.  If so, it looks to me like it would be 
> trivial to build a lens library like Racket's out of Specter, and it would 
> almost certainly be higher performance than the "obvious" implementation of 
> lenses.
>
> But I don't agree at all with the claim that Specter is some sort of 
> offbeat, ill-researched version of lenses.  It is something more advanced.  
> If Nathan had constrained his thinking to these other approaches, Specter 
> wouldn't have such richness of functionality and pragmatic performance 
> considerations.  
>
>
> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  > wrote:
>
>> Responsible adults sometimes needs to access and modify deeply nested 
>>> data structures
>>
>>
>> So far, my experience has been that it is almost always better to build a 
>> pair of flattening and unflattening transforms on the data. Especially 
>> since you frequently want only one flattening, but potentially many 
>> un-flattenings. The "unflattened" form (aka "documents") is usually an 
>> end-point where data goes to die; assuming it isn't immediately displayed 
>> on the screen.
>>
>> However, having said that, path-dependent / context-sensitive query is a 
>> very rich and interesting space that does have meaningful utility, 
>> especially in the context of graph-like datasets. This is especially true 
>> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
>> also interested in this sort of thing for programmable user-interface use 
>> cases: Think text editors with multiple-cursors.
>>
>> I think experimentation is in order
>>>
>>
>> Agreed. Here's some starting points for pre-hammock reading/viewing 
>> materials:
>>
>> *Tree Traversal *
>>
>>- XPath: https://www.w3.org/TR/xpath/
>>- CSS: https://www.w3.org/TR/css3-selectors/
>>
>> *Richer Tree Querying*
>>
>>- XQuery: https://www.w3.org/TR/xquery/
>>- jQuery: https://api.jquery.com
>>
>> *Second-Class "Generalized References" (nee "L-values")*
>>
>>- Common Lisp: 
>>http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm
>>- C/C++: 
>>
>> http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c
>>
>> *Lenses in Other Languages*
>>
>>- Haskell: 
>>
>> https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation
>>  
>>(great overview of key concepts!)
>>- Racket: https://docs.racket-lang.org/lens/index.html
>>
>> *Graph Querying*
>>
>>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>>
>> -- 
>> 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 

Re: Navigators and lenses

[Edwin Watkeys]

Alex,

I deeply appreciate the diligent virtue policing, but I don't think calling 
out the Comité de salut public is necessary. There was no attack: I'm much 
more a Nathan than a Rich person. The world needs both kinds of people. For 
me, Clojure would have simply been Yet Another Lisp had Nathan not put 
together Cascalog back in 2010. Yin and Yang.

Given that Rich is the BDFL of Clojure and Clojure is an art project, as 
someone recently wrote, issues of style are far from irrelevant when 
discussing what should be in or out of Clojure proper.

Edwin

On Wednesday, March 8, 2017 at 10:34:10 PM UTC-5, Alex Miller wrote:
>
> Edwin, we can have technical discussions about this topic without 
> comparing Nathan to Rich or making comments about Nathan that may feel like 
> a personal attack.
>
> Thanks
>

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

Navigators and lenses

[Edwin Watkeys]

Hey,

The recent heat about Specter got me thinking. There's legitimate pain that 
Spectre solves: Responsible adults sometimes needs to access and modify 
deeply nested data structures, and Clojure's batteries-included facilities 
for doing so can be tedious. But Specter is deeply un-Clojure-y, and, more 
to the point, I would say Nathan is basically Bizzaro-Rich.*

There has to be some Clojure-idiomatic ways of solving the common problems 
we confront, and I believe that one of the things we need to do to help 
discover those approaches, I think experimentation is in order. My 
contribution, my attempt, my essay to that end is cli-lens, available here: 
. Here's the example usage, from the 
README:

(require '[clj-lens.core :as lens])

(def m {:a 0, :b 1, :c [41 "Foocar"]})

(lens/get m [:c 1])
;; => "Foocar"

(lens/update m [:c 1 3] (fn [_] \b))
;; => {:a 0, :b 1, :c [41 "Foobar"]}

(lens/get-many m [:a] [:c 1 0])
;; => (0 \F)

(lens/update
 m
 [:a] dec
 [:b] inc
 [:d :i] (fn [_] #{:clubs :diamonds :hearts :spades}))

;; =>
;;
;; {:a -1,
;;  :b 2,
;;  :c [41 "Foocar"],
;;  :d {:i #{:spades :diamonds :clubs :hearts}}}

Your pull requests, issues, comments, counter-arguments-as-code, whatever, 
are welcome.

Regards,
Edwin

* A former co-worker of mine went to a talk of Nathan's in NYC about Storm. 
He asked Nathan how his work was influenced by CEP (complex event 
processing) systems. Nathan replied that he hadn't heard of CEP systems 
until his work on Storm was well underway. Nathan, discussing Specter, 
mentioned that he heard about Haskell's lenses well into the development of 
Specter. QED. Nathan has not drunk the hammock-driven development Kool-Aid.

-- 
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] Richelieu 0.4.0, a library for advising functions

[Edwin Watkeys]

Good morning,

Based on feedback from folks, changes since the initial 0.2.1 announcement:

* Added the ability to suppress zero or more advice functions via a 
`without-advice` macro.
* Changed the keyword used to indicate that a function should never be 
advised to be namespaced.

https://github.com/thunknyc/richelieu

Below is the example code from the README.

(require '[richelieu.core :refer :all])
;;; Here are some simple functions.

(defn add [ xs] (apply + xs))
(defn mult [ xs] (apply * xs))
(defn sum-squares [ xs]
  (apply add (map #(mult % %) xs)))
;;; `defadvice` is just a way to use `defn` with ':richelieu/no-advice`;;; 
metadata to prevent crazy infinite advice loops.

(defadvice plus1
  Adds one to each incoming argument, does nothing to the output.
  [f  xs]
  (apply f (map inc xs)))

(defadvice times2
  Multiplies each incoming argument by two, does nothing to the   output.
  [f  xs]
  (apply f (map (partial * 2) xs)))
;;; You can advise raw functions.

(def add* (- add
  (advise plus1)
  (advise times2)))

(add* 1 1)
;;; But more often, you'll want to trace vars, which is what the rest;;; of the 
example deals with.
;;; This tracing advice shows how to get the current advised object,;;; which 
can either be a var or a function value, depending on the;;; context in which 
the advice was added.

(def ^:dynamic *trace-depth* 0)

(defn- ^:richelieu.core/no-advice trace-indent []
  (apply str (repeat *trace-depth* \space)))

(defadvice trace
  Writes passed arguments and passes them to underlying  function. Writes 
resulting value before returning it as result.
  [f  args] 
  (printf %s %s %s\n (trace-indent) *current-advised* args)
  (let [res (binding [*trace-depth* (inc *trace-depth*)]
  (apply f args))]
(printf %s %s %s\n (trace-indent) *current-advised* res)
res))

(advise-var #'add trace)
(unadvise-var #'add trace)
;;; This is safe because we used `defadvice` to prevent trace from;;; advising 
itself--or other advice functions.

(advise-ns 'user trace)

(sum-squares 1 2 3 4);;; The above invocation produces the following output:
;;  #'user/sum-squares (1 2 3 4);;   #'user/mult (1 1);;   #'user/mult 1;;  
 #'user/mult (2 2);;   #'user/mult 4;;   #'user/mult (3 3);;   #'user/mult 
9;;   #'user/mult (4 4);;   #'user/mult 16;;   #'user/add (1 4 9 16);;   
#'user/add 30;;  #'user/sum-squares 30
;;; You can also suppress the evalutation of advice with the;;; 
`without-advice` macro. For example, the following will produce;;; no tracing 
output, but will allow any other advice that (possibly;;; someone else) 
attached to any function.

(without-advice [trace] (sum-squares (1 2 3 4))) ;; == 30, no tracing
;;; Finally, it will often be a good idea to refer to advice functions;;; via 
var quoting instead of by a simple reference. This will allow;;; you to 
redefine them during development and still add or remove old;;; versions of 
attached advice functions, because they will be;;; associated with the var, not 
the particular function value that the;;; var pointed to at the time.

(advise-ns 'user trace)   ;; This works great until you re-eval
  ;; your `(defadvice trace ...)` form.

(advise-ns 'user #'trace) ;; Infinitesimally slower but highly
  ;; recommended.



On Tuesday, December 2, 2014 9:39:45 PM UTC-5, Edwin Watkeys wrote:

 I think you're right; I was going back and forth on that.

 -- 
 Edwin Watkeys, 917-324-2435


 On Dec 2, 2014, at 20:52, Atamert Ölçgen mu...@muhuk.com wrote:

 Just a small suggestion; I would make :unadvisable namespaced since it's 
 richelieu specific.

 On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen gary.verhae...@gmail.com 
 wrote:

 At a very superficial glance, it looks like dire also sort of fits into 
 the same space: https://github.com/MichaelDrogalis/dire


 On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote:

 Phillip,

 Of Robert Hooke's features, I think the ability to suppress advice 
 temporarily (its `with-hooks-disabled`) as well to advise a function within 
 a particular dynamic scope (`with-scope`) are most relevant to Richelieu. 
 Since one of the major goals of Richelieu is to serve as a generic basis 
 for advising, I'll probably implement a `with-advice-disabled` form that 
 takes a sequence of advisedf-and-advicef-set values to temporarily suppress.

 R.H. and Richelieu, while they do much the same thing, seem to be 
 orthogonal to each other in terms of intent: Richelieu exists to allow 
 folks to write arbitrary advice-based facilities that are oblivious to each 
 others' existences, decorating functions that weren't written with being 
 advised in mind—think tracing and profiling. Phil, on the other hand, 
 focused on providing a facility for developers who anticipate that their 
 code might be advised à la the Emacs hooks mechanism. Or not. I'm totally 
 speculating.

 As for the name, I guess I'm willing to overlook some semantic

Re: Richelieu: a library for advising functions

[Edwin Watkeys]

Phillip,

I’d cry if it weren’t so funny; I’ve just begun to make my way through the 
lastest Read Eval Print λove and the first page or two dwells on reinvention. 
At least mine wasn’t intentional.

Edwin

-- 
Edwin Watkeys * 917-324-2435 * http://poseur.com/ http://poseur.com/


 On Dec 2, 2014, at 8:08 AM, Phillip Lord phillip.l...@newcastle.ac.uk 
 mailto:phillip.l...@newcastle.ac.uk wrote:
 
 
 Looks nice. It's pretty similar to Robert Hooke though -- which is more
 of an advice library than a hook library despite it's name. 
 
 Edwin Watkeys e...@poseur.com mailto:e...@poseur.com writes:
 
 Hello,
 
 Richelieu, a library for advising functions, is in something resembling 
 announcement-worthy shape. It's available at the following URL:
 
 http://github.com/thunknyc/richelieu http://github.com/thunknyc/richelieu
 
 During my experience writing thunknyc/profile and the associated CIDER 
 support, I realized that advising or decorating functions is something 
 that's been getting reinvented over and over. I wanted to put an end to 
 that. Richelieu supports advising functions as well as vars and namespaces. 
 Multiple advise functions can be associated with a function, and advise 
 functions have access to the underlying var or function this is being 
 decorated. Below is an edited sample from the README that shows how to 
 implement tracing advice using the library.
 
 I hope this may be useful to one or more people out there. I plan on 
 modifying thunknyc/profile to use Richelieu as part of a push to implement 
 additional profiling modalities.
 
 Regards,
 Edwin
 
 (require '[richelieu.core :refer [advice advise-ns
  *current-advised*
  defadvice]])
 
 ;;; Here are some simple functions.
 (defn add [ xs] (apply + xs))
 (defn mult [ xs] (apply * xs))
 (defn sum-squares [ xs]
  (apply add (map #(mult % %) xs)))
 
 ;;; This tracing advice shows how to get the current advised object,
 ;;; which can either be a var or a function value, depending on the
 ;;; context in which the advice was added.
 (def ^:dynamic *trace-depth* 0)
 
 (defn- ^:unadvisable trace-indent []
  (apply str (repeat *trace-depth* \space)))
 
 (defadvice trace
  Writes passed arguments and passes them to underlying
  function. Writes resulting value before returning it as result.
  [f  args] 
  (printf %s %s %s\n (trace-indent) *current-advised* args)
  (let [res (binding [*trace-depth* (inc *trace-depth*)]
  (apply f args))]
(printf %s %s %s\n (trace-indent) *current-advised* res)
res))
 
 (advise-ns 'user trace)
 
 (sum-squares 1 2 3 4)
 ;;; The above invocation produces the following output:
 
 ;;  #'user/sum-squares (1 2 3 4)
 ;;   #'user/mult (1 1)
 ;;   #'user/mult 1
 ;;   #'user/mult (2 2)
 ;;   #'user/mult 4
 ;;   #'user/mult (3 3)
 ;;   #'user/mult 9
 ;;   #'user/mult (4 4)
 ;;   #'user/mult 16
 ;;   #'user/add (1 4 9 16)
 ;;   #'user/add 30
 ;;  #'user/sum-squares 30
 
 -- 
 Phillip Lord,   Phone: +44 (0) 191 208 7827
 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk 
 mailto:phillip.l...@newcastle.ac.uk
 School of Computing Science,
 http://homepages.cs.ncl.ac.uk/phillip.lord 
 http://homepages.cs.ncl.ac.uk/phillip.lord
 Room 914 Claremont Tower,   skype: russet_apples
 Newcastle University,   twitter: phillord
 NE1 7RU 
 
 -- 
 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 
 mailto: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 
 mailto:clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en 
 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/ycw4pZQBFfs/unsubscribe 
 https://groups.google.com/d/topic/clojure/ycw4pZQBFfs/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 clojure+unsubscr...@googlegroups.com 
 mailto:clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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

Re: Richelieu: a library for advising functions

[Edwin Watkeys]

Phillip,

Of Robert Hooke's features, I think the ability to suppress advice 
temporarily (its `with-hooks-disabled`) as well to advise a function within 
a particular dynamic scope (`with-scope`) are most relevant to Richelieu. 
Since one of the major goals of Richelieu is to serve as a generic basis 
for advising, I'll probably implement a `with-advice-disabled` form that 
takes a sequence of advisedf-and-advicef-set values to temporarily suppress.

R.H. and Richelieu, while they do much the same thing, seem to be 
orthogonal to each other in terms of intent: Richelieu exists to allow 
folks to write arbitrary advice-based facilities that are oblivious to each 
others' existences, decorating functions that weren't written with being 
advised in mind—think tracing and profiling. Phil, on the other hand, 
focused on providing a facility for developers who anticipate that their 
code might be advised à la the Emacs hooks mechanism. Or not. I'm totally 
speculating.

As for the name, I guess I'm willing to overlook some semantic 
quibbles—especially since something very similar to Emacs's normal hooks 
could easily built atop R.H.—in pursuit of a charming allusion.

Edwin

On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote:


 I think yours might be nicer, to be honest, though, although Robert 
 Hooke has some features yours doesn't. Advising entire namespaces is an 
 interesting addition for sure. 

 I still don't understand why Robert Hooke has this name though. I can't 
 have been the only person expecting it to implements hooks. 

 Phil 

 Edwin Watkeys e...@poseur.com javascript: writes: 

  Phillip, 
  
  I’d cry if it weren’t so funny; I’ve just begun to make my way through 
 the 
  lastest Read Eval Print λove and the first page or two dwells on 
 reinvention. 
  At least mine wasn’t intentional. 
  
  Edwin 

 -- 
 Phillip Lord,   Phone: +44 (0) 191 208 7827 
 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk 
 javascript: 
 School of Computing Science,
 http://homepages.cs.ncl.ac.uk/phillip.lord 
 Room 914 Claremont Tower,   skype: russet_apples 
 Newcastle University,   twitter: phillord 
 NE1 7RU 


-- 
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: Richelieu: a library for advising functions

[Edwin Watkeys]

I think you're right; I was going back and forth on that.

-- 
Edwin Watkeys, 917-324-2435


 On Dec 2, 2014, at 20:52, Atamert Ölçgen mu...@muhuk.com wrote:
 
 Just a small suggestion; I would make :unadvisable namespaced since it's 
 richelieu specific.
 
 On Wed, Dec 3, 2014 at 6:01 AM, Gary Verhaegen gary.verhae...@gmail.com 
 wrote:
 At a very superficial glance, it looks like dire also sort of fits into the 
 same space: https://github.com/MichaelDrogalis/dire
 
 
 On Tuesday, 2 December 2014, Edwin Watkeys e...@poseur.com wrote:
 Phillip,
 
 Of Robert Hooke's features, I think the ability to suppress advice 
 temporarily (its `with-hooks-disabled`) as well to advise a function within 
 a particular dynamic scope (`with-scope`) are most relevant to Richelieu. 
 Since one of the major goals of Richelieu is to serve as a generic basis 
 for advising, I'll probably implement a `with-advice-disabled` form that 
 takes a sequence of advisedf-and-advicef-set values to temporarily suppress.
 
 R.H. and Richelieu, while they do much the same thing, seem to be 
 orthogonal to each other in terms of intent: Richelieu exists to allow 
 folks to write arbitrary advice-based facilities that are oblivious to each 
 others' existences, decorating functions that weren't written with being 
 advised in mind—think tracing and profiling. Phil, on the other hand, 
 focused on providing a facility for developers who anticipate that their 
 code might be advised à la the Emacs hooks mechanism. Or not. I'm totally 
 speculating.
 
 As for the name, I guess I'm willing to overlook some semantic 
 quibbles—especially since something very similar to Emacs's normal hooks 
 could easily built atop R.H.—in pursuit of a charming allusion.
 
 Edwin
 
 On Tuesday, December 2, 2014 8:39:37 AM UTC-5, Phillip Lord wrote:
 
 I think yours might be nicer, to be honest, though, although Robert 
 Hooke has some features yours doesn't. Advising entire namespaces is an 
 interesting addition for sure. 
 
 I still don't understand why Robert Hooke has this name though. I can't 
 have been the only person expecting it to implements hooks. 
 
 Phil 
 
 Edwin Watkeys e...@poseur.com writes: 
 
  Phillip, 
  
  I’d cry if it weren’t so funny; I’ve just begun to make my way through 
  the 
  lastest Read Eval Print λove and the first page or two dwells on 
  reinvention. 
  At least mine wasn’t intentional. 
  
  Edwin 
 
 -- 
 Phillip Lord,   Phone: +44 (0) 191 208 7827 
 Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk 
 School of Computing Science,
 http://homepages.cs.ncl.ac.uk/phillip.lord 
 Room 914 Claremont Tower,   skype: russet_apples 
 Newcastle University,   twitter: phillord 
 NE1 7RU 
 
 -- 
 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.
 
 
 
 -- 
 Kind Regards,
 Atamert Ölçgen
 
 -+-
 --+
 +++
 
 www.muhuk.com
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Clojure group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/clojure/ycw4pZQBFfs/unsubscribe.
 To unsubscribe from this group and all its

Richelieu: a library for advising functions

[Edwin Watkeys]

Hello,

Richelieu, a library for advising functions, is in something resembling 
announcement-worthy shape. It's available at the following URL:

http://github.com/thunknyc/richelieu

During my experience writing thunknyc/profile and the associated CIDER 
support, I realized that advising or decorating functions is something 
that's been getting reinvented over and over. I wanted to put an end to 
that. Richelieu supports advising functions as well as vars and namespaces. 
Multiple advise functions can be associated with a function, and advise 
functions have access to the underlying var or function this is being 
decorated. Below is an edited sample from the README that shows how to 
implement tracing advice using the library.

I hope this may be useful to one or more people out there. I plan on 
modifying thunknyc/profile to use Richelieu as part of a push to implement 
additional profiling modalities.

Regards,
Edwin

(require '[richelieu.core :refer [advice advise-ns
  *current-advised*
  defadvice]])

;;; Here are some simple functions.
(defn add [ xs] (apply + xs))
(defn mult [ xs] (apply * xs))
(defn sum-squares [ xs]
  (apply add (map #(mult % %) xs)))

;;; This tracing advice shows how to get the current advised object,
;;; which can either be a var or a function value, depending on the
;;; context in which the advice was added.
(def ^:dynamic *trace-depth* 0)

(defn- ^:unadvisable trace-indent []
  (apply str (repeat *trace-depth* \space)))

(defadvice trace
  Writes passed arguments and passes them to underlying
  function. Writes resulting value before returning it as result.
  [f  args] 
  (printf %s %s %s\n (trace-indent) *current-advised* args)
  (let [res (binding [*trace-depth* (inc *trace-depth*)]
  (apply f args))]
(printf %s %s %s\n (trace-indent) *current-advised* res)
res))

(advise-ns 'user trace)

(sum-squares 1 2 3 4)
;;; The above invocation produces the following output:

;;  #'user/sum-squares (1 2 3 4)
;;   #'user/mult (1 1)
;;   #'user/mult 1
;;   #'user/mult (2 2)
;;   #'user/mult 4
;;   #'user/mult (3 3)
;;   #'user/mult 9
;;   #'user/mult (4 4)
;;   #'user/mult 16
;;   #'user/add (1 4 9 16)
;;   #'user/add 30
;;  #'user/sum-squares 30

-- 
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] Clojure code profiling: profile, nrepl-profile, and cider-profile

[Edwin Watkeys]

Hey folks,

I've recently put together a profiling library for Clojure along with nREPL 
middleware and CIDER integration in Emacs. If runtime profiling is 
something that interests you, check out the following:

profile: A Clojure library for profiling
http://github.com/thunknyc/profile

nrepl-profile: nREPL middleware for profiling
http://github.com/thunknyc/nrepl-profile

cider-profile: nrepl-profile integration with CIDER
http://melpa.org/#/cider-profile

An excerpt from the `cider-profile` README is included at the end of this 
message.

Obligatory Criterium mention: Whenever I mention profiling, Criterium comes 
up. Criterium suits many people's needs and I encourage folks to check it 
out, but it's not suited to the sorts performance problems I've confronted 
in recent work. Thus this work.

Regards,
Edwin

*** README excerpt ***

Usage:

Add the following to your `init.el`, `.emacs`, whatever:
```
(add-hook 'cider-mode-hook 'cider-profile-mode)
(add-hook 'cider-repl-mode-hook 'cider-profile-mode)
```
Cider-profile includes the following keybindings out of the box:

* `C-c =` Toggle profiling of var under point.
* `C-c _` Clear collected profiling data.
* `C-c -` Print summary of profiling data to `*err*`.
* `C-c M--` Print profiling stats for var under point to `*err*`.
* `C-c +` Toggle profiling of namespace.
* `C-c M-=` Report whether var under point is profiled.
* `C-c M-+` Read (and, with `C-u`, set) current maximum per-var samples.


-- 
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: Proposing a new Clojure documentation system (in Clojure)

[Edwin Watkeys]

On Tuesday, May 6, 2014 10:39:47 AM UTC-4, Gregg Reynolds wrote:


 On Tue, May 6, 2014 at 4:53 AM, Phillip Lord philli...@newcastle.ac.uk 
 javascript: wrote:

Trivial things that I would like to be able to do that I cannot do (in a

 way which will be reliably interpreted).

  - Add hyperlinks
  - Distinguish between symbols (or names of vars) and normal words.
  - Distinguish between code (examples) and normal words
  - Have access to basic markdown style typography.


 I'm undecided on these.  They would obviously be useful, but on the other 
 hand minimalism has its virtues.  In the base case of reading code with a 
 plaintext editor, I usually find embedded doco with lots of markup annoying 
 and an impediment to code reading.  I think I'm inclined to favor keeping 
 markup out of code but I'm keeping an open mind about it.


Gregg,

I strongly opposed the introduction of case-sensitive identifiers in R6RS 
Scheme. Case-insensitive identifiers allow programmers to write comments 
and documentation that unambiguously refer to arguments and function names 
in ALL-CAPS. As a bonus, a sentence need never begin with a capital letter, 
even if one is using something like back-ticks to indicate monospaced type, 
because `All-caps` is an equally valid representation. There are legitimate 
reasons to embrace case-sensitive identifiers, but the happy interplay 
between pre-R5RS source code and the written word was lost.

In Clojure doc strings, I either pretend that identifiers are 
case-insensitive or use back-ticks and try very hard not to start sentences 
with lower-case identifiers. Regarding code itself, I tend to use all-caps 
identifiers for macro arguments, another common Scheme (and Lisp?) 
convention, to make it more clear what's going on during quasi-quoting.

Edwin

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

Clojure Positions in NYC at ActionX

[Edwin Watkeys]

Hey guys,

I'm the CTO of ActionX, where we've built much of our infrastructure in 
Clojure*. We're hiring. If you're in the NYC area and would like to work as 
part of an interestingly-eclectic group of programmers, please take a look 
at the position description below and get in touch if you're interested. 
Also, feel free to look out for one or more of us from ActionX at the 
LispNYC meet-up on the 12th.

Regards,
Edwin

* I've written web frameworks in Scheme, which I hope demonstrates my Smug 
Lisp Weenie bonafides.

--- Position description ---

ActionX, located in NYC, is looking for talented programmers
interested in working full-time in our SoHo office. Successful
candidates will have experience and interest in mostly-functional
programming as well as at least some familiarity with Java and the
Java Virtual Machine.

Furthermore, you should be familiar with the basics of Emacs, the Unix
(e.g. OS X, Linux, FreeBSD) programming environment and shell, and
a computer science or EE/ECE background.

You will be taking ownership of existing systems that employ
cloud-based storage and computational services as well as building out
new pieces of our data collection, analytics, and optimization
infrastructure. Our technologies are implemented using a variety of
languages including Python, Java, and Clojure. This position reports
to the VP of Engineering, and involves working closely with the CTO.

Please send your resume as a PDF or as plain text along with
compensation expectations to Edwin Watkeys at e...@actionx.com.

ActionX http://actionx.com/ is a leader in mobile marketing and has
built the industry's most advanced mobile remarketing platform. We're
a well funded start-up backed by companies such as Verizon Wireless,
Softbank, and Lerer Ventures and is led by experienced executives who
have helped define e-commerce on the web.

-- 
-- 
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/groups/opt_out.

Re: FleetDB or other NoSQL store for Clojure?

[Edwin Watkeys]

Hi,

I would recommend using — or at least giving serious consideration to — the 
Redis client as part of Zach Tellman's Aleph project. It has been the most 
reliable, robust Redis client I've found, and the Aleph framework makes it 
easy to deal with asynchronous I/O.

Edwin

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