> In 1.3, function calls are "compiled through" their vars. If function a calls
> function c inside its body, there is no runtime lookup of the var c. However,
> each function makes a (very low cost) check on entry to see if anything has
> been recompiled. If so, the function is recompiled. This
Dear all,
I am trying top port some code from 1.2 to 1.3 and I end up with this error:
Unknown location:
error: java.lang.VerifyError: (class:
nicolasoury/distributions/core/HashNodeDistribution, method:
delete_BANG_ signature: (Ljava/lang/Object;I)Ljava/lang/Object;)
Expecting to find integer
:
> On Nov 17, 12:31 pm, "nicolas.o...@gmail.com"
> wrote:
>> I am trying top port some code from 1.2 to 1.3 and I end up with this error:
>>
>> Unknown location:
>> error: java.lang.VerifyError: (class:
>
> Wow, that looks like a binary compatibil
I found a minimal case:
(defprotocol A (f [x]))
(deftype T [ ^{:unsynchronized-mutable true} ^int a] A
(f [x] (loop [c 0]
(set! a c
(class: user/T, method: f signature: ()Ljava/lang/Object;) Expecting
to find integer on stack
The problem disappear
I agree that Common Lisp is big and it might take some time to learn.
But it is not a waste of time either. It is an interesting language,
and it is interesting
to see the points of divergence with Clojure and understand them.
However, it might not be the fastest path to Clojure. There are good
bo
> Yes, 1.3 supports only long and double primitives as local variables.
> But the bug doesn't seem to be new. I get the same error if I try to
> assign an int into a long deftype field in 1.2.
>
>
So there is a bug in the way bad primitive assignement are reported or handled.
Has it been reported
> At first this surprised me, since Clojure is dynamically typed, while
> F# is statically typed. After some thought, however, it occurred to me
> that Clojure can generate code very similar to statically typed
> languages using type hints. Of course, as soon as you add type hints,
> the code is no
I think it is due to the fact that [1 2 3] is self-evaluating.
If you were to write
(defn f [x] ^{:order :ascending} x)
(f [1 2 3])
the data would be on x in the compiler but never on [1 2 3]
with-meta would do the right thing.
On Mon, Nov 22, 2010 at 3:57 PM, Mike K wrote:
> In "Programmin
> Type hints don't reduce flexibility AT ALL.
>
> user=> (defn t1 [x] (.length x))
> #'user/t1
> user=> (t1 "foo")
> 3
> user=> (t1 'foo)
> # field found: length for class clojure.lang.Symbol
> (NO_SOURCE_FILE:141)>
>
> Since it calls a String method it doesn't work if you call it with a
> non-Str
Dear all,
Is it already in 1.3 alpha3 (or planned before 1.3) to support
primitives as arguments and return values of members of protocols?
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
On Fri, Nov 26, 2010 at 5:28 PM, tpeng wrote:
> but this foldr can't handle the infinite list, am i right?
>
I doubt there is a foldr that handles the infinite list.
To do anything, it would have to read at least one element: the last.
Alex nice answer is a foldl.
--
You received this message
> Again, there'd have to be a staggering further benefit from the change
> than just "the clojure.core code looks cleaner in github" or even "the
> code is a bit easier to maintain in the future". I'm not sure that
> even massive increases in code maintainability alone suffice for
> something like
> The
> common case is test and accept the result, returning it, in both
> cases; so the common case should have comparable execution speed given
> both implementations. If not, something is wrong someplace else with
> at least one of the implementations (or, much less likely, with the
> JVM/JIT).
>
> The overflow check is the same whether you react to an overflow by
> boxing the result or react to an overflow by throwing an exception!
But then all the rest of the code has to check whether things are boxed or not.
Moreover, the JVM makes it very hard (impossible) to manipulate
something th
Dear all,
Is there a way to wait for all agents to be up-to-date without using await ?
I am in a specific case with a lot of agents and I want all of them to
have finished their work,
and only a few of them had initially work to do.
It is quite wasteful to explicitly await for N agents when on
I could, but I would have to add a watcher on every agent putting them
into a seq hold by an atom.
Which does not seem right, in some way...
On Fri, Dec 17, 2010 at 12:01 PM, Laurent PETIT wrote:
> 2010/12/17 nicolas.o...@gmail.com
>>
>> Dear all,
>>
>>
>> Is t
the computation graph, as
opposed to asynchronous state. Maybe, I was a bit cheating by trying
to use agents...)
Has anyone contributed a wrapper for Fork/Join?
Nicolas.
On Fri, Dec 17, 2010 at 1:14 PM, Laurent PETIT wrote:
> 2010/12/17 nicolas.o...@gmail.com
>>
>> I could, but
> How about futures? They are in clojure.core and can be used for much the same
> purposes as Fork/Join, unless your individual tasks are so small that the
> performance advantage of Fork/Join makes a difference.
>
Thank you for this suggestion. I thought a bit, and I wonder whether
it can resul
Thank you very much for the explanations. I will go for Fork/join.
Anybody is working on a clojure wrapper?
On Fri, Dec 17, 2010 at 7:48 PM, Konrad Hinsen
wrote:
> On 17 Dec 2010, at 19:47, nicolas.o...@gmail.com wrote:
>
>>> How about futures? They are in clojure.core and can b
On Sun, Dec 19, 2010 at 5:21 AM, Tim Daly wrote:
> Axiom, a computer algebra system I maintain,
> can dispatch on return type. I am looking at
> the things Clojure can do that might support
> the Spad language (the mathematical language
> in Axiom). I could not find a way to adjust
> the multimet
On Sun, Dec 19, 2010 at 11:24 AM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 19.12.2010 um 11:36 schrieb nicolas.o...@gmail.com:
>
>> There is no static typing in Clojure. So the notion of return type do
>> not really exists.
>
> Yes. The type system of eg. Haskel
If you wait for clojure in clojure and then use VMkit (LLVM based
thing to do Virtual Machine), it can be an interesting project.
I am not sure if it would be considered as really native, though.
Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure" grou
If you want native with enough reflection to compile clojure,
Objective-C might be a better choice than C++.
--
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
>
> I am not a Clojure expert. But if I understood Clojure correctly,
> Clojure would not be Clojure if it where natively compiled. Eg. The
> whole lazy seq's are required because of lack of tail call
> optimization in the JVM. Or am I wrong?
>
>
I don't think the lazy seq are necessary because of
> In my experience lazy-seqs are a reasonable replacement for the lack of TCO,
> and from what I've heard that is one of the reasons they exist.
> (defn a [x]
> (lazy-seq
> (cons x (b (inc x)
> (defn b [x]
> (lazy-seq
> (cons x (a (inc x)
> David
>
I am not sure I get you. C
> Those are mutual recursive functions. Trying to define them as regular
> functions will quickly result in a stack overflow.
> You could use trampoline but in my experience you will take a significant
> performance hit.
> Lazy sequences are a way to efficiently represent mutually recursive
> compu
> With TCO mutually recursive functions do not consume the stack. The same is
> true for well constructed lazy sequences.
> David
With TCO, mutually *tail* recursive functions do not consume the stack.
non-tail call always consume the stack in non CPS compiled languages.
(In which, it consumes th
> Yes I know, I thought the way I wrote the code was clear about that :)
I am sorry, I did not understand.
So let me try to explicit your transformation (please correct me if I am wrong):
- start with some mutually recursive functions: a and b, for example
- create a "lazy stack" for the recursiv
I have an example to clarify what I understood of your idea:
(declare odd)
(defn even [x]
(if (zero? x)
[true]
(lazy-seq nil (odd (dec x)
(defn odd [ x]
(if (zero? x)
[false]
(lazy-seq nil (even (dec x)
(defn get-value [l]
It's a funy and original trick but on this example at least,
it seems slower (and it can use a lot of memory, because it retains a
stack in the heap) than trampoline:
(time (get-value (even 1500)))
"Elapsed time: 1899.881769 msecs"
And a version with trampoline
(defn odd [^long x]
(i
Which version of Clojure are you using?
(How to speed that up depends a lot of the version you use)
I would like to see a with a longer run.
Optimised clojure is *asymptotically* nearly as fast as Java.
With under 1000 calls I am not sure the JIT is called.
Best,
Nicolas.
On Wed, Dec 22, 2010
Dear all,
Is there a way to make some mutable fields public in a deftype?
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 moder
On Thu, Dec 23, 2010 at 9:28 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 23.12.2010 um 15:26 schrieb nicolas.o...@gmail.com:
>
>> Is there a way to make some mutable fields public in a deftype?
>
> I think it is opinionated, that this is not possible as the documentation
On Thu, Dec 23, 2010 at 10:29 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 23.12.2010 um 23:15 schrieb nicolas.o...@gmail.com:
>
>> If I were to write such a patch, would it be accepted?
>
> I lean now quite a bit out the window, but I dare say: „No.“ The reason I
&g
After a few thoughts, I think this is a mistake not to allow this,
even if it his highly discouraged.
I think indeed, if you consider the data-structure usage of types and
Objects it is a very bad idea to have a mutable private field.
But some type you create are not for holding data on the long-
I never was fully convinced an atom around a functional hash was
perfect for concurrency.
There is no write/write or read/write concurrency possible, even on
independent data.
Someone was working a while ago ob TransactionalHashMap, if I recall well.
Is there something already to benchmark agains
On Mon, Jan 17, 2011 at 3:10 AM, chris wrote:
> Is it insane to suggest that perhaps clojure should work with scala
> such that we can write both languages in the same file?
>
A lot of reasons for which it is not possible:
- it would mean coordinating two implementations/implementers.
- it would
>
> Is this also useful for implementing something like Datalog? If yes,
> in what ways?
>
> Regards,
> Shantanu
I don't know for Datalog but for Prolog.
Imagine you have
parent(a,b).
parent(b,c).
ancestor(X,Y) :- parent(X,Z) , ancestor(Z,Y). (1)
ancestor(X,Y) :- parent(X,Y). (2)
Now you have t
Did you have a look at:
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf
After p. 50 there is a description of dequeues. I don't know how they
compare to yours.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojur
101 - 139 of 139 matches
Mail list logo
