Re: [ANN] Opencv bindings for clojure
Hi Chris, Great work! Sorry to jump in. I had already been working on an auto-generated wrapper directly for opencv. (not javacv though) It's called origami and is on github: https://github.com/hellonico/origami/tree/master I just ported origami to OpenCV4-beta. Maybe there is some work or examples we could merge or work on together ? Nico On Tuesday, October 30, 2018 at 3:37:09 AM UTC+9, ch...@techascent.com wrote: > > http://techascent.com/blog/opencv-love.html > > > Enjoy :-). If we would have had this earlier then a lot of our projects > would have taken considerably less time. > > > Also note at the end where we do some vector math in unsigned byte space > using the opencv image as the backing store. > > > Chris > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Reactive with ClojureScript Recipes (book)
Good morning All, >From the other side of the planet, Apress just published a recipe book on ClojureScript with React/Reagent. It should quite a fun and easy read for most of the people on this list, so please have a look: http://www.apress.com/jp/book/9781484230084 This being a book on Clojure, I really had a blast writing it. Hopefully, it will spark new ideas and makes readers try out many new things. For beginners, it should also be quite coherent and easy to pick up. Feedback very welcome. Nicolas, -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Clojure Programming Cookbook
Hi Clojure people, So after one year and 23 days, (that would be 388 days) the IT book I was working on with Makoto (merci!) finally got published! It has been a long battle with many late nights to get it out, tough deadlines and never-ending reviews, but thanks to some skilled people at Packt, thank you Sachin, Pranav (and not forgetting Nikhil, you got it all started!) (http://packtpub.com/ <http://l.facebook.com/l.php?u=http%3A%2F%2Fpacktpub.com%2F=MAQFNzSaTAQHKWtLeEq3J7Hse62fvy5HCVXjATDU_Uo_Mog=AZOQKxr9iAwYO-4NIUZEMIDfSEeKhXk_FcTllZQ1G-OAZ_V0IzblmJqZwGy5begkaWaGPbx4dHi4qXYIGHplfH0AWzx9YN9KATmNN1KOxCOnGzR6Mhj_iervp1Z1dqcLQjJDYArmfzPJituI9206NvaheQ3Ze3m22pkRU0oZCGBiuLP2BKti9tUXLZkiW4wnqZw=1>) it is finally there in all its 635 pages glory ;) (PACK) https://www.packtpub.com/application-development/clojure-programming-cookbook (AMAZON) http://a.co/3c9ckbp The book while also presenting Clojure language centric topics, wants to be slightly more focused around using Clojure at work and is bringing tons and tons of working examples for every day usage. Along its (long!) 10 chapters, the book goes through many various topics but tries to keep each topic easy to follow, with fun and useful recipes for great projects and various creative ideas. The book may sometimes be too simple to many of the members of this mailing list, but we hope the book contribute to grow the Clojure community by sharing useful (and battled) Clojure code and stories. This is out now ! Enjoy! Nicolas & Makoto, all the way from Japan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Largest Clojure codebases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 16/11/2015 15:54, Kyle R. Burton a écrit : > At the last company I was with I used sloccount [1] to analyze the codebase. > I concatenated all the clj files to a .lisp file so sloccount could analyze it. I was curious about the cost estimate that sloccount performs to see how the team measured up (size varied from 2 to 7 over 5 years). When I did the analysis (over a year ago) we had about 130k lines of Clojure that represented about two dozen libraries and bout six services. Including the javascript, java, C, Ruby and other languages in our repositories, sloccount estimated over 5x the person years we actually spent. This team was also responsible for the whole stack - production operations, releases, etc. If someone is doing research, I'd be happy to reach out to a colleague to see if they would run the analysis again. Is sloccount reliable for anything beyond counting the lines of code? In the past, I've tried it over simple code bases in various languages and it would always produce cost estimates way higher than the reality (one-off perl things I would do over a week-end would be estimated at something 150 days). I confess I've never configured sloccount (actually, I have no idea whether this is possible at all) and have always relied on the stock, default execution. I'm genuinely interested in knowing whether sloccount can be used as a serious cost estimator. Nicolas -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWVEbeAAoJEEm9nYAWkk7woBIIAL6RcZxEAbI8t7x4r9EcuoZv QvoD6XJYiUB70GL7fY/Rr5NMcLMjWAAE0RI/2Z25237+RNnJ/QM3gMhCRxNuuMAz koEzEGY24yhCw6e6d7nmB7C2ryW0g7tlhLQUJz2vNqJkqlN8P+qvbvHIEiGHJ2lq Q54GC4ZCodVUvJIKT48F4+E0i1d4uakWP4VP1ZYriTH+I3DZIDyomIAXKL9p37hg rI+K3lFT1DQOXc87jyHufh4+R9er+RPwLiQ/3cUq3CsrJS9yU0is6a5iw284CAdf 6CbFWyuHUf9KvZ9nMnCDx4zM02tfz8UJkMJbIyByJNucsDduO32w81iGg6d/Rzw= =bhxa -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] - New Clojure Instant Answer on DuckDuckGo
On 26 Aug 2015, at 00:04, Rafik NACCACHE rafik.nacca...@gmail.com wrote: Hi Guys, I contributed an Instant Answer to DuckDuckGo. When you search for Clojure with a number of terms, you directly have under the software tab all the packages matching your query from Clojars. Nice ! Very handy, thanks ! Nicolas. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Reviewers needed for new Clojure book!
Hi, I have reviewed other IT books before and also using clojure on an everyday basis. I would really love to be able to review this new Clojure book. Nico On Monday, August 24, 2015 at 3:46:06 PM UTC+9, Akhil Wali wrote: If anyone is interested in being a reviewer for a new book *Mastering Clojure* by Packt Publishing, please let me know. Reviewers will be entitled to a 6 montn subscription of PacktLib https://www.packtpub.com/books/subscription/packtlib. Here's the list of topics covered in this title. - - Working with Sequences and Types - Orchestrating Concurrency and Parallelism - Parallelization using Reducers - Writing Macros - Composing Transducers - Using Functors and Monads - Programming with Logic - Asynchronous Programming - Reactive Programming - Working with Tests - Troubleshooting and Best Practices -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: awful performance on Windows 7 compared to anything else
Hi Colin, Would you have a subset of your app as a project on github/bitbucket so we can help finding out ? I am not sure it is related but the call to fsync in clojure http://dev.clojure.org/jira/browse/CLJ-703 looks slightly similar to what other people are seeing. https://blogs.oracle.com/charlesLamb/entry/berkeley_db_java_edition_vs_wi And that surprisingly slowed my app down on windows some time ago. (I gave up investigating at that time to be honest) Again, a small app similar to your set up would be great to help out. Kind Regards, On Saturday, July 4, 2015 at 1:50:23 AM UTC+9, Colin Yates wrote: Hi all, I have a Clojure/ClojureScript app using http-kit. When deployed on Windows 7 it is a insanely slow. For example, loading the first screen loads immediately but then takes minutes to populate. The exact same jar on Windows XP, OS X, Linux, Windows 2008 server etc. take a handful of seconds. In total, 3 Windows 7 machines (including a fresh VM I just booted up, installed Win7SP1 and all patches, installed latest JDK on and then ran the JAR) exhibit the same performance. 2 OSXs, 1 Linux box and 1 Windows 2008 are all fine. Fortunately no-one is going to run the server on Windows 7, and using a browser on Windows 7 to connect to the server running anywhere else is absolutely fine. Anyone else run into this? Any pointers? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] 美味しいClojure
The whole text has also been written in English, so I guess there could be a chance to put it out there. But we have had no contacts with US/UK publishers so far. On Tuesday, October 1, 2013 9:43:00 PM UTC+9, Jim foo.bar wrote: also, is this only going to be published in Japanese? Jim On 01/10/13 13:41, sailor...@gmail.com javascript: wrote: Is there any E-book to buy ? The shipping cost of Amazon.jp is high. -- -- 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: [ANN] 美味しいClojure
yes, the ebook should be on sale in the next few weeks. On Tuesday, October 1, 2013 9:41:10 PM UTC+9, sailor...@gmail.com wrote: Is there any E-book to buy ? The shipping cost of Amazon.jp is high. -- -- 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 cannot last be fast on vector?
I would say we can have different ways of designing things.
A way is to design abstractions and provide services on top on theses
abstractions. The abstraction here is ISeq. That is sequences. Last
is not part of the ISeq abstraction and just work on top of it. There
is no way to access last element directly from something that is just
a an ISeq. So last can't use it.
If last was part of ISeq abstraction, you would not need a separate
last function at all. But this would also mean that all ISeq
implementations would need to implement last. This would be sure
conveniant, but this is not the same abstraction. It is also heavier
(more code, more maintenance...). And for some implementation like
networks streams, this would be anoying than anything as it would
provide no added value.
Seq abstraction is exactly that: a very basic (yet powerfull)
abstraction for accessing streams, linked list and other specialized
structures that are sequential in essence.
Clojure team could have designed last to work on any possible type
where it make sense and so have better performance for each possible
type. An efficient implementation would use a protocol to do so.
Making last its own abstraction. This is indeed possible, but was not
the choice here.
Fact is others abstractions already allow you to have the last element
directly like Indexed if this important to you.
So yes we could have a better last, promoting it to a full
abstraction. Like clojure could be many more things. Is this REALLY a
priority for the future of clojure? Not at least for clojure core
team. I tend to share their views. You have the right to disagree.
On my side, I'am far more interrested to see progress in
clojurescript, IDEs, tooling, maybe even grid computing.
You care about last. This is your right... And well why not implement
your own last in contrib or private lib and use if it is important?
Like other members of the community implemented code matching their
own interrest.
It is logical you ask for it, but there is no need to insist or maybe
be a little offensive if others don't share your views.
Regards,
Nicolas Bousquet.
On 29 juin, 01:32, Warren Lynn wrn.l...@gmail.com wrote:
This is an off-shoot subject from my last post General subsequence
function.
I found people had similar questions before (one year
ago):http://groups.google.com/group/clojure/browse_thread/thread/712711f04...
As of Clojure 1.4, seems nothing changed, as source show here:
user (source last)
(def
^{:arglists '([coll])
:doc Return the last item in coll, in linear time
:added 1.0
:static true}
last (fn ^:static last [s]
(if (next s)
(recur (next s))
(first s
Any reason for that? 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
Should I better use a state monad (and how)?
I'm working on a turn-based game and I'm looking for a good way to manage
states. In the game each turn is composed of multiple phases. I started by
using atoms for the phases field (this is a sequence of functions) in a
record and realized that it wouldn't be ideal to keep track of states in
the case where I'd need to keep a snapshot of every phases. Here's the
original code I had:
(defrecord Game [phases]
(next-phase [this]
(stop-timer)
(swap! phases #(conj (vec (rest %)) (first %)))
(log :info change phase to %s (key (first @phases)))
(start-phase this))
I then started to think that this would be a good opportunity to use a
state monad. I've tried to reimplement the above code using the algo.monads
library but the result was less than satisfactory (probably due to my own
shortcoming), here's the monadic version:
(defrecord Game [phases]
(next-phase [this]
(-
((domonad state-m
[_ (fn [s] (stop-timer) [s s])
_ (update-state
(fn [s]
(update-in s [:phases]
#(conj (vec (rest %)) (first %)
_ (fn [s]
(log :info change phase to %s (key (first (:phases s [s s])]
nil)
state)
second
start-phase))
As my code probably doesn't need the full power of the state monad, I tried
to write a lighter-weight version using the following macro:
(defmacro [ state-and-forms]
(reduce #(list (if ('#{fn fn*} (first %2))
%2
`(fn [s#] ~%2 s#)) %)
state-and-forms))
Which let me write:
(next-phase [state]
( state
(stop-timer)
(fn [s] (update-in s [:phases] #(conj (vec (rest %)) (first %
#(do (log :info change phase to %s (key (first (:phases % %)
#(start-phase %)))
With some more helper macro this version looks promising. In the end I
wonder if there's some Clojure feature I'm overlooking or if I should
rethink the whole solution? Is there a better way to accomplish this?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Should I better use a state monad (and how)?
On Monday, April 16, 2012 12:08:30 AM UTC-4, kovasb wrote: You can try using the in-memory version of Datomic. Besides keeping track of the state at every point, it can help with the reasoning about what should happen next for each state change. Hum, I hadn't though about using a service like Datomic at all, but I'm not sure it fill the bill has it looks like a very heavyweight solution. I'm not even sure where to start to understand what Datomic is! -- 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
Re: Should I better use a state monad (and how)?
I couldn't resist writing some more macros!
(defmacro [k-or-ks f]
`(fn [state#]
(update-in state#
~(if (vector? k-or-ks)
k-or-ks
(vector k-or-ks))
~f)))
(defn * [state form]
(condp = (first form)
' `(fn [~state] ~@(rest form) ~state)
' `(fn [~state] ~@(rest form))
form))
(defmacro [state forms]
(reduce #(list (if (#{' 'fn 'fn*
'clojure.core/fn
'clojure.core/fn*} (first %2))
%2
`(fn [s#] ~%2 s#)) %)
(conj (map (partial * state) forms)
state)))
With those the resulting code looks pretty clean and remain purely
functional:
(next-phase [state]
( state
(stop-timer)
( :phases #(conj (vec (rest %)) (first %)))
( (log :info change phase to %s (- state :phases first key)))
( (start-phase state
Now, I'd need to find better names!
On Sunday, April 15, 2012 11:25:21 PM UTC-4, Nicolas Buduroi wrote:
I'm working on a turn-based game and I'm looking for a good way to manage
states. In the game each turn is composed of multiple phases. I started by
using atoms for the phases field (this is a sequence of functions) in a
record and realized that it wouldn't be ideal to keep track of states in
the case where I'd need to keep a snapshot of every phases. Here's the
original code I had:
(defrecord Game [phases]
(next-phase [this]
(stop-timer)
(swap! phases #(conj (vec (rest %)) (first %)))
(log :info change phase to %s (key (first @phases)))
(start-phase this))
I then started to think that this would be a good opportunity to use a
state monad. I've tried to reimplement the above code using the algo.monads
library but the result was less than satisfactory (probably due to my own
shortcoming), here's the monadic version:
(defrecord Game [phases]
(next-phase [this]
(-
((domonad state-m
[_ (fn [s] (stop-timer) [s s])
_ (update-state
(fn [s]
(update-in s [:phases]
#(conj (vec (rest %)) (first %)
_ (fn [s]
(log :info change phase to %s (key (first (:phases s [s
s])]
nil)
state)
second
start-phase))
As my code probably doesn't need the full power of the state monad, I
tried to write a lighter-weight version using the following macro:
(defmacro [ state-and-forms]
(reduce #(list (if ('#{fn fn*} (first %2))
%2
`(fn [s#] ~%2 s#)) %)
state-and-forms))
Which let me write:
(next-phase [state]
( state
(stop-timer)
(fn [s] (update-in s [:phases] #(conj (vec (rest %)) (first %
#(do (log :info change phase to %s (key (first (:phases % %)
#(start-phase %)))
With some more helper macro this version looks promising. In the end I
wonder if there's some Clojure feature I'm overlooking or if I should
rethink the whole solution? Is there a better way to accomplish this?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Logic puzzle: send more money performance
Hi, I translated[1]the solution to the send more money logic puzzle from the cKanren paper in core.logic and I was wondering about its expected performance. I wasn't patient enough to run it without giving it some clues, giving it the S E N D digits make it run in around 36s on my machine, but then giving it just three digits make it goes on for minutes. So I'm curious about how much time would be needed to run this solution without any clues. Is its performance expected or I've made some kind of mistake? Also does anyone know of ways to optimize this code? [1]: https://gist.github.com/2364695 -- 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
A simple (and naive) online whiteboard using Aleph ClojureScript
Hi everyone, I've been experimenting with ClojureScript and Aleph lately and made this sample application. It's a naive implementation of an online whiteboard. It's under a hundred line of code so it's a quick read: https://github.com/budu/board The Clojure web development story is getting better and better everyday, bit thanks to everyone involved! -- 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
Re: A simple (and naive) online whiteboard using Aleph ClojureScript
On Saturday, March 31, 2012 7:35:03 PM UTC-4, jun lin wrote: Maybe you can create an online demo site? Yes good idea, I'll try to get it running on Heroku tomorrow. -- 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
Tutorial: Clojure applications in Eclipse with Counterclockwise and Maven
Hi Everyone, I wrote an extensive tutorial in two parts about developing Clojure applications with Maven and Counterclockwise in Eclipse: Clojure in Eclipse, Part 1: Mavenhttp://chaomancy.squarespace.com/blog/clojure-in-eclipse-part-1-maven.html: Develop, test and deploy a Clojure app in Eclipse with Maven only. Get into the details of the POM and understand Maven's concept of life-cycle. Clojure in Eclipse, Part 2: Counterclockwise + Mavenhttp://chaomancy.squarespace.com/blog/clojure-in-eclipse-part-2-counterclockwise-maven.html: Develop comfortably and interactively with CCW. Fulfill all your workflow needs with the combination of CCW and Maven. I wrote this in two parts, in particular to help understand what Maven is about and what each tool adds to the other. Also, there was a bit to say about how to make Eclipse, Maven and Clojure work together happily. I hope you find it interesting and, even better, helpful. Do shout if I wrote anything wrong or if any of it is not understandable. Cheers, Nico -- 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
Re: Can Clojure be as readable as Python or Ruby ?
Well maybe the problem of the let? macro is that it is not standard. If you use standard constructs and I'am proeficient with clojure I'll understand your code fast. I'll concentrate on understanding your code relevant for your application and domain. But just adding a few new constructs specific to ypur libr can make code really complex to read, even to experimented clojurians. That the power of macros (or even functions). Abstract things away. But you also need to know the function/macro. And if it is not standard, we end up with many different version of let? depending of the library, author... By all means I'm not against let? macro or On 9 mar, 19:04, Evan Gamble solar.f...@gmail.com wrote: I find let? useful and readable, as do others. There's a bit of brain- training necessary to read it, but not a lot. Probably no more than the keyword clauses of the for comprehension. The argument that decades of Lisp programmers haven't invented this particular chucklehead macro is a bit weak, since there have been many other similar macros. ...and I have learned to love nil, even the :else nil clause that repels you. - Evan On Mar 9, 9:26 am, Craig Brozefsky cr...@red-bean.com wrote: Evan Gamble solar.f...@gmail.com writes: (let? [a foo :else nil b bar :is even? c baz :when ( b c) d qux] (f a b c d)) Macros like that just make your code so much LESS readable. I now have to understand the semantics of a bunch of keywords specific to the macro, their order of operations within the macro, as well as recognizing the little ? on the end of the let as I'm scanning. I also have to see if that's a keyword or the start of another binding! :else nil? really? :is ... Geezus christ :when !?!?! Put down that nailgun, kid ;; This maintains the same logic (unless I fucked up transcoding) ;; and also the same err, complexity, in that forms are not exeuted if ;; they don't need to be, as your initial example, without nesting all ;; the way over to the side, or using some weird keyword language. (when-let [a foo] (let [b bar c (when (even? b) baz)] (when (and c ( b c)) (f a b c qux ;; or (when-let [a foo] (let [b bar c (when (even? b) baz) d (when (and c ( b c)) qux)] (when d (f a b c d Keep your constructs simple, and learn to love the nil. Also, people have been writing lisp for a real long time, and they haven't invented a chucklehead macro like let? yet, so prolly not really needed to improve the readability... -- Craig Brozefsky cr...@red-bean.com Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
(Sorry for split post). So I'am not against let? macro of whatever you might need. That why we have a lisp here. But be sure you really need it/use it. And it is designed to be intuitive as possible. On 9 mar, 23:05, Nicolas bousque...@gmail.com wrote: Well maybe the problem of the let? macro is that it is not standard. If you use standard constructs and I'am proeficient with clojure I'll understand your code fast. I'll concentrate on understanding your code relevant for your application and domain. But just adding a few new constructs specific to ypur libr can make code really complex to read, even to experimented clojurians. That the power of macros (or even functions). Abstract things away. But you also need to know the function/macro. And if it is not standard, we end up with many different version of let? depending of the library, author... By all means I'm not against let? macro or On 9 mar, 19:04, Evan Gamble solar.f...@gmail.com wrote: I find let? useful and readable, as do others. There's a bit of brain- training necessary to read it, but not a lot. Probably no more than the keyword clauses of the for comprehension. The argument that decades of Lisp programmers haven't invented this particular chucklehead macro is a bit weak, since there have been many other similar macros. ...and I have learned to love nil, even the :else nil clause that repels you. - Evan On Mar 9, 9:26 am, Craig Brozefsky cr...@red-bean.com wrote: Evan Gamble solar.f...@gmail.com writes: (let? [a foo :else nil b bar :is even? c baz :when ( b c) d qux] (f a b c d)) Macros like that just make your code so much LESS readable. I now have to understand the semantics of a bunch of keywords specific to the macro, their order of operations within the macro, as well as recognizing the little ? on the end of the let as I'm scanning. I also have to see if that's a keyword or the start of another binding! :else nil? really? :is ... Geezus christ :when !?!?! Put down that nailgun, kid ;; This maintains the same logic (unless I fucked up transcoding) ;; and also the same err, complexity, in that forms are not exeuted if ;; they don't need to be, as your initial example, without nesting all ;; the way over to the side, or using some weird keyword language. (when-let [a foo] (let [b bar c (when (even? b) baz)] (when (and c ( b c)) (f a b c qux ;; or (when-let [a foo] (let [b bar c (when (even? b) baz) d (when (and c ( b c)) qux)] (when d (f a b c d Keep your constructs simple, and learn to love the nil. Also, people have been writing lisp for a real long time, and they haven't invented a chucklehead macro like let? yet, so prolly not really needed to improve the readability... -- Craig Brozefsky cr...@red-bean.com Premature reification is the root of all evil -- 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
Re: Can Clojure be as readable as Python or Ruby ?
I’m not sure that just adding counter responses to almost all Mark points really help. Most counter arguments here resume to you are doing it wrong and all clojure 'warts' are here to force you to better design. Indeed some kind of code is more readable when written in an imperative way than functional way. Like some kind of code is more readable when written in a functional way. This depend what kind of code you want/need to write and that a strong point for supporting both style in same language. Clojure try to avoid imperative code style... Honestly I’m not sure if avoiding all imperative code is a good idea or not... I need more experience in clojure and lisp like language to have a good opinion on that point. But anyway I enjoy clojure as it is today. Mark, I would say using a few well designed macros you can make clojure feel a lot more like you want to. That would be interesting to see and experiment on. Have a nice day, all! Nicolas. On 8 mar, 08:37, Sean Corfield seancorfi...@gmail.com wrote: On Wed, Mar 7, 2012 at 5:10 PM, Mark Engelberg mark.engelb...@gmail.com wrote: * introducing variables creates new indenting level, making code creep to the right Mitigated by breaking functions into sub-functions (which is good practice anyway). * as code creeps to the right, you need to have a lot more newlines Then your code is too deeply nested and should be broken into sub-functions. That's standard best practice across all languages. * The convention of using hyphens to separate words is hard to read I disagree. I find camelCase far harder to read than hyphenated-names. * loop/recur is significantly less readable I don't think it's significantly less readable but I do agree that recur is a bit of a wart. * cond branches are sometimes written with the test and the answer on the same line, or when the test gets too long you have to write it with the test and answer on subsequent lines; this inconsistent formatting can make it hard to know in long blocks whether you are looking at the test or the answer Don't write long blocks. Don't write complex conditions. Introduction more sub-functions. * Interweavings of cond and let (a common pattern) end up ridiculously indented and hard to read See above (and I don't agree it's a common pattern... perhaps an anti-pattern?). * Decades worth of classic algorithms involving imperative manipulation of arrays look significantly uglier in Clojure Yet many algorithms are significantly cleaner in a pure functional style... * Expression-oriented syntax (along with the indenting cost of using let) encourages people to pack far too much into one line rather than giving names to intermediate results. Again, poor style. Break things into sub-functions. * DSLs are supposed to bring customized readable notation to many tasks, but by the time you include namespace prefixes and colons for all the keywords, DSLs don't really look that good. Then those DSLs are not achieving their design goals. DSLs are a good use case for :use or :require/:refer. * ... But when I read someone else's compact higher-order stuff, it's usually a nightmare to try to interpret what it is doing. Really? I find the compaction outweighs the effort involved - as long as the code is modular enough (see comments above). * And the number 1 problem with all Lisps is that when you look at Lisp code, it's a sea of sameness. Function applications, Macros, Control constructs, bindings, data lookups, etc. all look exactly the same. I actually find that to be a plus - there's no distracting variance that artificially makes things different that don't need to be. Syntax is very subjective. It's really good to here your pro-Python thoughts tho'... -- 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
Re: Bret Victor - Inventing on Principle
The talk was really enligthing... but I would say it is still research. While I can trust you can make, say an intuitive and reactive UI for flash like animations, I think there are still problems to take care of for the program example. Here this is just a simple algorithm without long calls inside, without access to external systems or mutable state. All kind of things that would simply fail to work properly in pratice. I can see this as an evolution of unit testing and debugging. You still need to mock dependancies and take care to build input data to test your program. But in exchange you can check interractively execution outcome and intermediate steps and tweak it until it provide the required result. You could then ask to generate the proper unit test because well all information is already available. But making this kind of UI fluid and easy including a way to properly specify your mocks (and what is not mocked) is going to be complex... But I agree, functional languages that tend to favor pure functions really help there. On 27 fév, 19:44, Colin Yates colin.ya...@gmail.com wrote: Amazing. The lesson for me (which has echoes of the 'hammock driven design' message) is that sometimes the best ideas come not from evolutions of existing answers but starting completely from scratch. As techies, we sometimes (I think) restrict ourselves to improving our existing solutions which in effect restrict our solution space to our own (sometimes inferior) answers. For example, I doubt any of his answers came as an improvement to existing IDEs - they are new creations. Hmm - not sure I made that clear - I learnt a lesson anyway. Excellent points and I certainly found the video inspiring. Good link! Col On Friday, 24 February 2012 18:29:06 UTC, Damien wrote: Hi Everyone, You may have seen this already, if not I believe it's worth investing 1h of your life: http://vimeo.com/36579366 That's already a good candidate for the technical talk of the year, if not the decade IMO. Ok, I'm getting a bit too enthusiastic here but this is so inspiring. After watching it, you can't help thinking that we have a whole new world to invent. As a side note, you may start thinking that a REPL is not good enough. - Personal message to Laurent Petit: please watch and start thinking about CCW 1.0 ;o) - It also feels like ClojureScript is on the right path. But, most importantly, beyond any technical consideration, the last part is a great life lesson. -- Damien Lepage http://damienlepage.com @damienlepage https://twitter.com/#%21/damienlepage linkedin.com/in/damienlepage http://www.linkedin.com/in/damienlepage -- 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
Re: Question about this little method I wrote
Hi Mike, If I understood your aim correctly, and if you accept changing the output of (combinations [[1 2]]) to ((1) (2)) instead of (1 2), which I think makes more sense,then the reduce function does the job in one line for you. (defn combinations [items] (reduce #(for [l % i %2] (conj l i)) [[]] items)) the same, wordier and maybe clearer: (defn combinations [items] (reduce (fn [output item] (for [o output i item] (conj o i))) [[]] items)) and if you really need the output to be a list of lists instead of a list of vectors, maybe something like: (defn combinations [items] (map seq (reduce #(for [o % i %2] (conj o i)) [[]] items))) Btw, I learned an awful lot about compact ways of doing stuff in Clojure by doing the exercises (and checking others' solutions) on 4clojure.com, which I warmly recommend. Nico On Feb 27, 3:45 am, Mike Ledoux mike.led...@gmail.com wrote: So I recently decided to start learning Clojure. I installed Clojure box and wrote this little method to compute all possible combinations of input: (defn combinations [items] (if (== (count items) 1) (flatten items) (for [frstitems (flatten (first items)) tlitm (combinations (rest items))] (flatten (list frstitems tlitm) so (combinations [[1 2] [1 2]]) returns ((1 1) (1 2) (2 1) (2 2)) Is there a way I can get rid of the if form? Having the if statement duplicates what the for loop does when it creates frstitems. I tried removing the if statement so the function looks like: (defn combinations [items] (for [frstitems (flatten (first items)) tlitm (combinations (rest items))] (flatten (list frstitems tlitm but when I do this the function just returns an empty list. I tried to figure out why using the REPL but did not discover the problem. Is what I'm asking possible and if so what would the function look like? Thank you. So far Clojure is pretty cool! Mike -- 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
Re: clojure-opennlp
Just for the record, it seems this issue has been fixed today: https://github.com/dakrone/clojure-opennlp/commit/887add29a1fbc3b4aac7d12f5cbc52c43c6a7dcd Try out the the new 0.1.8 version. On Feb 11, 9:20 am, Jim foo.bar jimpil1...@gmail.com wrote: HI everyone, I was just wondering whether anyone has used the clojure-opennlp wrapper for multi-word named entity recognition (NER)? I am using it to train a drug finder from my private corpus and even though i get correct behavior when using the command line tool of apache openNLP when trying to use the API i only get single-words entities recognised!!! I've opened up a thread in the official mailing list because initially i thought there was a genuine problem with openNLP but since the command line tool does exactly what i want i'm starting to think that it might not be openNLP's fault but either in my code or in the clojure wrapper... I've followed both the official tutorials and the wrapper documentation and thus i am doing everything as instructed... I know the name finder expects tokenized sentences and i am indeed passing tokenized sentences like this: (defn find-names-model [text] (map #(drug-find (tokenize %)) (get-sentences text))) It is very strange because i am getting back Folic but not Folic acid regardless of using the exact same model i used with the command line tool... Any help will be greatly appreciated... Regards, Jim -- 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
Re: Need help to translate a simple java program into Clojure program
Thanks a lot to all of you. Regards, Nicolas On 10 jan, 08:14, Brian Mosley brian.d.mos...@gmail.com wrote: Oops. A possible solution might look something like 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Need help to translate a simple java program into Clojure program
Hi, Finally I managed to write my program, see below. It is probably not optimized at all (I had some issues with vector concatenation..) but at least it does the same as my java program. Thanks again! Regards, Nicolas (defrecord Pos [name value] Object (toString [this] (str Name: name , Value: value ))) (def options [(Pos. IBM, -50) (Pos. ACCOR, -30); (Pos. IBM, -10); (Pos. APPLE, -20); (Pos. AIRFRANCE, -20)]) (def actions [(Pos. IBM, 55) (Pos. ACCOR, 40) (Pos. AIRFRANCE, 10) (Pos. LUFTHANSA, 100)]) (defn matchOneOptionWithOneAction [options actions x y] (if ( = (:name (get options x)) (:name (get actions y))) (let [sum (+ (:value (get options x)) (:value (get actions y)) )] [ (reduce conj (reduce conj (subvec options 0 x) (vector (Pos. (:name (get options x)) (min 0 sum (subvec options (+ 1 x) (.length options)) ) (reduce conj (reduce conj (subvec actions 0 y) (vector (Pos. (:name (get actions y)) (max 0 sum (subvec actions (+ 1 y) (.length actions)) ) ] ) [options actions] ) ) (defn matchOptionsWithActions [options actions x y] (if (= x (.length options)) [options actions] (if (= y (.length actions)) (matchOptionsWithActions options actions (+ 1 x) 0) (let [matchCouple (matchOneOptionWithOneAction options actions x y)] (matchOptionsWithActions (get matchCouple 0) (get matchCouple 1) x (+ 1 y) ) ) ) ) ) (defn matchIt [options actions] (matchOptionsWithActions options actions 0 0 ) ) (let [[matchedOptions matchedActions] (matchIt options actions) ] (println matched options: (map str matchedOptions)) (println matched actions: (map str matchedActions)) ) On 10 jan, 09:35, Nicolas Garcin nicolas.etienne.gar...@gmail.com wrote: Thanks a lot to all of you. Regards, Nicolas On 10 jan, 08:14, Brian Mosley brian.d.mos...@gmail.com wrote: Oops. A possible solution might look something like 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Need help to translate a simple java program into Clojure program
Hello,
I'm new to functional programming and Clojure and I'm trying to
translate a simple java program into Clojure. My program must build
from 2 input lists (stored in a vector) 2 output lists (also stored in
a vector) which have same number of elements as input lists for both
output lists. The elements' values of the output lists will be the
result of a very simple arithmetical calculation based on input lists'
elements.
Since my java program iterates on lists, I wanted to use a 'higher
order function' in the Clojure version of the program (like the 'map'
function). But I didn't manage to write the equivalent program in
Clojure.
Could someone please help me?
Below is the java program that I'd like to translate.
Thanks a lot,
Regards,
Nicolas
// first file (these are the elements of my lists):
public class Pos {
public String name;
public int value;
public Pos(String newName, int newValue) {
name = newName;
value = newValue;
}
@Override
public String toString() {
return Name: + name + , Value: + value + \n;
}
}
// second file that contains the method I'd like to translate using a
higher order function (method called match):
import java.util.ArrayList;
import java.util.List;
import java.util.Vector;
public class Matching {
public static void main(String[] args) throws Exception {
ListPos options = new ArrayListPos(5);
Pos option1 = new Pos(IBM, -50);
Pos option2 = new Pos(ACCOR, -30);
Pos option3 = new Pos(IBM, -10);
Pos option4 = new Pos(APPLE, -20);
Pos option5 = new Pos(AIRFRANCE, -20);
options.add(option1);
options.add(option2);
options.add(option3);
options.add(option4);
options.add(option5);
ListPos actions = new ArrayListPos(4);
Pos action1 = new Pos(IBM, 55);
Pos action2 = new Pos(ACCOR, 40);
Pos action3 = new Pos(AIRFRANCE, 10);
Pos action4 = new Pos(LUFTHANSA, 100);
actions.add(action1);
actions.add(action2);
actions.add(action3);
actions.add(action4);
VectorListPos input = new VectorListPos(2);
input.set(0, options);
input.set(1, actions);
System.out.println(Options: + options);
System.out.println(Actions: + actions);
VectorListPos res = Matching.match(input);
System.out.println(Options: + res.get(0));
System.out.println(Actions: + res.get(1));
}
public static VectorListPos match(VectorListPos
optionsAndActions) {
if (optionsAndActions == null) {
return optionsAndActions;
}
if (optionsAndActions.size() 2) {
return optionsAndActions;
}
VectorListPos modifiedOptionsAndActions = new
VectorListPos(2);
if (optionsAndActions.get(1) == null) {
modifiedOptionsAndActions.add(0, new
ArrayListPos(optionsAndActions.get(0)));
return modifiedOptionsAndActions;
} else if (optionsAndActions.get(0) == null) {
modifiedOptionsAndActions.add(1, new
ArrayListPos(optionsAndActions.get(1)));
return modifiedOptionsAndActions;
}
ArrayListPos modifiedOptions = new
ArrayListPos(optionsAndActions.get(0));
ArrayListPos modifiedActions = new
ArrayListPos(optionsAndActions.get(1));
modifiedOptionsAndActions.add(0, modifiedOptions);
modifiedOptionsAndActions.add(1, modifiedActions);
for (Pos option : modifiedOptions) {
for (Pos action : modifiedActions) {
if (option.name.equals(action.name)) {
int tempActionValue = Math.max(0, action.value +
option.value);
int tempOptionValue = Math.min(0, action.value +
option.value);
action.value = tempActionValue;
option.value = tempOptionValue;
}
}
}
return modifiedOptionsAndActions;
}
}
--
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
Clojure/ClojureScript code and refs
I'm thinking about writing some code that would better be transactional and thus use refs in a multi-threaded environment like Clojure. But then it would also be nice to be able to run that code as ClojureScript code (which obviously doesn't support refs) so I'm wondering if anybody has worked on that kind of problem. Would encapsulating refs operations inside macros that detect if refs are available and if not would fall back to a simple atom (ignoring transactional stuff and replacing alter/commute by swap!) be a good way? -- 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
Re: Proposal: libraries should have type hints
Hi !
An interresting point of clojure is that it is dynamically typed. This
for a reason. There is a tradeoff in performance but the benefit is
that the code is shorter, more expressive and reusable.
Type hinting should be exceptionnal and used only in critical areas
when you see a huge boost in performance. And if you need this boost.
I think then that's the library author responsability and own right to
figure by himself where ultimate performance is needed or instead
where greater flexibility is to be prefered.
Bye,
Nicolas.
On Nov 21, 5:12 pm, Tassilo Horn tass...@member.fsf.org wrote:
Herwig Hochleitner hhochleit...@gmail.com writes:
Hi Herwig,
In principle you're right. But you have to keep in mind, that type
hints actually alter runtime behavior.
A hinted call tries to cast its argument into the desired type,
possibly resulting in a type cast exception. An unhinted call, on the
other hand, just looks for the signature.
So in essence a hinted call can fail for cases where an unhinted call
succeeds, effectively reducing composability at a type level
(polymorphism).
Hm, indeed. This function works for any java object that has a
zero-parameters doubleValue() method.
(defn double-val [x] (.doubleValue x))
In contrast,
(defn double-val [x] (.doubleValue ^Integer x))
will fail for (double-val 7), because by default any integer is a Long
in Clojure 1.3. However, one could go with
(defn double-val [x] (.doubleValue ^Number x))
instead, and that works fine for Integer, Long, Double, ... But of
course, it's not applicable for
class Foo { String doubleValue() {return foo;} }
whereas the non-type-hinted version is. Note that this doubleValue()
method doesn't even return a double.
But is that really an issue? I mean, since you cannot use such duck
typing in Java itself (except in terms of reflection), any method
defined for more than one class with shared, consistent semantics is
declared in some common parent class or interface which you can use for
your type hint.
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes,http://tinyurl.com/3y9l2kf
--
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
What is the cost of calling require for something that already have been loaded?
I'm using a function in Lobos to automatically load the backend code associated to a specific database and wonder if I should track what is loaded to avoid repeatedly calling `require`? This isn't an issue currently as performance isn't a problem for this library, but this might change in the future. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
question about cons function
Hello, I'm a new Closure user and I'm wondering why the 'cons' function applied on a vector returns a list. Ex: user= (def v1 [:one :two]) #'user/v1 user= (cons :three v1) (:three :one :two) user= Thanks for your help, Regards, Nicolas -- 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
Re: Lazy behavior
Hi, I'am not really sure on your explanation here. For me if the processor, JVM or clojure compiler cannot prove it doesn't change the semantics, the optimization will not be applyed. readLine behing a java method call, it can perform any operations and thus clojure compiler will not change the execution order (or number of calls to it). I agree that some clojure functions explicitely expect that no side effect will be performed to perform futher optimizations, but then it is stated in the documentation. On Nov 1, 11:33 am, Ingo ingo.wechs...@googlemail.com wrote: The problem with the direct call of the readLine() method is that it might not work some day like it appears to work today. Specifically, the meaning of your program depends on: - evaluation order the compiler chooses - the fact that the compiler obviously does not do common subexpression elimination in this case, maybe because it sees that readLine() is not pure, but who knows. -- 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
Re: Lazy behavior
I have done futher experimentations and have found that, if I call directly readLine method, it work like a normal stream: (let [reader (java.io.BufferedReader. (java.io.FileReader. liars.txt))] [(.readLine reader) (.readLine reader) (.readLine reader) (.readLine reader)]) = [5 Stephen 1 Tommaso Tommaso 1] You see that there is no immutability that come into play. BufferedReader being a mutable java object work as intended. So it is just that if I make a lazy sequence of it with repeatedly, I create an immutable object, and thus experiment the behavior of my previous post. What would be the best (idiomatic and efficiant) solution then? - wrap my file under a lazy sequence, call take drop recursively with recur - just call readLine method directly when I need more lines and process them. The second doesn't seems clojurish while I'am not sure on the memory usage implications on the first for the lazy sequence. Any insights? Best Regards, Nicolas On 1 nov, 01:09, nchurch nchubr...@gmail.com wrote: The problem you're having doesn't have anything to do with file reads. Every time you call (take 5 data), you're calling it on the same item 'data'; your variable 'data' doesn't change between each call. The chief thing you have to understand about Clojure is that variables never change. Never. If you want 'change' you need to use refs, atoms, etc. So for instance if you wrote (let [x (iterate inc 1)] [(take 5 x) (take 5 x)]) you'd get [(1 2 3 4 5) (1 2 3 4 5)] You need to make the next call on the \rest of the sequence, which you can get by calling (drop n data). Then your processing function could be something like (loop [x data] (your-processing-function-here (take 5 x)) (recur (drop 5 x))) That will walk right through the sequence or the file or whatever you have (if it's infinite, make sure to write a terminating condition, e.g.: (loop [x (iterate inc 1)] (print (take 5 x)) (if ( (first x) 50) nil (recur (drop 5 x ) On Oct 31, 2:53 pm, Nicolas bousque...@gmail.com wrote: Hi everybody! I'am experimenting with clojure and as an exercice I use the facebook puzzles (http://www.facebook.com/careers/puzzles.php?puzzle_id=20) Most puzzles require to read from a text file efficiently. So I try to not read the full file at a time, but process it lazily. For that I made a very small helper library that try to benefit of lazy sequences: ;Pattern instances are immutables and thread safe (def split-pattern (java.util.regex.Pattern/compile \\s)) (defn split-words [string] Split the provided string into words. Separators are space and tabs (if (nil? string) nil (vec (remove #(.equals % ) (.split split-pattern string) (defn read-text-file [file-name] Read a text file, line per line, lazily returning nil when end of file has been reached. Each line is a vector of words (let [reader (java.io.BufferedReader. (java.io.FileReader. file- name))] (map split-words (repeatedly #(.readLine reader) (defn next-line [lines] (first (take 1 lines))) So basically, a file is a lazy sequence of lines, and each line is a vector of words. Lazy behavior seems to be working at first, it I write: (let [data (read-text-file liars.txt)] (take 5 data)) - ([5] [Stephen 1] [Tommaso] [Tommaso 1] [Galileo]) It correctly return the 5 first lines of my file. Perfect that's exactly what I want. But when really using it, it doesn't work. If I call several time the take function, it always return the first lines instead of providing the next ones: (let [data (read-text-file liars.txt)] [(take 5 data) (take 5 data)]) =[([5] [Stephen 1] [Tommaso] [Tommaso 1] [Galileo]) ([5] [Stephen 1] [Tommaso] [Tommaso 1] [Galileo])] If I call take 10 directly, it works as expected: (let [data (read-text-file liars.txt)] (take 10 data)) =([5] [Stephen 1] [Tommaso] [Tommaso 1] [Galileo] [Isaac 1] [Tommaso] [Galileo 1] [Tommaso] [George 2]) You would say, why not just take all data from the stream and then process it? Well the file has a specific format, first line contain some data, then few next line contain another data and so on. So I want to have a function that will read only a subpart of the file for example, another function another part and call them sequentially. But as shown in the simple previous example it simply doesn't work. My understanding is that some immutable thing is in the middle and it act like the data reference isn't changed between calls. That not what I want obviously as I'am getting data from a java stream, that is not supposed to be immutable. And how can I manage correctly this kind of cases? Efficiantly and idiomatically. Thanks in advance, Nicolas. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure
Re: Trickiness with protocols and extends (1.3.0)
Hi ! For clojure, a type or a record, represent data. A protocol represent a set of linked polymorph functions. But protocol themselves are not types. Just grouped functions. The types is what they apply on. Not what they are themselves. You can view each method of a protocol like a big swich function that test the type of it first argument and choose the right implementation of the function depending of the type of this first argument. Type can be extended to support a protocol. By doing that you define the call that will be called when you call the protocol function with a first parameter of the extended type. Type is a record or a type. For java interop support, it can be also any java class/interface. Clojure intentionnaly avoid support for inheritence. A record/type can't inherit from another record/type. And protocol can't be extended to another protocol. Because in clojure this would made no sence. A function can't inherit from another function. This is by design. Clojure avoid to support inheritence for clojure concepts. It only support for java interop because this might be needed for interfacing with an existing java library (Like swing listeners). In your example, extending cascade.Asset work because it is considered as a java interface, and is supported for interoperability. But this is likely not what you really want to do as Asset is still not a clojure type. Hope this help, Nicolas On 28 oct, 19:46, Howard Lewis Ship hls...@gmail.com wrote: I'm hitting a bit of frustration with (defprotocol) and friends and I'm hoping someone can enlighten me: Context: this is part of the Cascade layer I'm building on top of Compojure. It's all about rendering markup, borrowing ideas from Tapestry. I have a protocol that represents Assets: any kind of static resource that can be exposed to the client via a URL, such as a JavaScript library or stylesheet: (defprotocol Asset Represent a server-side resource so that it can be exposed efficiently to the client. (^InputStream content [asset] Returns the content of the Asset as a stream of bytes, or null if the Asset does not exist.) (^String client-url [asset] Returns an absolute URL to the Asset.)) Cascade builds a DOM tree before streaming; one step of that is to convert attribute values inside DOM nodes into strings. (defprotocol ToAttributeValueString Converts an attribute value to a string. It is not necessary to apply quotes (those come at a later stage). (to-attribute-value-string [value] Converts the value to a string that can be safely streamed as an attribute value.)) (extend-protocol ToAttributeValueString String (to-attribute-value-string [string] (encode-string string)) Number (to-attribute-value-string [num] (.toString num)) Keyword (to-attribute-value-string [kw] (encode-string (name kw Now, I want Assets to be used as attribute values, so: (extend-type Asset ToAttributeValueString (to-attribute-value-string [asset] (:client-url asset))) But this fails with: Exception in thread main java.lang.IllegalArgumentException: Unable to resolve classname: Asset, compiling:(cascade.clj:84) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6416) at clojure.lang.Compiler.analyze(Compiler.java:6216) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6397) at clojure.lang.Compiler.analyze(Compiler.java:6216) at clojure.lang.Compiler.analyze(Compiler.java:6177) at clojure.lang.Compiler$MapExpr.parse(Compiler.java:2782) at clojure.lang.Compiler.analyze(Compiler.java:6224) at clojure.lang.Compiler.analyze(Compiler.java:6177) at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3503) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6411) at clojure.lang.Compiler.analyze(Compiler.java:6216) at clojure.lang.Compiler.analyze(Compiler.java:6177) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5572) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5008) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3629) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6407) at clojure.lang.Compiler.analyze(Compiler.java:6216) at clojure.lang.Compiler.eval(Compiler.java:6462) at clojure.lang.Compiler.load(Compiler.java:6902) at clojure.lang.RT.loadResourceScript(RT.java:357) at clojure.lang.RT.loadResourceScript(RT.java:348) at clojure.lang.RT.load(RT.java:427) at clojure.lang.RT.load(RT.java:398) at clojure.core$load$fn__4610.invoke(core.clj:5386) at clojure.core$load.doInvoke(core.clj:5385) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5200) at clojure.core$load_lib.doInvoke(core.clj:5237) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core
Re: repl output for list seems inconsistent and a holdover from yesteryear
Hi!
Well [1 2 3] is just a syntaxic sugar for (vector 1 2 3):
=(vector 1 2 3)
[1 2 3]
When you enter a vector in the repl, it is evaluted to itself. Here an
example that show it:
=[1 2 (+ 1 2)]
[1 2 3]
And you can use the vector function for the same result:
=(vector 1 2 (+ 1 2))
[1 2 3]
The quote prevent evaluation but this is not specific to lists:
='[1 2 (+ 1 2)]
[1 2 (+ 1 2)]
The way to make function calls in lisp (and in clojure) is to consider
the first element of the list to be the function, and the next one to
be the argument of the function. This what happen when you perform say
an addition
(+ 1 2) is a call to the add function with 2 parameters.
But this mean that you can't define a list (data structure) just by
writing it, because it will be evaluated. To prevent this, maybe the
best solution is to use the list function, that return a list with its
arguments.
=(list 1 2 3)
(1 2 3)
You see the consistency here. As vectors are contructed with vector
function. Notice calling the list function is very different that
using a quote:
=(list 1 2 (+ 1 2))
(1 2 3)
='(1 2 (+ 1 2))
(1 2 (+ 1 2))
This mean that you might not want to use quote everywhere just to say
'here is a list data structure'.
The preference for vectors as data structure when possible is to make
code more lisible. Using a list is just adding more parens, in a
language with lot of parens. Doesn't help the reading.
Using syntaxic sugar for vector, on the contrary help the reading.
On 27 oct, 01:08, e evier...@gmail.com wrote:
not necessarily.
[1 2 3] is a vector that is not evaluated. Since there is no overload with
things that are, there's no need for a special mark.
'(1 2 3) is currently a way of say, don't evaluate this list, but it could
have been:
'(1 2 3) is a list that is not evaluated. No loss of generality. it's a
special type of list. One that's not evaluated. as opposed to a special
indicator to the repl.
On Wed, Oct 26, 2011 at 6:09 PM, Mark Rathwell mark.rathw...@gmail.comwrote:
The point to think about here is that functions are also lists, the
same as your list of integers. The difference is that one is
evaluated, the other is not. That is what the quote is saying: don't
evaluate me. The quote is not actually a part of the list. It's just
the way you tell the reader not to evaluate the list that follows.
So the question is should all unevaluated forms be preceded with a
quote in the repl output? To me that would be more confusing.
On Wed, Oct 26, 2011 at 5:34 PM, e evier...@gmail.com wrote:
long long time since I last looked a clojure, but I've never lost
interest and I'm trying to find the time again.
for the short version see *INCONSISTENT*, in the example at the end.
I know what the answer will be here. Something like you will get
used to it. or it's not important. or no one hardly uses lists
anymore, anyway, since vectors are not purely contiguous. But, if
you can make things better and it's easy, then why not?
So here's the deal:
I still think the following is only inconsistent because that's how it
was in older lisps. Specifically, lists had to be quoted so the first
argument wouldn't be called as a function. I asked long ago (here and
in person) why, then regular functions couldn't require the quote so
the paren could be reserved for the list data structure, and Rich
answered that it'd simply be a pain to have to quote every function
call. Well, my mind moves slowly. I'm just now realizing to ask,
Ok, then how about making the list really be defined using the single
quote as part of it just like sets include the sharp to distinguish
them from maps?. That's a much simpler explanation than saying, you
have to escape them, etc, etc. I realize this is a small matter since
all I am talking about is how lists are represented as text.
checking out the Try Clojure:
if you type the following, you get output that matches what you typed
in every case except for lists.
Vectors: -- [1 2 3 4]
[1 2 3 4]
Maps: -- {:foo bar 3 4}
{:foo bar 3 4}
Lists: -- '(1 2 3 4)
(1 2 3 4) - *INCONSISTENT* why not render this as '(1 2 3 4) ...
this would make much more sense to newbies.
Sets: -- #{1 2 3 4}
#{1 2 3 4}
--
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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
Re: Blog post declare type implements protocol feature
Yes you need to provide an implementation of the protocol for the type directly or a parent interface. What the initial author says is that you can do that on any type, even on an outside library, without changing the initial Type source code or recompile it. You can do that at runtime and because protocol are namespace, there is no risk to replace by error an already existing method with the same name in the class. In java to do that you would need to modify the class itself or make a proxy through inheritence or implementing a common interface. On Oct 26, 1:42 am, Brent Millare brent.mill...@gmail.com wrote: I recently read the article http://www.colourcoding.net/blog/archive/2011/10/25/clojure-is-a-get-... and it mentions in the Better than a better java section, that Compojure defines a protocol called Renderable that allows you to specify how return types get converted into Ring responses. Now, you could apply an adapter pattern in most languages to link these two up. In Clojure, you can declare that a type implements a protocol and it*just works*. You don’t need to extend the type; you don’t need to monkey patch it; you don’t need to introduce a proxy object under your control. What does the author mean by don't need to extend the type but only need to declare that a type implements a protocol? I am familiar with extend, and extend-type, or extend-protocol, but not JUST declaring a type implements a protocol and it magically works. From what I know, you always have to specify the implementation, even if the implementation is simply delegating it to some other function. Best, Brent -- 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
Re: Reactions to google dart?
For me the real meaning of this is that support for new features in closure library will stop in its actual form in the years to come. Only bugs will be corrected, no more. This is already the case in a sence I think, because before Dart, GWT was viewed as the new official way to make new web applications at google. Closure library is not where google put effort for new developpments. GWT somewhat failed on some aspects and now google is betting on Dart. For short term, this change nothing to us. In the long term we might have to choose between staying on a legacy library (closure library in JS form) or compile to Dart instead of JS. For raw clojure script code, this would not be very important. As the semantics could be preserved. But call to APIs might change quite a lot. New APIs under Dart might have really different behavior than actual closure library. Like in a sence GWT API is already totally different beast than closure library. Long term this might mean that instead of compilling to raw JS and having a dependancy on closure library, we might choose to compile to raw Dart and use new Dart APIs. In a sence to keep with the with the latest trend and benefits of latest features. This is not the only choice, as long as the closure compiler from google is working and there are not too many bugs in closure library, there is no real problem. As this is open source, nothing prevent us to fix things ourselves if needed... Maybe we are more interrested by the compiler itself and by the low level closure API providing access to all browser features (DOM...) than using cutting edge API that will not be idiomatic clojure anyway. If we want more idiomatic libraries, we will have to make them ourselves anyways. My 2 cents... On Oct 11, 4:43 pm, Timothy Washington twash...@gmail.com wrote: What I have in mind is not related to Dart, but to the support of Closure Tools from Google. Will Dart javascript compatibility layer/javascript compilation for non-Chrom(e)(ium) browsers include the Closure Tools Suite ? 2011/10/10 David Nolen dnolen.li...@gmail.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
Re: Macro tutorials?
A good book to learn lisp macros, is On Lisp from Paul Graham. This book really cover advanced topics and concepts, and has many chapters related to macros. The book is freely available in online format from Paul Graham Website: http://www.paulgraham.com/onlisp.html On Oct 6, 1:02 pm, Michael Jaaka michael.ja...@googlemail.com wrote: Thanks to all! You have helped a lot! Also I will consider reading Practical Common Lisp. On Oct 6, 9:42 am, Stefan Kamphausen ska2...@googlemail.com wrote: Hi. You might consider reading Peter Seibel's excellent Practical Common Lisp which has some nice macro-work in it. If after that you're still hungry for more, consider Let Over Lambda by Doug Hoyte. Admitted, both cover Common Lisp, but the differences will not keep you from getting a deeper understanding of how macros work and where and how they can be used. (This is more an answer to the subject of this thread, less to the question in your body :) Regards, Stefan -- 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
Re: producing Blub code and vv.
Hi, Well many will agree that if you can find a good solution to this problem this is going to be usefull. I tend to agree too. The question is maybe can you find a good solution? My response would be no. Let me explain: From a theoretical point of view you can always translate one turring complete language to one another; But if you do that you really miss the point of using clojure instead of blurb. Clojure isn't theorycally better. It is not. Every thing you can do in clojure you'll be able to do in any blurb language, at soon at it is turing complete. So this include cobol, vhdl or SQL. If it was easy to transform easilly back and forth to idiomatic blurb language that would mean that there is some sort of bijection between all idiomatic feature of clojure and blurb. But the whole point of using clojure instead of blurb here is because clojure is a better or at least different language. With more interresting abstractions than one available in blurb, at least for a specific problem domain. So the bijection is not here. To have this bijection the blurb language would need to be clojure with a different syntax. We could think about common lisp but even there... Immutability and persistent collection could be enough to make the translation not idiomatic at all. And this only for the language. A language is just one part of the problem. You also need the libraries. For example GWT team had to support a good subset of Java API to make GWT usable. To transform back and forth would mean that you'll need a common API for both language, that is an API that would not be idiomatic for at least one of thoses language. More than being not idiomatic this would be an API thoses of blurb would not be used to. Maybe all of this is possible. After all an human can do it manually. But I see it as more a research topic than engineering topic. With low probability of sucess. It is a good thing to work on it then when many things aren't here yet for clojure? Best Regards, Nicolas. On Sep 30, 5:48 am, Hank h...@123mail.org wrote: I think the major obstacle is likely to be the difference in idioms. Any substantial idiomatic piece of Clojure is going to be almost impossible to automatically translate to _idiomatic_ code in another high-level language that uses different idioms. That could very well turn out to be the case. In the spectrum between fully manual and fully automated I can picture scenarios like: - Mostly manual but with some automatic assistance from the IDE: E.g. the way Eclipse assists you in coding Java, when you press Ctrl+Space. It doesn't automatically write code for you but it can narrow down the choice as to what to type next. - Most automatic but with some manual assistance from the coder: E.g. annotate the Clojure code with hints about the idioms to translate to in the target language. Right now in Clojure we use annotations like :exposes-methods that aren't strictly for the Clojure functionality itself but for Java interop. So there could be annotations like :use-design-pattern-x that dictate the choice of idiom/design pattern in the compilation to the target language. You'd also probably have to introduce a number of coding conventions to constrain your Clojure code in order to avoid holes in the translation. It's probably a question of how unwieldy the produced code is allowed to get. If you express the goal of maintainability in terms of some metric like lines of code or whatever then I can see hard limits being reached. If you don't put a limit on that then I don't see any danger of holes. Some questions: * How do you translate Clojure functions in namespaces spread across multiple files into a Java class? [...] Those are very good questions and I'd have to think about it. Maybe I'll start a wiki somewhere so we can start collecting translation recipes. Generally, if the answer isn't obvious from staring at the Clojure code, it helps to think about the problems in terms of the bigger picture, i.e. the business logic/domain knowledge, and then translate to Blub in the head. E.g. I want to cache generated web pages on the disk, how would I do this in Java? * How would code that uses STM translate to a Blub without it? I like this one in particular. People have written concurrent code before STM. I do it in my job every day. :) How did that work with explicit locks again?? * How idiomatic would Blub code be when Clojure uses immutable data by default? A good source for this is the O'Reilly book Functional Programming in Java. There you can see how idioms from one language can be applied to another. I think Java code that uses a lot of immutable data, i.e. final variables all around, would still be accepted by the Java community. The produced code could even leave out the final keyword in order to not cause too much clutter but still not modify the variables. It violates the principle of least authority but I see
Waiting for swank-clojure to be ready.
Hi, I'm currently redoing my Clojure setup and I wonder how to make Emacs wait for swank-clojure to be ready before calling slime-connect. I've added a shortcut to start swank-clojure: (global-set-key [f8] '(lambda () (interactive) (start-process swank-clojure swank-clojure ~/.lein/bin/swank-clojure) ;; should wait for swank-clojure to be ready (slime-connect 127.0.0.1 4005))) but I don't have any idea how to do the waiting part. -- 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
Re: Waiting for swank-clojure to be ready.
Thanks, this was really helpful. Here's what my shortcut looks like now: (global-set-key [f8] '(lambda () (interactive) (start-process swank-clojure *swank-clojure* ~/.lein/bin/swank-clojure) (set-process-filter (get-buffer-process *swank-clojure*) (lambda (process output) (when (string-match Connection opened on output) (slime-connect localhost 4005) (with-current-buffer (slime-output-buffer t) (setq default-directory root)) (set-process-filter process nil)) On Mon, Oct 3, 2011 at 8:33 PM, Phil Hagelberg p...@hagelb.org wrote: On Mon, Oct 3, 2011 at 5:12 PM, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I'm currently redoing my Clojure setup and I wonder how to make Emacs wait for swank-clojure to be ready before calling slime-connect. You can use M-x clojure-jack-in, but that only works for Leiningen projects out of the box. The other place I'd look is M-x durendal-jack-in, which was its mostly-deprecated precursor. It has a less comprehensive bootstrap mechanism, but if you've already got slime-repl installed then that shouldn't be an issue. https://github.com/technomancy/durendal/blob/master/durendal.el#L82 -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 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
Re: suggestion for clojure development
I think that backward compatibilities problem do hurt. Some people will not invest in an unstable language by default and some will be tempted to give up after experimenting too many problem with it. We don't choose a language,we choose a full echosystem that include libraries, IDE tooling, documentation, community, long term support. So this is more a question of tradeoff between having the best possible language and breaking or not backward compatibility. But I would say that clojure is not made for the masses. (Java/C# are for that). Clojure is more for geeks/hackers/searchers that love computer science and want a fun language to work with. Clojure core team did a great job ensure that clojure has a good reach in term of platform (JVM, CLR, browsers) and also to bring the best possible language. So the problem should be from what ecosystem, language combination you benefit most. Clojure bring outstanding expressivity and consision to programs. It allow very expressive DSLs and bring interresting concepts toward managing shared state. For me this is more than enough to consider clojure as a very viable alternative. On Sep 29, 2:54 am, Michael Gardner gardne...@gmail.com wrote: I don't think there will (nor should) ever be a declaration by the core team that from this point onward, we will never break backwards compatibility. There's always a trade-off between maintaining backwards compatibility and making improvements to the language. Naturally, as the language matures the tradeoff will shift towards compatibility, but in my opinion it would be foolish to set anything in stone. I don't think the lack of any such promise has hurt Python, for example; and while the transition to 3.0 certainly seems to have been slow and painful, I don't doubt the language will survive. -- 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
Re: producing Blub code and vv.
Clojure has native interoperability with JVM CLR. This mean that you can have part of your code written in Clojure, part in Java/Jython/ JRuby if your target the JVM or C# if you target CLR. Of course you'll not be able to mess everything like first half of a method in Clojure, second half in java but this is going to work. Clojurescript might bring you interroperability with JS too. The best blurb language then is going to be java because support for it is part of the clojure design. But adding a new arbitrar language to this equation is going to be very costly. Also you don't only want interroperability you want to have a translation to idiomatic blurb code and back to idiomatic clojure. There is no offering for this right now and this would need lot of time to do it properly. And from my understanding, I see no other language that bring such support you ask for. This is not a feature that clojure lack. Maybe its me, but I do not see it as a a top priority for clojure language. We already have support with JVM, CLR. If required to any language through a network protocol. With Java/Clojure combination you can do nearly everything and have library for nearly everything too. Life is great ! On 29 sep, 12:39, Hank h...@123mail.org wrote: Hi, I'd like to check the interest in the community for a comprehensive Clojure library/framework/whathaveyou that helps produce Java/Python/ Ruby/... a.k.a. Blub (http://www.paulgraham.com/avg.html) code, i.e. instead of writing a Clojure program that e.g. produces web pages, writing a Clojure program that produces a Blub program that produces web pages. A Blub program in idiomatic, maintainable, efficient Blub code that is. This is obviously to enable cooperation on shared domain knowledge/business logic across communities with mixed Clojure/Blub language preferences that I expect will continue to exist for decades. Full cooperation would then also require the framework to produce Clojure code that embodies functionality embodied in Blub code. I'd expect that bit to be harder to realize but also more valuable, as it would allow drawing not only on the body of work done in Blub for reasons of preference but also on legacy code from the dark ages when there was no Clojure. I'm asking this especially in light of the upcoming Clojure Conj where there would be an opportunity to discuss this complex subject in a high bandwidth :) kind of way. Searching this group I haven't found much along those lines other than isolated problems being tackled -- the question here rather being: What's the furthest the the envelope can be pushed in terms of co- opting the Blub world? Hank -- 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
Re: Using Clojure to Generate Java Source?
Best would be to act as professionnal: - try to convince your new boss of the benefits of using clojure from a business point of view. - if this fail, either go back to writing java or quit. But do not try to abuse your boss and company by developping in clojure behind the scene and deliver some crappy generated java. This would be a legitimate reason to be fired. On 29 sep, 20:09, Dennis Crenshaw crensha...@gmail.com wrote: I'm in a bit of a bind-- I've written some really nice Clojure code for dealing with Genomic sequences that works as well or better than the reference implementation we currently use where I work. However, the the hierarchy has recently changed and my new boss is requiring me to have all code in Java (eg. interop is not an option since he wants the source to be pure Java.) Is there any way to prevent my head exploding from hand-translating my Clojure code into Java? I'm sure it's possible to generate Java source since we heard Rich's amusing anecdote about using Clojure to write reams of Java boilerplate instead of doing himself. Is there a precedent or even an existing library for translation from Clojure into Java source though? I'd like to be able to use the code I've got without a long, painful devolution. More importantly, I want to be able to continue developing in Clojure and just compile it to Java source and check that in. Thanks, Dennis -- 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
Re: suggestion for clojure development
On Sep 28, 1:30 pm, Gary Poster gary.pos...@gmail.com wrote: On Sep 28, 2011, at 1:26 AM, Sean Corfield wrote: Perhaps Java has been different, but the languages I use and follow have not, with the exception of JavaScript. I perceive it to be a mildly unfortunate fact of life at this point. Gary Java is backward compatible. You know that by default you can run old legacy code on lastest JVM without problem. This is one of the reason JAVA is so successfull in enterprise world, you can take code from year 2000, run it on latest VM, and the only change is that this code will run dramatically faster. Clojure itself really benefit from java popularity and stability. Imagine if clojure couldn't run JVM7 without a significant effort to update clojure compiler ! This is also a reason why JAVA has difficulties to have latest and greatest features and to inovate... Java fail to really improve. I think that clojure/core team is doing its best to ensure backward compatibility and break it only when there are prevalent reasons to do 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
Re: On Lisp with Clojure
I would rather say difficult than impossible... and maybe not that important. After all JVM is turring complete. If scheme can do it compiling down to machine code, clojure could do it compiling down to JVM bytecode. On Sep 7, 1:54 am, Brian Goslinga quickbasicg...@gmail.com wrote: On Sep 6, 11:20 am, Michael Jaaka michael.ja...@googlemail.com wrote: Btw. it looks like Clojure is missing an ability to program reader. It would allow to program a syntax. This is by design as there is no good way to namespace syntax. The tail recursion and continuations also would be awesome. Those aren't provided because the tight integration with the JVM makes it impossible. -- 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
Re: New to Clojure -- Errors Are Frustrating
On 3 août, 03:00, Mark markaddle...@gmail.com wrote: The compiler might not be able to do better but the runtime system certainly could. In this case, both filtered and more information is what's needed. Why couldn't the runtime generate a message like: Symbol fac of type clojure.lang.IFn is used where type java.lang.Number is expected in #2 operand to function * Of course, if this information were structured in some well-understood way, IDEs could consume the error and do an awfully good job of putting the cursor on exactly where the error is occurring. When I code in clojure, IDE assistance for situations like this is probably the thing that I miss the most. I agree that it would make us more effective. But honestly, before that, I tend to find my clojure ide, to be very lacking. If I type CTRL-SHIFT-T I can search for java type instantly but auto completion in the editor for exampel take more than 10 seconds. -- 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
Re : Re: novel feedback is always welcome
y I'am tThe main point for me of this whole discussion is that someone should use clojurescript if he want to use clojure instead of javascript on the browser. Like GWT, JWT, ZK or other, you do not longer develop in the client language. You develop in a different language and compile/generate down/use internally JS under the wood. The whole thing is abstracting things away. Like you don't care in java about CPU registers, x86 instruction set or even allocating memory. The JVM and java abstract it for you. So there no point as of idiomatic javascript, better OOP model, bad part or good parts. Like one don't care how the x86 code generated by JIT look like, one don't care the look of generated javascript. In fact this discussion is not new. Like you on clojurescript, some developers in the sixties were thinking that assembly language was important, that higher level language were not usefull and that the generated code should look like beautiful handcrafted code. Today processors intruction set are made for compilers, not programmers and most of us don't care much about assembly code anymore. You can think that idiomatic JS is indeed better than clojurescript. Then don't use clojure. Even by using Jquery or Crawford best pratices, clojurescript will always feel clojure, not like JS. That the essence of clojure. And if you don't like it, there isn't much to argue. You may not like closure library and prefer jquery. That's fine. But we are not in JS. And in fact closure library with it's strong namespace and convention, with it's compiler is a good fit. In particular because Closure is not idiomatic javascript and much more java-like that it fit clojure that well. You don't like closure library, and that was by design... like you don't like closurescript decision, but it is by design too. In fact nobody use closure library except google... But nobody is able to produce advenced browser client UI except google. Maybe the design of clojurescript is not so bad after all? We can argue all we want. But it's time to make decision. It time to use your brain. If you fail to understand/embrace/love clojurescript, no one will care. We can't change people. Maybe clojurescript is really useless and serve nobody interrest and you are on the right side. Maybe you totally missed the point and you humor decision to give will make you lose years and limit your comprehension of computer science and software engineering. In the end what you choose, what we choose just concern ourselve individually, not others. Many will make mystake and will be persuaded to have done the right choice anyway. But that's life. The more likely is we are all wrong anyway, maybe some a little less wrong than other, nothing more. Me think clojurescript is exactly the type of think I need and want to use. And I'am happy. Me don't want to use jQuery instead. Me prefer that you fork or make your design if you are serious about it. So all the bad things remains in your repository and hopefully nobody will be forced to use it. Have a nice day. -- 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
Re: Monadic implementation of the Shunting-yard algorithm
On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote: I wrote a simple implementation: http://gist.github.com/953966https://gist.github.com/953966 (only supports operators) It's not very elegant (I don't know how to use fnparse..), but it is functional. What it does is find out what the next element in the operator stack and the out stack should be, and then recursively update the stacks and output the finished out stack. As I said I don't know how to use fnparse and therefore I couldn't really understand your code. Either way I hope that this code helps in some way.. ;) This is great, hadn't thought about using a protocol for this! I'll improve both versions to be able to compare them on equal ground and to see how they cope with adding more features. Although in the end, I think the recursive one will be faster while the monadic one will be more composable, 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
Re: Monadic implementation of the Shunting-yard algorithm
One small question, how would you modify your version to output s-expressions? -- 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
Re: Monadic implementation of the Shunting-yard algorithm
I've refactored your code into this: https://gist.github.com/954579 On Tuesday, 3 May 2011 15:02:02 UTC-4, odyssomay wrote: I wrote a simple implementation: http://gist.github.com/953966https://gist.github.com/953966 (only supports operators) It's not very elegant (I don't know how to use fnparse..), but it is functional. What it does is find out what the next element in the operator stack and the out stack should be, and then recursively update the stacks and output the finished out stack. As I said I don't know how to use fnparse and therefore I couldn't really understand your code. Either way I hope that this code helps in some way.. ;) Jonathan On Tue, May 3, 2011 at 2:23 AM, Nicolas Buduroi nbud...@gmail.com wrote: Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written the following implementation of the Shunting-yard algorithm: https://gist.github.com/952607 I plan to make a lightning talk about monadic parser at the next Bonjure meeting and I'd like to hear what people here think about that implementation first. It is more imperative that I would like, but that is the nature of this algorithm I think. Would a non-monadic implementation would be better in some ways? How would you make this code more flexible, faster and/or cleaner? Is there a more functional way of writing it? Thanks in advance for any comments! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To 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
Monadic implementation of the Shunting-yard algorithm
Hi, I'm working on my parsing skills using fnparse 2.2.7 and have written the following implementation of the Shunting-yard algorithm: https://gist.github.com/952607 I plan to make a lightning talk about monadic parser at the next Bonjure meeting and I'd like to hear what people here think about that implementation first. It is more imperative that I would like, but that is the nature of this algorithm I think. Would a non-monadic implementation would be better in some ways? How would you make this code more flexible, faster and/or cleaner? Is there a more functional way of writing it? Thanks in advance for any comments! -- 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
Re: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
On Tue, Apr 26, 2011 at 2:16 PM, lispnik burnsid...@gmail.com wrote: ...Liquibase so I can get rollbacks and branching easily. Off-topic question: What does branching mean in the context of Liquidbase? I suggest not getting into the SQL in sexps/naming strategies business. That kind of thing doesn't really fall under the scope of JDBC, which clojure.java.jdbc should be modeled around. I'm with you on that one. The row as a structmap works well. 90% of the time I use use select foo_bar as \foo-bar\... to get a Clojure-ish map key. Other 10% I might also have to apply a transformation to the row, especially when working with legacy databases. I thought having something like: (with-query-results rs transform-fn [ ... params...] (first rs)) So that by the time I call (first rs), transform has already been applied, but (map transform-fn rs) is trivial enough also. Is that good enough for you: https://github.com/clojure/java.jdbc/issues/7#issuecomment-1060402 I could always add an extra optional argument to with-query-results. -- 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
Re: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
On Mon, Apr 25, 2011 at 12:23 PM, Michael michael-a...@db.com wrote: I was wondering if c.j.jdbc could provide some help in composing sql fragments, but I'm not sure what form it should take or if core clojure would suffice. We would have looked into ClojureQL, but it doesn't directly support Oracle. Would also be curious to know how people use clojure to compose sql fragments. For Lobos I've written a compiler which transform an AST into SQL DDL statements. You can have a look at the compiler here: https://github.com/budu/lobos/blob/master/src/lobos/compiler.clj It's based on the legacy ClojureQL project, I've written some helpers but it's mostly using Clojure string facilities. So I'm not sure it would be a good idea to include such helpers inside c.j.j, outside the as-identifier function here: http://dev.clojure.org/jira/browse/CLJ-778 As for the new ClojureQL project, it would certainly be feasible to add support for Oracle, but I find it hard to work with its current simplified compiler. I've tried to add stropping to ClojureQL multiple times, but gave up in the end. -- 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
Re: Intro to Live Programming with Overtone
Overtone really looks awesome, looking forward to use it! Thanks for the video. -- 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
Re: clojure.contrib.sql = clojure.java.jdbc - looking for feedback!
I'm going to be working on clojure.java.jdbc, with Steve Gilardi, and I'd like to get people's feedback on what you like / what you don't like / what you need changed or added in clojure.contrib.sql so that clojure.java.jdbc can become what the community wants for 1.3.0. What I would like to see added is a global connection mechanism like in ClojureQL and Lobos. We could even add a connection pool behind the scene. Then there's support for quoted identifiers, maybe something like: (with-quoted-identifiers \ ...) And for qualified identifiers we could let c.j.j accept vectors of identifiers so that [:some_schema :a_table] would become some_schema.a_table. I could provide an implementation if you'd like. -- 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
Re: ANN: pallet.thread-expr, a macro lib for use with - argument threading
This is a very interesting set of macros, I'll certainly use some of them. In fact I think this library should at least make it to clojure.contrib! BTW, there's a small error in the when-not- docstring, the result should be 1. -- 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
ANN: Lobos 0.7, a SQL database schema manipulation library
Hi, I've released version 0.7 of Lobos today, enjoy it. I've posted a more comprehesive announcement on the new Lobos Google Group: https://groups.google.com/forum/#!topic/lobos-library/mTL9HLiHOrA If you have questions, suggestions, comments or insults please post them there. For those who hadn't heard about Lobos before this post (most of you I suppose) feel free to visit one of the following link: Website: http://budu.github.com/lobos/index.html GitHub Repo: https://github.com/budu/lobos Google Group: http://groups.google.com/group/lobos-library Future announcements will be only posted on the Lobos Google Group. 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
Reading back record instances
I've been using records extensively lately and I think they are a really great addition to Clojure. One problem I'm facing tough is to read them back once printed to a file (or anything else). All others Clojure data structures are supported by the reader, but not records. One way to do this would be to write my own printer to output constructor forms for the given records. That should be working as the current implementation returns the keys in order. Am I missing something? Is there a better way? Regards, budu -- 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
What's the best way to hide transaction error output from contrib.sql
By design contrib.sql, when executing a batch of commands, uses transaction and if an exception is raised, it is printed to the error output stream. This is very practical but when you are using such code in a test that is meant to throw an exception it adds a lot of noise to the tests output. I was thinking about solving this by redirecting the error output stream, but then it might hide some errors I'd like to know about. Does anyone have a better solution to this (minor) issue? -- 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
Re: REPL+Laziness: the worst combination ever!
Didn't knew about scope, it looks like an interesting feature. Still as you point this is pretty much a problem BKAC! On Jan 8, 12:33 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: One goal of resource scopes [1] is to help with scoping activities at the REPL. That said, I think this is a ramping up problem -- I rarely if ever hit it anymore. Stu [1]http://dev.clojure.org/display/design/Resource+Scopes I've been doing a lot of Clojure lately and, of all thing, collection's laziness coupled with a REPL is what makes me loose the most time. I really love having laziness built-in by default and I'm a REPL-driven development addict, but sometimes I just loose minutes (if not hours) chasing imaginary bugs that in the end only were a misuse of laziness at the REPL. Still, I can't think of any way of fixing this problem other than writing on top of my monitor: If it doesn't make sense it's certainly because of laziness. I wonder what other people think about this problem? P.S.: While writing this I just got an idea, but I'm not really sure it's a good one. Would it be wise to make the binding macro force evaluation of its body? That would be the most common mistake I make. -- 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 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
Re: REPL+Laziness: the worst combination ever!
On Jan 8, 12:25 pm, Brian Goslinga quickbasicg...@gmail.com wrote: I find that if your code is functional, laziness works quite well (except for the rare expensive function + chunking problem). Perhaps your code isn't very functional? (your mention of binding suggests that) That's a valid observation, most of the time I hit that kind of problems, I'm using code that really isn't functional. But the reason it's not functional is mainly to make it more practical while used at the REPL, so I've mostly fallen victim to a catch-22! -- 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
REPL+Laziness: the worst combination ever!
I've been doing a lot of Clojure lately and, of all thing, collection's laziness coupled with a REPL is what makes me loose the most time. I really love having laziness built-in by default and I'm a REPL-driven development addict, but sometimes I just loose minutes (if not hours) chasing imaginary bugs that in the end only were a misuse of laziness at the REPL. Still, I can't think of any way of fixing this problem other than writing on top of my monitor: If it doesn't make sense it's certainly because of laziness. I wonder what other people think about this problem? P.S.: While writing this I just got an idea, but I'm not really sure it's a good one. Would it be wise to make the binding macro force evaluation of its body? That would be the most common mistake I make. -- 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
Re: ANN: ClojureQL 1.0.0 now released
Congratulation, you've finally made it! P.S.: Nice job on the website! On Jan 5, 9:14 am, LauJensen lau.jen...@bestinclass.dk wrote: Hey everybody, Just a quick heads up that ClojureQL 1.0.0 is now released. All interfaces should be final and there are no known bugs. Works out of the box with PostgreSQL and MySQL but the compiler is a multimethod so you can implement your own backend if you need to work with other database backends. If you do so, please consider contributing it to ClojureQL :) All the info is found onhttp://www.clojureql.orgbut for those of you who haven't tried it out yet, I recommend watching this (dated) video:http://vimeo.com/16958466 Big thanks to everybody who has helped make this happen, Lau -- 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
Working with protocols
Hi, I've been working lately on my first project (https://github.com/
budu/lobos) that use protocols. Up until now, it's been quite
infuriating, I can't stop getting seemingly random No implementation
of method exceptions and I really don't understand why.
For example here's what happened this morning. In this project I have
a Creatable protocol that contains only one method: create. It is
currently implemented by two records: Table and Schema. I realized I
hadn't updated the example in the readme file and while testing that
code it threw an error because I changed stuff yesterday and the
object passed to the create method was a function. I call it a second
time, after fixing (at the REPL) that mistake, and there was a bug in
my code when calling create on a MapEntry instead of a Table. I fixed
(in the file) that issue and after that all I get when trying out the
same call is No implementation of method for the Schema class. I
review the code (it should work), try stuff and here's the really
strange thing:
user (create (schema :test {}) nil)
#:lobos.ast.CreateSchemaStatement{:cnx nil, :sname :test, :elements
()}
user (create (sample-schema) nil)
; Evaluation aborted.
user (type (schema :test {}))
lobos.schema.Schema
user (type (sample-schema))
lobos.schema.Schema
I wasn't able to narrow down what is the problem exactly. The only way
I found to fix that kind of problem is the kill the JVM and restart
the whole thing. This is just one example, a lot of similar situations
happened during the past few days. It may be related more to my
development environment or the way I'm using it. I'm using Clojure 1.2
and swank-clojure 1.2.1 in Emacs from which I connect to a swank
instance launched from Leiningen. I'm using the REPL to test my code
and after I've changed a file I use slime-eval-buffer. I wonder if
there's some general issues with this setup or advices on working with
protocols that can help me?
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
Re: Working with protocols
On Dec 22, 1:03 pm, David Nolen dnolen.li...@gmail.com wrote: (Foo.) is a Java method call determined at compile-time. If you change the definition of the Foo type/record, create-foo will be out of date. Default constructor fns could alleviate this but I think some design/modularity issues need to be hashed out. Yes, I've realized this when developing this project. At first, it was less modular and I encountered much more of such issues. I also used `immigrate` previously and that was causing troubles not only with protocols, but with multimethods also. In the end there still appears to be some problems while developing protocol based code in a REPL- driven fashion. I was hoping I did something wrong that somebody could point out. P.S.: It makes me wonder if there's some improvements that can be done to make that type of coding more REPL friendly. -- 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
Re: Catching ClassNotFoundException.
Cool, that explain everything. Thanks On Dec 16, 4:40 am, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 16.12.2010 um 04:16 schrieb Nicolas Buduroi: So we could always use RT/classForName to detect what classes are available. Do you think the extend-type thrown exception can possibly be fixed or is it a fundamental limitation? I think the problem here is „when“ not „where.“ The „extend-type“ exception is thrown when the expression is compiled because the compiler tries to resolve the class. But the try catch is not in effect at that time: it just gets compiled! Using RT/classForName moves the class resolution to the runtime and everything works fine. You could do something like (try (load file/with/extend-type) (catch ClassNotFoundException uhOh ...)). Sincerely Meikel -- 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
ANN: clj-help 0.2.0 released
Hi, I've been using this small project to get some help while working at the REPL. It's a macro that regroups into one command a set of useful functions from contrib libraries while auto-quoting it's arguments. It's quite simple to use, after loading it (use 'clj- help), you only have to type (help) to print it's usage: Usage: (help query ...) macro - Pretty prints the macro expansion of the given form. clean - Remove a namespace (and used vars) from the given namespace, or *ns* if none. source - Prints a string of the source code for the given symbol show - Prints all instance members of the given class with an optional int, string or regex selector. info - Analyzes the given s-expr and prints the class of the value it returns. dir - Prints a sorted directory of public vars in the given namespace, or *ns* if none. cp - Prints all files in the classpath, accept 'jars' or 'dirs' as optional argument. pp - Evaluates the given form and pretty prints its result. docs - Prints documentation for the public vars in the given namespace, or *ns* if none. Most of these already existed in the previous version. This time, I've added the clean query which remove a namespace and all it's used vars from a specified namespace. It can be useful while experimenting back and forth between two version of a same API and you used use for some reason. If you have any repetive REPL idioms which you think could be generally useful, I would be pleased to add it. Any ideas, corrections or comments would be welcome. 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
Re: ANN: clj-help 0.2.0 released
It appears I've forgotten to include some essential information to this announcement! ;-) git repo: https://github.com/budu/clj-help leiningen: [clj-help 0.2.0] On Dec 15, 6:23 pm, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I've been using this small project to get some help while working at the REPL. It's a macro that regroups into one command a set of useful functions from contrib libraries while auto-quoting it's arguments. It's quite simple to use, after loading it (use 'clj- help), you only have to type (help) to print it's usage: Usage: (help query ...) macro - Pretty prints the macro expansion of the given form. clean - Remove a namespace (and used vars) from the given namespace, or *ns* if none. source - Prints a string of the source code for the given symbol show - Prints all instance members of the given class with an optional int, string or regex selector. info - Analyzes the given s-expr and prints the class of the value it returns. dir - Prints a sorted directory of public vars in the given namespace, or *ns* if none. cp - Prints all files in the classpath, accept 'jars' or 'dirs' as optional argument. pp - Evaluates the given form and pretty prints its result. docs - Prints documentation for the public vars in the given namespace, or *ns* if none. Most of these already existed in the previous version. This time, I've added the clean query which remove a namespace and all it's used vars from a specified namespace. It can be useful while experimenting back and forth between two version of a same API and you used use for some reason. If you have any repetive REPL idioms which you think could be generally useful, I would be pleased to add it. Any ideas, corrections or comments would be welcome. 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
Catching ClassNotFoundException.
Hi, is there a way of catching ClassNotFoundException? Using try..catch doesn't work! 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
Re: Catching ClassNotFoundException.
Yeah, while doing more testing it seems to depend from where the ClassNotFoundException is thrown. What I was trying to do at first is to call extend-type on a Java class only if it exists. Surrounding extend-type by a try..catch clause doesn't work here. So I tried to simply type: user (try org.postgresql.PGConnection (catch ClassNotFoundException e :catched)) ; Evaluation aborted. And, as you see, the try..catch didn't work either. But I just found out that when using Clojure internal classForName method it can be catched: user (try (clojure.lang.RT/classForName org.postgresql.PGConnection ) (catch ClassNotFoundException e :catched)) :catched So we could always use RT/classForName to detect what classes are available. Do you think the extend-type thrown exception can possibly be fixed or is it a fundamental limitation? On Dec 15, 9:27 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Can you post an example? (try (throw (ClassNotFoundException. What makes you say that?)) (catch ClassNotFoundException e (println (.getMessage e Hi, is there a way of catching ClassNotFoundException? Using try..catch doesn't work! 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 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
Re: Any demand for ClojureCLR support under slime / emacs?
I'm interested, can't provide much programming help in this area tough. I could always help test it. On Dec 12, 6:36 pm, Mike K mbk.li...@gmail.com wrote: I really, really want ClojureCLR to play nice with emacs the way Clojure does. I've looked at the swank-clojure sources, but I really don't know enough about the Clojure and ClojureCLR internals to make much headway with this project. Still, I'd love to help out in any way that I can. Is anyone else out there interested in such a project? Mike -- 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
Re: (ab)using STM for longish calculations, network I/O
dosync is a way of ensuring whole stateful operation is done atomically. (ie as if everything was happening in one step.) That contradicts b). During a whole dosync, you can only see one state of the world. If you do not need atomicity, do multiple dosync. You should create another abstraction for the retry part of the problem. (retry is an artifact of the non-blocking atomicity. If it fails, we need to restart) Interesting read if you do not know it already: http://clojure.org/state Best, Nicolas. -- 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
Re: precise numbers
Another proof:
Let study the sequence sn = 0....9 , with n 9s.
Or s0= 0 and s(n+1) = sn + 9 / 10 ^n
lim sn = 0.9...
and lim sn = 1.
so
If I remember my meth correctly,
the number 0... does not exist.
This not a legal decimal sequence.
(Any decimal sequence finishing by .. is forbidden to allow a
one to one mapping between real numbers and
decimal sequence.)
This kind of infinity is one of the reason equality is not devidable
on real numbers.
You can manipulate square root directly. For example by defining
numbers as a map from ratio to ratio.sqr
sqrt(5) is represented by {5 1}
sqrt(5) + 3. sqrt(2) by {5 1 , 2 3}
15 + sqrt(3) {1 15, 3 1}
adding is just a reduce of one map into the other.
neg is a map.
multiplying is more complex. For each two pairs in the map
[a b] [c d], you check wether (ac) can be written as sqr(e).f
(For example 2 * 6 can be written as sqr(2)*3)
If it is the case, you return [f (* e b d)]
else you return [(* a c) (* b d)]
Dividing is more difficult.
I don't know if it is the most efficien way to do that, but it is the
easiest to code.
Best,
Nicolas.
--
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
Re: generator in Clojure
(defn iterate [s] (let [a (atom s)] (fn [] (let [s @a] (reset! a (next s)) (first s)) but it's not very idiomatic in clojure. (In Lisp it is traditional to hide a state in a closure. A lot of toy object language work like that) On Thu, Oct 14, 2010 at 9:38 PM, Moritz Ulrich ulrich.mor...@googlemail.com wrote: Are you sure you need to capture the state in next-sine? It's not very clojure-ly to have functions with state. I would capture the state in the caller as an integer and just use get or nth on the lazy seq. If you want to stick to your impure function, please mark it with a ! at the end: next-sine! On Thu, Oct 14, 2010 at 9:52 PM, clwham...@gmail.com clwham...@gmail.com wrote: I need a function that produces the 'next' value from a lazy-seq -- something like a Python generator. I imagine it would have to be some sort of closure like: (def next-sine (let [sines (atom (cycle (map sin (range 0 6.28 0.01] #(swap! sines rest))) Is there a more idomatic way of doing this? I don't see a lot of use of closures in clojure... -- 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 -- Moritz Ulrich Programmer, Student, Almost normal Guy http://www.google.com/profiles/ulrich.moritz BB5F086F-C798-41D5-B742-494C1E9677E8 -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: precise numbers
On Tue, Oct 12, 2010 at 8:35 PM, cej38 junkerme...@gmail.com wrote: The more that I think about it, the more I would rather have a set of equalities that always work. float= was a good try. The only way to do so is to have numbers with infinite precision. For example as lazy-seq of their digits. But: - it is slow - equality is semi-decidable only. -- 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
Re: precise numbers
If you want to be really precise, most real numbers are an infinite number of decimals. If you encode them as a lazy seq of decimals, + - and other ops are doable. Comparison is semi-decidable only: it terminates only in certain case (finite number of decimals) or when the number are different. big-decimal or fractions are a good approximation, though. -- 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
Re: clojure-cake
I had a similar error last time I tried. Didn't manage to solve it. On Fri, Oct 8, 2010 at 10:49 AM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: I forgot to mention the versions... My cake version is 0.4.18 and ruby version is ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux] On Fri, Oct 8, 2010 at 3:17 PM, Sunil S Nandihalli sunil.nandiha...@gmail.com wrote: Hello everybody, I am trying to use cake .. was just exploring it with a very simple default cake new expcake cake deps but cake deps gives me the following error http://gist.github.com/616564 can anybody suggest as to what could be going wrong? Thanks, Sunil. -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
There is no java definition for (Number, long) or (Number, int). As 1 is now a primitive, I think it cannot find any corresponding function. Strangely, putting 1M or (num 1) might be faster. Can someone try? On Fri, Oct 1, 2010 at 10:28 AM, David Powell djpow...@djpowell.net wrote: So, if it is true that range produces objects and dotimes produces primitive longs, then I believe that it is the odd interaction between bit-shift-left's inlining and long objects (as opposed to primitives) that is causing the disparity in your measurements, not something inherent in the mechanism of doseq vs dotimes. [Oops - sorry for the blank email] I notice, that If you enable *warn-on-reflection*, you can see that a call using the inline version gets compiled as a reflective call. If you remove the inline definition, no such reflective call is made. Not sure why this is. -- Dave -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: Clojure 1.3 alpha 1 report - bitwise operations extremely slow
David pointed out what should have been the obvious overhead (I'll blame it on being up at 2am), and Nicolas pointed out the specific problem. two solutions: - writing all combinations of unboxed/boxed for every function - having a more clever code generator that try to box every primitive if it allows to prevent a reflective call. (And maybe emit a boxing warning) -- 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
Re: anonymous fn or partial?
The two styles are ok. Matter of taste. (partial ...) have probably a slight cost I wouldn't worry about except if profiler tells me to worry. The (partial...) style is called point-less, because you directly manipulate the arrows and not the points. It is the same kind of question as : should you use composition or call (f (g x))? Should I use the do-monad notation or a clever combination of m-bind, map, and composition? No good answer. Do what you like best in each situation. If you want to have something looking like (+ 2) with multiple args possible, I would advocate the best way might be to add a reader macro to clojure expanding to partial. #p(+ 2) for example. It is a better idea than using having evaluation depending of the context, IMHO. -- 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
Re: question regarding macro (ab)usage
I hadn't time to read the whole post, but, I I understand it well, this snipset
(defmacro with-context [options body]
`(let [context# (create-context options)
thread# (create-thread context)
sources# (atom {})
receivers# (atom {})]
(binding [init-receiver (partial init-receiver-on context# receivers#)
init-source (partial init-source-on context# sources#)
publish (partial publish-on context# sources#)
receiver (partial receive-on context# receivers#)]
(try
(do ~...@body)
(finally
... close stuff, cleanup)
can be written more or less:
(defn with-context [options action]
(let [context ..])
(binding [init-receiver .]
(try (action) (finally )))
That can be called with
(with-context options #(body))
You can then wrap this call in a macro to remove the #().
I am not sure it is a good idea, but it is always good to know for
which precise feature you need the macro.
Here tou need it to prevent to have to pass some code around as a function.
That's one frequent usage of macro, it can help readability and (very
little) performance.
But depending of the situation. you might want to trade these
advantages for composability and ease of programming.
Best,
Nicolas.
--
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
Re: How often do you use REPL?
On Tue, Sep 28, 2010 at 12:03 PM, David Cabana drcab...@gmail.com wrote: My standard practice is to split the (Emacs) screen, one side is a Clojure mode edit session, the other a repl. Best of both worlds. One can easily build up complex expressions as required, and still easily evaluate expressions in either side of the screen. Same here. Dream of having a bigger screen to have more than one file and a REPL. Use REPL all the time to test function and to try expression while waiting complex functions. -- 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
Re: Hiccup with Sequence
doseq do not return anything. (It is for side-effect only). You might be looking for 'for'. (doc for) - clojure.core/for ([seq-exprs body-expr]) Macro List comprehension. Takes a vector of one or more binding-form/collection-expr pairs, each followed by zero or more modifiers, and yields a lazy sequence of evaluations of expr. Collections are iterated in a nested fashion, rightmost fastest, and nested coll-exprs can refer to bindings created in prior binding-forms. Supported modifiers are: :let [binding-form expr ...], :while test, :when test. (take 100 (for [x (range 1) y (range 100) :while ( y x)] [x y])) On Mon, Sep 27, 2010 at 11:25 AM, Paul paul_bow...@yahoo.com wrote: Hi all, I'm trying to output the items from a sequence into a HTML list using the Hiccup HTML builder, but am having problems. Here is the code I think 'should' work, but nothing after the ':ul' is passed back to the response: (html [:html [:body [:ul (doseq [item myseq] [:li item]) ] ] ] ) Can anyone see why this is not working? Thanks, Paul. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: Macro expansion problem
Difficult problem. macro are syntactic tools. So they are not made to evaluate things at runtime. You could expand to something that call eval at runtime but it is not a good idea (It involves the compiler at each call) If your (rest alist) is known at macro-expansion time, then it can work but to help, I would need to know the context in which you are using it. What you want to do would be done by apply for functions. However, as far as I know, apply do not work on method calls. If you look at the problem from the java point of view, it is quite hard to write some code that call a method with an unkown number of argument without using reflection. If you have a fix number of argument, you can do this: (defmacro call-5 Calls an instance method on a given object with a list of params. [obj method-name params] `(apply (fn [x1# x2# x3# x4# x5#] (. ~obj ~(symbol method-name) x1# x2# x3# x4# x5#) ) ~params)) You can also write a macro that takes the arity as a parameter and do that trick. You can also generate an anonymous function with multiple arity `(apply (fn ([x1#] (. ~obj ~(symbol method-name) x1# )) ([x1# x2#] (. ~obj ~(symbol method-name) x1# x2#)) ([x1# x2# x3#] (. ~obj ~(symbol method-name) x1# x2# x3#)) ... up to enough (20 should do the trick) ~params) However, ti might be easier to explain what you are trying to achieve in a bigger context to see if there is a simpler path. Best, Nicolas. On Mon, Sep 27, 2010 at 6:52 AM, stefanmuenchow stefanmuenc...@gmx.de wrote: I am a macro newbie... I want to create a macro that calls a function with a given name and a parameter list on a given object. My first idea was like this: (defmacro call Calls an instance method on a given object with a list of params. [obj method-name params] `(. ~obj ~(symbol method-name) ~...@params)) It works fine, if the param list is a simple list, like (1 2 3 4), but if params is created from an existing list, like (rest alist) then it doesn't work. So params has to be evaluated first and then the single params has to be expanded. How do I do that? I tried it with a let block then I got other errors. -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: Some code dramatically slower in Clojure 1.3 Alpha 1?
Your code was simple enough for me to make a couple of educated guesses. For more complex code I'd use VisualVM, https://visualvm.dev.java.net/ David I use that too. Sampling for a first look, profiling with instrumentation for a more precise answer. (Here, the sampling gives even? and the profiling gives the reflection methods) -- 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
Re: finding value nearest x
On Sat, Sep 25, 2010 at 3:40 PM, Jules julesjac...@gmail.com wrote: Maybe this: (min-key #(abs (- % 136)) xs) Wouldn't that be (apply min-key #(abs (- % 136)) xs)? -- 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
Re: Some code dramatically slower in Clojure 1.3 Alpha 1?
After profiling even seems effectively the culprit. Some method reflector shows up too. On Fri, Sep 24, 2010 at 6:15 PM, David Nolen dnolen.li...@gmail.com wrote: (defn next-term [n] (if (= (mod n 2) 0) (/ n 2) (inc (* n 3 (defn count-terms [n] (if (= 1 n) 1 (inc (count-terms (next-term n) (time (let [pair (juxt identity count-terms) pairs (map pair (range 1 10))] (println (first (apply max-key second pairs) It looks even? is the culprit here. The code above executes in 1 sec on my machine. So it looks like even? needs to repaired to account for the numeric changes. David -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: Some code dramatically slower in Clojure 1.3 Alpha 1?
Try
(defn even?
Returns true if n is even, throws an exception if n is not an integer
{:added 1.0
:static true}
[n] (zero? (bit-and (long n) (long 1
before your example.
It is fast on my computer.
(I believe there is a reflective call, without the explicit cast.)
--
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
Re: Isn't STM good at building an ant colony?
If you have a fixed geometry of cells, it is quite easy to have one ref per cell. Which reduce a lot of contention. For example, on a grid where ant can go instead of representing the world as a ref to a matrix, you can represent the world as a matrix of refs. Those refs can then be update concurrently. Provided there are a lot of cells and not too much contention, iti should work well. On Sun, Sep 19, 2010 at 11:01 PM, Hozumi fat...@googlemail.com wrote: Hi. I posted following question. The more threads that changes the Clojure's ref are, the more does the rate of retries per threads rise? http://stackoverflow.com/questions/3746893/the-more-threads-that-changes-the-clojures-ref-are-the-more-does-the-rate-of-re I think increasing retries in O(thread^2) means that refs should not be used to store the data that is aletered by too many threads like big ant colony map or newral network nodes. If modifying the data by too many threads is planned, instead of refs, are agents best way to store it? Any other solution? Thanks. Takahiro Hozumi -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: why the big difference in speed?
A first good start is to put (set! *warn-on-relection* true) at the start of the file and removes all reflective access. Before the 1.3 release, function cannot receive/returns primitive so you might consider (defmacro next-gaussian [] `(.nextGaussian ^Random r)) (^Random is here to make sure r is seen with the right type) in both function, add ^doubles before arr at the binding point. (defn ... [^doubles arr]) then set will not be rflective and be as fast as a set in java. Ask other questions of you need more help. The best reference on all that: clojure.org/java_interop On Sun, Sep 19, 2010 at 3:29 PM, Ranjit rjcha...@gmail.com wrote: Hi, I'm trying learn Clojure to see if I can use it in my simulations, and one thing I need to do is generate arrays of normally distributed numbers. I've been able to come up with the following two ways of doing this. gaussian-matrix2 is a lot faster than gaussian-matrix1, but I'm not sure why. And it's still slower than it should be I think. Is there anything I can do to speed this up still further? Thanks, -Ranjit (import java.util.Random) (def r (Random. )) (defn next-gaussian [] (.nextGaussian r)) (defn gaussian-matrix1 [arr L] (doseq [x (range L) y (range L)] (aset arr x y (next-gaussian (defn gaussian-matrix2 [L] (into-array (map double-array (partition L (repeatedly (* L L) next-gaussian) -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: partition-starting-every : yet another partition function
I was just saying that not returning something that is a pair, for example nil, is good enough. (unfold (fn [x] (when (= x 10) [(* x x) (inc x)])) would work. Both function can be written with each other anyway. And they don't have the same number of args so they are compatible with each other. On Thu, Sep 16, 2010 at 8:05 PM, Gijs S. gijsstuur...@gmail.com wrote: Finished is a predicate which designates when the seed is exhausted. Because seed is not necessary a sequence, finished is not always empty?. For instance: = (unfold (fn [x] [(* x x) (inc x)]) #( % 10) 0) (0 1 4 9 16 25 36 49 64 81 100) Or the zipmap (zip2) example from the wikipedia page. Although the first example wanders back into territory where the existing sequence functions such as iterate, take-while and for would suffice. -Gijs -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: partition-starting-every : yet another partition function
(defn unfold ([grow seed] (lazy-seq (if-let [[elt next-seed] (grow seed)] (cons elt (unfold grow next-seed) ([grow finished? seed] (unfold #(when (not (finished? %)) (grow %)) seed))) (unfold (fn [x] [(* x x) (inc x)]) #( % 10) 0) (0 1 4 9 16 25 36 49 64 81 100) (unfold (fn [x] (when (= x 10) [(* x x) (inc x)])) 0) (0 1 4 9 16 25 36 49 64 81 100) I think it can be proved that any sequence can be build with a call to unfold. Which makes it useful and solves the why reduce is not lazy? question. -- 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
Re: partition-starting-every : yet another partition function
I think that unfold (or co-reduce, or generate) should find its way in contrib. I am not sure we need finished arg though. The traditional finish in the seq family is nil. My own version of unfold: (defn unfold (unfold seed grow) use the seed and a function grow that returns an element and another seed to creates a lazy seq. The seq is stopped the grow function returns nil. [seed grow] (if-let [[elt next-seed] (grow seed)] (cons elt (lazy-seq (unfold next-seed grow))) ())) Whether the cons is in or outside the lazy-seq is debatable. (I like to think of seq as the fixpoint of the functor (X - Cons Object (lazy X))) Best, Nicolas. -- 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
Re: Feature idea: meta-macros
Your example can be solved with (binding ...) For the proposal, I think it's a bad idea : huge potential for abuse (and importing abuse from other namespaces written by other people) and little benefit. I wouldn't be so strongly against it if it was in a delimited scope. In any case, you can probably implement it as a library on top of the compiler, with a code walker. -- 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
Re: Feature idea: meta-macros
You can also use binding eval evil brother : alter-var-root. On Wed, Sep 15, 2010 at 8:04 PM, Richard Newman holyg...@gmail.com wrote: My suggestion is inline with other commenters: use binding. If that doesn't satisfy you, consider using or writing a preprocessor like m4. -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: why doesn't a function have a type ?
On Tue, Sep 14, 2010 at 2:35 PM, Belun alexandrurep...@gmail.com wrote: why isn't the type of a function : clojure.lang.IFn ? Actually you assume the existence of an unique type. In most OO-language, and Clojure inherits that from its host, an object has multiple types. Indeed an object can be seen as of type its class or any of its super-class or any of the interface it implements. (Formally a : T' and T' T = a T). When you asked with type, clojure answer the most specific type. The class it has created for this function compilation. However, if you ask instance?, you should see that any function implements IFn. Best, Nicolas. -- 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
Re: clojurescript and 1.2.0
Hi, I soon realised that applying the patch won't be easy... After going through the different rejected diffs, I realised I wasn't going to manage to make it work. I switched to Parenscript for my small JS project, even if I's rather have used Clojure than CL (especially a very small subste of CL) I agree it will be a better idea to wait for Clojure-in-Clojure. Could you mail the list, when you want to start working back on this? I would really be happy to help you with the clojurization of clojurescript if you need more hands... Best regards, Nicolas. On Mon, Sep 13, 2010 at 5:59 AM, Chouser chou...@gmail.com wrote: On Sun, Sep 12, 2010 at 9:04 AM, Nicolas Oury nicolas.o...@gmail.com wrote: Oooops. Ansered my question. Haven't seen the patch in the git repository. Will try to apply it to clojure 1.2. I imagine you'll have some difficulty with that. ClojureScript was last updated to work with Clojure 1.0 (with the patch applied) ... or perhaps even an earlier version than that. I've given up working on it until more of Clojure-in-Clojure is complete, which will make bringing ClojureScript up to date and keeping it there dramatically easier. --Chouser http://joyofclojure.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 -- Sent from an IBM Model M, 15 August 1989. -- 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
Re: clojurescript and 1.2.0
Thanks for the link. Very interesting indeed. Didn't know about it. On Mon, Sep 13, 2010 at 11:38 AM, Daniel Werner daniel.d.wer...@googlemail.com wrote: On Sep 13, 9:40 am, Nicolas Oury nicolas.o...@gmail.com wrote: I switched to Parenscript for my small JS project, even if I's rather have used Clojure than CL (especially a very small subste of CL) There is also Scriptjure, which is basically JavaScript with Clojury syntax, similar to what ParenScript does for CL: http://github.com/arohner/scriptjure -- 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 -- Sent from an IBM Model M, 15 August 1989. -- 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
clojurescript and 1.2.0
Dear all, I cannot manage to make ClojureScript work from clojure 1.2.0. It seems that *compiler-analyse-only* used to exist but do not exist anymore. Does someone know what it was and what replaced it? Best regards, Nicolas. -- 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
Re: clojurescript and 1.2.0
Oooops. Ansered my question. Haven't seen the patch in the git repository. Will try to apply it to clojure 1.2. On Sun, Sep 12, 2010 at 1:52 PM, Nicolas Oury nicolas.o...@gmail.com wrote: Dear all, I cannot manage to make ClojureScript work from clojure 1.2.0. It seems that *compiler-analyse-only* used to exist but do not exist anymore. Does someone know what it was and what replaced it? Best regards, Nicolas. -- Sent from an IBM Model M, 15 August 1989. -- 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
