On 28 Nov., 23:29, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> Hi André,
>
> Am 28.11.2008 um 22:56 schrieb André Thieme:
>
> >> Maybe I have a wrong understanding of "closure", but
> >> as far as I understand, every function definition in
> >> Clojure - be it defn or #() - finally translates t
Thanks for the comments, the prefix notation may indeed be something
that one gets used to. I find it just fine for most cases, just not
for mathematical expressions. The example function was not meant as a
complete solution, but rather as an example of how trivial it is to
switch between the two
Hello.
I want to embed Clojure into a Java system we are creating at work to
have interactive control on it (via SLIME) during development. The
system is running in Tomcat.
I did not find a conventional to do this. Therefore I copy/pasted
peace of clojure.lang.Repl class and created a JSP page,
On Friday 28 November 2008 15:54, Dmitri wrote:
> First of I'd like to say that I find Clojure to be an excellent
> language, however I find the lack of infix operators makes reading
> equations somewhat unnatural, eg:
>
> (+ (- (* x x) (* y y)) a)
Try this:
(+
(-
(* x x)
(* y y))
a)
I can understand how that might be attractive to someone accustomed to
a language that uses infix operators (as opposed to a Lisp), but I
wonder how many people with a few weeks of Lisp under their belt would
find the infix function worth the trouble.
This reminds me of when we introduced the C l
Clojure
user=> (nil (println "asd")
)
java.lang.NullPointerException (NO_SOURCE_FILE:1)
user=>
This seems like an odd error to get here. Couldn't it say something
like "invalid function as first value"?
It also made me wonder, would it be possible to have a line counter
inside the REPL, and
On Nov 28, 2008, at 7:22 PM, ppierre wrote:
> More complete :
>
> (def *locale* nil)
>
> (binding [clojure.core/format
>(fn [fmt & args]
> (String/format (or *locale*
> (java.util.Locale/getDefault))
[...]
> (with-out *err*
> (with-locale "
First of I'd like to say that I find Clojure to be an excellent
language, however I find the lack of infix operators makes reading
equations somewhat unnatural, eg:
(+ (- (* x x) (* y y)) a)
I ended up writing a simple function to handle infix notation
(defn infix [arg1 func arg2 & args]
(l
More complete :
(def *locale* nil)
(binding [clojure.core/format
(fn [fmt & args]
(String/format (or *locale*
(java.util.Locale/getDefault))
fmt (to-array args)))
*out* *err*
*locale* java
Hi again,
Am 28.11.2008 um 23:07 schrieb Meikel Brandmeyer:
It's not perfect, though. The following packages are not
compiled:
I missed enum. That one uses gen-and-load-class in
some dynamic way...
Sincerely
Meikel
smime.p7s
Description: S/MIME cryptographic signature
Hi Rich,
Am 28.11.2008 um 23:17 schrieb Rich Hickey:
I don't see why having the .cljs and .class files in the classpath
should be a problem - that's the normal case for compilation.
It may simply be that the lib has problems being compiled - I'm not
sure all of the libs in clojure.contrib have
Hi André,
Am 28.11.2008 um 22:56 schrieb André Thieme:
Maybe I have a wrong understanding of "closure", but
as far as I understand, every function definition in
Clojure - be it defn or #() - finally translates to (fn ...).
And fn creates a closure.
I tooled myself up and looked up the definiti
On Nov 28, 4:53 pm, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I noticed a problem with AOT if not all libraries
> are compiled. For example contrib only provides
> a jar with the sources. Compiling a library using
> - say - clojure.contrib.def will compile
> clojure.contrib.def with
Why not add a *locale* var and use it in format ?
You would write :
(binding [*out* ...
*locale* ... ]
(printf ... ))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
Hi,
I'm kind of lost with the latest works on the compiler.
However here is a short patch, which modifies build.xml
of contrib to also compile the sources.
It's not perfect, though. The following packages are not
compiled:
- javalog: wants some GLOBAL_LOGGER_NAME, which
I can't find anywhere.
Hi,
please find attached a patch for clojure.contrib.javadoc,
which adapts the doto to the new syntax.
Sincerely
Meikel
javadoc-doto.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
On 27 Nov., 13:06, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
Hello.
> Maybe I have a wrong understanding of "closure", but
> as far as I understand, every function definition in
> Clojure - be it defn or #() - finally translates to (fn ...).
> And fn creates a closure.
Well, from my experien
Hi,
I noticed a problem with AOT if not all libraries
are compiled. For example contrib only provides
a jar with the sources. Compiling a library using
- say - clojure.contrib.def will compile
clojure.contrib.def with the library itself. Without
special measures the clojure.contrib.def will be
in
Hi Rich,
Am 28.11.2008 um 15:10 schrieb Rich Hickey:
Useful - thanks! Would you be able to please resend the patch as an
attachment? I much prefer patches as attachments, vs in the message
body or as file uploads. Patches in the message body often get
destroyed by wrapping, as yours has.
Sorry
On Nov 28, 1:05 am, "Michael Wood" <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 28, 2008 at 2:59 AM, Kei Suzuki <[EMAIL PROTECTED]> wrote:
>
> > On Nov 27, 11:21 am, Chouser <[EMAIL PROTECTED]> wrote:
> [...]
> >> All those methods take Java variadic arguments, which generally means
> >> you need build
CLinorm Is Not an ORM. Basically because it is not object oriented. It's
in its very very early stages of development. It's basically useless and
I'm developed on a need-to-function basis for another project I'm doing
which is not public yet. The reason to upload it is so that other people
can take
On Nov 28, 12:03 am, "Paul Drummond" <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> Well, this is the sort of feature provided by IDEs rather than editors as
> you say, so it's not a "clojure" specific issue. It's whether your chosen
> IDE supports the feature you require.
No, I'd be perfectly happ
On Nov 28, 2008, at 11:55 AM, Stephen C. Gilardi wrote:
>
>
>> I am not in favor of creating the directory nor fabricating the
>> classpath.
>
> Clojure currently creates the directory. Since that appears
> unintentional, fixing that would go a long way to improving the
> behavior that caught me
On Fri, Nov 28, 2008 at 8:33 PM, Vincent Foley <[EMAIL PROTECTED]> wrote:
>
> I can agree with the multiple-exceptions-in-one-catch, however I don't
> think the syntax should be so liberal. It should all be (catch
> [Exception+] e body).
The liberal syntax "feature" was more because I didn't know
> I am not in favor of creating the directory nor fabricating the
> classpath.
Clojure currently creates the directory. Since that appears
unintentional, fixing that would go a long way to improving the
behavior that caught me.
Here's the behavior that cost me a couple of hours of confusi
On Fri, Nov 28, 2008 at 5:09 PM, Chouser <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 28, 2008 at 9:38 AM, Michael Wood <[EMAIL PROTECTED]> wrote:
>>
>> I imagine counting characters in a string will be quicker than setting
>> up a bunch of pointers or copying a bunch of characters and then
>> garba
On Fri, Nov 28, 2008 at 9:38 AM, Michael Wood <[EMAIL PROTECTED]> wrote:
>
> I imagine counting characters in a string will be quicker than setting
> up a bunch of pointers or copying a bunch of characters and then
> garbage collecting them again.
>
> They might both be O(1), but one O(1) is still
I can agree with the multiple-exceptions-in-one-catch, however I don't
think the syntax should be so liberal. It should all be (catch
[Exception+] e body).
On Nov 28, 1:19 am, "Vijay Lakshminarayanan" <[EMAIL PROTECTED]>
wrote:
> Hi
>
> I'd like to propose a change to Clojure's current try-catch
On Fri, Nov 28, 2008 at 3:45 PM, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On 28 Nov., 14:37, "Michael Wood" <[EMAIL PROTECTED]> wrote:
>> I assume (count largecoll) and (empty? largecoll) would be more
>> efficient than (seq largecoll)?
>
> Since empty? is implemented as #(not (seq
On Nov 28, 8:36 am, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote:
> Dear Clojurians,
>
> currently the trio of require, use and import is slightly
> inconsistent.
> While use and require allow either symbols or lists, import only
> allows
> lists. (The vector notation doesn't make sense for impor
@dokondr: the blackboard mechanism you mention is just a distributed
associative memory, and there is already a Java specification for such
a system (search for Jini and Javaspaces), with several open source
and commercial implementations available. Unfortunately, anyone who
has ever worked with s
On Nov 28, 8:21 am, "Mark Volkmann" <[EMAIL PROTECTED]> wrote:
> I've been learning Clojure for about a month now and like it so far.
> In the interest of making it easier to convince other people to give
> it a try, I think it would be a good idea to carefully consider some
> readability issues
Hi,
On 28 Nov., 14:37, "Michael Wood" <[EMAIL PROTECTED]> wrote:
> I assume (count largecoll) and (empty? largecoll) would be more
> efficient than (seq largecoll)?
Since empty? is implemented as #(not (seq %)) there is no
difference for those. count is O(1) for maps, sets, vectors and
lists. I
On Fri, Nov 28, 2008 at 3:33 PM, Chouser <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 27, 2008 at 11:50 PM, Stephen C. Gilardi <[EMAIL PROTECTED]>
> wrote:
>>
>> You might also consider these Clojure functions:
>> user=> (count "")
>> 0
>> user=> (empty? "")
>> true
>
> or (seq "") which returns ni
Dear Clojurians,
currently the trio of require, use and import is slightly
inconsistent.
While use and require allow either symbols or lists, import only
allows
lists. (The vector notation doesn't make sense for import). So one has
to specify always the full list, even if one only wants to import
On Thu, Nov 27, 2008 at 8:45 AM, Stephen C. Gilardi <[EMAIL PROTECTED]>wrote:
>
> On Nov 27, 2008, at 7:41 AM, Stefan Bodewig wrote:
>
> Looks pretty easy and it would probably take me longer to sign and
> send the CA than to put together an antlib.xml file 8-)
>
> If anybody is interested, let me
On Thu, Nov 27, 2008 at 11:50 PM, Stephen C. Gilardi <[EMAIL PROTECTED]> wrote:
>
> You might also consider these Clojure functions:
> user=> (count "")
> 0
> user=> (empty? "")
> true
or (seq "") which returns nil on empty.
--Chouser
--~--~-~--~~~---~--~~
You re
On Nov 28, 5:01 am, "Michael Wood" <[EMAIL PROTECTED]> wrote:
> > ;; YMMV
> > (add-classpath
> > "file:///opt/local/lib/erlang/lib/jinterface-1.4/priv/OtpErlang.jar")
>
> Using add-classpath, except at the REPL, is discouraged.
True, it felt dirty doing that. My intent was to give someone who
m
I've been learning Clojure for about a month now and like it so far.
In the interest of making it easier to convince other people to give
it a try, I think it would be a good idea to carefully consider some
readability issues before making the 1.0 release. I'd hate for people
to reject Clojure bas
Hello,
This is certainly possible, I think.
The "fix import" action could try to resolve an unknown symbol by
first searching the symbol in one of the classpath available
namespaces, and then search for java classes in the classpath.
It could then add an import/require command for each found reso
Hi
I'd like to propose a change to Clojure's current try-catch syntax.
Currently the syntax is (copied from clojure.org)
(try expr* catch-clause* finally-clause?)
catch-clause -> (catch classname name expr*)
finally-clause -> (finally expr*)
I'd like to propose a change to the catch-clause so t
On Fri, Nov 28, 2008 at 2:33 AM, Eric Sessoms <[EMAIL PROTECTED]> wrote:
>
> For kicks, I've uploaded a little wrapper around JInterface to make it
> a little more lispy. It might make it a little easier for anyone
> interested in playing around with that option.
>
> http://clojure.googlegroups.c
On Fri, Nov 28, 2008 at 2:59 AM, Kei Suzuki <[EMAIL PROTECTED]> wrote:
>
> On Nov 27, 11:21 am, Chouser <[EMAIL PROTECTED]> wrote:
[...]
>> All those methods take Java variadic arguments, which generally means
>> you need build the array the method is expecting. Fortunately, in the
>> cases you l
On Fri, Nov 28, 2008 at 3:05 AM, Kei Suzuki <[EMAIL PROTECTED]> wrote:
>
> On Nov 27, 12:07 pm, "Michael Wood" <[EMAIL PROTECTED]> wrote:
>> On Thu, Nov 27, 2008 at 9:21 PM, Chouser <[EMAIL PROTECTED]> wrote:
>>
>> > On Thu, Nov 27, 2008 at 2:12 PM, Kei Suzuki <[EMAIL PROTECTED]> wrote:
>>
>> >> A
Hi Martin,
Well, this is the sort of feature provided by IDEs rather than editors as
you say, so it's not a "clojure" specific issue. It's whether your chosen
IDE supports the feature you require.
FYI, there is a NetBeans plugin (http://enclojure.org/) and a Eclipse plugin
(http://code.google.co
45 matches
Mail list logo
