New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Clojure Programmer at Triggit http://functionaljobs.com/jobs/148-clojure-programmer-at-triggit Cheers, Sean Murphy FunctionalJobs.com -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Local database recommendation?
Use postgres. If it makes sense later on, then try a nosql solution. Until then, postgres will probably do 95% of what you want out of the box. -Zack On Sunday, May 26, 2013 6:20:02 PM UTC-4, Amirouche Boubekki wrote: 1) Is it structured aka. an object can have several fields possibly complex fields like list or hashmaps but also integers ? dates and uuids can be emulated with strings and integers 2) Do objects have relations ? a lot of relations ? 3) is the data schema fixed at compilation or do you need to have the schema to be dynamic ? Much of the data is conditional in a certain sense -- if it's an X, it's also a Y and it may be a W or a Z as well, but if it's a G it's certainly not a W, etc.; though simply storing a large number of boolean columns that may be unused by many of the table rows would be acceptable. The thing that makes me slightly dubious about relational here is that there will necessarily either be many columns unused by many rows, as there's a lot of data that's N/A unless certain other conditions are met; or else there will be many whole tables and a lot of expensive joins, as we have a table of Foos, with an isBar? column with either a BarID or a null, and a table of Bars with an isBaz? column, and a table of Bazzes with an isQuux? column, and then a need to do joins on *all* of those tables to run a query over a subset of Quuxes and have access to some Foo table columns in the results. This sort of thing points towards an object database more than any other sort, with inherited fields from superclasses, or a map database that performs well with lots of null/missing keys in most of the maps. But maybe a relational DB table with very many columns but relatively few used by any given row would perform OK. The only kind of object database that does ACID across documents on the JVM I know of is Tinkerpop' Blueprints. Blueprints is an abstraction layer on top of many graph databases among which Neo4j an OrientDB. The difference between a graph database and an object database is that «pointers» in a graph database are known at both ends. If you don't know graph you will need to learn a bit of it. Basicaly, if A is connected to B, B knows also about A being connected to it, which is not the case with a pointer. Otherwise said, like in relationnal database, you can ask for «all things connected to B» or «all things B connects to». The same query in an object database will cost more. On top of that it's schemaless, like an object database, but there is no notion of class, similar to what is found OO programming (even if you can model the graph to have the concept of classes). The DB must be able to grow larger then available RAM without crashing the JVM and the seqs resulting from queries like the above will also need to be able to get bigger than RAM. My own research suggests that H2 may be a good choice, but it's a standard SQL/relational DB and I'm not 100% sure that fits well with the type of data and querying noted above. Note though that not all querying will take that form; there'll also be strings, uuids, dates, and other such field types and the need to query on these and to join on some of them; also, to do less-than comparisons on dates. Depending on your speed needs and the speed of the database, a kv store can be enough, you serialize the data as strings and deserialize it when you need to do computation. Except that kv store are not easy to deal with when you have complex queries, but again it depends on the query. I expect they'd also have problems with transactional integrity if, say, there was a power cut during an update. Anything involving serialize the data as strings sounds unsuited to either the volume I'm envisioning or the need for consistency. It certainly wouldn't do to overwrite the file with half of an updated version of itself and then lose power! Keeping the previous version around as a .bak file is scarcely much better. It pretty much needs to be ACID since there will need to be coordinated changes to more than one bit of the data sometimes and having an update interrupted with only half the changes done, and having it stay in that half-done state, would potentially be disastrous. At least unqlite is a embeddable kv store that is ACID across several keys, you won't have data cut in half (based on what is advertised), I think berkley db is also transactional. Also I'm interested only in opensource software so there might be proprietary softwares that solve you problem best, but I doubt that ;) -- -- 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
Re: Knowledge derivation in core.logic?
Patrick Logan patrickdlo...@gmail.com writes: OWL has several levels of increasingly expressive but general inferences. Much of the domain could be represented in OWL (classes (i.e. sets), instances (i.e. set membership), relationships with domains and ranges, etc.), but there would still be a need for the domain-specific inferences described in the original post. Not sure that I understand the domain-specifc inferences that you mean here; you want a model of the domain that draw inferences over that model. The actual inferencing technology that you need is not domain-specific. The other concern about applying OWL when it comes to security and privacy is that OWL is based on Open World reasoning and does not follow the Unique Name Assumption. OWL would say, Unless these two things are explicitly designated as being different, assume they *might* be the same thing. You have to go a bit further to close off these open questions in OWL. One of the motivations for tawny, is that you can automate this process. By default, the logic of OWL will not assume that Alice and Bob are different people, as you say, but it's easy to add these statements. Phil -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: wouldn't this be an interesting clojure code editor?
I kinda found the haskell equivalent of the editor I mentioned above(well, at least conceptually) and it's a work in progress but looks great so far, it's written in haskell it's in 3D https://github.com/Peaker/lamdu On Mon, May 20, 2013 at 8:17 PM, atkaaz atk...@gmail.com wrote: Hi guys. I just stumbled upon something [1] and the editor is quite similar to what I was hoping/focusing on having(these days) for editing/writing (not just) clojure code. What are your thoughts on this? (just don't think too much of it in that is for java and ignore the 3D thing) To see what I mean, please see the second video on that [1] page (it's 12 minutes), or if you don't have flash and can get the .wmv file from [2] [1] http://www.alice.org/index.php?page=what_is_alice/what_is_alice [2] http://www.alice.org/what_is_alice/AliceDemonstrationVideo.wmv to note the different colors for forms within a form (ie. at minute 8:57 in the video) I especially wanted something very similar in ccw so it would be obvious where each form begins (which is currently being done with colored parens i think) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Has anyone here played with Wisp?
I've played around with it a fair bit and it's got promise. Despite appearances, it's not really a Clojure - as David says it's missing a lot of features that make Clojure more than Just Another Lisp. It's probably best to think of it as its own Lisp that's adopted Clojure's modernised syntax. With that in mind, there are some things I really like about it. It's nice to be able to write Lisp for the browser without using the JVM as a middle-man. It's nice to get a small compiled file without having to negotiate with the Google Closure compiler. JavaScript interop is easy, as is using existing Node packages. And there's good reason to thinkhttps://github.com/Gozala/wisp/issues/16it'll get source map support support first, which will be a godsend for debugging. On the downside, the first things that come to mind are a lack of destructing binds, and its lazy-seq implementation is borked. There's plenty that you'll miss if you go in expecting Clojure. I think it's a project to keep an eye on. I'm using it in some personal projects, but I wouldn't use it for production. With some work, it'll still be a lesser language than ClojureScript, but one with a better development deployment experience. Personally I hope it spurs some more work on ClojureScript-in-ClojureScript... Kris On Saturday, 25 May 2013 00:59:22 UTC+1, Rich Morin wrote: I saw mention of Wisp the other day (on Hacker News, IIRC), but I haven't noticed any discussion of it on the Clojure email list, (def newsletter), etc: Wisp is a homoiconic JavaScript dialect with clojure syntax, s-expressions and macros. Unlike clojurescript, Wisp code compiles to human-readable JavaScript. The goal of Wisp is to compile to the JavaScript you would have written anyway. Think of Wisp asmarkdown for JS programing! Homoiconic syntax and macros are the primary motivations! -- https://github.com/Gozala/wisp See also http://jeditoolkit.com/try-wisp/ Has anyone here played with Wisp? Any reactions? -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com javascript: http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Game Project - HTML5 or Applet?
Sorry for answering a little late. You are welcome to do whatever you want with the code. Therefore, I licensed it under CC0. And you are welcome to do pull requests. Regarding the state monad, I'm not fully sure what you mean. Do you have any suggestions? You can of course use the - macro: (- ces (update-entity entity [:pos] inc) (assoc :key value)) On Saturday, May 25, 2013 10:21:26 PM UTC+2, JvJ wrote: The combination of CES and LibGDX seems intriguing. I think I'd like to go with that. Stephen, how would you feel about me extending/using your library for the contest? Technically, it's not against the rules, but I still wouldn't feel right if I didn't ask for permission. On Saturday, 25 May 2013 01:04:29 UTC-4, Mikera wrote: You might want to consider LibGDX: https://code.google.com/p/libgdx/ Looks pretty flexible, can do HTML5 games with WebGL as well as Android, iOS and desktop. It's also Java based so should be pretty easy to use from Clojure. On Friday, 24 May 2013 17:22:20 UTC+8, JvJ wrote: I'm thinking of making a game in Clojure for this competition: http://lispinsummerprojects.org/. However, I'm not sure if the best way to go is HTML5 with ClojureScript or a Java applet More specifically, I'd like to do HTML5, but am unsure of the current capabilities of ClojureScript. Any advice would be appreciated. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Maven + LibGDX - HELP!
You just have to include the following item under :dependencies in your
project.clj:
[com.badlogic.gdx/gdx 0.9.9-SNAPSHOT]
[com.badlogic.gdx/gdx-backend-lwjgl 0.9.9-SNAPSHOT]
If you want to use another backend, you have to change the second entry
accordingly. The following code is the main namespace for a game prototype
of mine. Maybe, it can help you a little.
(ns unfinished-game.core
(:gen-class)
(:require [clojure.java.io :as io]
[unfinished-game.input :as input]
[unfinished-game.logic :as logic]
[unfinished-game.util.geometry :refer (vec2d)])
(:import (com.badlogic.gdx ApplicationAdapter Gdx InputAdapter)
(com.badlogic.gdx.graphics GL10 Mesh OrthographicCamera Texture)
(com.badlogic.gdx.graphics.g2d SpriteBatch)
(com.badlogic.gdx.backends.lwjgl LwjglApplication)))
(def images {})
(defn draw! [^SpriteBatch batch {:keys [type image position anchor]}]
(let [image-object ^Texture (images image)
x (float (- (:x position) (* (.getWidth image-object) (case (:x
anchor)
:center 0.5
:right 1
0
y (float (- (:y position) (* (.getHeight image-object) (case (:y
anchor)
:bottom 0
:center 0.5
1]
(cond (= type :image) (.draw batch image-object x y
(def image-names #{player
block1
cross
MetalBlock})
(def game-state (atom {}))
(defn app-adapter []
(let [batch (atom nil)
keys-down (atom #{})]
(proxy [ApplicationAdapter] []
(create []
(println Init.)
(doseq [image-name image-names]
(def images
(conj images
[(keyword image-name)
(Texture.
(.internal Gdx/files (str images/ image-name
.png)))])))
(reset! game-state (logic/initial-game-state))
(reset! batch (SpriteBatch.))
(.setInputProcessor Gdx/input
(proxy [InputAdapter] []
(keyDown [keycode]
(when-let [key-keyword
(input/libgdx-key-map keycode)]
(swap! keys-down #(conj % key-keyword)))
true)
(keyUp [keycode]
(when-let [key-keyword
(input/libgdx-key-map keycode)]
(swap! keys-down #(disj % key-keyword)))
true
(render []
(let [canvas-dims (vec2d (.getWidth Gdx/graphics) (.getHeight
Gdx/graphics))
delta-in-s (.getDeltaTime Gdx/graphics)]
(swap! game-state logic/advance-game-state canvas-dims @keys-down
delta-in-s))
(let [things-to-draw (logic/rendering-commands
@game-state)]
(.glClear (Gdx/gl) GL10/GL_COLOR_BUFFER_BIT)
(.enableBlending @batch)
(.begin @batch)
(doseq [thing-to-draw things-to-draw]
(draw! @batch thing-to-draw))
(.end @batch))
(defn App []
(LwjglApplication. (app-adapter) Unfinished Game 800 600 false))
(defn -main
[ args]
(App))
Greetings
Stephen
On Sunday, May 26, 2013 4:02:07 AM UTC+2, JvJ wrote:
I am more or less terrible at Maven, but I'm OK with Leiningen. Given
that I have some information about a Maven repository (
https://code.google.com/p/libgdx/wiki/MavenProjectSetup#Maven_Archetype),
how do I use it with Leiningen?
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/groups/opt_out.
Re: wouldn't this be an interesting clojure code editor?
or maybe this (Subtext2): http://www.subtextual.org/subtext2.html or this (Conception): https://www.youtube.com/watch?v=DNJ7HqlV55k maybe someone could get some ideas and adapt them to clojure or something On Mon, May 27, 2013 at 10:42 AM, atkaaz atk...@gmail.com wrote: I kinda found the haskell equivalent of the editor I mentioned above(well, at least conceptually) and it's a work in progress but looks great so far, it's written in haskell it's in 3D https://github.com/Peaker/lamdu On Mon, May 20, 2013 at 8:17 PM, atkaaz atk...@gmail.com wrote: Hi guys. I just stumbled upon something [1] and the editor is quite similar to what I was hoping/focusing on having(these days) for editing/writing (not just) clojure code. What are your thoughts on this? (just don't think too much of it in that is for java and ignore the 3D thing) To see what I mean, please see the second video on that [1] page (it's 12 minutes), or if you don't have flash and can get the .wmv file from [2] [1] http://www.alice.org/index.php?page=what_is_alice/what_is_alice [2] http://www.alice.org/what_is_alice/AliceDemonstrationVideo.wmv to note the different colors for forms within a form (ie. at minute 8:57 in the video) I especially wanted something very similar in ccw so it would be obvious where each form begins (which is currently being done with colored parens i think) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some feedback on coding style
On May 26, 2013 8:53 PM, Mark Engelberg mark.engelb...@gmail.com wrote: Another possible design choice is to store a domain-testing predicate in the function's metadata. Using metadata would be a much more idiomatic choice than using arity. Multiple arities are idiomatically used (like method overloading) to default arguments. An interesting detail James thought of but didn't call out is putting the domain check in the :pre metadata of the fn. This is an infrequently used Clojure feature, but it's a perfect fit for partial functions. Calling a fn with an argument that fails the :pre check will throw an exception, so the body can be written to assume it's got good input. Anyone can grab the :pre metadata to test for applicability, and anyone who knows clojure will have at least passing familiarity with the concept. Your macro can still pull apart the pattern matching forms to build the :pre fn, and it's still easy to do orElse-style composition. Unrelated: If you haven't already, you may want to read and follow up on the May 16 thread core.match before going very far with it. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Some feedback on coding style
Hi John,
By :pre, do you mean function preconditions? eg. (fn [] {:pre [..]}) ?
How is :pre related to metadata and dispatch? AFAICT it's purely for
macroexpansion and
there is no metadata available on the precondition post-macroexpansion.
Thanks,
Ambrose
On Mon, May 27, 2013 at 9:00 PM, John D. Hume duelin.mark...@gmail.comwrote:
On May 26, 2013 8:53 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
Another possible design choice is to store a domain-testing predicate in
the function's metadata.
Using metadata would be a much more idiomatic choice than using arity.
Multiple arities are idiomatically used (like method overloading) to
default arguments.
An interesting detail James thought of but didn't call out is putting the
domain check in the :pre metadata of the fn. This is an infrequently used
Clojure feature, but it's a perfect fit for partial functions. Calling a fn
with an argument that fails the :pre check will throw an exception, so the
body can be written to assume it's got good input. Anyone can grab the :pre
metadata to test for applicability, and anyone who knows clojure will have
at least passing familiarity with the concept.
Your macro can still pull apart the pattern matching forms to build the
:pre fn, and it's still easy to do orElse-style composition.
Unrelated: If you haven't already, you may want to read and follow up on
the May 16 thread core.match before going very far with it.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Some feedback on coding style
Oops. That is what I meant, but I don't know why I thought pre- and
post-conditions get stored in metadata. It would be handy for :pre. Thanks,
Ambrose.
To the OP, I would still recommend using metadata to store the
applicability test and also making it a precondition of the fn in a partial
function implementation, but that will require more effort than I thought.
On May 27, 2013 8:12 AM, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
Hi John,
By :pre, do you mean function preconditions? eg. (fn [] {:pre [..]}) ?
How is :pre related to metadata and dispatch? AFAICT it's purely for
macroexpansion and
there is no metadata available on the precondition post-macroexpansion.
Thanks,
Ambrose
On Mon, May 27, 2013 at 9:00 PM, John D. Hume duelin.mark...@gmail.comwrote:
On May 26, 2013 8:53 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
Another possible design choice is to store a domain-testing predicate
in the function's metadata.
Using metadata would be a much more idiomatic choice than using arity.
Multiple arities are idiomatically used (like method overloading) to
default arguments.
An interesting detail James thought of but didn't call out is putting the
domain check in the :pre metadata of the fn. This is an infrequently used
Clojure feature, but it's a perfect fit for partial functions. Calling a fn
with an argument that fails the :pre check will throw an exception, so the
body can be written to assume it's got good input. Anyone can grab the :pre
metadata to test for applicability, and anyone who knows clojure will have
at least passing familiarity with the concept.
Your macro can still pull apart the pattern matching forms to build the
:pre fn, and it's still easy to do orElse-style composition.
Unrelated: If you haven't already, you may want to read and follow up on
the May 16 thread core.match before going very far with it.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
is there a way to use clojure.main/repl from lein?
As opposed to tools.nrepl? Thanks, Stu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Local database recommendation?
Sqlite is worth a look. Never used it with the JVM, but I assume there is a JDBC driver for it. On Mon, May 27, 2013 at 1:01 AM, Zack Maril thewitzb...@gmail.com wrote: Use postgres. If it makes sense later on, then try a nosql solution. Until then, postgres will probably do 95% of what you want out of the box. -Zack On Sunday, May 26, 2013 6:20:02 PM UTC-4, Amirouche Boubekki wrote: 1) Is it structured aka. an object can have several fields possibly complex fields like list or hashmaps but also integers ? dates and uuids can be emulated with strings and integers 2) Do objects have relations ? a lot of relations ? 3) is the data schema fixed at compilation or do you need to have the schema to be dynamic ? Much of the data is conditional in a certain sense -- if it's an X, it's also a Y and it may be a W or a Z as well, but if it's a G it's certainly not a W, etc.; though simply storing a large number of boolean columns that may be unused by many of the table rows would be acceptable. The thing that makes me slightly dubious about relational here is that there will necessarily either be many columns unused by many rows, as there's a lot of data that's N/A unless certain other conditions are met; or else there will be many whole tables and a lot of expensive joins, as we have a table of Foos, with an isBar? column with either a BarID or a null, and a table of Bars with an isBaz? column, and a table of Bazzes with an isQuux? column, and then a need to do joins on *all* of those tables to run a query over a subset of Quuxes and have access to some Foo table columns in the results. This sort of thing points towards an object database more than any other sort, with inherited fields from superclasses, or a map database that performs well with lots of null/missing keys in most of the maps. But maybe a relational DB table with very many columns but relatively few used by any given row would perform OK. The only kind of object database that does ACID across documents on the JVM I know of is Tinkerpop' Blueprints. Blueprints is an abstraction layer on top of many graph databases among which Neo4j an OrientDB. The difference between a graph database and an object database is that «pointers» in a graph database are known at both ends. If you don't know graph you will need to learn a bit of it. Basicaly, if A is connected to B, B knows also about A being connected to it, which is not the case with a pointer. Otherwise said, like in relationnal database, you can ask for «all things connected to B» or «all things B connects to». The same query in an object database will cost more. On top of that it's schemaless, like an object database, but there is no notion of class, similar to what is found OO programming (even if you can model the graph to have the concept of classes). The DB must be able to grow larger then available RAM without crashing the JVM and the seqs resulting from queries like the above will also need to be able to get bigger than RAM. My own research suggests that H2 may be a good choice, but it's a standard SQL/relational DB and I'm not 100% sure that fits well with the type of data and querying noted above. Note though that not all querying will take that form; there'll also be strings, uuids, dates, and other such field types and the need to query on these and to join on some of them; also, to do less-than comparisons on dates. Depending on your speed needs and the speed of the database, a kv store can be enough, you serialize the data as strings and deserialize it when you need to do computation. Except that kv store are not easy to deal with when you have complex queries, but again it depends on the query. I expect they'd also have problems with transactional integrity if, say, there was a power cut during an update. Anything involving serialize the data as strings sounds unsuited to either the volume I'm envisioning or the need for consistency. It certainly wouldn't do to overwrite the file with half of an updated version of itself and then lose power! Keeping the previous version around as a .bak file is scarcely much better. It pretty much needs to be ACID since there will need to be coordinated changes to more than one bit of the data sometimes and having an update interrupted with only half the changes done, and having it stay in that half-done state, would potentially be disastrous. At least unqlite is a embeddable kv store that is ACID across several keys, you won't have data cut in half (based on what is advertised), I think berkley db is also transactional. Also I'm interested only in opensource software so there might be proprietary softwares that solve you problem best, but I doubt that ;) -- -- 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
Re: is there a way to use clojure.main/repl from lein?
Hello, What about lein run -m clojure.main ? 2013/5/27 Stuart Halloway stuart.hallo...@gmail.com: As opposed to tools.nrepl? Thanks, Stu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys
Dear clojure-users, What does this error message means: Exception in thread AWT-EventQueue-0 java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; Thanks in advance. Sincerely, Ru -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys
2013/5/27 ru soro...@oogis.ru Exception in thread AWT-EventQueue-0 java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; You have code compiled against 1.4 (or later) that's running against Clojure 1.3. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Any generic DB libs?
Does Clojure have anything like Ruby's Datamapper or ActiveRecord (besides clj-record)? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why is using (not (empty? coll)) not idiomatic?
On May 26, 2013, at 5:47 AM, Alex L. alexander.lo...@gmail.com wrote: First, the use of seq as a terminating condition is the idiomatic way to test whether a sequence is empty. In natural languages, idioms change. Sometimes it's to the despair of purists: for example, I've had to accept that hopefully at the beginning of a sentence doesn't act as an adverb: Hopefully, he will ascend to a higher plane. Having consumed the HOPE1 drug, he will hopefully ascend to a higher plane. The same is true of programming languages. When I was programming on the PDP-11, it was idiomatic to use pre-increment instead of post-increment when either would do: for (i=0; iN; ++i) … /* right */ for (i=0; iN; i++) … /* wrong */ That was because the former compiled into one machine language instruction, but the latter required two. PDP-11s were slow, so it could matter. There exists in 2013 a person who, in a code review, insists that every post-increment be changed to a pre-increment, even though (1) compilers are way smarter than they were in 1981, (2) computers are way faster too, and (3) insisting on a stylistic point only relevant in the distant past is the sign of a mind past its sell-by date. I've met that person. There is no one who understands `(if (seq thing)` who wouldn't understand `(if (not (empty? thing))` or, better, `(if (not-empty? thing)`. The converse is not true. That suggests that the latter should be the idiom, given that the difference between them is as consequential as the difference between `++i` and `i++`. It's fun to make use of esoterica like `seq`'s behavior with an empty list. Back in the early days, it was necessary. Witness Guy Steele's StrangeLoop talk that began with the need to get a program to fit onto a single punched card. And language implementors still need to care about those things. But, for the rest of us, the necessity has drained out of that kind of esoterica. It's now more of a shibboleth, a way to identify yourself as one of the tribe. That's actually tolerable human behavior, but those who indulge in it shouldn't feel *smug*. Rather, the opposite. Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
MicroStrategy Developer --- Jersey City, NJ --- 6+ months
*Dear Associate,* *Please check the below requirement and advise us the right consultant’s along with Rate, Availability, Contact Details, Current Location Visa Status.* *It’s an immediate requirement please sent me the suitable resumes ASAP. Please make sure the candidate has all the required skills.Send me the resumes on Email: dhruv.ku...@panzersolutions.com* *Job Title: MicroStrategy Developer Location: Jersey City, NJ Duration: 6+ months Client Domain: Insurance Industry* *Responsibilities* *• Design, development and implementation of MicroStrategy dashboards and visualization. • Assist in the system planning, scheduling and implementation • Build enhancements (including new product features) and resolve bugs. • Work in conjunction with other developers and collaborate on design, code, and issue resolutions • Perform unit and integration testing • Deliver development tasks while meeting tight deadlines. • Ability to work efficiently both in a team environment and alone and unsupervised. • Must think logically and be detail oriented. • Possess strong Technical, Analytical and Problem-solving skills* *Qualifications and Education Requirements* *• 5+ years of MicroStrategy overall experience • Must have current experience working with MicroStrategy version 9.2.1. • Key Skills: MicroStrategy Visualization; MicroStrategy Dashboarding; MicroStrategy Reporting and Web Development • Must have strong experience in code optimization and tuning • Must have extensive experience with large file processing. • Strong analytical and problem skills • Experience in Agile development methodologies.* *Preferred Skills but not required:* *• Experience using Netezza database and stored procedure • Microstrategy SDK knowledge Our client is looking to move very quickly. If you are interested in this opportunity, please send me an email with your latest resume or give me a call. If you are not currently looking for new opportunities, feel free to forward this email to any friends or colleagues who may be interested.* * ** * *Best Regards, Dhruv Kumar || Technical Recruiter Panzer Solutions LLC Email: dhruv.ku...@panzersolutions.com GTalk: dhruv.kumar510* *Skype: live:dhruv.kumar* *Voice : 203 652 1444 Ext: 104* -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why is using (not (empty? coll)) not idiomatic?
I really liked your take on this *Brian*. You kinda convinced me to use (if (not-empty? foo)) from now on :) Alexander On Monday, May 27, 2013 2:58:38 AM UTC+3, Brian Marick wrote: On May 26, 2013, at 5:47 AM, Alex L. alexand...@gmail.com javascript: wrote: First, the use of seq as a terminating condition is the idiomatic way to test whether a sequence is empty. In natural languages, idioms change. Sometimes it's to the despair of purists: for example, I've had to accept that hopefully at the beginning of a sentence doesn't act as an adverb: Hopefully, he will ascend to a higher plane. Having consumed the HOPE1 drug, he will hopefully ascend to a higher plane. The same is true of programming languages. When I was programming on the PDP-11, it was idiomatic to use pre-increment instead of post-increment when either would do: for (i=0; iN; ++i) … /* right */ for (i=0; iN; i++) … /* wrong */ That was because the former compiled into one machine language instruction, but the latter required two. PDP-11s were slow, so it could matter. There exists in 2013 a person who, in a code review, insists that every post-increment be changed to a pre-increment, even though (1) compilers are way smarter than they were in 1981, (2) computers are way faster too, and (3) insisting on a stylistic point only relevant in the distant past is the sign of a mind past its sell-by date. I've met that person. There is no one who understands `(if (seq thing)` who wouldn't understand `(if (not (empty? thing))` or, better, `(if (not-empty? thing)`. The converse is not true. That suggests that the latter should be the idiom, given that the difference between them is as consequential as the difference between `++i` and `i++`. It's fun to make use of esoterica like `seq`'s behavior with an empty list. Back in the early days, it was necessary. Witness Guy Steele's StrangeLoop talk that began with the need to get a program to fit onto a single punched card. And language implementors still need to care about those things. But, for the rest of us, the necessity has drained out of that kind of esoterica. It's now more of a shibboleth, a way to identify yourself as one of the tribe. That's actually tolerable human behavior, but those who indulge in it shouldn't feel *smug*. Rather, the opposite. Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Any generic DB libs?
Those are both object/relational mapping libs, so the paradigm is a little different, but Korma is probably what you're looking for: http://sqlkorma.com Jason On May 27, 2013 12:18 PM, sdegutis sbdegu...@gmail.com wrote: Does Clojure have anything like Ruby's Datamapper or ActiveRecord (besides clj-record)? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys
clojure.lang.RT.mapUniqueKeys was added to Clojure 1.5, and did not appear in 1.4 or earlier. It was added to Clojure 1.5 as part of this change: https://github.com/clojure/clojure/blob/master/changes.md#210-set-and-map-constructor-functions-allow-duplicates But yes, as Michael said, it means that you have some code compiled with Clojure 1.5 or later that you are attempting to run with an earlier version of Clojure. Andy On Mon, May 27, 2013 at 9:15 AM, Michael Klishin michael.s.klis...@gmail.com wrote: 2013/5/27 ru soro...@oogis.ru Exception in thread AWT-EventQueue-0 java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; You have code compiled against 1.4 (or later) that's running against Clojure 1.3. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: is there a way to use clojure.main/repl from lein?
I thought I wanted some of the affordances, but not the nrepl connection (e.g. get to reply's standalone eval mode). But it turns out that for my use case, I don't need any of that, so calling clojure.main directly is the right thing. Thanks, Stu On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT laurent.pe...@gmail.comwrote: Hello, What about lein run -m clojure.main ? 2013/5/27 Stuart Halloway stuart.hallo...@gmail.com: As opposed to tools.nrepl? Thanks, Stu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
state management
Hi, I'm dealing with a problem where numerical data needs to be read through a serial port, then rendered to a chart and displayed to the user. The user has to be able to export the chart, and control whether or not reading is actually being done. In addition to this, the chart needs to reflect a rolling average (like the last ten numbers read over the serial port). I tried to do this a few months ago, but ran into problemshttps://github.com/JouisWalker/clattery. The libraries were very good (seesaw, serial port reader, incanter), and with a little java I was able to finish grittier parts of the project. At one point, it was even working - before other details of the project were revealed to me. I have since listened to Stu's excellent talk on concurrencyhttp://www.infoq.com/presentations/Concurrency-Clojure, and am analyzing what went wrong. Perhaps most obvious is the use of reset!, the presence of several atoms scattered throughout (voltage-db, temperature-db etc), and weird undocumented functions like 'update-data. Any criticism, as well as advice on seesaw's workflow (should interface design really be done in a repl?), would be very much appreciated. 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/groups/opt_out.
Re: is there a way to use clojure.main/repl from lein?
The project.clj files in pedestal contain an alias definition:
:aliases {dumbrepl [trampoline run -m clojure.main/main]}
You could try something like that.
--
Dave
On Mon, May 27, 2013 at 6:48 PM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
I thought I wanted some of the affordances, but not the nrepl connection
(e.g. get to reply's standalone eval mode).
But it turns out that for my use case, I don't need any of that, so
calling clojure.main directly is the right thing.
Thanks,
Stu
On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT
laurent.pe...@gmail.comwrote:
Hello,
What about
lein run -m clojure.main
?
2013/5/27 Stuart Halloway stuart.hallo...@gmail.com:
As opposed to tools.nrepl?
Thanks,
Stu
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. And by the way: As I said, I have not been using Clojure for a few months, but: What's the state of the art of debugging for Vim users? I've been meaning to try out vim-fireplace and ritz and see if they work together well, but have not gotten around to it yet. I would very much appreciate a nudge in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why is using (not (empty? coll)) not idiomatic?
There is no one who understands `(if (seq thing)` who wouldn't understand `(if (not (empty? thing))` or, better, `(if (not-empty? thing)`. The converse is not true. That suggests that the latter should be the idiom No, it doesn't. That simply illustrates that idioms must be learned, as in any kind of language. But, for the rest of us, I don't believe you speak for the rest of us. Not for me, anyway. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Recommended SPDY client?
What are the recommended Java/Clojure SPDY clients? I'm interested in using it for backend RPC. Ilya Grigorik discusses this in his AirBnB TechTalk on SPDY. At the end he makes the case for using it for modern backend RPC instead of stuff like Thrift, etc. See... Building a Modern Web Stack Video: https://www.youtube.com/watch?v=ZxfEcqJ4MOM Slides: http://www.igvita.com/slides/2012/http2-for-fun-and-profit.pdf Blog: http://www.igvita.com/2012/01/18/building-a-modern-web-stack-for-the-realtime-web/ Square's OkHttp (https://github.com/square/okhttp/) is usually the one you see mentioned, but its lead developer Jesse Wilson told me that it's not recommended for use as a standalone SPDY client because its SPDY support is based on an internal API that frequently changes. - James -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys
Thank you very much, Michael and Andy! понедельник, 27 мая 2013 г., 20:09:12 UTC+4 пользователь ru написал: Dear clojure-users, What does this error message means: Exception in thread AWT-EventQueue-0 java.lang.NoSuchMethodError: clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; Thanks in advance. Sincerely, Ru -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Maven + LibGDX - HELP!
Wowwee zowee that's a lot of code. Thanks. On Saturday, 25 May 2013 22:02:07 UTC-4, JvJ wrote: I am more or less terrible at Maven, but I'm OK with Leiningen. Given that I have some information about a Maven repository ( https://code.google.com/p/libgdx/wiki/MavenProjectSetup#Maven_Archetype), how do I use it with Leiningen? 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/groups/opt_out.
Re: Game Project - HTML5 or Applet?
Thanks for permission. Also... as far as the state monad goes, it's just a half-formed idea. I'll try to throw something together in the next week or so. On Monday, 27 May 2013 06:26:30 UTC-4, Stephen Kockentiedt wrote: Sorry for answering a little late. You are welcome to do whatever you want with the code. Therefore, I licensed it under CC0. And you are welcome to do pull requests. Regarding the state monad, I'm not fully sure what you mean. Do you have any suggestions? You can of course use the - macro: (- ces (update-entity entity [:pos] inc) (assoc :key value)) On Saturday, May 25, 2013 10:21:26 PM UTC+2, JvJ wrote: The combination of CES and LibGDX seems intriguing. I think I'd like to go with that. Stephen, how would you feel about me extending/using your library for the contest? Technically, it's not against the rules, but I still wouldn't feel right if I didn't ask for permission. On Saturday, 25 May 2013 01:04:29 UTC-4, Mikera wrote: You might want to consider LibGDX: https://code.google.com/p/libgdx/ Looks pretty flexible, can do HTML5 games with WebGL as well as Android, iOS and desktop. It's also Java based so should be pretty easy to use from Clojure. On Friday, 24 May 2013 17:22:20 UTC+8, JvJ wrote: I'm thinking of making a game in Clojure for this competition: http://lispinsummerprojects.org/. However, I'm not sure if the best way to go is HTML5 with ClojureScript or a Java applet More specifically, I'd like to do HTML5, but am unsure of the current capabilities of ClojureScript. Any advice would be appreciated. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
I just watched that video and interpreted it to mean that of the many strategies available to understand problematic behavior in a live app: * reading the code offline + sufficient hammock time * reproducing the problem offline using test cases in an appropriate simulation environment * appropriate logging and tracing at runtime * repl into the live app * tool-assisted stepwise execution and runtime examination (debugging) He's able to be sufficiently productive using the first 4 strategies and doesn't miss the 5th. In that video he also clarified that his recent experience in the field with clojure has been with datomic, of which he and Rich are probably the principal authors, so it's familiar code, with test cases and the logging and tracing he wants. He usually responds very quickly to bug reports on the datomic list, often within hours, so in that case it's fair to say that he's not being hampered by the absence of a debugger. I've found debuggers are most useful in cases where: * the code is unfamiliar/source is unavailable * there isn't an appropriate staging environment or test harness * there aren't good logs * there's no repl However, in a language like clojure, a live repl can fill the role (and then some) of a debugger. I personally can't speak to vim integration, don't use it with clojure. On Mon, May 27, 2013 at 2:34 PM, Oskar Kvist oskar.kv...@gmail.com wrote: Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. And by the way: As I said, I have not been using Clojure for a few months, but: What's the state of the art of debugging for Vim users? I've been meaning to try out vim-fireplace and ritz and see if they work together well, but have not gotten around to it yet. I would very much appreciate a nudge in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. Like Stuart, I haven't used a debugger in years. I find that debuggers give me something to do with my hands while thinking about the failure. They used to be very useful on slow machines but these billion-instructions-per-second toys we have now just tend to overwhelm with data. Try navel debugging. Write a few lines of code, rebuild the system, test that it works the way you expect. If it fails the failure is almost certainly in the changes you just made. Sit back, contemplate your navel, stare at the code, and the nature of the bug will likely reveal itself. Most likely the bug is in the piece of code you don't understand. Of course, this won't work well when working with other people's code. Finding those bugs usually requires human to human communication. The REPL is your best friend. You can hand execute small pieces of code to test your assumptions. Common Lisp systems have wonderfully powerful trace functions allowing arbitrary conditions and actions. I haven't seen anything like that in Clojure yet. Is it possible to dynamically swap a Clojure function definition with a trace function? You would have to interpret the tracer's code fragments in the lexical environment of the call. Are environments first class objects in Clojure? How would that work in an STM code block? How do you stack smash an immutable data structure and continue execution from the breakpoint? How would you mutate a value in the caller's environment? Tim -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Doesn't ritz support nrepl? http://github.com/pallet/ritz On Mon, May 27, 2013 at 5:53 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I would be a lot happier with the state of Clojure debugging if, in addition to a stacktrace, I could easily explore the local variables in play when an error was triggered. It was possible to do this in earlier Clojure environments, but the capability seems to have been lost in the transition to nrepl. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Yes and no. nrepl ritz lags behind slime, especially in areas such as breakpoints and inspection. On Mon, May 27, 2013 at 3:22 PM, David Nolen dnolen.li...@gmail.com wrote: Doesn't ritz support nrepl? http://github.com/pallet/ritz On Mon, May 27, 2013 at 5:53 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I would be a lot happier with the state of Clojure debugging if, in addition to a stacktrace, I could easily explore the local variables in play when an error was triggered. It was possible to do this in earlier Clojure environments, but the capability seems to have been lost in the transition to nrepl. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
I use Eclipse and rarely use the debugger. When I use the debugger it's mainly in some interop situations where I need to look at both sides of the fence, Java and Clojure at the same time. Most of the time it's a misuse of the API that triggers exceptions. These first four strategies are both covering 98% of the needs and reflect sane priorities. Reading the code offline and hammock time is of the utmost importance. If you get stuck in a dead end with some obscure bug, it's a sign that you need this time to reassess your understanding and design of your code. Think about others trying to understand your code if you cannot keep your own code under control... It may well be a sign that it needs some improvements to make it more resilient and cleaner. I frequently used a debugger in the past when integrating component written in different languages because most of the time it's the only easy way to bridge the gap between them (different call conventions, runtimes, call side effects, ...). There are lot less side effects in Clojure, it makes the added value of a debugger limited in a Clojure centric app. The importance of having a debugger is highly exaggerated in this context. A debugger as good as it is cannot replace the 4 first strategies. Luc P. I just watched that video and interpreted it to mean that of the many strategies available to understand problematic behavior in a live app: * reading the code offline + sufficient hammock time * reproducing the problem offline using test cases in an appropriate simulation environment * appropriate logging and tracing at runtime * repl into the live app * tool-assisted stepwise execution and runtime examination (debugging) He's able to be sufficiently productive using the first 4 strategies and doesn't miss the 5th. In that video he also clarified that his recent experience in the field with clojure has been with datomic, of which he and Rich are probably the principal authors, so it's familiar code, with test cases and the logging and tracing he wants. He usually responds very quickly to bug reports on the datomic list, often within hours, so in that case it's fair to say that he's not being hampered by the absence of a debugger. I've found debuggers are most useful in cases where: * the code is unfamiliar/source is unavailable * there isn't an appropriate staging environment or test harness * there aren't good logs * there's no repl However, in a language like clojure, a live repl can fill the role (and then some) of a debugger. I personally can't speak to vim integration, don't use it with clojure. On Mon, May 27, 2013 at 2:34 PM, Oskar Kvist oskar.kv...@gmail.com wrote: Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. And by the way: As I said, I have not been using Clojure for a few months, but: What's the state of the art of debugging for Vim users? I've been meaning to try out vim-fireplace and ritz and see if they work together well, but have not gotten around to it yet. I would very much appreciate a nudge in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
Re: Why is using (not (empty? coll)) not idiomatic?
On May 27, 2013, at 1:38 PM, Armando Blancas abm221...@gmail.com wrote: It's fun to make use of esoterica like `seq`'s behavior with an empty list. Back in the early days, it was necessary. [2 examples] But, for the rest of us, the necessity has drained out of that kind of esoterica. I don't believe you speak for the rest of us. Not for me, anyway. So, for you, it is *necessary* that you use `seq` instead of `not-empty`. That is, there is some way in which your applications, or your life, would be worse if you used the latter - a way that is different than just it's the way my gang does it. I'd be happy to convinced there's a difference, as I'd learn something new. What is that difference? Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loop run until a Clojure Agent send-off is complete
404? On May 10, 2013 8:04 AM, Kelker Ryan theinter...@yandex.com wrote: I would like to share a library that allows for bodies of code to loop run until a Clojure Agent send-off is complete. https://github.com/runexec/hollywood#how -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Coming from Visual Studio all those years ago, I deeply missed my debugger. These days, I miss my debugger extremely rarely. And when I do use a debugger, I much prefer a non-visual one: Either something like dgb, or something like a hypothetical open-repl-here function, where I can ask specific questions and get specific answers... logged to my terminal! I find that trace points (aka print statements) are more useful than break points because I can look at cross sections of execution (read: logs) rather than specific instruction pointer locations. And when you get a log in your terminal, you spend less time re-asking and re-evaluating by hovering your mouse around, which is quick to confuse you. Logs are particularly useful with pretty printed Clojure data, since you know the values have remained immutable since you have printed them! Most of the time, stepping through code is just much slower than thinking, inserting a precise print statement, and then re-executing the broken code. However, this means that you need to design your code for determinism, repeatability, and visibility. So not having a debugger means also has pleasant affects on your design! On Monday, May 27, 2013 2:34:23 PM UTC-4, Oskar Kvist wrote: Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. And by the way: As I said, I have not been using Clojure for a few months, but: What's the state of the art of debugging for Vim users? I've been meaning to try out vim-fireplace and ritz and see if they work together well, but have not gotten around to it yet. I would very much appreciate a nudge in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
realizing a lazy line-seq inside with-open
Hi everyone, I had a function that reads the contents of a file (in this case, it represents a license) and then verifies the contents. As I started to expand the code for verifying, it made sense to break the function up into a function for file parsing and a function for verification. The following is the function that I created to return the contents of the file parsing: (defn- lic-file-msg-sigs return a vector containing the original license string/message and a seq of each signature line generated. the input is the string of the entire license file [lic-file-str] (let [result (promise)] (with-open [rdr (BufferedReader. (StringReader. lic-file-str))] (let [lines (line-seq rdr) line-sandwich-middle-fn (fn [lines line-before line-after] (- lines (drop-while #(not (re-find (re-pattern line-before) %))) rest (take-while #(not (re-find (re-pattern line-after) %) msg-lines (line-sandwich-middle-fn lines LICENSE-BEGIN LICENSE-END) sig-strs (line-sandwich-middle-fn lines SIGNATURE-BEGIN SIGNATURE-END) msg (clojure.string/join \newline msg-lines)] (str msg sig-strs) ;; need to realize the values to force file ;; parsing before file is closed. couldn't figure out how to ;; force realization except for the str function (deliver result [msg sig-strs]))) @result)) My question is related to the comments towards the end -- is there a better way to force the realization of the contents of the line-seq before I deliver it? (If there is a better way to write this code, let me know In case you are wondering, I wanted to use line-seq for parsing the file so that I get the contents of the lines in between special sentinel lines. line-seq requires a reader, and readers are best used with with-open. But with-open closes the reader object at the end of its scope, so any code using the contents of the reader need to be realized before the reader is closed. In order to return the contents outside of the with-open form, I used a promise deliver.) Thanks, Elango -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loop run until a Clojure Agent send-off is complete
I wrote it for fun and deleted after no one took interest. There was no real purpose other than to see if it could be done. 28.05.2013, 08:33, "Plínio Balduino" pbaldu...@gmail.com:404?On May 10, 2013 8:04 AM, "Kelker Ryan" theinter...@yandex.com wrote:I would like to share a library that allows for bodies of code to loop run until a Clojure Agent send-off is complete. https://github.com/runexec/hollywood#how -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Google Summer of Codeq
I am delighted to report that my notion of a GSoC project on Codeq was (a) taken up by Navgeet Agrawal and (b) accepted by Google. Paul deGrandis, Tom Faulhaber, and I will be Navgeet's official mentors for the project, but everyone is welcome to help: Program analysis suite, based on Rich Hickey's Codeq http://www.google-melange.com/gsoc/project/google/gsoc2013/navgeet/7001 A number of folks on this list have expressed interest in Codeq; here is an opportunity to help move it from prototype to production status! I have set up a public Google Group for announcements, comments, ideas, reports, questions, etc. If you are interested in this project, please sign up: Google Summer of Codeq https://groups.google.com/forum/?fromgroups#!forum/gsocq Please contact me directly if you experience any trouble in signing up. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: realizing a lazy line-seq inside with-open
Much simpler, although I'm still seeing the following exception, unless I keep the form (str [msg sig-strs]): IOException Stream closed java.io.BufferedReader.ensureOpen (BufferedReader.java:115) Any ideas why? On Mon, May 27, 2013 at 5:44 PM, Sean Corfield seancorfi...@gmail.comwrote: Just use doall: (doall [msg sig-strs]) No need for the let / result / promise / deliver. On Mon, May 27, 2013 at 5:32 PM, Elango Cheran elango.che...@gmail.com wrote: Hi everyone, I had a function that reads the contents of a file (in this case, it represents a license) and then verifies the contents. As I started to expand the code for verifying, it made sense to break the function up into a function for file parsing and a function for verification. The following is the function that I created to return the contents of the file parsing: (defn- lic-file-msg-sigs return a vector containing the original license string/message and a seq of each signature line generated. the input is the string of the entire license file [lic-file-str] (let [result (promise)] (with-open [rdr (BufferedReader. (StringReader. lic-file-str))] (let [lines (line-seq rdr) line-sandwich-middle-fn (fn [lines line-before line-after] (- lines (drop-while #(not (re-find (re-pattern line-before) %))) rest (take-while #(not (re-find (re-pattern line-after) %) msg-lines (line-sandwich-middle-fn lines LICENSE-BEGIN LICENSE-END) sig-strs (line-sandwich-middle-fn lines SIGNATURE-BEGIN SIGNATURE-END) msg (clojure.string/join \newline msg-lines)] (str msg sig-strs) ;; need to realize the values to force file ;; parsing before file is closed. couldn't figure out how to ;; force realization except for the str function (deliver result [msg sig-strs]))) @result)) My question is related to the comments towards the end -- is there a better way to force the realization of the contents of the line-seq before I deliver it? (If there is a better way to write this code, let me know In case you are wondering, I wanted to use line-seq for parsing the file so that I get the contents of the lines in between special sentinel lines. line-seq requires a reader, and readers are best used with with-open. But with-open closes the reader object at the end of its scope, so any code using the contents of the reader need to be realized before the reader is closed. In order to return the contents outside of the with-open form, I used a promise deliver.) Thanks, Elango -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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
Re: Loop run until a Clojure Agent send-off is complete
I find this might be helpful in this situation: Google I/O 2009 - The Myth of the Genius Programmer https://www.youtube.com/watch?v=0SARbwvhupQ On Tue, May 28, 2013 at 4:02 AM, Kelker Ryan theinter...@yandex.com wrote: I wrote it for fun and deleted after no one took interest. There was no real purpose other than to see if it could be done. 28.05.2013, 08:33, Plínio Balduino pbaldu...@gmail.com: 404? On May 10, 2013 8:04 AM, Kelker Ryan theinter...@yandex.com wrote: I would like to share a library that allows for bodies of code to loop run until a Clojure Agent send-off is complete. https://github.com/runexec/hollywood#how -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Loop run until a Clojure Agent send-off is complete
I can't watch videos at the moment, so would you mind writing a short summary? 28.05.2013, 10:12, "atkaaz" atk...@gmail.com:I find this might be helpful in this situation:Google I/O 2009 - The Myth of the Genius Programmerhttps://www.youtube.com/watch?v=0SARbwvhupQOn Tue, May 28, 2013 at 4:02 AM, Kelker Ryan theinter...@yandex.com wrote:I wrote it for fun and deleted after no one took interest. There was no real purpose other than to see if it could be done. 28.05.2013, 08:33, "Plínio Balduino" pbaldu...@gmail.com:404?On May 10, 2013 8:04 AM, "Kelker Ryan" theinter...@yandex.com wrote:I would like to share a library that allows for bodies of code to loop run until a Clojure Agent send-off is complete. https://github.com/runexec/hollywood#how -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
On May 27, 2013, at 5:53 PM, Mark Engelberg wrote: I would be a lot happier with the state of Clojure debugging if, in addition to a stacktrace, I could easily explore the local variables in play when an error was triggered. It was possible to do this in earlier Clojure environments, but the capability seems to have been lost in the transition to nrepl. This is also the main debugging feature I want and don't have in any of the ways that I currently work with Clojure. I've seen montion of libraries that one can include that will give one this kind of functionality, but I've never gotten anything to work. Does anyone know a simple way to do this that doesn't involve an Emacs-based tool set? In my former life in Common Lisp I think that every environment -- from command-line-based implementations to full-featured IDEs -- would put you in a REPL at the point of an error, from which you could examine locals all the way up the stack, evaluate expressions, and even redefine things and continue. I don't usually need all of this, but it seems cruel for the system to be throwing away all of that stack info (local variables) that I often know contains the information I need to track down and fix a bug. Later in the thread: On May 27, 2013, at 8:17 PM, Brandon Bloom wrote: Most of the time, stepping through code is just much slower than thinking, inserting a precise print statement, and then re-executing the broken code. However, this means that you need to design your code for determinism, repeatability, and visibility. So not having a debugger means also has pleasant affects on your design! Most of my code is intentionally and intrinsically non-deterministic, and re-executing can take days. So it sure would be nice to be able to see the locals that were in play when the error was triggered! -Lee -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
For Vim users, I ported the debug repl. This is a tool that allows you to create a REPL in the middle of the call stack, which allows you to suspend the evaluation of functions, lazy seqs, etc, and then inspect the locals and globals at that location. If you've already installed Fireplace, then you just need add the vim plugin and include redl in your project.clj, and use :Repl or :ReplHere to create a repl, and then use redl.core/break and redl.core/continue to use the debugger. You can find the vim component here: https://github.com/dgrnbrg/vim-redl and the Clojure component here: https://github.com/dgrnbrg/redl Let me know if you need help setting it up! On Monday, May 27, 2013 2:34:23 PM UTC-4, Oskar Kvist wrote: Stuart Halloway said in his video Clojure in the Field ( http://www.infoq.com/presentations/Clojure-tips) from March 1, 2013 (I think): I don't feel the absence of a debugger because I've learnt enough that I don't ever need a debugger. I am very intrigued by that statement. What does he (or you, if you are reading, Stuart) mean? For me, debugging is the biggest thing that I don't know how to do well currently in Clojure (I use Vim, and have not programmed in Clojure for a while), so I am really interested in what he meant. And by the way: As I said, I have not been using Clojure for a few months, but: What's the state of the art of debugging for Vim users? I've been meaning to try out vim-fireplace and ritz and see if they work together well, but have not gotten around to it yet. I would very much appreciate a nudge in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Google Summer of Codeq
Congrats and good luck! Ambrose On Tue, May 28, 2013 at 9:06 AM, Rich Morin r...@cfcl.com wrote: I am delighted to report that my notion of a GSoC project on Codeq was (a) taken up by Navgeet Agrawal and (b) accepted by Google. Paul deGrandis, Tom Faulhaber, and I will be Navgeet's official mentors for the project, but everyone is welcome to help: Program analysis suite, based on Rich Hickey's Codeq http://www.google-melange.com/gsoc/project/google/gsoc2013/navgeet/7001 A number of folks on this list have expressed interest in Codeq; here is an opportunity to help move it from prototype to production status! I have set up a public Google Group for announcements, comments, ideas, reports, questions, etc. If you are interested in this project, please sign up: Google Summer of Codeq https://groups.google.com/forum/?fromgroups#!forum/gsocq Please contact me directly if you experience any trouble in signing up. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
Lets take a real life example, I had to design a backup system to take over when a master quote feed made of several individual feeds failed. My backup system had access to same raw feeds as the master system using serial lines but there were no guarantee that both systems would receive the raw feeds within the same time slot. I had to sort out messages while listening to the master feed to replicate the same orderly message stream as the master while avoiding sending duplicates. This was highly non deterministic, I ended up with more than two dozen threads with circular buffers, etc... with obviously mutation everywhere, mutexes, condition variables, ... to try to stay in sync with the master feed. Tests had to be done with real data which of course changed every time I had to test. Add to this an unstable Solaris kernel thread subsystem. Took three weeks to find the proper patch mix to attain the nirvana of stability. Debugging was not a viable option. The only options were code review/hammock time and sufficient logging. This was written in C, no REPL, the old fail/fix/compile/link/run cycle. This project was extreme in this regard but it prove to me that reviewing code offline and thinking about how to improve it gives much more payback than using the debugger to fix a specific problem. Luc P. On May 27, 2013, at 5:53 PM, Mark Engelberg wrote: I would be a lot happier with the state of Clojure debugging if, in addition to a stacktrace, I could easily explore the local variables in play when an error was triggered. It was possible to do this in earlier Clojure environments, but the capability seems to have been lost in the transition to nrepl. This is also the main debugging feature I want and don't have in any of the ways that I currently work with Clojure. I've seen montion of libraries that one can include that will give one this kind of functionality, but I've never gotten anything to work. Does anyone know a simple way to do this that doesn't involve an Emacs-based tool set? In my former life in Common Lisp I think that every environment -- from command-line-based implementations to full-featured IDEs -- would put you in a REPL at the point of an error, from which you could examine locals all the way up the stack, evaluate expressions, and even redefine things and continue. I don't usually need all of this, but it seems cruel for the system to be throwing away all of that stack info (local variables) that I often know contains the information I need to track down and fix a bug. Later in the thread: On May 27, 2013, at 8:17 PM, Brandon Bloom wrote: Most of the time, stepping through code is just much slower than thinking, inserting a precise print statement, and then re-executing the broken code. However, this means that you need to design your code for determinism, repeatability, and visibility. So not having a debugger means also has pleasant affects on your design! Most of my code is intentionally and intrinsically non-deterministic, and re-executing can take days. So it sure would be nice to be able to see the locals that were in play when the error was triggered! -Lee -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
On May 27, 2013, at 9:54 PM, Softaddicts wrote: Lets take a real life example, [etc.] Debugging was not a viable option. [etc.] This project was extreme in this regard but it prove to me that reviewing code offline and thinking about how to improve it gives much more payback than using the debugger to fix a specific problem. Okay, sometimes debuggers don't help... but sometimes they do! And often it's necessary to step back and think... but sometimes having some key information (like the value of the arguments to my function, or of some other locals, that led to the error) makes the thinking a lot more productive. Elsewhere on this thread: On May 27, 2013, at 9:36 PM, dgrnbrg wrote: For Vim users, I ported the debug repl. This is a tool that allows you to create a REPL in the middle of the call stack, which allows you to suspend the evaluation of functions, lazy seqs, etc, and then inspect the locals and globals at that location. If you've already installed Fireplace, then you just need add the vim plugin and include redl in your project.clj, and use :Repl or :ReplHere to create a repl, and then use redl.core/break and redl.core/continue to use the debugger. You can find the vim component here: https://github.com/dgrnbrg/vim-redl and the Clojure component here: https://github.com/dgrnbrg/redl This sounds pretty neat... but I also don't use Vim. (It's also not completely clear to me from this description if you can get the locals from the context of an error, rather than from a manual suspension.) Is there anything that will provide the values of locals at an error (whether interactively or in a big dump) regardless of the IDE or launch method that one uses? Or if there's nothing that's so general then is there anything that would work from a call to lein run or from Clooj or from Eclipse/CCW? Thanks, -Lee -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Clojure and Datomic workshops at NDC Oslo week of June 10
Hi all, I will be doing Clojure and Datomic workshops, as well as a few talks. at NDC Oslo in a few weeks, see http://ndcoslo.oktaset.com/Agenda for details. Hope to see some of you there! Stu -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
If you haven't tried out Light Table, it shows you the values of local variables. It is a pretty nice feature. On Monday, May 27, 2013 5:53:16 PM UTC-4, puzzler wrote: I would be a lot happier with the state of Clojure debugging if, in addition to a stacktrace, I could easily explore the local variables in play when an error was triggered. It was possible to do this in earlier Clojure environments, but the capability seems to have been lost in the transition to nrepl. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Knowledge derivation in core.logic?
On Monday, May 27, 2013 12:40:34 AM UTC-7, Phillip Lord wrote: Patrick Logan patric...@gmail.com javascript: writes: OWL has several levels of increasingly expressive but general inferences. Much of the domain could be represented in OWL (classes (i.e. sets), instances (i.e. set membership), relationships with domains and ranges, etc.), but there would still be a need for the domain-specific inferences described in the original post. Not sure that I understand the domain-specifc inferences that you mean here; you want a model of the domain that draw inferences over that model. The actual inferencing technology that you need is not domain-specific. In the cryptography domain, the original post mentioned (I rephrase)... Given a secret key and encrypted nonce for that key, assert the unencrypted nonce. What I mean is that there is no way to express this in OWL alone. This could be expressed in core.logic, in clojure, in java, in SPARQL + a custom function, in SWRL + a custom function, in Prolog, etc. The other concern about applying OWL when it comes to security and privacy is that OWL is based on Open World reasoning and does not follow the Unique Name Assumption. OWL would say, Unless these two things are explicitly designated as being different, assume they *might* be the same thing. You have to go a bit further to close off these open questions in OWL. One of the motivations for tawny, is that you can automate this process. By default, the logic of OWL will not assume that Alice and Bob are different people, as you say, but it's easy to add these statements. Yes, that's all I meant by the above, i.e. people unfamiliar with OWL inferences would need to be aware of this and explicitly add statements like Alice and Bob are different individuals or the set of Male and Female are disjoint, etc. -pdl -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: is there a way to use clojure.main/repl from lein?
On Monday, May 27, 2013 12:48:24 PM UTC-5, stuart@gmail.com wrote:
I thought I wanted some of the affordances, but not the nrepl connection
(e.g. get to reply's standalone eval mode).
But it turns out that for my use case, I don't need any of that, so
calling clojure.main directly is the right thing.
Sounds like this is solved, but in case it comes up for anyone else, there
are a couple options to get a non-nREPL REPLy via leiningen. All will
currently require going through trampoline, but we think that's a
historical requirement and a non-trampolined version shouldn't be a big
deal to add if people want to avoid the trampoline.
- in project.clj: `:repl-options {:standalone true}`, and running `lein
trampoline repl`
- or override any existing setting from the command line: `lein update-in
:repl-options assoc :standalone true -- trampoline repl`
I am curious as to the use cases for avoiding nREPL. I know one is Heroku,
where network connections are more restricted. Are there others? Just want
to be sure there's nothing broken that we don't know about. If there are
bugs in REPLy that make people need to bypass it entirely, please let me
know with an issue: https://github.com/trptcolin/reply/issues (though you
may want to look at reply 0.2.0 first, which will be in lein 2.2.0).
- Colin
Thanks,
Stu
On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT
lauren...@gmail.comjavascript:
wrote:
Hello,
What about
lein run -m clojure.main
?
2013/5/27 Stuart Halloway stuart@gmail.com javascript::
As opposed to tools.nrepl?
Thanks,
Stu
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Has anyone here played with Wisp?
Hi all, I've spent several months working on Krishnan's Clojurejs and added a lot of things I could to make it more practical. I named the fork ChlorineJs and lots about it can be found here: https://github.com/chlorinejs/chlorine/wiki Compared to wisp, ChlorineJS is a bit ahead, especially with destructing and a subset[1] of Clojure's core library. I haven't announced about ChlorineJS because I still want some more hammock driven development. But today when you guys talk about a similar language, I decide to tell a little about it. Bug reports, ideas and pull requests are welcome[2] though I don't promise I will be very responsive during this HDD time. [1]: https://github.com/chlorinejs/core-cl2/blob/master/core-cl2/test/cl2/core_tests.cl2 [2]: https://github.com/chlorinejs/chlorine/issues -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
writing a multimap implementation: problems with transients, metadata
So, inspired by this post on SO:
http://stackoverflow.com/questions/10942607/clojure-multi-maps
I've been trying to write some multimap functions, in a transient
version:
https://gist.github.com/anonymous/5660467
This was my first experience with transients, and it's been
problematic. First problem: transients do not support or preserve
metadata, or so it seems. I wanted my multimaps to function also as
regular maps until the multi- functionality is needed, so I needed a
way to distinguish multi entries from regular ones. At first blush,
you'd just test to see if the entry is a set; but if you think about
it, you might want to make a regular map have set entries too. No
problem, that's what metadata's for, right? But of course this code
doesn't work:
(defn plural? [item]
(get (meta item) :multi))
(defn pluralize! [item]
(if (plural? item)
item
(transient (with-meta (set (list item)) {:multi true}
Since transients do not preserve metadata.
Is this an oversight in Clojure, or something that's intentionally
missing? The following thread throws a little light on the matter but
is not conclusive (and I couldn't find anything more recent):
https://groups.google.com/group/clojure-dev/browse_thread/thread/acb8e6c1ace4613f/0bd110fd226fe547
In the meantime, how would I best accomplish what I am trying to do
with this use of metadata?
And here's still another issue:
(defn persist-all! [mmap]
(let [persisted-map (persistent! mmap)
mkeys (keys persisted-map)]
(loop [item (first mkeys)
restof (rest mkeys)
wmap (transient persisted-map)]
...
You can see here that in order to get the keys from the transient
multimap, I have to persist it first (since you can't seq on
transients, and calling keys requires seq-ability); but then to
persist all the sets, I re-convert the persisted transient multimap to
a transient (since I'm about to do a bunch of changes on the multimap
at once, which would seem to be what transients are for in the first
place). That seems redundant, but I haven't found any way around it:
I don't see how to get the keys otherwise, and once I've called
persist! I can't re-use the underlying transient.
I'm sure all these problems are eminently solvable by approaching the
problem in a different way; but I thought this was a good opportunity
to seed some discussion about using transients (and metadata).
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: realizing a lazy line-seq inside with-open
doall doesn't recurse, so you are not realizing the lazy-seq, you want something like [msg (doall sig-strs)] if you are looking to play around with io stuff, I recommend looking in to using reducers for io, they allow you to sort of invert control, keeping the nice property of with-open always cleanly closing resources after use, but making it easier to break up io processing in functional steps with out needing to deal with the dynamic scoping issues of with-open and the lazy issues with line-seq On Mon, May 27, 2013 at 6:10 PM, Elango Cheran elango.che...@gmail.comwrote: Much simpler, although I'm still seeing the following exception, unless I keep the form (str [msg sig-strs]): IOException Stream closed java.io.BufferedReader.ensureOpen (BufferedReader.java:115) Any ideas why? On Mon, May 27, 2013 at 5:44 PM, Sean Corfield seancorfi...@gmail.comwrote: Just use doall: (doall [msg sig-strs]) No need for the let / result / promise / deliver. On Mon, May 27, 2013 at 5:32 PM, Elango Cheran elango.che...@gmail.com wrote: Hi everyone, I had a function that reads the contents of a file (in this case, it represents a license) and then verifies the contents. As I started to expand the code for verifying, it made sense to break the function up into a function for file parsing and a function for verification. The following is the function that I created to return the contents of the file parsing: (defn- lic-file-msg-sigs return a vector containing the original license string/message and a seq of each signature line generated. the input is the string of the entire license file [lic-file-str] (let [result (promise)] (with-open [rdr (BufferedReader. (StringReader. lic-file-str))] (let [lines (line-seq rdr) line-sandwich-middle-fn (fn [lines line-before line-after] (- lines (drop-while #(not (re-find (re-pattern line-before) %))) rest (take-while #(not (re-find (re-pattern line-after) %) msg-lines (line-sandwich-middle-fn lines LICENSE-BEGIN LICENSE-END) sig-strs (line-sandwich-middle-fn lines SIGNATURE-BEGIN SIGNATURE-END) msg (clojure.string/join \newline msg-lines)] (str msg sig-strs) ;; need to realize the values to force file ;; parsing before file is closed. couldn't figure out how to ;; force realization except for the str function (deliver result [msg sig-strs]))) @result)) My question is related to the comments towards the end -- is there a better way to force the realization of the contents of the line-seq before I deliver it? (If there is a better way to write this code, let me know In case you are wondering, I wanted to use line-seq for parsing the file so that I get the contents of the lines in between special sentinel lines. line-seq requires a reader, and readers are best used with with-open. But with-open closes the reader object at the end of its scope, so any code using the contents of the reader need to be realized before the reader is closed. In order to return the contents outside of the with-open form, I used a promise deliver.) Thanks, Elango -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
On Mon, May 27, 2013 at 5:39 PM, u1204 d...@axiom-developer.org wrote: The REPL is your best friend. You can hand execute small pieces of code to test your assumptions. Common Lisp systems have wonderfully powerful trace functions allowing arbitrary conditions and actions. I haven't seen anything like that in Clojure yet. What about add-watch? Can be used with any of Clojure's mutable-value containers -- atoms, refs, agents, vars. If one is getting set to an inappropriate value, or you suspect it is, you can attach a watcher to it that will emit a log entry anytime it gets set to a value outside its expected range, including printing a stack trace that should include the spot in the code where this happened. In the case of immutable data or mutable Java objects getting scrozzled, there's always the option of modifying the possible sites of the trouble to log buggy behavior. For instance, if a LinkedBlockingQueue is getting polluted with nils that are making the consumer blow up, adding before (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.))) will move the blowup closer to the actual site of the error and give you an informative stack trace. You might even leave that one in in production, if the thing should (or *will*) die anyway if a nil gets in there, so your user base's bug reports will already have a useful stack trace instead of a useless one. Bad function arguments? Add a :pre clause to blow up immediately with a useful stack trace, if one otherwise doesn't show up or shows up far from the error. Bad values getting into immutable data? Add a (print ...) wherever it's built up using assoc or conj or what-have-you. The only times I've resorted to a debugger myself have been with buggy C code that trashed the stack or heap or jumped off into the middle of nowhere and the resulting stack trace, if existent, didn't point to the true location of the error, or give any useful hints as to where that was, and when diagnosing and fixing deadlocks in Java code. Java dispensed with C's ability to trash the system badly enough to not have a meaningful stack trace (even if it's far from the real error, a Java stack trace is pointing to something *relevant*, like a null where one shouldn't be that you can find all the mutators of; with C in real mode it was frighteningly easy to get no stack trace at all, just a hang, kernel panic, or BSOD, and even in protected mode your bug could systematically destroy all of the data you could use to diagnose it and *then* crash the process) and Clojure has more or less ended the deadlock menace (where being able to see which threads hold what monitors and are waiting for what other monitors was the key debugger killer-feature that stack traces and logging weren't so helpful with) and anything that simply hangs inside the JVM can be re-tried in the context of (def x (Thread. #(hanging-fn args))), (.start x), wait for it to have stopped working, (.getStackTrace x), and check out the stack trace you get to see where hanging-fn and its callees went off the fairway and into the trees (maybe lower x's priority before (.start x) if it wedges a core and that would otherwise make the REPL unresponsive). -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
On Mon, May 27, 2013 at 10:25 PM, Cedric Greevey cgree...@gmail.com wrote: What about add-watch? Can be used with any of Clojure's mutable-value containers -- atoms, refs, agents, vars. If one is getting set to an inappropriate value, or you suspect it is, you can attach a watcher to it that will emit a log entry anytime it gets set to a value outside its expected range, including printing a stack trace that should include the spot in the code where this happened. In the case of immutable data or mutable Java objects getting scrozzled, there's always the option of modifying the possible sites of the trouble to log buggy behavior. For instance, if a LinkedBlockingQueue is getting polluted with nils that are making the consumer blow up, adding before (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.))) will move the blowup closer to the actual site of the error and give you an informative stack trace. You might even leave that one in in production, if the thing should (or *will*) die anyway if a nil gets in there, so your user base's bug reports will already have a useful stack trace instead of a useless one. Bad function arguments? Add a :pre clause to blow up immediately with a useful stack trace, if one otherwise doesn't show up or shows up far from the error. Bad values getting into immutable data? Add a (print ...) wherever it's built up using assoc or conj or what-have-you. You've just listed three things that I can *add* to my code to track down errors: watches, logging, pre clauses (and let's not forget the old standby printf). But that all misses the point. When my code goes *boom* and I get an error and a stacktrace, I want to know specifically what the context was at the time of *that particular crash*. If I have to alter my code and rerun, it may be hard to recreate the conditions that caused the error. If the stacktrace simply revealed richer information, such as what the inputs were to the various functions in the stacktrace, and I could explore the local variables, that would save tons of time spent trying to annotate the function to print or log the variables and then trying to get the bug to happen again. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger.
You have production code going *boom* that doesn't have any failing tests? Or you have nondeterministic tests? :) On Tue, May 28, 2013 at 1:49 AM, Mark Engelberg mark.engelb...@gmail.comwrote: On Mon, May 27, 2013 at 10:25 PM, Cedric Greevey cgree...@gmail.comwrote: What about add-watch? Can be used with any of Clojure's mutable-value containers -- atoms, refs, agents, vars. If one is getting set to an inappropriate value, or you suspect it is, you can attach a watcher to it that will emit a log entry anytime it gets set to a value outside its expected range, including printing a stack trace that should include the spot in the code where this happened. In the case of immutable data or mutable Java objects getting scrozzled, there's always the option of modifying the possible sites of the trouble to log buggy behavior. For instance, if a LinkedBlockingQueue is getting polluted with nils that are making the consumer blow up, adding before (.offer lbq x) something like (if (nil? x) (throw (NullPointerException.))) will move the blowup closer to the actual site of the error and give you an informative stack trace. You might even leave that one in in production, if the thing should (or *will*) die anyway if a nil gets in there, so your user base's bug reports will already have a useful stack trace instead of a useless one. Bad function arguments? Add a :pre clause to blow up immediately with a useful stack trace, if one otherwise doesn't show up or shows up far from the error. Bad values getting into immutable data? Add a (print ...) wherever it's built up using assoc or conj or what-have-you. You've just listed three things that I can *add* to my code to track down errors: watches, logging, pre clauses (and let's not forget the old standby printf). But that all misses the point. When my code goes *boom* and I get an error and a stacktrace, I want to know specifically what the context was at the time of *that particular crash*. If I have to alter my code and rerun, it may be hard to recreate the conditions that caused the error. If the stacktrace simply revealed richer information, such as what the inputs were to the various functions in the stacktrace, and I could explore the local variables, that would save tons of time spent trying to annotate the function to print or log the variables and then trying to get the bug to happen again. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
