Strange behaviour of a callable record
Hi, I have encountered the problem with Clojure 1.6.0, when I create the record that implements IFn. For example, (defrecord Foo [x] clojure.lang.IFn (invoke [_ f] (f x))) Than create an instance of this record: (def f (->Foo 10)) And we can call it without a problem: user=> (f inc) 11 Yet, if you try to define a value to keep the result, compiler throws an error: user=> (def z (f inc)) CompilerException java.lang.AbstractMethodError, compiling:(form-init4774307052978984831.clj:1:8) There is workaround: create local binding first and then assign the value to a global variable: user=> (def z (let [temp (f inc)] temp)) #'user/z user=> z 11 Is this a bug or I don't fully understand why you can't do that? Cheers, Alexey -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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.6.0, when I create the record > that implements IFn. > > For example, > > (defrecord Foo [x] > clojure.lang.IFn > (invoke [_ f] (f x))) > > Than create an instance of this record: > > (def f (->Foo 10)) > > And we can call it without a problem: > > user=> (f inc) > 11 > > Yet, if you try to define a value to keep the result, compiler throws an > error: > > user=> (def z (f inc)) > > CompilerException java.lang.AbstractMethodError, > compiling:(form-init4774307052978984831.clj:1:8) > > There is workaround: create local binding first and then assign the value > to a global variable: > > user=> (def z (let [temp (f inc)] temp)) > #'user/z > user=> z > 11 > > Is this a bug or I don't fully understand why you can't do that? > > Cheers, Alexey -- -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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] > clojure.lang.IFn > (invoke [_ f] (f x))) > > Than create an instance of this record: > > (def f (->Foo 10)) > > And we can call it without a problem: > > user=> (f inc) > 11 > > Yet, if you try to define a value to keep the result, compiler throws an > error: > > user=> (def z (f inc)) > > CompilerException java.lang.AbstractMethodError, > compiling:(form-init4774307052978984831.clj:1:8) > > There is workaround: create local binding first and then assign the value > to a global variable: > > user=> (def z (let [temp (f inc)] temp)) > #'user/z > user=> z > 11 > > Is this a bug or I don't fully understand why you can't do that? > > Cheers, Alexey -- -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Looking for remote work, small is okay too
Located in munich, germany. I have used the language since 2010, experience with the clojure webstack, shipped code to production for a big german fashion website. Looking for remote work, does not matter if it is a small project or you looking for long-term employees. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
guides for porting clojure to clojurescript
Has anyone written a guide, or best-practices doc for converting clojure libs to clojurescript? I'm thinking of things like "what to do with java methods calls?" Write shim objects? Convert all the method calls to protocols? I expect this has been done many times, especially for common needs, like string methods. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Clojure web server capacity
On Thu, Apr 23, 2015 at 1:34 AM Paul deGrandis wrote: > > I'd also encourage you to reconsider your benchmark - ask yourself, "What > does this really tell me?" Is the benchmark an accurate representation of > the kinds of HTTP services you build? Are the payloads (parsing and > generation) representative of common data you deal with in the systems you > build? Is the network, topology, and traffic generation realistic (or at > least analogous) to production systems? Can the results of the benchmark > directly inform architectural considerations of real systems? > (I'm answering this one, but I really have to thank everyone who has chimed in, all of the comments are valuable) Your comments helped me understand a lot about what I'm trying to do here. The underlying goal is to uncover the fallacy that peak performance of web server frameworks matter a whole lot in practice. To show that, I have a latency oriented benchmark, which is able to show there are some discrepancies in the high percentiles of different frameworks. Usually due to the invocation of GC, or due to queueing/stalling under load. It changes the notion that you have a "winner" because many of the web servers which tend to have good median latencies, turns out to have outright appalling latencies in the 99.9th percentile. Furthermore, the test verifies work is being evenly distributed over all the 10k connections. Again, it turns out that many measurements are flawed because the web server will serve 300 connections, and letting 9700 stall. Then the server can have excellent peak req/s rate, and good average/median latency, but it is pretty bad for real work in a 10k connection setting (think websockets). But to tell that story I don't need a whole lot of "specimens". You made me realize that the work is not about testing every and all frameworks in existence, but rather about presenting differing behavior. In fact, the argument can be made that if I already have undertow in the mix, I have a fairly realistic coverage of how the JVM reacts under load. It can even be argued that I shouldn't test too broadly since people would falsely rely too much on a number for which their use case doesn't match. By not doing so, I would be forcing people to make up their own measurements. I do think there is some value in reporting what I've found up to this point, but I definitely plan to include a large section of caveats and known weaknesses of the test methodology. One, which Paul touches on, is that the network is "perfect" in the sense that it can handle the load from the load generator. But in practice, there will be clients accessing over WAN with highly varying behaviour in the network. This test can't address that point, which is very real in a practical setting. -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Meaning of part of the doc string for `ns-resolve`
The last sentence of the `ns-resolve` documentation reads: Note that if the symbol is fully qualified, the var/Class to which it resolves need not be present in the namespace. What does that mean? I would expect something like the following to produce a non-nil value: user=> (ns-resolve 'clojure.core 'fofofof) user=> (ns-resolve 'clojure.core 'clojure.core/fofofof) user=> (ns-resolve *ns* 'clojure.core/fofofof) ... to produce a non-nil value, but they're all nil. (Note: in the 1.6 API, it looks to me like the only other uses of "fully qualified" refer to classes.) -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Meaning of part of the doc string for `ns-resolve`
Could you clarify why you expect that? Thanks, Ambrose On Thu, Apr 23, 2015 at 6:43 PM, Brian Marick wrote: > The last sentence of the `ns-resolve` documentation reads: > > Note that > if the symbol is fully qualified, the var/Class to which it resolves > need not be present in the namespace. > > What does that mean? I would expect something like the following to > produce a non-nil value: > > user=> (ns-resolve 'clojure.core 'fofofof) > user=> (ns-resolve 'clojure.core 'clojure.core/fofofof) > user=> (ns-resolve *ns* 'clojure.core/fofofof) > > > ... to produce a non-nil value, but they're all nil. > > (Note: in the 1.6 API, it looks to me like the only other uses of "fully > qualified" refer to classes.) > > -- > 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 with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- You received this message because you are subscribed to the Google > Groups "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Meaning of part of the doc string for `ns-resolve`
It's talking about fully qualified symbols that map to an actual var. E.g user=> (ns-resolve *ns* 'clojure.string/join) #'clojure.string/join Brian Marick writes: > The last sentence of the `ns-resolve` documentation reads: > >Note that >if the symbol is fully qualified, the var/Class to which it resolves >need not be present in the namespace. > > What does that mean? I would expect something like the following to > produce a non-nil value: > > user=> (ns-resolve 'clojure.core 'fofofof) > user=> (ns-resolve 'clojure.core 'clojure.core/fofofof) > user=> (ns-resolve *ns* 'clojure.core/fofofof) > > > ... to produce a non-nil value, but they're all nil. > > (Note: in the 1.6 API, it looks to me like the only other uses of "fully > qualified" refer to classes.) -- -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Meaning of part of the doc string for `ns-resolve`
This fails: (ns-resolve 'sumtin 'clecs.world/remove-entity) Exception No namespace: sumtin found clojure.core/the-ns (core.clj:3830) But this succeeds: (ns-resolve 'seesaw.core 'clecs.world/remove-entity) #'clecs.world/remove-entity It seems when the 2nd argument is fully qualified, first argument is not important but it still needs to be a valid namespace. On Fri, Apr 24, 2015 at 1:43 AM, Brian Marick wrote: > The last sentence of the `ns-resolve` documentation reads: > > Note that > if the symbol is fully qualified, the var/Class to which it resolves > need not be present in the namespace. > > What does that mean? I would expect something like the following to > produce a non-nil value: > > user=> (ns-resolve 'clojure.core 'fofofof) > user=> (ns-resolve 'clojure.core 'clojure.core/fofofof) > user=> (ns-resolve *ns* 'clojure.core/fofofof) > > > ... to produce a non-nil value, but they're all nil. > > (Note: in the 1.6 API, it looks to me like the only other uses of "fully > qualified" refer to classes.) > > -- > 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 with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- You received this message because you are subscribed to the Google > Groups "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com www.olcgen.com -- 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 with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
