Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process
On 21 May 2014 at 16:58:38, Thomas Kristensen (thomas.kristen...@uswitch.com) wrote: you'll notice that the message gets rejected as we'd expect when the exception is NOT re-thrown, but the reject seems to be ignored in the case where we re-throw. You could argue that you should never have a handler throw exceptions to the langohr-lib, but seeing as this can happen, and since it handles exceptions just fine when :auto-ack is true (not demonstrated in the experiment, but tested and verified), it seems that a consistent behaviour on a reject should be to continue consuming. Is there something I'm missing? What do you mean by ignored? Is the channel still open? Do you see basic.reject on the wire? (e.g. using Tracer: http://www.rabbitmq.com/java-tools.html) Throwing exceptions in delivery handlers is fine, it should not exhaust consumer thread pool or anything like that. -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [clojure-rabbitmq] SocketTimeoutExceptions terminates listening process
On 21 May 2014 at 19:15:50, Thomas Kristensen (thomas.kristen...@uswitch.com) wrote: You are right, the channel has been closed by me throwing on the exception. I attached a debugger and traced it to line 106 of DefaultExceptionHandler which closes the channel in handleChannelKiller. All of this does makes sense as a default behaviour, but it doesn't seem to be documented in langohr, so it took quite a while to figure out. Feel free to contribute doc improvements. - ack-unless-exception is confusing at best - it should not throw the exception on but handle it to be valuable. Otherwise users of langohr should just call .basicAck and .basicReject themselves. I'd vote for just removing it from langohr. - The behaviour of langohr in the case where a handler throws an exception is not documented in the doc-string of langohr.consumers/subscribe Screw doc strings. They cannot describe much because they can't be too long. http://clojurerabbitmq.info should cover this, in both Working with Queues and Error Handling and Recovery (the Queues guide can link to the Error Handling one, for example ). -- MK Software Engineer, Pivotal/RabbitMQ -- You received this message because you are subscribed to the Google Groups clojure-rabbitmq group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure-rabbitmq+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Question regarding tools.analyzer.jvm and the :tag, :o-tag, and :class entries
Hello,
This question is primarily addressed to Nicola Mometto, but I am sending
it to the list so it may be helpful to other Clojure developers. Help is
appreciated, regardless of the source.
I am using tools.analyzer(.jvm) to build a Closeable resource linter,
but I have run into the following problem: a function call's type hint
is lost when an instance method is called on its output.
For example, given the following setup:
(alias 'ana 'clojure.tools.analyzer)
(alias 'ast 'clojure.tools.analyzer.ast)
(alias 'jvm 'clojure.tools.analyzer.jvm)
(defn analyze [form]
(binding [ana/macroexpand-1 jvm/macroexpand-1
ana/create-varjvm/create-var
ana/parse jvm/parse
ana/var? var?]
(jvm/analyze form (jvm/empty-env
(defn analyze-debug [form]
(for [ast (ast/nodes (analyze form))
:let [{:keys [op form tag o-tag class]} ast]]
(array-map :op op :form form :tag tag :o-tag o-tag :class class)))
(defn ^java.io.FileInputStream fis [^String x]
(java.io.FileInputStream. x))
I would like to detect that (fis x) returns a java.io.FileInputStream.
If I call:
(analyze-debug '(str (fis x)))
I receive:
({:op :invoke,
:form (str (fis x)),
:tag java.lang.String,
:o-tag java.lang.Object,
:class nil}
{:op :var,
:form str,
:tag clojure.lang.AFunction,
:o-tag java.lang.Object,
:class nil}
{:op :invoke,
:form (fis x),
:tag java.io.FileInputStream, ; ◀ The desired metadata
:o-tag java.lang.Object,
:class nil}
{:op :var,
:form fis,
:tag clojure.lang.AFunction,
:o-tag java.lang.Object,
:class nil}
{:op :const,
:form x,
:tag java.lang.String,
:o-tag java.lang.String,
:class nil})
However, if I call:
(analyze-debug '(.toString (fis x)))
-
({:op :instance-call,
:form (. (fis x) toString),
:tag java.lang.String,
:o-tag java.lang.String,
:class java.lang.Object}
{:op :invoke,
:form (fis x),
:tag java.lang.Object, ; ◀ The type hint is missing!
:o-tag java.lang.Object,
:class nil}
{:op :var,
:form fis,
:tag clojure.lang.AFunction,
:o-tag java.lang.Object,
:class nil}
{:op :const,
:form x,
:tag java.lang.String,
:o-tag java.lang.String,
:class nil})
The :tag of (fis x) is now java.lang.Object, and
java.io.FileInputStream is not present in the node.
Calling java.io.InputStream#markSupported sheds more light on the
matter:
(analyze-debug '(.markSupported (fis x)))
-
({:op :instance-call,
:form (. (fis x) markSupported),
:tag boolean,
:o-tag boolean,
:class java.io.InputStream}
{:op :invoke,
:form (fis x),
:tag java.io.InputStream, ; ◀ The instance method's class
:o-tag java.lang.Object,
:class nil}
{:op :var,
:form fis,
:tag clojure.lang.AFunction,
:o-tag java.lang.Object,
:class nil}
{:op :const,
:form x,
:tag java.lang.String,
:o-tag java.lang.String,
:class nil})
Finally, calling java.io.FileInputStream#getFD on (fis x) returns the
expected :tag entry:
(analyze-debug '(.getFD (fis x)))
-
(…
{:op :invoke,
:form (fis x),
:tag java.io.FileInputStream, ; ◀ Also the instance method's class
:o-tag java.lang.Object,
:class nil}
…)
Is there a reliable way to retrieve the original type hint of
(.method (fis x))?
If not, does it make sense to ensure that the metadata of the (fis x)
node is constant regardless of its context?
And finally, while we're on the topic, what is the difference between
the :tag, :o-tag, and :class entries? I have a vague idea based on a
quick perusal of the library, but I would be delighted if you could
provide a quick summary.
Thank you for your hard work on these analyzers! You are laying the
groundwork for a whole new generation of Clojure tools.
guns
pgpfLMYGxbQQb.pgp
Description: PGP signature
Re: Community Interest in a Clojure Application Config Library, using Zookeeper?
FWIW, I’ve recently implemented a configuration library for a work project. It’s file-based, but I’m also investigating different approaches on configuration management. Mainly on this areas: - Configuration as a service. - Real-time configuration changes (w/ REST interface to hook UIs). - Components lifecycle (some components needs to be restarted to take advantage of certain configuration changes). I’m thinking about stuartsierra/component and puppetlabs/trapperkeeper. - Applicability of the approach to on-premise solutions (mainly keeping the application and its configuration in sync). drcfg seems to be a good case study, considering that you are using it in production. I’d love to hear some details about the operations side of the story, how it intersects with components lifecycles, and your thoughts on using it for on-premise solutions. My current local solution uses a schema (versioned and packaged with the application) to validate the configuration to keep it in sync with the runnin app, sounds like I coud hook that into the validator. Cheers, Manuel Il giorno martedì 20 maggio 2014 23:33:05 UTC+2, Thomas Steffes ha scritto: Hey folks, At Room Key we're using Apache Zookeeper and a home-grown clojure library called drcfg for real-time application configuration management. We're debating open-sourcing drcfg and are trying to gauge community interest in such a tool. We think it's got great usage semantics, basically you just def an atom in any namespace where you'd like a variable that can be changed in real-time on a running system. When you define the atom, you can also provide defaults to fall back to if zookeeper is unavailable, a validator to be run on any value when a change is attempted (to prevent invalid configuration data), as well as some meta-data about the variable. We've also got a web UI we use to change configuration data, but that would likely be released separate of drcfg itself. If anyone's interested, could you reply to this post? I can provide more information as well if need be. -Thomas Steffes @ Room Key -- 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.
Heidegger, literate programming, and communication
The primary focus of a documentation system is communication from the author to the audience. One of the struggles apparent in discussing issues of communication, especially with programmers, is Heideggers present-at-hand vs breaking down. Programmers write programs to instruct a machine to perform some task. In the ideal, this involves communication from the mind of the programmer to the execution of the program. If the program works the first time it is all a seamless entity (present-at-hand). When the program fails, by compiler errors, missing libraries, runtime errors, design errors, inappropriate actions, or any of the other dragons of programming, the process is not seamless. The details of the process rise to our awareness (breaking down). The burden of failure is likely to fall on people who use or maintain the program rather than the authors. If the program survives, these are likely audiences. Programmers, generalizing from my own case, rarely have a seamless experience. Programs that work the first time, are correct, efficient, and all of the other properties, are rather far outside our experience. The effect of this constant breaking down is that we have learned, rather painfully, to be aware of the machinery of the process at every step of the way. This focus on the machinery becomes the expected way of communicating with the machine. Scratch any programmer, interview at any company, listen to any talk, and you find machinery. But communication from the author to the audience is the underlying theme of literate programming. Knuth's point is about communication, not about the machinery of communication. The question is, to what audience, not how. Discussions seem to get lost in a debate about the machinery rather than the goal. We focus our debate on docstrings versus markup versus wiki. We consider literate programming to be too much machinery. In these forums there is rarely find any example of present-at-hand issues of communication. That is, given a large program (e.g. Axiom, Clojure), what is it that we need to communicate, to what audience, and at what level of detail? Axiom focuses on The 30 year horizon under the assumption that the computational mathematics will be forever valid and that the audience will be unable to contact the likely-dead authors. Pharr and Humphreys' Physically Base Rendering [0] is written as a literate program, a book that won an Academy Award, using Tex and C++. The very first thing they mention in the preface is the Audience. They communicate to humans and, also, to machines. What is the audience for Clojure? Common Lisp has achieved a long-term horizon by raising the language to a standard. No standard is perfect but it does make it possible to construct programs which have a stable base for communication. That base makes it possible to write a book like Lisp in Small Pieces [1] which communicates ideas in natural language using an embedded program as a reduction to practice. So the fundamental point is what to communicate to what audience, not how to implement it. Different audiences will need different implementations (e.g. docstrings for REPL users) but we must avoid losing ourselves in the noise. Axiom, by choice, has a defined audience. Does Clojure? Tim Daly d...@axiom-developer.org [0] Pharr, Matt; Humphreys, Greg Physically Based Rendering ISBN 978-0-12-375079-2 [1] Queinnec, Christian Lisp in Small Pieces ISBN 978-0521545662 -- 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: Count vowels in a string
On Wednesday, May 21, 2014 2:03:14 AM UTC+3, Brad Kurtz wrote:
I saw a rant online about interviewing developers that mentioned
candidates not being able to count the number of vowels in a string. So
naturally, I decided to see if I could do it in Clojure!
I wanted to see others' opinions on other ways of doing it.
*https://gist.github.com/bradkurtz/6ce500d0361ccdc08c8e
https://gist.github.com/bradkurtz/6ce500d0361ccdc08c8e*
Hi,
I ended up with this: https://gist.github.com/ponzao/7399c08bb3b40d349289
(def vowels
#{\a \e \i \o \u})
(defn count-vowels
[s]
(count (keep vowels (.toLowerCase s
Vesa
--
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: Count vowels in a string
My one cent:
(defn count-vowels
([^String text]
(count-vowels text aeiouAEIOU))
([^String text ^String accepted-vowels]
(let [vowel? (set accepted-vowels)]
(- text
(filter vowel?)
count
user= (count-vowels Plínio Balduino)
6
user= (count-vowels Plínio Balduino aeiouAEIOUíÍ)
7
I think this solves the problems for US-ASCII vowels and specific locale
vowels.
Plínio
On Wed, May 21, 2014 at 4:35 AM, Vesa Marttila vtmartt...@gmail.com wrote:
On Wednesday, May 21, 2014 2:03:14 AM UTC+3, Brad Kurtz wrote:
I saw a rant online about interviewing developers that mentioned
candidates not being able to count the number of vowels in a string. So
naturally, I decided to see if I could do it in Clojure!
I wanted to see others' opinions on other ways of doing it.
*https://gist.github.com/bradkurtz/6ce500d0361ccdc08c8e
https://gist.github.com/bradkurtz/6ce500d0361ccdc08c8e*
Hi,
I ended up with this: https://gist.github.com/ponzao/7399c08bb3b40d349289
(def vowels
#{\a \e \i \o \u})
(defn count-vowels
[s]
(count (keep vowels (.toLowerCase s
Vesa
--
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: Clojure Office Hours - Experience Report and Future Plans
For the in-person variety, I've written up some thoughts on why office hours are a good format for meetups, and ideas on the underlying processes: http://blog.factual.com/clojure-office-hours. On Thursday, April 24, 2014 8:44:08 PM UTC-7, Leif wrote: This message is aimed at people that want to *hold* office hours primarily, but of course others can chime in with opinions, suggestions, cheerleading, etc. I recently held office hours where I chatted / pair programmed with less experienced clojure programmers (some were in fact more experienced). Lessons learned: 1. It's fun! Do it! Online like me, or convince your local clojure user group to do it. 2. As I expected, I was more help to less experienced people, but learned a lot *from* the others, and hopefully I was at least useful as a sounding board. 3. An hour is less time than it sounds. 4. If possible, test your pair programming setup beforehand (see point 3 above) a) corollary: if someone is asking about a library that takes some setup, it's probably best if *they* do the setup and host the pairing session. 5. Any remote sharing software (tmux, teamviewer, etc) will mangle *some* input. Be prepared to work around that. 6. Educate people how to cancel, and to cancel ASAP, since some will inevitably need to. 7. For beginners (at clojure, but not programming), pick a specific problem and work through it, or have a solution and explain it step-by-step; that seemed to work best. Code review of some OSS project they are interested in might also work, I didn't try it (but again, see point 3) 8. Unfortunately, no one completely new to programming booked with me, so others will have to give advice here. 9. Many people outside of the western hemisphere were interested, so it would be nice to have coverage across the globe. Future plans: Small plug: I used youcanbook.me to manage the office hours, with no problems. I encourage you to use their service, say nice things about them, and possibly give them money, *because*: These fine folks allow non-profits to use their advanced features for free, or at a reduced price. So, I requested that the Clojure community's office hours get this status. They said yes, so my account (for now, for testing, we can move it later) can have unlimited team members and services. So, I'd like to ask if there is interest in setting up a community clearinghouse for giving/receiving more office hours, possibly of more types. Some ideas (chime in with your own): 1. General Office Hours Basically what I did, except with more people offering office hours, so that: a. Any one person will only have to offer a small number of hours a week (1, even). b. Hopefully more coverage across time zones. c. People can tag what kinds of programming / projects they have expertise in, so that beginners picking up clojure for a specific reason or library can have a more productive session. E.g. some descriptions could read: Leif Poorman Location: Eastern USA Languages: en Tags: beginners, absolute beginners, web, data analysis, machine learning Rich Hickey (obviously this is just an example) Location: USA Languages: en, Bynar Tags: distributed systems, functional databases, Datomic, concurrency, alien technology, everything else 2. Office Hours for Beginners Specifically geared toward beginners in FP, absolute beginners in programming, etc. This could be covered by the description tags as above. Or this could be more of a hangout, where a set number of beginners get led through the ClojureBridge curriculum, or similar. 3. Project Specific Hours a) Someone with knowledge of an open source project gives a demo of its capabilities/weaknesses to prospective users (kind of a technical sales pitch, but for OSS) b) The maintainer of a fairly complex open source project walks some people that want to contribute through the codebase, to kickstart their contributions (I've seen this done/proposed for Midje and Cascalog, at least). Alternatively, we could just start with 1-on-1, or 1-on-1 and small group, and see where it goes from there. Comments? Questions? Suggestions? Cheers, Leif P.S. If you are interested in holding a few office hours, email me, and we can start testing out the more advanced youcanbook.me features. -- 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
Idiomatic clojure on building a sequence
I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Idiomatic clojure on building a sequence
I like to build more complex sequences within the sequence monad, like this: (concat (when cond1 [start elements]) main-seq (when cond2 [end elements])) This also composes nicely with function calls. Another option for a subset of cases: (cond- start-vec condition1 (conj end-element1) condition2 (conj end-element2)) kind regards 2014-05-21 18:23 GMT+02:00 Colin Yates colin.ya...@gmail.com: I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Community Interest in a Clojure Application Config Library, using Zookeeper?
On 5/20/14, 3:33 PM, Thomas Steffes wrote: Hey folks, At Room Key we're using Apache Zookeeper and a home-grown clojure library called drcfg for real-time application configuration management. We're debating open-sourcing drcfg and are trying to gauge community interest in such a tool. We think it's got great usage semantics, basically you just def an atom in any namespace where you'd like a variable that can be changed in real-time on a running system. When you define the atom, you can also provide defaults to fall back to if zookeeper is unavailable, a validator to be run on any value when a change is attempted (to prevent invalid configuration data), as well as some meta-data about the variable. We've also got a web UI we use to change configuration data, but that would likely be released separate of drcfg itself. If anyone's interested, could you reply to this post? I can provide more information as well if need be. -Thomas Steffes @ Room Key Hi Thomas, I'd be interested in learning more about your solution. Have you ever ran into the case where a config change needs to restart a component? If so, have you written the logic that handles the updating of your entire system based on this change? e.g. a new DB config requires that your DB component be restarted and each component that relies on the DB component be restarted as well to get the new connection. Thanks, Ben -- 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: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig, I needed this myself and took a stab at it before it occurred to me to look for other implementations and found yours. I like the way that you have split the implementation of functionality into different namespaces. The current release is a little monolithic. One thing that bothers me is what's going on in clojure.data.xml.impl. I haven't tried to go through all of it yet, but I didn't think that the code needed to be that complex. The way I handled prefix-uri mappings was to use a stack of maps, which I thought was adequate. Your implementation of XmlNamespaceImpl has me thinking that I've been missing something important. Could you explain why XmlNamespaceImpl is structured the way it is? Thanks in advance, Paul On Wed, Mar 26, 2014 at 10:34 AM, Herwig Hochleitner hhochleit...@gmail.com wrote: Hi, I'm taking a stab at namespaced xml support: http://dev.clojure.org/jira/browse/DXML-4 I've uploaded a patch, that should implement 1:1 roundtripping, fully preserving prefixes and xmlns declarations: http://dev.clojure.org/jira/secure/attachment/12899/roundtrip-documents.patch This doesn't implement any advanced serialization or deserialization strategies described in the design page: http://dev.clojure.org/display/DXML/Fuller+XML+support However, it allows such strategies to be implemented by transforming clojure data structures, hence it should be a suitable common representation for any namespaced xml needs. I'd like to work on some namespace-related treewalking next, most importantly normalizing prefixes and default namespaces, so that one can actually parse namespaced xml. Meanwhile, I'd be delighted if you could try out the patch on any (well-formed) namespaced xml you have at hand and see, if it roundtrips correctly. kind regards -- 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: Community Interest in a Clojure Application Config Library, using Zookeeper?
I wrote a ZooKeeper based config system at Climate Corporation. I also found that there is a need to trigger some action when a config value changes, and went with a simple callback solution. I do like the idea of tying this to Stuart's Component lifecycle model; although I think you would also need the callback option for legacy code. Another feature that was important to us was overrides for development. When you start a system locally in dev mode, you probably don't want it to use the production (or even QA environment) config. So we allow overrides in a local file. A few other features that we support, and I would like to see in a generic open-source solution: - Callbacks for config changes as explained above - Caching of the most recent config, in case the system restarts and ZK is not available - Command line client for viewing and modifying config - History of changes to config - A notion of environment (we have multiple ZK clusters, and a 'promote' command in the CLI tool to migrate from one to another-- this could also be done with multiple branches in one ZK cluster) - Public profiles that can be optionally merged in. When an app starts, it specifies it's system name and that branch is pulled from the overall config in ZK, but there are also some values that are shared across apps. These shared configs can go in public profiles, and then the App specific which public profiles it wants to merge in. The app can always override a public profile value by specifying the same key in it's app-or-system-specific config. Some other features that I haven't implemented, but I would like: - Web client for config viewing and modification - Templates (for a group of config options that might be re-used) which can be copied and then edited - A standard way for an app to say (document) what config values it needs - Simple transactions, so multiple config changes can be made or promoted at once marc On Wed, May 21, 2014 at 5:57 AM, Manuel Paccagnella manuel.paccagne...@gmail.com wrote: FWIW, I’ve recently implemented a configuration library for a work project. It’s file-based, but I’m also investigating different approaches on configuration management. Mainly on this areas: - Configuration as a service. - Real-time configuration changes (w/ REST interface to hook UIs). - Components lifecycle (some components needs to be restarted to take advantage of certain configuration changes). I’m thinking about stuartsierra/component and puppetlabs/trapperkeeper. - Applicability of the approach to on-premise solutions (mainly keeping the application and its configuration in sync). drcfg seems to be a good case study, considering that you are using it in production. I’d love to hear some details about the operations side of the story, how it intersects with components lifecycles, and your thoughts on using it for on-premise solutions. My current local solution uses a schema (versioned and packaged with the application) to validate the configuration to keep it in sync with the runnin app, sounds like I coud hook that into the validator. Cheers, Manuel Il giorno martedì 20 maggio 2014 23:33:05 UTC+2, Thomas Steffes ha scritto: Hey folks, At Room Key we're using Apache Zookeeper and a home-grown clojure library called drcfg for real-time application configuration management. We're debating open-sourcing drcfg and are trying to gauge community interest in such a tool. We think it's got great usage semantics, basically you just def an atom in any namespace where you'd like a variable that can be changed in real-time on a running system. When you define the atom, you can also provide defaults to fall back to if zookeeper is unavailable, a validator to be run on any value when a change is attempted (to prevent invalid configuration data), as well as some meta-data about the variable. We've also got a web UI we use to change configuration data, but that would likely be released separate of drcfg itself. If anyone's interested, could you reply to this post? I can provide more information as well if need be. -Thomas Steffes @ Room Key -- 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
Re: Heidegger, literate programming, and communication
Hi Tim, I'm glad you're continuing the conversation, which has helped me at least to clarify my thinking about not just LP but about the nature of programming and the sort of tools we (or I at least) need to support good programming. I end up in a very different place than you, but I don't think it's a zero-sum game. Please take the comments below in the irenic spirit in which they are offered - not you are wrong on so many levels that I'm compelled to enlighten you, but here are some other ways to look at things that seem interesting. On Wed, May 21, 2014 at 6:03 AM, d...@axiom-developer.org wrote: The primary focus of a documentation system is communication from the author to the audience. Communication is an important part of the puzzle, I agree; but what exactly is it? There are lots of modelshttp://en.wikipedia.org/wiki/Models_of_communication, which carry very different implications. One of the struggles apparent in discussing issues of communication, especially with programmers, is Heideggers present-at-hand vs breaking down. Programmers write programs to instruct a machine to perform some task. In the ideal, this involves communication from the mind of the programmer to the execution of the program. This suggests a transference or transmission model of communication based on what Roy Harris http://www.royharrisonline.com/INP26.html calls the telementation and fixed-code fallacies - the idea that communication involves transference of some kind of content (thoughts, concepts, etc.) from one mind to another, or to a machine, by encoding, sending, receiving, and decoding messages. That may be a good model for computational communication, but it has severe (and I think insurmountable) problems as a model for human communication. More fundamentally, whether human-computer interaction should be considered communication at all is problematic to say the least. For a terrific study on communication check out Michael Tomasello's Origins of Human Communicationhttp://books.google.com/books/about/Origins_of_Human_Communication.html?id=T3bqzIe3mAEC. The suggestion there is that successful communication amounts to successful coordination of joint action. The notion that programs instruct a machine to perform some task is very common - it's arguably central to Knuth's concept of LP - but I'm not convinced it is correct. In a sense, a program just *is* a machine, albeit an abstract one. When you compile it, you just translate it into another language, yielding an equivalent machine, one that a physical machine understands. When you run the machine program, it doesn't instruct the hardware to do this or that, any more than the laws of physics instruct apples to fall in a certain way, or a hurled stone instructs the window it meets to shatter. ...snip... The effect of this constant breaking down is that we have learned, rather painfully, to be aware of the machinery of the process at every step of the way. This focus on the machinery becomes the expected way of communicating with the machine. Scratch any programmer, interview at any company, listen to any talk, and you find machinery. How could it be otherwise? Programming is machine construction. But communication from the author to the audience is the underlying theme of literate programming. Knuth's point is about communication, not about the machinery of communication. The question is, to what audience, not how. I'm not sure what machinery of communication means. It's not something I ever think about when I'm programming; in fact I never think about communication. I think about language, logic, and expressiveness. Whether others understand what I write is not something I can control; all I can do is try to write clearly under the constraints of the language I'm using. The problem with focusing on communication is that successful communication is the responsibility of all parties involved. Authors can be held responsible for what they write, but not for what readers read; this is true for all forms of writing. There's not much an author can do to prevent readers from misreading, other than try to write clearly. Unfortunately, the Principle of Charityhttp://en.wikipedia.org/wiki/Principle_of_charityis routinely ignored (especially on the internet!) Knuth: Instead of imagining that our main task is to instruct a *computer*what to do, let us concentrate rather on explaining to *human beings* what we want a computer to do. Notice how Knuth changes horses in midstream, from instructing a computer (i.e. writing code) to explaining to humans, which is not writing code. The conclusion that many (well, some) have drawn is that we should treat the literary explanation as central, and the code as secondary or even incidental. I guess that's ok if your task is to explain a program, but as a model of what programming is or ought to be, it's not even wrong. The *only* reason to write a (real, not toy or pedagogical)
Re: [RFC] Roundtripping namespaced xml documents for data.xml
2014-05-21 19:31 GMT+02:00 Paul Gearon gea...@gmail.com: I needed this myself and took a stab at it before it occurred to me to look for other implementations and found yours. Hi Paul, good to hear you are interested in this effort. I like the way that you have split the implementation of functionality into different namespaces. The current release is a little monolithic. The patch I attached to DXML-4 [1] are just minimal changes to make roundtripping work. No refactoring. I've started to implement a much more advanced approach to namespaced xml in my repo [2], the design of which came from feedback on clojure-dev thread [3] and is documented in a new design page [4]. This approach will add another data tier (and make it the default), where tags and attribute names will be represented as QNames and xmlns attributes won't be present in :attrs One thing that bothers me is what's going on in clojure.data.xml.impl. I haven't tried to go through all of it yet, but I didn't think that the code needed to be that complex. Good thing that you didn't bother consuming it all, impl currently has a lot of code, that will get deleted again. Basically all the stuff for automagically mixing raw and resolved data. The relevant parts for now are mostly XmlNamespace and the reader tag implementations. The way I handled prefix-uri mappings was to use a stack of maps, which I thought was adequate. Your implementation of XmlNamespaceImpl has me thinking that I've been missing something important. Could you explain why XmlNamespaceImpl is structured the way it is? Apart from basic bidirectional mapping functionality, XmlNamespaceImpl is built in such a way that: - Adding mappings is semantically equivalent to a child element declaring xmlns attributes - A new prefix for an already established mapping won't displace the current reverse mapping (uri-prefix), but get recorded as an alternative - Remapping a prefix to a new uri or deleting it, will establish an alternative prefix for that uri, in FIFO manner The aim is to strip out redundant xmlns attributes in the emitter, while retaining xml semantics. There is indeed something missing: Two XmlNamespaces must be diffable, to discover which xmlns attributes actually have to be emitted. I'm sure it could be built a lot simpler. It's currently basically a product of making its tests work [5]. It could probably be made to work with stacks of maps, but then each lookup would involve a linear search, no? -- What do you think of the proposed design? [1] http://dev.clojure.org/jira/browse/DXML-4 [2] https://github.com/bendlas/data.xml [3] https://groups.google.com/d/topic/clojure-dev/2ckb0NxJTlQ/discussion [4] http://dev.clojure.org/display/DXML/Namespaced+XML [5] https://github.com/bendlas/data.xml/blob/master/src/test/clojure/clojure/data/xml/test_namespace.clj kind regards -- 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: [RFC] Roundtripping namespaced xml documents for data.xml
Hi Herwig, Thanks for the response. I'll remove some of the less relevant bits as I reply inline... On Wed, May 21, 2014 at 2:26 PM, Herwig Hochleitner hhochleit...@gmail.comwrote: 2014-05-21 19:31 GMT+02:00 Paul Gearon gea...@gmail.com: I like the way that you have split the implementation of functionality into different namespaces. The current release is a little monolithic. The patch I attached to DXML-4 [1] are just minimal changes to make roundtripping work. No refactoring. I've started to implement a much more advanced approach to namespaced xml in my repo [2], the design of which came from feedback on clojure-dev thread [3] and is documented in a new design page [4]. I wasn't really paying attention to the patch, since I saw your link to your fork. Someone mentioned the thread to me, but I hadn't found it yet. Thanks for the link. I'll read up on it, along with the design page. I'll continue to comment while I'm here, though I may get some of my answers as I read more. This approach will add another data tier (and make it the default), where tags and attribute names will be represented as QNames and xmlns attributes won't be present in :attrs Are QNames strictly necessary? Keywords seem to do the trick, and they work in nicely with what already exists. I know that there are some QName forms that are not readable as a keyword, but the XML parsing code will always call (keyword ...) and that holds any kind of QName, One thing that bothers me is what's going on in clojure.data.xml.impl. I haven't tried to go through all of it yet, but I didn't think that the code needed to be that complex. Good thing that you didn't bother consuming it all, impl currently has a lot of code, that will get deleted again. Basically all the stuff for automagically mixing raw and resolved data. The relevant parts for now are mostly XmlNamespace and the reader tag implementations. The way I handled prefix-uri mappings was to use a stack of maps, which I thought was adequate. Your implementation of XmlNamespaceImpl has me thinking that I've been missing something important. Could you explain why XmlNamespaceImpl is structured the way it is? Apart from basic bidirectional mapping functionality, XmlNamespaceImpl is built in such a way that: - Adding mappings is semantically equivalent to a child element declaring xmlns attributes - A new prefix for an already established mapping won't displace the current reverse mapping (uri-prefix), but get recorded as an alternative - Remapping a prefix to a new uri or deleting it, will establish an alternative prefix for that uri, in FIFO manner Are the reverse mappings (uri-prefix) definitely necessary? My first look at this made me think that they were (particularly so I could call XMLStreamWriter.getPrefix), but it seemed that the XmlWriter keeps enough state that it isn't necessary. My final code didn't need them at all. I thought I covered the various cases, but I could well believe that I missed one, since there are so many ways to represent the data. Do you have some good examples? The aim is to strip out redundant xmlns attributes in the emitter, while retaining xml semantics. There is indeed something missing: Two XmlNamespaces must be diffable, to discover which xmlns attributes actually have to be emitted. I was mostly considering round-tripping the data, and the parser is good at not repeating namespaces for child elements, so the emitter didn't need to either. As a result I didn't need to filter out prefix-uri bindings from parent elements when emitting namespaces, though that should be easy. I'm sure it could be built a lot simpler. It's currently basically a product of making its tests work [5]. It could probably be made to work with stacks of maps, but then each lookup would involve a linear search, no? If uri-prefix is needed, then a simple map would need that, yes. However, if I needed the reverse mapping then I'd use a pair of stacks of maps - one for each direction. (BTW, a stack of maps sounds complex, but the top of the stack is just the new bindings merged onto the previous top of the stack). What do you think of the proposed design? I will take the time to go through them, thanks. Even if it ends up different to how I'd do it, it'll be the core library, and I need to work with it no matter what. Thanks for being on top of this. I'm looking to reimplement a parser in Clojure when 99% of the world is using a single Java library for this job. That's no good for diversity (as OpenSSL showed recently) and also because I can hardly say I'm offering an alternative system when core elements are built on the same library that everyone else uses. It's a W3C standard, so it makes ridiculously heavy use of namespaces. :) Regards, 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
Re: [RFC] Roundtripping namespaced xml documents for data.xml
Hi, Speaking of Clojure and XML, what is the preferred way of dealing with XML in Clojure these days? In the past I have used clojure.xml and clojure.zip. Is clojure.data.xml the best way to do this now? TIA, Thomas -- 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: Community Interest in a Clojure Application Config Library, using Zookeeper?
BTW, just to clarify: even if it's used in a closed-source product, this configuration library is open-source on GitHub, I'm going to post the link if someone is interested. Cheers, Manuel Il giorno mercoledì 21 maggio 2014 11:57:51 UTC+2, Manuel Paccagnella ha scritto: FWIW, I’ve recently implemented a configuration library for a work project. It’s file-based, but I’m also investigating different approaches on configuration management. Mainly on this areas: - Configuration as a service. - Real-time configuration changes (w/ REST interface to hook UIs). - Components lifecycle (some components needs to be restarted to take advantage of certain configuration changes). I’m thinking about stuartsierra/component and puppetlabs/trapperkeeper. - Applicability of the approach to on-premise solutions (mainly keeping the application and its configuration in sync). drcfg seems to be a good case study, considering that you are using it in production. I’d love to hear some details about the operations side of the story, how it intersects with components lifecycles, and your thoughts on using it for on-premise solutions. My current local solution uses a schema (versioned and packaged with the application) to validate the configuration to keep it in sync with the runnin app, sounds like I coud hook that into the validator. Cheers, Manuel Il giorno martedì 20 maggio 2014 23:33:05 UTC+2, Thomas Steffes ha scritto: Hey folks, At Room Key we're using Apache Zookeeper and a home-grown clojure library called drcfg for real-time application configuration management. We're debating open-sourcing drcfg and are trying to gauge community interest in such a tool. We think it's got great usage semantics, basically you just def an atom in any namespace where you'd like a variable that can be changed in real-time on a running system. When you define the atom, you can also provide defaults to fall back to if zookeeper is unavailable, a validator to be run on any value when a change is attempted (to prevent invalid configuration data), as well as some meta-data about the variable. We've also got a web UI we use to change configuration data, but that would likely be released separate of drcfg itself. If anyone's interested, could you reply to this post? I can provide more information as well if need be. -Thomas Steffes @ Room Key -- 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.
stderr with repl development
Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- 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: Community Interest in a Clojure Application Config Library, using Zookeeper?
I'm interested! One of the things on the wish list for trapperkeeper is to make our current configuration service swappable--currently it only supports files, but I'd really like to be able to swap in a database-backed config or zookeeper-based implementation. When we get some time to work on something like that it'd be great to be able to consider building it to use an existing library. On Tuesday, May 20, 2014 2:33:05 PM UTC-7, Thomas Steffes wrote: Hey folks, At Room Key we're using Apache Zookeeper and a home-grown clojure library called drcfg for real-time application configuration management. We're debating open-sourcing drcfg and are trying to gauge community interest in such a tool. We think it's got great usage semantics, basically you just def an atom in any namespace where you'd like a variable that can be changed in real-time on a running system. When you define the atom, you can also provide defaults to fall back to if zookeeper is unavailable, a validator to be run on any value when a change is attempted (to prevent invalid configuration data), as well as some meta-data about the variable. We've also got a web UI we use to change configuration data, but that would likely be released separate of drcfg itself. If anyone's interested, could you reply to this post? I can provide more information as well if need be. -Thomas Steffes @ Room Key -- 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: Community Interest in a Clojure Application Config Library, using Zookeeper?
On Wednesday, May 21, 2014 11:14:28 AM UTC-7, mlimotte wrote: I wrote a ZooKeeper based config system at Climate Corporation. I also found that there is a need to trigger some action when a config value changes, and went with a simple callback solution. I do like the idea of tying this to Stuart's Component lifecycle model; although I think you would also need the callback option for legacy code. Another feature that was important to us was overrides for development. When you start a system locally in dev mode, you probably don't want it to use the production (or even QA environment) config. So we allow overrides in a local file. A few other features that we support, and I would like to see in a generic open-source solution: Is this library open source? -- 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: Community Interest in a Clojure Application Config Library, using Zookeeper?
Not yet, but I hope to be able to do that in the future. On Wed, May 21, 2014 at 4:17 PM, Chris Price ch...@puppetlabs.com wrote: On Wednesday, May 21, 2014 11:14:28 AM UTC-7, mlimotte wrote: I wrote a ZooKeeper based config system at Climate Corporation. I also found that there is a need to trigger some action when a config value changes, and went with a simple callback solution. I do like the idea of tying this to Stuart's Component lifecycle model; although I think you would also need the callback option for legacy code. Another feature that was important to us was overrides for development. When you start a system locally in dev mode, you probably don't want it to use the production (or even QA environment) config. So we allow overrides in a local file. A few other features that we support, and I would like to see in a generic open-source solution: Is this library open source? -- 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: stderr with repl development
A small clue, gleaned from a cider issue: This outputs to the repl terminal. (future (.start (Thread. #(println blah2 This output is captured by vim. (future (println blah3)) Still no idea what's going on. On Wednesday, May 21, 2014 1:09:31 PM UTC-7, Brian Craft wrote: Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- 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: [RFC] Roundtripping namespaced xml documents for data.xml
My understanding is that this is the central library for XML, so theoretically it's preferred. This is why I'm trying to use it. Also, it's one of the few implementations using StAX, which is the best way to do lazy streaming (though core.async makes SAX a viable option again). However, without namespaces there are numerous applications where data.xml won't work, so it's still immature. Paul On Wed, May 21, 2014 at 3:47 PM, Thomas th.vanderv...@gmail.com wrote: Hi, Speaking of Clojure and XML, what is the preferred way of dealing with XML in Clojure these days? In the past I have used clojure.xml and clojure.zip. Is clojure.data.xml the best way to do this now? TIA, Thomas -- 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: stderr with repl development
I use this trick pretty much all the time. (alter-var-root #'*out* (constantly *out*)), same for *err*, though I'll wire *err* to *out* (future (println blah3)) works because *out* is conveyed to the future via binding-conveyor-function. That's not the case in the first. On Wed, May 21, 2014 at 4:41 PM, Brian Craft craft.br...@gmail.com wrote: A small clue, gleaned from a cider issue: This outputs to the repl terminal. (future (.start (Thread. #(println blah2 This output is captured by vim. (future (println blah3)) Still no idea what's going on. On Wednesday, May 21, 2014 1:09:31 PM UTC-7, Brian Craft wrote: Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- 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: Heidegger, literate programming, and communication
On Wednesday, May 21, 2014 6:03:04 AM UTC-5, da...@axiom-developer.org wrote: The primary focus of a documentation system is communication from the author to the audience. One of the struggles apparent in discussing issues of communication, especially with programmers, is Heideggers present-at-hand vs breaking down. Programmers write programs to instruct a machine to perform some task. In the ideal, this involves communication from the mind of the programmer to the execution of the program. If the program works the first time it is all a seamless entity (present-at-hand). When the program fails, by compiler errors, missing libraries, runtime errors, design errors, inappropriate actions, or any of the other dragons of programming, the process is not seamless. The details of the process rise to our awareness (breaking down). The burden of failure is likely to fall on people who use or maintain the program rather than the authors. If the program survives, these are likely audiences. Programmers, generalizing from my own case, rarely have a seamless experience. Programs that work the first time, are correct, efficient, and all of the other properties, are rather far outside our experience. The effect of this constant breaking down is that we have learned, rather painfully, to be aware of the machinery of the process at every step of the way. This focus on the machinery becomes the expected way of communicating with the machine. Scratch any programmer, interview at any company, listen to any talk, and you find machinery. But communication from the author to the audience is the underlying theme of literate programming. Knuth's point is about communication, not about the machinery of communication. The question is, to what audience, not how. Discussions seem to get lost in a debate about the machinery rather than the goal. We focus our debate on docstrings versus markup versus wiki. We consider literate programming to be too much machinery. In these forums there is rarely find any example of present-at-hand issues of communication. That is, given a large program (e.g. Axiom, Clojure), what is it that we need to communicate, to what audience, and at what level of detail? Axiom focuses on The 30 year horizon under the assumption that the computational mathematics will be forever valid and that the audience will be unable to contact the likely-dead authors. Pharr and Humphreys' Physically Base Rendering [0] is written as a literate program, a book that won an Academy Award, using Tex and C++. The very first thing they mention in the preface is the Audience. They communicate to humans and, also, to machines. What is the audience for Clojure? Common Lisp has achieved a long-term horizon by raising the language to a standard. No standard is perfect but it does make it possible to construct programs which have a stable base for communication. That base makes it possible to write a book like Lisp in Small Pieces [1] which communicates ideas in natural language using an embedded program as a reduction to practice. So the fundamental point is what to communicate to what audience, not how to implement it. Different audiences will need different implementations (e.g. docstrings for REPL users) but we must avoid losing ourselves in the noise. Axiom, by choice, has a defined audience. Does Clojure? Tim Daly da...@axiom-developer.org javascript: [0] Pharr, Matt; Humphreys, Greg Physically Based Rendering ISBN 978-0-12-375079-2 [1] Queinnec, Christian Lisp in Small Pieces ISBN 978-0521545662 -- 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: stderr with repl development
On Wednesday, May 21, 2014 2:10:06 PM UTC-7, Gary Trakhman wrote: I use this trick pretty much all the time. (alter-var-root #'*out* (constantly *out*)), same for *err*, though I'll wire *err* to *out* Wow, I have no clue what that does. When do you run this? When would *out* not be the value in #'*out*? You've closed over *out* in some context, and the alter-var-root is running in some different context, where *out* has been reassigned? (future (println blah3)) works because *out* is conveyed to the future via binding-conveyor-function. That's not the case in the first. To be clear, it's the future case that is problematic. It writes (I think) to some vim channel and is lost forever. The Thread case works. It writes to the repl terminal, where I can see it. So, future invokes the binding conveyor, which sets *err* to the vim channel. Where does Thread get its *err*? On Wed, May 21, 2014 at 4:41 PM, Brian Craft craft...@gmail.comjavascript: wrote: A small clue, gleaned from a cider issue: This outputs to the repl terminal. (future (.start (Thread. #(println blah2 This output is captured by vim. (future (println blah3)) Still no idea what's going on. On Wednesday, May 21, 2014 1:09:31 PM UTC-7, Brian Craft wrote: Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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: Heidegger, literate programming, and communication
Tim, From my point of view there are at least a few things that seem clear: 1. I think that Gregg Reynolds and I agree on a lot, but I would add to his remarks that there is almost always a human audience for source code, as well as the compiler/interpreter. Sometimes, the audience is just the originally programmer, perhaps at a later date. (If I missed something, Gregg, sorry, but I don't think you disagree, anyway.) 2. Since Clojure is a general-purpose tool, Clojure source code has no single kind of human audience for the code. In general, I do different things with comments, or with my coding style, depending on whether I expect that I will be the only maintainer of the code, or expect that others with whom I'm collaborating will need to interface with it, for example. Further, I think about the skill levels and background of those who will read the code. And I think about what they would want to do with it. And then I make decisions that involve tradeoffs between competing desiderata. 3. There is a tradeoff between the desire to see a lot of code at once, without a lot of text cluttering it up, and understanding what the code is doing. Comments hurt the former but can help the latter. The same thing goes for literate programming, but--it depends on your goals and your human audience. 4. Two examples to convey the context-dependence of appropriate configuration schemes: A. One time I wrote a small but slightly complex bit of code (in Perl, not Clojure). I could see that it would be confusing, if someone just started reading the code at an arbitrary place. But I also knew the ability of the other programmers I worked with, and I knew that if they started reading at one particular function, they would be able to figure out most of the rest. I provided text that explained what they wouldn't be able to figure out. About six months after I left the company, one of the programmers contacted me and asked me to explain the program; he had to make a modification. I told him to look at such and such document, which mainly said Start reading the code at such and such point, and understand these few other things. He did, and that was all he needed. If I wrote more documentation, I would only be duplicating the information that was already there in the source code, and that would be apparent for the kind of people who would read it. In fact, if I provided *more* documentation, I doubt that the other programmers would have read it. They would have just looked at the source. B. Another example. I generally don't like the idea of LP. That is to say, I like the idea of people who want to be able to use it, using it, but I don't want to use it, usually. And the reason that I don't want to use it is not simply that I don't want to bother writing it. It's that I want the ability to use simple tools and I want to have relatively uncluttered source code. (I could use LP and have uncluttered source much of the time, but only by using special tools.) In my current main project, there is source code that implements the central functionality of the application, and there are rather complex configuration files. I write documents to describe the central functionality source code, so that someone who wants to hack on it will know where to start and where to look. I have to trust that they will know or will be willing to learn Clojure, because otherwise I'd have to explain too much. However, the configuration files should be modifiable by people who won't understand the guts of the program, and yet, they are in Clojure, and would be pretty unintelligible to someone who merely understood in general what the program was supposed to do. (I may create a DSL for the config files, but all that will do will be to get rid of a few parentheses. The information in the config files won't be expressed significantly more succinctly.) For the first time I'm thinking of using LP. It would be perfect for the config files, and in fact, any other way of documenting the config files will probably be inadequate. Interspersing explanations with the configuration code is precisely what's needed. -- 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: stderr with repl development
Ah, so in my case, I run that snippet when I want *other* threads to write to stdout/stderr buffers instead of showing up in the terminal. In your case, you could rebind vim's *err* to its *out*, since you say anything sent to *err* doesn't show up (unless it's not seeing vim's binding), but *out* shows up fine. On Wed, May 21, 2014 at 5:38 PM, Brian Craft craft.br...@gmail.com wrote: On Wednesday, May 21, 2014 2:10:06 PM UTC-7, Gary Trakhman wrote: I use this trick pretty much all the time. (alter-var-root #'*out* (constantly *out*)), same for *err*, though I'll wire *err* to *out* Wow, I have no clue what that does. When do you run this? When would *out* not be the value in #'*out*? You've closed over *out* in some context, and the alter-var-root is running in some different context, where *out* has been reassigned? (future (println blah3)) works because *out* is conveyed to the future via binding-conveyor-function. That's not the case in the first. To be clear, it's the future case that is problematic. It writes (I think) to some vim channel and is lost forever. The Thread case works. It writes to the repl terminal, where I can see it. So, future invokes the binding conveyor, which sets *err* to the vim channel. Where does Thread get its *err*? On Wed, May 21, 2014 at 4:41 PM, Brian Craft craft...@gmail.com wrote: A small clue, gleaned from a cider issue: This outputs to the repl terminal. (future (.start (Thread. #(println blah2 This output is captured by vim. (future (println blah3)) Still no idea what's going on. On Wednesday, May 21, 2014 1:09:31 PM UTC-7, Brian Craft wrote: Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- 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. -- 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: stderr with repl development
you probably want to use set! for that instead of alter-var-root. On Wed, May 21, 2014 at 5:44 PM, Gary Trakhman gary.trakh...@gmail.comwrote: Ah, so in my case, I run that snippet when I want *other* threads to write to stdout/stderr buffers instead of showing up in the terminal. In your case, you could rebind vim's *err* to its *out*, since you say anything sent to *err* doesn't show up (unless it's not seeing vim's binding), but *out* shows up fine. On Wed, May 21, 2014 at 5:38 PM, Brian Craft craft.br...@gmail.comwrote: On Wednesday, May 21, 2014 2:10:06 PM UTC-7, Gary Trakhman wrote: I use this trick pretty much all the time. (alter-var-root #'*out* (constantly *out*)), same for *err*, though I'll wire *err* to *out* Wow, I have no clue what that does. When do you run this? When would *out* not be the value in #'*out*? You've closed over *out* in some context, and the alter-var-root is running in some different context, where *out* has been reassigned? (future (println blah3)) works because *out* is conveyed to the future via binding-conveyor-function. That's not the case in the first. To be clear, it's the future case that is problematic. It writes (I think) to some vim channel and is lost forever. The Thread case works. It writes to the repl terminal, where I can see it. So, future invokes the binding conveyor, which sets *err* to the vim channel. Where does Thread get its *err*? On Wed, May 21, 2014 at 4:41 PM, Brian Craft craft...@gmail.com wrote: A small clue, gleaned from a cider issue: This outputs to the repl terminal. (future (.start (Thread. #(println blah2 This output is captured by vim. (future (println blah3)) Still no idea what's going on. On Wednesday, May 21, 2014 1:09:31 PM UTC-7, Brian Craft wrote: Still not able to track down stderr. Anyone know how this stuff works? Dumping *err* from a ring handler, running from jetty, I get this: java.io.PrintWriter@1d9e436a. This will write to the repl terminal, so long as I flush (wtf... stderr is buffered?). If I dump *err* from a future, I get this: java.io.PrintWriter@fa4b83c. This is the same value I get if I eval (str *err*) in fireplace. Writing to this PrintWriter doesn't output anywhere that I can find. I'm guessing this is the channel used by fireplace to capture output and return it to vim. So, something is different in how *err* is set up, between the jetty adaptor and a future? -- 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. -- 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: Idiomatic clojure on building a sequence
Hi Colin, Have a look at the 'as-' macro, its very helpful in some cases, as: (- [] (conj some-element) (as- some-seq (if some-condition? (conj some-seq some-element) some-seq) (if some-other-condition? (conj some-seq some-other-element) some-seq)) (take some-number-of-elements)) Dňa streda, 21. mája 2014 18:23:06 UTC+2 Colin Yates napísal(-a): I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Idiomatic clojure on building a sequence
Thanks Herwig, cond- looks just the ticket. Off the read the core API again :). On Wednesday, 21 May 2014 17:49:11 UTC+1, Herwig Hochleitner wrote: I like to build more complex sequences within the sequence monad, like this: (concat (when cond1 [start elements]) main-seq (when cond2 [end elements])) This also composes nicely with function calls. Another option for a subset of cases: (cond- start-vec condition1 (conj end-element1) condition2 (conj end-element2)) kind regards 2014-05-21 18:23 GMT+02:00 Colin Yates colin...@gmail.com javascript:: I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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.
[ANN] core.async (and more) video tutorials
From time to time I get asked to do more writing on core.async, and I've come to the realization that try as I might, I'm not a writer. However I recently started a set of video tutorials I'm making available today. The videos average about 12min in length and focus on a single topic. Currently I have 5 videos on core.async completed and two on logic programming. I plan on expanding both series over time. My plans are to release 2-3 videos a week but that may change over time. At any rate, the videos are available here ( https://tbaldridge.pivotshare.com/). Yes, there is a small charge for the majority of the videos, but think of it as a way to prod me to make more tutorials. Thanks! And hopefully this will be useful to some. Timothy Baldridge -- 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] core.async (and more) video tutorials
Awesome! Thanks Tim! '(Devin Walters) On May 21, 2014, at 17:32, Timothy Baldridge tbaldri...@gmail.com wrote: From time to time I get asked to do more writing on core.async, and I've come to the realization that try as I might, I'm not a writer. However I recently started a set of video tutorials I'm making available today. The videos average about 12min in length and focus on a single topic. Currently I have 5 videos on core.async completed and two on logic programming. I plan on expanding both series over time. My plans are to release 2-3 videos a week but that may change over time. At any rate, the videos are available here (https://tbaldridge.pivotshare.com/). Yes, there is a small charge for the majority of the videos, but think of it as a way to prod me to make more tutorials. Thanks! And hopefully this will be useful to some. Timothy Baldridge -- 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: Idiomatic clojure on building a sequence
Another option that I've been using a bit recently is: (- [(if some-condition? some-thing) (if some-other-condition? some-other-thing) ...] (filterv (complement nil?))) Which when the list of expressions is long (more than 3-4 or so) is the most readable alternative I've come up with. Cheers, Colin On 22 May 2014 09:50, Colin Yates colin.ya...@gmail.com wrote: Thanks Herwig, cond- looks just the ticket. Off the read the core API again :). On Wednesday, 21 May 2014 17:49:11 UTC+1, Herwig Hochleitner wrote: I like to build more complex sequences within the sequence monad, like this: (concat (when cond1 [start elements]) main-seq (when cond2 [end elements])) This also composes nicely with function calls. Another option for a subset of cases: (cond- start-vec condition1 (conj end-element1) condition2 (conj end-element2)) kind regards 2014-05-21 18:23 GMT+02:00 Colin Yates colin...@gmail.com: I often find myself doing the following: (let [some-seq [] some_seq (if some-condition? (conj some-seq some-element) some-seq) some_seq (if some-other-condition? (conj some-seq some-other-element) some-seq) some_seq etc.]) In other words building up a sequence which contains the results of predicated elements. Building up a where clause in SQL for example. I experimented with the - and - but that didn't help and just looked messier. How do you handle this pretty common use case? Thanks! -- 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. -- 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.
Help with a memory leak
Hello Devs, I'm working a tool for my thesis using clojure for the first time. The tools will randomly execute methods of a java class for generating an state machine of the API. The java class is annotated with preconditions that are compiled to clojure functions. You can see and example here[1] My problem is that after generating one state machine the memory is not GC'd. I have tried to discover the leak using visualVM and yourkit without luck. The main loop is here[2] in the function trace-gen that generates a lazy list. I don't care about the memory required during the execution of the function but after it should be GC'd all. I would like if someone can recommend me some techniques or tools that can help me to better understood the issue. Regards, -- Pablo [1] https://github.com/bauna/Mentat/blob/master/src/test/java/ar/com/maba/tesis/collections/ArrayStack.java#L24 [2] https://github.com/bauna/Mentat/blob/master/src/main/clojure/mentat/trace.clj#L90-L114 -- 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.
xsl:clj-ext : Live test documentation (or: Illiterate Programming I)
Hi list, xsl.clj-ext https://github.com/mobileink/xsl.clj-ext is a very simple implementation of an XSL extension function that evaluates Clojure code. It's just proof-of-concept stuff at the moment but it works well enough to play around with it. The provided minimal example shows how to embed Clojure code in an XML document and typeset both the code and the result of evaluating it. One possible use of this would be to create something like Concordionhttp://concordion.org/, only simpler. It could also be used to implement LP-style documentation of APIs. I won't be able to get back to it for a few weeks at least, but in the meantime what's there seems to work well enough for experimentation, for those who know a bit of XSL. If there is sufficient interest, the thing to do would be to define an XML schema and some XSL stylesheets for unit testing, API documentation, etc. What's there should be sufficient for that sort of experimentation. Gregg -- 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] core.async (and more) video tutorials
Nice work! I've really enjoyed your past videos. Ambrose On Thu, May 22, 2014 at 6:32 AM, Timothy Baldridge tbaldri...@gmail.comwrote: From time to time I get asked to do more writing on core.async, and I've come to the realization that try as I might, I'm not a writer. However I recently started a set of video tutorials I'm making available today. The videos average about 12min in length and focus on a single topic. Currently I have 5 videos on core.async completed and two on logic programming. I plan on expanding both series over time. My plans are to release 2-3 videos a week but that may change over time. At any rate, the videos are available here ( https://tbaldridge.pivotshare.com/). Yes, there is a small charge for the majority of the videos, but think of it as a way to prod me to make more tutorials. Thanks! And hopefully this will be useful to some. Timothy Baldridge -- 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: Heidegger, literate programming, and communication
On Wed, May 21, 2014 at 4:39 PM, Mars0i marsh...@logical.net wrote: Tim, From my point of view there are at least a few things that seem clear: 1. I think that Gregg Reynolds and I agree on a lot, but I would add to his remarks that there is almost always a human audience for source code, as well as the compiler/interpreter. Sometimes, the audience is just the originally programmer, perhaps at a later date. (If I missed something, Gregg, sorry, but I don't think you disagree, anyway.) I agree; whoever writes the code automatically forms an audience of one. I guess I would say reader/responder. 2. Since Clojure is a general-purpose tool, Clojure source code has no single kind of human audience for the code. In general, I do different things with comments, or with my coding style, depending on whether I expect that I will be the only maintainer of the code, or expect that others with whom I'm collaborating will need to interface with it, for example. Further, I think about the skill levels and background of those who will read the code. And I think about what they would want to do with it. And then I make decisions that involve tradeoffs between competing desiderata. Exactly. Conclusion: it's hard, maybe impossible, to generalize about what all code should look like. Maybe it's essentially pluralistic. 3. There is a tradeoff between the desire to see a lot of code at once, without a lot of text cluttering it up, and understanding what the code is doing. Comments hurt the former but can help the latter. The same thing goes for literate programming, but--it depends on your goals and your human audience. 4. Two examples to convey the context-dependence of appropriate configuration schemes: A. One time I wrote a small but slightly complex bit of code (in Perl, not Clojure). I could see that it would be confusing, if someone just started reading the code at an arbitrary place. But I also knew the ability of the other programmers I worked with, and I knew that if they started reading at one particular function, they would be able to figure out most of the rest. I provided text that explained what they wouldn't be able to figure out. About six months after I left the company, one of the programmers contacted me and asked me to explain the program; he had to make a modification. I told him to look at such and such document, which mainly said Start reading the code at such and such point, and understand these few other things. He did, and that was all he needed. If I wrote more documentation, I would only be duplicating the information that was already there in the source code, and that would be apparent for the kind of people who would read it. In fact, if I provided *more* documentation, I doubt that the other programmers would have read it. They would have just looked at the source. Yep; there's always a point of diminishing returns. I find that in developing code (or trying to understand others' code) I often take extensive notes and sometimes try to mentally improve what I deem sloppy or hard-to-read by writing a clear description of it, or just expressing it in different language. But once I get comfortable with the code I don't often return to my documentation. ... For the first time I'm thinking of using LP. It would be perfect for the config files, and in fact, any other way of documenting the config files will probably be inadequate. Interspersing explanations with the configuration code is precisely what's needed. I agree, that's a case where monolithic LP is entirely appropriate. Ditto for APIs and unit tests; maybe also for simplified examples of API usage expressly designed for training. -Gregg -- 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.
passing a non-anoymous function as an argument to another clojure function
A totally noob question so please bear with me ... I'm trying to pass a function to another function in the REPL like so: function number 1: (defn div [x y] (/ x y)) function number 2: ;; this is from the joy of clojure (defn throw-catch [f] [(try (f) (catch ArithmeticException e No dividing by zero!) (catch Exception e (str You are so bad (.getMessage e))) (finally (println returning... )))]) throw-catch works as expected if I use an anonymous function as shown in the book. But what I'd like to do is pass my div function to the throw-catch function. I've tried a number of iterations but throw-catch always throws an exception (throw-catch div 10 2) ;; throws an exception (throw-catch '(div 10 2)) ;; throws an exception (throw-catch [div 10 2]) ;; throws an exception ... you get the idea (throw-catch #(/ 10 5));; returns 2 Can anyone enlighten me? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
