Re: Strange behaviour of a callable record

Thanks, Nicola! It solved it. When I looked at docs, I couldn't figure out the role of `applyTo`. Well, now I know. On Thursday, April 23, 2015 at 1:47:11 PM UTC+2, Nicola Mometto wrote: > > > You're not implementing IFn.applyTo, you should. > > Why applyTo is used in the second example while in

Re: Strange behaviour of a callable record

It would be great if the ticket has more of the original use case as motivation. On Thursday, April 23, 2015 at 7:00:51 AM UTC-5, Nicola Mometto wrote: > > > I've opened an enhancement ticket with a patch that changes this > behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 >

Re: Strange behaviour of a callable record

I've opened an enhancement ticket with a patch that changes this behaviour btw: http://dev.clojure.org/jira/browse/CLJ-1715 Alexey Cherkaev writes: > Hi, > > I have encountered the problem with Clojure 1.6.0, when I create the record > that implements IFn. > > For example, > > (defrecord Foo [x]

Re: Strange behaviour of a callable record

You're not implementing IFn.applyTo, you should. Why applyTo is used in the second example while invoke is used in the other cases has to do with implementation details of how def expressions are compiled/evaluated. Alexey Cherkaev writes: > Hi, > > I have encountered the problem with Clojure 1

Re: Strange behaviour for proxy when two abstract classes are passed in

Ah no wonder! I was looking at the wrong documentation for asm. On 02/04/2014, at 1:41, "A. Webb" wrote: > > > On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote: >> >> I know this is a silly example but I am curious to know what is happening >> with the proxy method. >> >> I have

Re: Strange behaviour for proxy when two abstract classes are passed in

On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote: > > I know this is a silly example but I am curious to know what is happening > with the proxy method. > > I have set up two calls to proxy: > > 1. > (def cp > (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] [])) > > 2. >

Re: strange behaviour

ooo I found this: http://stackoverflow.com/questions/10565874/non-linear-slowdown-creating-a-lazy-seq-in-clojure I did not post this but this guy came up with the same solution... Jim ps: the 'partition' solution does seem much better... On 24/03/13 14:17, Jim - FooBar(); wrote: i'm getting s

Re: strange behaviour

i'm getting slightly paranoid now...let's forget about my code for a second...paste this into your repl: *;;using the original ngrams** (defrecord DUMMY [token tag]) (def Dpairs (doall (repeat 3 (DUMMY. "them" "PRO" ;them->pronoun (def Dtags (mapv :tag Dpairs)) (def tag-ngrams (doall (

Re: strange behaviour

wow! this is even stranger now!!! I removed the call to count from ngrams* and now the same thing happens but all 4 cpus are busy!!! I don't understand... Jim On 24/03/13 13:54, Marko Topolnik wrote: May or may not be related, but calling /count/ on a lazy sequence eagerly consumes the entir

Re: strange behaviour

May or may not be related, but calling *count* on a lazy sequence eagerly consumes the entire sequence. On Sunday, March 24, 2013 2:35:35 PM UTC+1, Jim foo.bar wrote: > > the operation is 'ngrams*' which doesn't care about what objects it > finds in the seq...Typically you'd have characters or

Re: strange behaviour

in other words, I can lose the 'doall' and do this: =>(def ntt-pairs (ngrams* tt-pairs 2)) #'hotel_nlp.algorithms.viterbi/ntt-pairs => (first ntt-pairs) (#hotel_nlp.algorithms.viterbi.TokenTagPair{:token "The", :tag "DET"} #hotel_nlp.algorithms.viterbi.TokenTagPair{:token "Fulton", :tag "NP"})

Re: strange behaviour

the operation is 'ngrams*' which doesn't care about what objects it finds in the seq...Typically you'd have characters or word ngrams but that doesn't mean you can't have any type of object...it simply doesn't care... (defn ngrams* "Create ngrams from a seq s. Pass a single string for chara

Re: strange behaviour

What do you mean by "performing the same operation"? How can you perform the same operation on completely different objects? Do you mean that you don't have the exact same *ngrams** in the first and second case? On Sunday, March 24, 2013 1:45:37 PM UTC+1, Jim foo.bar wrote: > > Hi everyone, > >

Re: Strange behaviour: nested def in proxy method body

Ah, thanks for your reply, both of you! That's why I got confused: it seemed to work when I didn't use proxy. I'll stop using nested defs for now. But I will miss them: they allow me to evaluate them top-level in the REPL (using C-x C-e in emacs) and play around with them. K. On Thursday, D

Re: Strange behaviour: nested def in proxy method body

On Thursday, December 13, 2012 4:14:23 AM UTC-8, Marshall Bockrath-Vandegrift wrote: > kristianlm > writes: > > > I'm enjoying testing Java code with Clojure and it's been a lot of fun > > so far. Coming from Scheme, the transit is comfortable. However, I > > encountered a big surprise when I

Re: Strange behaviour: nested def in proxy method body

kristianlm writes: > I'm enjoying testing Java code with Clojure and it's been a lot of fun > so far. Coming from Scheme, the transit is comfortable. However, I > encountered a big surprise when I nested def's and used them with a > proxy: This is a common surprise for people with previous expos

Re: Strange behaviour

On Nov 17, 2008, at 14:30, Rich Hickey wrote: > It's best to do this as generally as possible, building on something > like this: > > (defn map-same [f coll] > (let [ret (into (empty coll) (map f coll))] > (if (seq? coll) > (reverse ret) > ret))) OK, so I have as a minimal set

Re: Strange behaviour

On Nov 17, 7:56 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > On Nov 17, 2008, at 13:33, mb wrote: > > > vals returns a clojure.lang.APersistentMap$ValSeq, which > > is not a list. Hence list? returns false and you get the true > > branch, ie. the thing itself. > > A. It looks like a li

Re: Strange behaviour

On Nov 17, 2008, at 13:33, mb wrote: > vals returns a clojure.lang.APersistentMap$ValSeq, which > is not a list. Hence list? returns false and you get the true > branch, ie. the thing itself. A. It looks like a list, but it isn't a list. > I know. It doesn't help much, but it shows, tha

Re: Strange behaviour

Hi, On 17 Nov., 13:05, Konrad Hinsen <[EMAIL PROTECTED]> wrote: >         (defn replace-syms >            [sym-map expr] >            (let [replace #(replace-syms sym-map %)] >               (cond (contains? sym-map expr) (get sym-map expr) >                     (list? expr) (map #(replace-syms s