Re: labrepl incanter IntelliJ Ubuntu 64-bit X11 error
OK that's nice and clear. Thanks for your help --PG On Apr 11, 1:31 pm, Aaron Bedra wrote: > I'm on Ubuntu 10.10 64. I use it as my daily development environment. > I just installed IntelliJ community edition 10 and checked out labrepl. > I used the maven browser and selected the clojure:repl task and > everything worked successfully. You can still try out Clojure though > labrepl using any of the other editor options until you get your > IntelliJ issues sorted out. > > On 04/10/2011 10:49 PM, peterg wrote:> The Ubuntu configuration is very plain > - not used for anything else. > > X11 is part of the standard distribution. > > > I would really like to try out Clojure through this tutorial... > > > --PG > > -- > Cheers, > > Aaron Bedra > -- > Clojure/corehttp://clojure.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: Clojures macro system is essentially hygienic -- In the good sense.
On 11 Apr 2011, at 03:50, George Rogers wrote: ;;2) Shadowing a macro does not change macros that depend on it. (defmacro foobar [x] `(let [a# ~x] (+ a# a#))) (defmacro let [] `(guik.evil/let*)) (foobar 10) ;=> 20 That's due to namespaces, which indeed solve many of the "hygiene" problems that have been discussed for Common Lisp. Namespaces are one of the most important features that have appeared in programming languages since the early days of Lisp. To quote "The Zen of Python": ... Namespaces are one honking great idea -- let's do more of those! Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Contrib.Logging enhancements: set-log-level!, spy for lazy sequences
Just a reminder that logging has moved to it's own repository in the clojure space. It can be found at http://github.com/clojure/tools.logging and is where all future development of the library should exist. If you would like to submit patches for logging, please do so against the new project instead of contrib. -- Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 04/10/2011 10:48 PM, Paul Legato wrote: Hi, I'd like to suggest two enhancements to clojure-contrib.logging: 1) There should be an easy way to set the current log level threshold (DEBUG, WARN, etc.) I've written two set-log-level! functions which do this, at http://www.paullegato.com/blog/setting-clojure-log-level/ . I'm not sure why some Clojure instances return a org.apache.commons.logging.impl.Jdk14Logger and others a java.util.logging.LogManager$RootLogger from (impl-get-log ""). Perhaps there's a better / more universal way to write the log level setting function than this? 2) The logging/spy macro doesn't print lazy sequences to the log; instead, it prints something like "clojure.lang.LazySeq@8592". Since the user has explicitly requested that the sequence's value be logged, it makes sense to me to run the sequence and log the result. I've implemented this at http://www.paullegato.com/blog/lazy-spy-clojure-logging-lazy-sequences/. Again, I'm not sure if this is the best way to go about it. Suggestions or improvements would be greatly appreciated. Best, 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
Re: labrepl incanter IntelliJ Ubuntu 64-bit X11 error
I'm on Ubuntu 10.10 64. I use it as my daily development environment. I just installed IntelliJ community edition 10 and checked out labrepl. I used the maven browser and selected the clojure:repl task and everything worked successfully. You can still try out Clojure though labrepl using any of the other editor options until you get your IntelliJ issues sorted out. On 04/10/2011 10:49 PM, peterg wrote: The Ubuntu configuration is very plain - not used for anything else. X11 is part of the standard distribution. I would really like to try out Clojure through this tutorial... --PG -- Cheers, Aaron Bedra -- Clojure/core http://clojure.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
Contrib.Logging enhancements: set-log-level!, spy for lazy sequences
Hi, I'd like to suggest two enhancements to clojure-contrib.logging: 1) There should be an easy way to set the current log level threshold (DEBUG, WARN, etc.) I've written two set-log-level! functions which do this, at http://www.paullegato.com/blog/setting-clojure-log-level/ . I'm not sure why some Clojure instances return a org.apache.commons.logging.impl.Jdk14Logger and others a java.util.logging.LogManager$RootLogger from (impl-get-log ""). Perhaps there's a better / more universal way to write the log level setting function than this? 2) The logging/spy macro doesn't print lazy sequences to the log; instead, it prints something like "clojure.lang.LazySeq@8592". Since the user has explicitly requested that the sequence's value be logged, it makes sense to me to run the sequence and log the result. I've implemented this at http://www.paullegato.com/blog/lazy-spy-clojure-logging-lazy-sequences/. Again, I'm not sure if this is the best way to go about it. Suggestions or improvements would be greatly appreciated. Best, 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
labrepl incanter IntelliJ Ubuntu 64-bit X11 error
Has anyone got the current labrepl/IntelliJ configuration running on Ubuntu 64-bit? I get the following error when trying to run the first incanter graph exercise: user=> (def words (read-lines "data/words")) #'user/words user=> (count words) user=> 234936 user=> user=> (use '[incanter core charts]) nil user=> (let [f (frequencies (map first words))] (view (bar-chart (keys f) (vals f java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. (NO_SOURCE_FILE:0) The Mac/Linux command line version runs fine and opens the graph window. I reported the problem on github; there was an associated maven problem, but the fix to that hasn't repaired the X11 problem. The Ubuntu configuration is very plain - not used for anything else. X11 is part of the standard distribution. I would really like to try out Clojure through this tutorial... --PG -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojures macro system is essentially hygienic -- In the good sense.
(ns guik.evil) ;;1) Special forms cannot be shadowed (defmacro let* [] (+ 1 1)) ;; (let*) ; would yield ;=> clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: Bad binding form, expected vector (evil.clj:6) ;;2) Shadowing a macro does not change macros that depend on it. (defmacro foobar [x] `(let [a# ~x] (+ a# a#))) (defmacro let [] `(guik.evil/let*)) (foobar 10) ;=> 20 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: refer-clojure does not prevent namespace conflicts
Hi, Am 10.04.2011 um 14:37 schrieb limux: > java.lang.IllegalStateException: distinct already refers to: > #'clojureql.core/distinct in namespace: myoa.core (core.clj:1). but in > clojureql/core.clj has already (:refer-clojure > :exclude [take drop sort distinct conj! disj! compile case]). What clojureql does is only of importance to clojureql. What happens is that your namespace (myoa.core) "use"s clojureql and then tries to define an own Var named distinct. This leads to the problem. To fix this you have to exclude the clojureql distinct from the use clause. (ns myoa.core (:use [clojureql.core :exclude (distinct)])) Here for illustration of what happens. The refers can be read as use clauses in the ns definition. (I just used refer, because I don't have the corresponding files. use is basically refer + loading from the file.) user=> (ns foo.bar) nil foo.bar=> (def x 5) #'foo.bar/x foo.bar=> (ns yoyo.dyne) nil yoyo.dyne=> (refer 'foo.bar) nil yoyo.dyne=> (def x 6) java.lang.IllegalStateException: x already refers to: #'foo.bar/x in namespace: yoyo.dyne (NO_SOURCE_FILE:5) yoyo.dyne=> (ns frob.nicate) nil frob.nicate=> (refer 'foo.bar :exclude '(x)) nil frob.nicate=> (def x 7) #'frob.nicate/x Hope this helps. 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
Re: Announcement: pretzel - a predicate library + call for suggestions
On Sun, Apr 10, 2011 at 1:37 PM, James Reeves wrote: > By adding error messages to predicates, we tightly couple the > validation error with the predicate, which in general is considered > bad. However, this might be a valid compromise, but only if it > improves readability. I showed two posts ago how to keep that decoupled. > I don't really understand what you're saying here. Do you disagree > that "deny by default" is more secure in general than "allow by > default"? I think it's a bit subtler than that. On the face, I wouldn't disagree with that statement. But if you arrive at your security rules by two different procedures, one resulting set of rules might specify what-to-deny and be more secure than another that specifies what-to-allow. And ultimately there's a mathematically equivalent what-to-allow set for any what-to-deny set, and vice versa, like a photograph and its negative. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Announcement: pretzel - a predicate library + call for suggestions
On 10 April 2011 12:33, Ken Wesson wrote: > I thought you were the one who wanted the strings moved out to a data > structure that could be swapped with localized versions? :) Not really. I just want the error messages to be independent of the predicates. In essence, I'm looking for a solution with two properties: 1. Non-compound (i.e. simple) 2. Readable By adding error messages to predicates, we tightly couple the validation error with the predicate, which in general is considered bad. However, this might be a valid compromise, but only if it improves readability. >> My perception of validations is that they are a contract that a >> particular map of data has to conform to. I don't like the idea of >> encouraging people to think in terms of "allow by default", as that's >> not considered good security practise. > > On the contrary, if you don't think carefully about each specific > thing that could cause a problem and forbid that thing, you can end up > accidentally allowing corner cases that break the security model. If > you work backwards from the security model to derive a set of > constraints, though, those constraints are often mostly "shalt-nots". I don't really understand what you're saying here. Do you disagree that "deny by default" is more secure in general than "allow by default"? - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: refer-clojure does not prevent namespace conflicts
Odds are your namespace conflict is not in your core.clj, but in somebody who uses core.clj, e.g. the REPL. Stu Clojure/core http://clojure.com > I use compojure, hiccup and clojureql to study web development, in my > myoa project's core.clj, require clojureql with cause > java.lang.IllegalStateException: distinct already refers to: > #'clojureql.core/distinct in namespace: myoa.core (core.clj:1). but in > clojureql/core.clj has already (:refer-clojure > :exclude [take drop sort distinct conj! disj! compile case]). > > Thanks. > Limux > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from 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: Announcement: pretzel - a predicate library + call for suggestions
On Sun, Apr 10, 2011 at 11:42 AM, James Reeves wrote:
> On 10 April 2011 09:49, Ken Wesson wrote:
>> (def age-invalid-en
>> {:low "age must be at least 1"
>> :high "nobody is THAT old!"
>> :blank "age is required"
>> :non-integer "age must be a whole number"})
>>
>> (def qty-invalid-en
>> {:low "quantity must be at least 1"
>> :high "maximum 10 per customer per order"
>> :non-integer "quantity must be a whole number"})
>>
>> (if-let [err (age-invalid-en (not-int-in-range? age 1 120))]
>> (println err)
>> (if-let [err (qty-invalid-en (not-int-in-range? qty 1 10))]
>> (println err)
>> (process-order age qty)))
>
> IMO, that's not as as simple or as easy to read as:
>
> (validate thing
> [:age present? "age is required"]
> [:age integer-string? "age must be a whole number"]
> [:age (at-least 1) "age must be at least 1]
> [:age (at-most 120) "nobody is that old"]
> [:qty integer-string? "quantity must be a whole number"]
> [:qty (at-least 1) "quantity must be at least 1"]
> [:qty (at-most 10) "maximum 10 per customer per order"])
I thought you were the one who wanted the strings moved out to a data
structure that could be swapped with localized versions? :)
> But I guess to an extent that's a matter of opinion.
Obviously.
>> I don't agree. Everything that is not forbidden is allowed. Specific
>> chunks of the input-space are "wrong" for specific reasons; what's
>> valid it what's left after whittling all of those away.
>
> My perception of validations is that they are a contract that a
> particular map of data has to conform to. I don't like the idea of
> encouraging people to think in terms of "allow by default", as that's
> not considered good security practise.
On the contrary, if you don't think carefully about each specific
thing that could cause a problem and forbid that thing, you can end up
accidentally allowing corner cases that break the security model. If
you work backwards from the security model to derive a set of
constraints, though, those constraints are often mostly "shalt-nots".
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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: Announcement: pretzel - a predicate library + call for suggestions
On 10 April 2011 09:49, Ken Wesson wrote:
> (def age-invalid-en
> {:low "age must be at least 1"
> :high "nobody is THAT old!"
> :blank "age is required"
> :non-integer "age must be a whole number"})
>
> (def qty-invalid-en
> {:low "quantity must be at least 1"
> :high "maximum 10 per customer per order"
> :non-integer "quantity must be a whole number"})
>
> (if-let [err (age-invalid-en (not-int-in-range? age 1 120))]
> (println err)
> (if-let [err (qty-invalid-en (not-int-in-range? qty 1 10))]
> (println err)
> (process-order age qty)))
IMO, that's not as as simple or as easy to read as:
(validate thing
[:age present? "age is required"]
[:age integer-string? "age must be a whole number"]
[:age (at-least 1) "age must be at least 1]
[:age (at-most 120) "nobody is that old"]
[:qty integer-string? "quantity must be a whole number"]
[:qty (at-least 1) "quantity must be at least 1"]
[:qty (at-most 10) "maximum 10 per customer per order"])
But I guess to an extent that's a matter of opinion.
> I don't agree. Everything that is not forbidden is allowed. Specific
> chunks of the input-space are "wrong" for specific reasons; what's
> valid it what's left after whittling all of those away.
My perception of validations is that they are a contract that a
particular map of data has to conform to. I don't like the idea of
encouraging people to think in terms of "allow by default", as that's
not considered good security practise.
However, I'm undecided whether the validation system itself should
enforce a "deny by default" policy. That seems like the right thing to
do, but I can't think of a way to do that without making the
validation system more complex.
- James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ANN: Logos v0.6 - Pattern matching, Tabling, Disequality Constraints, and now on Clojars
On Sun, Apr 10, 2011 at 6:11 AM, faenvie wrote: > very interesting stuff. i will follow this with pleasure ... > > to get into it, a basic tutorial that focuses on solving > one or two classical problems using logos would > probably be a winner. Thanks. A tutorial is definitely planned. 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
Re: clj3D, a Clojure 3D Library
The second screencast is out! http://www.youtube.com/watch?v=Xg2gZpWU6AE Enjoy! Alfredo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Announcement: pretzel - a predicate library + call for suggestions
On Sat, Apr 9, 2011 at 10:12 PM, James Reeves wrote:
> On 9 April 2011 10:07, Ken Wesson wrote:
>>> That particular example ties a predicate to a particular error
>>> message. Error messages should be independent of predicates, otherwise
>>> they can't be localized or changed to fit a specific situation.
>>
>> It can always be an integer or a keyword (or a string!) used to look
>> up the localized or situation-specific message in a map.
>
> It's still not as flexible, because different keywords with the same
> validation may require different error messages.
(def age-invalid-en
{:low "age must be at least 1"
:high "nobody is THAT old!"
:blank "age is required"
:non-integer "age must be a whole number"})
(def qty-invalid-en
{:low "quantity must be at least 1"
:high "maximum 10 per customer per order"
:non-integer "quantity must be a whole number"})
(if-let [err (age-invalid-en (not-int-in-range? age 1 120))]
(println err)
(if-let [err (qty-invalid-en (not-int-in-range? qty 1 10))]
(println err)
(process-order age qty)))
>>> This would lead to a lot of validations with "not" in front of them.
>>> i.e not-email-address?, not-integer?, etc.
>>
>> So?
>
> It's redundant, doesn't read as well, and reverses people's usual
> conceptions about validations.
I don't agree. Everything that is not forbidden is allowed. Specific
chunks of the input-space are "wrong" for specific reasons; what's
valid it what's left after whittling all of those away.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
refer-clojure does not prevent namespace conflicts
I use compojure, hiccup and clojureql to study web development, in my myoa project's core.clj, require clojureql with cause java.lang.IllegalStateException: distinct already refers to: #'clojureql.core/distinct in namespace: myoa.core (core.clj:1). but in clojureql/core.clj has already (:refer-clojure :exclude [take drop sort distinct conj! disj! compile case]). Thanks. Limux -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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: Logos v0.6 - Pattern matching, Tabling, Disequality Constraints, and now on Clojars
very interesting stuff. i will follow this with pleasure ... to get into it, a basic tutorial that focuses on solving one or two classical problems using logos would probably be a winner. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
