This error is also intermittent. It doesn't happen every time I start the
app. I would guess this is some kind of timing issue, but I can't think
where the issue of timing comes up.
On Monday, January 25, 2016 at 4:04:50 PM UTC-5, piast...@gmail.com wrote:
>
> I've never had this problem befo
Thanks everyone for your answers. I must say I'm quite mystified as to why
Stuart's version works.
I ended up defining a function that has the same signature as the protocol,
and whose first argument wraps a function that contains the appropriate
code.
Vincent
On Wednesday, 5 June 2013 23:57:
Legal but comparable to a hidden side effect with all the pitfalls that can
derive
from this.
It's not a compiler issue, more a discipline issue.
Having a helper macro like Stuart suggest is acceptable to me
if it's called at top level, it's always done. There's less ambiguity.
Using def/defn i
On Wed, Jun 5, 2013 at 7:35 PM, Colin Fleming
wrote:
> Given this, are there any forms that are genuinely top-level from the
> compiler's point of view?
It's never explicitly enforced, just a consequence of how the compiler
creates and loads Java classes. Generally, the things which compile
dir
*`defprotocol` is a top-level form...*
This is interesting, and it's something I've wondered about. As far as I
can tell, there's really no distinction between top-level forms and other
forms, for example this is legal and works:
(defn define-my-functions []
(defn test-1 []
1)
(defn test-
Hi Vincent,
`defprotocol` is a top-level form, not really meant to be mixed with
value-returning expressions like `fn`. Protocols are always global because
of how they compile into Java interfaces.
Here's one way to make it work, by defining a symbol instead of returning a
function:
(defmacro
On Thursday, May 17, 2012 1:25:45 PM UTC-7, Armando Blancas wrote:
>
> -- it's also just plain wrong. Those are not local functions: def always
>> operates at top-level.
>>
>>
> Big deal. You see what I mean? Pedantry is contagious.
>
Well, I guess if "trying not to give newcomers blatantly fals
On Thu, May 17, 2012 at 1:25 PM, Armando Blancas wrote:
>> -- it's also just plain wrong. Those are not local functions: def always
>> operates at top-level.
> Big deal. You see what I mean? Pedantry is contagious.
er, i should think it *is* a big deal: programming languages really
don't give on
>
> -- it's also just plain wrong. Those are not local functions: def always
> operates at top-level.
>
>
Big deal. You see what I mean? Pedantry is contagious.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cl
On Thursday, May 17, 2012 12:52:27 PM UTC-7, Armando Blancas wrote:
>
> "There's nothing wrong" is a pretty strong statement.
>
>
> LOL. Perhaps as strong as "it is definitely the wrong way to do things"?
> Jeez.
>
> Pedantry is the wrong way to welcome newbies to this board.
>
Far from being ped
On Thu, May 17, 2012 at 12:52 PM, Armando Blancas wrote:
> Pedantry is the wrong way to welcome newbies to this board.
stop with your pedantry about there must be no pedantry?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, se
>
> "There's nothing wrong" is a pretty strong statement.
LOL. Perhaps as strong as "it is definitely the wrong way to do things"?
Jeez.
Pedantry is the wrong way to welcome newbies to this board.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
It's called Emacs + Paredit :-)
On Thu, May 17, 2012 at 8:00 PM, Raoul Duke wrote:
> some day we'll have the technology to let the compiler tell us that,
> instead of spewing some horrible, pointless, stack trace?
--
Moritz Ulrich
--
You received this message because you are subscribed to t
"There's nothing wrong" is a pretty strong statement. It works, but it
is definitely the wrong way to do things. Using a letfn, or external
helper functions, is a much better approach.
On May 17, 12:19 pm, Armando Blancas wrote:
> The redefinition of functions somehow is spooking the compiler. Bu
The redefinition of functions somehow is spooking the compiler. But if
you're at the REPL you should be seeing these warnings (are you doing AOT
compile?)
WARNING: double already refers to: #'clojure.core/double in namespace:
user, being replaced by: #'user/double
WARNING: * already refers to: #
2012/5/17 Raoul Duke
> On Thu, May 17, 2012 at 10:55 AM, eniotna wrote:
> > Look at your parenthesis.
> > You did not close your first function.
>
> some day we'll have the technology to let the compiler tell us that,
>
emacs told me.
But i'm sure some other editors can tell you that too.
inst
Furthermore, The syntax you're using is not correct.
If you want to define functions inside your function ex1_17, use letfn.
Something along the line:
(defn ex1_17 []
(letfn [(double [x] (+ x x))
(halve [x] (/ x 2))
(mult [a b]
(cond
(= b 0) 0
On Thu, May 17, 2012 at 10:55 AM, eniotna wrote:
> Look at your parenthesis.
> You did not close your first function.
some day we'll have the technology to let the compiler tell us that,
instead of spewing some horrible, pointless, stack trace?
--
You received this message because you are subsc
Hi,
Look at your parenthesis.
You did not close your first function.
Antoine
2012/5/17 Sargash
> Hi!
>
> I have a problem. With that code:
>
> ; ===
> ; ex 1.17 multiply
> (defn ex1_17 []
> (defn double [x] (+ x x))
> (defn halve [x] (/ x 2))
>
> (defn *
On Nov 9, 2011, at 4:58 PM, Stuart Halloway wrote:
>>> Line 4 of midje.util.report is unusual in several ways: it precedes the ns
>>> call, adds a second ns call, does an eval, and uses def forms not at the
>>> top level:
>>
>> Thanks, Stu. That code was a patch that came in when I was new to
>> Line 4 of midje.util.report is unusual in several ways: it precedes the ns
>> call, adds a second ns call, does an eval, and uses def forms not at the top
>> level:
>
> Thanks, Stu. That code was a patch that came in when I was new to Clojure,
> and I didn't understand it. I think it was a
On Nov 8, 2011, at 8:47 PM, Alan Malloy wrote:
>> (let [ns-obj (the-ns (doto 'clojure.test require))
>> the-var (intern ns-obj 'old-report)]
>> (when-not (.hasRoot the-var)
>> (intern ns-obj 'old-report clojure.test/report)))
>>
>> Seems to have the same effect as the defonce in some
On Nov 8, 2011, at 6:44 PM, Stuart Halloway wrote:
> Line 4 of midje.util.report is unusual in several ways: it precedes the ns
> call, adds a second ns call, does an eval, and uses def forms not at the top
> level:
Thanks, Stu. That code was a patch that came in when I was new to Clojure, an
On Nov 8, 6:46 pm, Alan Malloy wrote:
> On Nov 8, 4:44 pm, Stuart Halloway wrote:
> > > This is under clojure 1.2.0, 1.2.1, 1.3.0, though the error messages
> > > differ.
>
> > > Consider a trivial project that `uses` midje:
>
> > > (ns midje-aot.core
> > > (:use midje.sweet))
>
> > > If
On Nov 8, 4:44 pm, Stuart Halloway wrote:
> > This is under clojure 1.2.0, 1.2.1, 1.3.0, though the error messages differ.
>
> > Consider a trivial project that `uses` midje:
>
> > (ns midje-aot.core
> > (:use midje.sweet))
>
> > If it's aot-compiled, everything appears to go well:
>
> >
> This is under clojure 1.2.0, 1.2.1, 1.3.0, though the error messages differ.
>
> Consider a trivial project that `uses` midje:
>
>(ns midje-aot.core
> (:use midje.sweet))
>
> If it's aot-compiled, everything appears to go well:
>
>1762 $ lein compile
>Copying 6 files to /User
Opened ticket #360 for this.
https://www.assembla.com/spaces/clojure/support/tickets/360-nullpointerexception-on-disj
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 pos
On May 27, 1:10 am, Allen Johnson wrote:
> Hey everyone. I was playing around with the protocols/deftype stuff
> and ran into a weird NullPointerException when calling the satisfies?
> function. Seems to only happen with a java.lang.Object instance.
>
> Clojure 1.2.0-master-SNAPSHOT
> user=> (de
2010/1/15 C. Florian Ebeling :
> I agree. It only looks inconsistent when you assume nil is treated
> uniformly by these comparison function, which does not make sense.
I quite often wish to compare comparable objects that are not numbers
and wrote some simple operators to do that:
user=> ( ( ( (
Also, it is consistent given that == is the numerical analogue to <=,
etc.
--
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
On Jan 14, 9:00 am, "C. Florian Ebeling"
wrote:
> > What do you think should be the boolean result of (> nil 1)?
>
> > Since the inequality functions only work with Numbers, and nil is not
> > a Number. The only way to make that work would be to impute some
> > default numerical value to nil, w
> What do you think should be the boolean result of (> nil 1)?
>
> Since the inequality functions only work with Numbers, and nil is not
> a Number. The only way to make that work would be to impute some
> default numerical value to nil, which would probably introduce more
> problems than it solve
What do you think should be the boolean result of (> nil 1)?
Since the inequality functions only work with Numbers, and nil is not
a Number. The only way to make that work would be to impute some
default numerical value to nil, which would probably introduce more
problems than it solved.
On Jan
Ah,
thanks to both of you for the fast reply - as always, the problem's to
be found between chair and keyboard. ;)
Greetings from Germany,
Sir Diddymus
P.S.: Btw, great props to Meikel for vimclojure - now I can use the
world's best editor with nice Clojure integration. 8)
--~--~-~--
Hi,
Am 01.09.2009 um 17:44 schrieb Sir Diddymus:
(defmacro RunQt [args & body]
`(
(try
(QApplication/initialize (into-array [~args]))
(catch RuntimeException e# (println e#)))
~...@body
(QApplication/exec)))
You have to wrap the try and QApplication/exec call into a `do`:
Hello!
On Tue, Sep 1, 2009 at 5:44 PM, Sir Diddymus wrote:
> Hi all,
>
>> (defmacro RunQt [args & body]
>> `(
>> (try
>> (QApplication/initialize (into-array [~args]))
>> (catch RuntimeException e# (println e#)))
>> ~...@body
>> (QApplication/exec)))
(defmacro RunQt [ar
On Jul 3, 5:27 am, jon wrote:
> Hi, could Rich or someone knowledgeable look into this (reflection
> related?) NullPointerException in Compiler.java.
> I think it's either a bug or at least should provide a better error
> message, but I don't have any time to look deeper into it..
> Thanks, Jon
37 matches
Mail list logo
