Hi,
On 19 Aug., 17:19, Sean Devlin wrote:
> http://first.clojure-conj.org/
Will the talks be recorded? Put on blip.tv? For those on the other
side of the Big Pond?
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this g
Yes, this is very important problem with current implementation of
Clojure. Many of beginners complain, that they couldn't understand where
error happened, especially during compilation of code.
Phil Hagelberg at "Tue, 24 Aug 2010 21:55:52 -0700" wrote:
PH> One of the most common complaints abo
It would be fantastic if the talkes would be record. We have seen the
effects a couple of videos of rich had on the world and how many
people it led to clojure (including me).
On Aug 25, 9:36 am, Meikel Brandmeyer wrote:
> Hi,
>
> On 19 Aug., 17:19, Sean Devlin wrote:
>
> >http://first.clojure-c
+1 Good idea.
On Aug 25, 12:45 pm, Alex Ott wrote:
> Yes, this is very important problem with current implementation of
> Clojure. Many of beginners complain, that they couldn't understand where
> error happened, especially during compilation of code.
>
> Phil Hagelberg at "Tue, 24 Aug 2010 21:
Hello everybody,
I wanted to package jreality along with its native dependencies and upload
it to my clojars since there were none already there.. I followed the
procedure on
http://nakkaya.com/2010/04/05/managing-native-dependencies-with-leiningen/
the resultant was the following ...
http://cl
I think what Stuart meant is that the class files compiled from the core
clojure library will not be incide the clojure contrib uberjar. Only the
class files compiled from the clojure contrib libs will be in there.
On Wed, Aug 25, 2010 at 8:20 AM, ataggart wrote:
> Pardon the silly question, but
On Aug 24, 2010, at 9:55 PM, Phil Hagelberg wrote:
>
> Thoughts?
+1.
The existing stack traces are pretty horrible. Phil's proposal, or something
similar, would be a huge improvement.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to t
I am a newcomer to the language, and to lisps in general, and having
to interpret Clojure's stacktraces is really hard. It is one of those
things that made me not want to use the language at all. It also makes
it hard for me to recommend the language to others.
It is not just the stacktraces, but
On 13 Jul., 12:03, Meikel Brandmeyer wrote:
> I'm not sure, though, why the metadata gets moved to the function on
> redefinition.
Does anyone know why this is so?
> (defn foo [x] x)
> (defn foo [x y] (+ x y))
> (:arglists (meta (var foo))) ==> ([x y])
> (:arglists (meta foo)) ==> ([x])
Thanks
+1 on improving stack traces (though I haven't had experience with
clj-stacktrace, other than what I have read on this list).
--
/ Peter Schuller
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegrou
I haven't had a lot of problems with stack-traces.
I would be happy to have more information on the context, though.
And maybe better reporting of exception occuring in a delayed context.
(when forcing a seq and the excpetion occurs under a lazy.)
In this situation I have sometimes fonud that the
I agree with the point in discussion that the error messages in
Clojure are more of a problem than stack traces per se.
Regards,
Shantanu
On Aug 25, 5:02 pm, Nicolas Oury wrote:
> I haven't had a lot of problems with stack-traces.
>
> I would be happy to have more information on the context, tho
I'm glad my question generated so much discussion! Thank you all for
the suggestions...it's all good stuff trying to wrap my head around
and improve my facility with clojure.
On Aug 24, 1:27 am, Meikel Brandmeyer wrote:
> Hi,
>
> On 24 Aug., 03:08, gary ng wrote:
>
> > (map #(for [s %2] (map *
I will try submitting one or a few of my benchmark programs created 1 year
ago.
For anyone that wants to look at some timing results and/or my source code
used to achieve them before then, they are available on github here:
http://github.com/jafingerhut/clojure-benchmarks
I just pushed a few cha
The error messages are often the easiest the thing in the world to improve,
even if you are new to contributing to Clojure. Most of the bad error messages
are in the context of macroexpansion, so it is almost free (in performance
terms) to add rigorous checks and error messages.
Take a look at
After toying around at the REPL I realize that I have been working
with a heretofore invalid understanding of collections. For example,
working with the following collection(s):
signal:
(((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7 8)))
I wanted to sum each individual list: e.g. (
You can probably boost n-body on 1.2 by replacing arrays with deftypes.
(definterface BodyIsh
(^double getMass [])
(setMass [^double x])
(^double getPosX [])
.)
(deftype Body [^double ^{:unsynchronized-mutable true} mass ^double
^{:unsynchronized-mutable true} posX .]
BodyIsh
"clojure sees 'signal' as 2 collections" thats wrong signals is one
collection with two items. These happen to be collection but only the
function that gets called by map carres what it gets.
How can this
(map #(map reduce + %) signal)
work? (map ) does take 1 function and some collections
Hi,
On 25 Aug., 16:06, Glen Rubin wrote:
> (map #(map reduce + %) signal)
The error you got here is probably related to the inner map. It should
probably read (map #(map (partial reduce +) %) signal) or (map
(partial map #(reduce + %)) signal)
Sincerely
Meikel
--
You received this message be
On Aug 25, 4:06 pm, Glen Rubin wrote:
> After toying around at the REPL I realize that I have been working
> with a heretofore invalid understanding of collections. For example,
> working with the following collection(s):
>
> signal:
> (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7
Ahoy,
On 25 August 2010 15:46, Stuart Halloway wrote:
>
> *Specific* documentation of pain points also welcome.
In general I haven't found the stack traces to be too much of a
problem, but the lack of full paths in the trace has bitten me. Since
all of my namespaces have a core.clj this can mean
On Wed, 25 Aug 2010 16:06:15 +0200, Glen Rubin wrote:
After toying around at the REPL I realize that I have been working
with a heretofore invalid understanding of collections. For example,
working with the following collection(s):
signal:
(((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7)
Ahoy,
On 25 August 2010 16:06, Glen Rubin wrote:
> After toying around at the REPL I realize that I have been working
> with a heretofore invalid understanding of collections. For example,
> working with the following collection(s):
>
> signal:
> (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5
Hi,
and again the for solution if nested anonymous functions are too hard
to read.
(for [signals signals-list]
(map #(reduce + %) signals))
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloj
I think you're getting confused.
(map reduce + %) won't work, because the signature of the map function
is (map func & colls). In other words, the second argument is expected
to be a collection, but you've put in +, which is a function.
When dealing with nested collections, you may want to work f
Hi Glen,
You have two separate problems here. The question of understanding collections
isn't really that tricky. Your variable 'signals' is simply a 2-element list.
Conceptually it's no different than: (a b). But in your case each element is
itself a 3-element list. An equivalent would be: ((a
To bad we don't have a voting system like on stackoverflow would be
nice to see witch answer got the most points.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new me
I vote for James'.
On 25 Aug., 16:42, nickikt wrote:
> To bad we don't have a voting system like on stackoverflow would be
> nice to see witch answer got the most points.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send em
On Wed, Aug 25, 2010 at 7:06 AM, Glen Rubin wrote:
> After toying around at the REPL I realize that I have been working
> with a heretofore invalid understanding of collections. For example,
> working with the following collection(s):
>
> signal:
> (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5
I added the *deserializers* atom, converted read-json-object to a
macro
(def *deserializers* (atom {}))
(defn add-deserializer [k deserializer]
(swap! *deserializers* #(assoc % k deserializer)))
(defn remove-deserializer [k]
(swap! *deserializers* #(dissoc % k)))
(defmacro get-object-reader
I posted the complete file on github here http://gist.github.com/549771
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient wi
Thanks, I'll give it a try.
On Aug 25, 12:00 pm, Dmitri wrote:
> I posted the complete file on github herehttp://gist.github.com/549771
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Not
I have the same problem, but you can usually figure that out by
looking at the function to which the backtrace refers, as well as the
filename:
4: clojure.lang.RT.nth(RT.java:722)
5: ddsolve.core$play_deal_strategically.invoke(core.clj:177)
6: ddsolve.core$eval2129.invoke(NO_SOURCE_FILE:1)
+1
the default stacktraces in clojure are one of the most off-putting
things for new people (Besides the ) :-)).
On Wed, Aug 25, 2010 at 6:55 AM, Phil Hagelberg wrote:
> One of the most common complaints about the current implementation of
> Clojure is that the stack traces are often unreadable.
On Aug 24, 4:43 pm, Sunil S Nandihalli
wrote:
> Could not locate de/jreality/plugin/JRViewer__init.class or
> de/jreality/plugin/JRViewer.clj on classpath:
> [Thrown class java.io.FileNotFoundException]
>
> I verified that the final jar that I created had JRViewer file it is
> complaining about
So if I do this in a clean REPL
Clojure 1.2.0
user=> (defprotocol Foo (bar [this x]))
Foo
user=> (defrecord fooed [] Foo (bar [this x] (* 2 x)))
user.fooed
user=> (defprotocol Foo (bar [this x]))
Foo
user=> (extend-type Object Foo (bar [this x] (/ 2 x)))
nil
user=> (def fooey (fooed.))
#'user/fooe
> problem, but the lack of full paths in the trace has bitten me. Since
> all of my namespaces have a core.clj this can mean a bit of detective
> work to find which core.clj is being reported.
+1 for that.
--
You received this message because you are subscribed to the Google
Groups "Clojure" gro
On 25 August 2010 20:16, Alan wrote:
> I have the same problem, but you can usually figure that out by
> looking at the function to which the backtrace refers, as well as the
> filename:
>
> 4: clojure.lang.RT.nth(RT.java:722)
> 5: ddsolve.core$play_deal_strategically.invoke(core.clj:177)
> 6:
+1
need to improve the present stacktrace, and error messages if clojure is to
attract more noobs.
On Wed, Aug 25, 2010 at 6:16 PM, Alan wrote:
> I have the same problem, but you can usually figure that out by
> looking at the function to which the backtrace refers, as well as the
> filename:
>
Hi all,
We are completing the migration to clojure and contrib 1.2.
I am working on the packaging this week using leinigen 1.3 for acceptance
tests.
I download artifacts from Clojars and other maven repos using our archiva
server here.
I have a problem that I do not understand yet (slowly comin
On Wed, Aug 25, 2010 at 5:59 PM, wrote:
> We are completing the migration to clojure and contrib 1.2.
> I am working on the packaging this week using leinigen 1.3 for acceptance
> tests.
>
> I download artifacts from Clojars and other maven repos using our archiva
> server here.
>
> I have a probl
Hey,
I just want to be sure that I understand the proxy macro correctly.
proxy macro is used to create a block of code that implements/extends
Java interface/class , so we don't have to create Java object
explicitly.
Please correct me if I'm wrong.
Thanks.
--
You received this message because you
Hey,
Both Groovy and Scala have a compiler to produce class files.
Does Clojure has a compiler?
Do Clojure files are compiled usually?
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.co
On Wed, Aug 25, 2010 at 7:17 PM, HB wrote:
> Both Groovy and Scala have a compiler to produce class files.
> Does Clojure has a compiler?
Yup. See the recent thread called "AOT compilation newbie mistakes"
for both the way to do it and some of the issues you may run into.
Several people prefer u
Yes, clojure has a compiler that can compile directly to class files.
There's more information here:
http://clojure.org/compilation
and a short demo that you can try here:
http://www.rlmcintyre.com/iassac-gouy.tar.bz2
or
http://www.bortreb.com/iassac-gouy.tar.bz2
--Robert McIntyre
On Wed, Aug
I think the current behavior follows the principle of least surprise:
(1) bar is a function, in whatever namespace the protocol Foo is defined in
(2) you redefine bar (perhaps by reloading the file Foo is in)
(3) you call bar and get the new behavior
Remember that bar lives in Foo's namespace,
Yes, proxy returns an instance of whatever classes/interfaces you're
extending/implementing.
On Aug 25, 7:15 pm, HB wrote:
> Hey,
> I just want to be sure that I understand the proxy macro correctly.
> proxy macro is used to create a block of code that implements/extends
> Java interface/class ,
On Aug 25, 6:17 am, John Fingerhut wrote:
> I will try submitting one or a few of my benchmark programs created 1 year
> ago.
>
> For anyone that wants to look at some timing results and/or my source code
> used to achieve them before then, they are available on github here:
>
> http://github.co
Hi,
On 26 Aug., 05:37, Isaac Gouy wrote:
> 1) The command line requested for these first programs doesn't AOT
> compile so the measured time includes compiling the program.
Which makes the comparison of languages with this benchmark even more
uninteresting.
> Perhaps AOT compilation is an usua
On Aug 25, 10:31 pm, Meikel Brandmeyer wrote:
> Hi,
>
> On 26 Aug., 05:37, Isaac Gouy wrote:
>
> > 1) The command line requested for these first programs doesn't AOT
> > compile so the measured time includes compiling the program.
>
> Which makes the comparison of languages with this benchmark
50 matches
Mail list logo
