Re: [ANN] Clojure 1.7.0-alpha5 now available
Hey guys, I noticed that PersistentVector.create() is missing one arity that used to exist before: PersistentVector.create(List items) ... which caused this library https://github.com/ninjudd/clojure-protobuf/blob/develop/src/flatland/protobuf/PersistentProtocolBufferMap.java#L479 to throw NoSuchMethodError clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector; I can fix the library, I don't think it will be a big problem, just making sure that's something you guys were OK with breaking - it's more like an implementation detail as far as I can see. Thanks, Rangel @raspasov On Sunday, January 11, 2015 at 6:34:07 AM UTC-8, Alex Miller wrote: I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok. We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one. Interested particularly in: regressions, performance +/-, and for this alpha, AOT. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
I have a set of micro-benchmarks on a project that is compute-heavy (symbolic regression, genetic programming). I see no performance regressions :-) 1.6.0 http://viewer.gorilla-repl.org/view.html?source=gistid=3e943292b03755681e50filename=expression-1.6.0.clj 1.7.0-alpha5 http://viewer.gorilla-repl.org/view.html?source=gistid=3e943292b03755681e50filename=expression-1.7.0.clj Jony -- 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.
[ANN] POSThere.io 1.0.0
POSThere.io ( http://posthere.io ) is a simple free service for developers to help debug API calls and web hooks. When your code is POSTing to someone else’s code… or they'll be POSTing to you, it can be hard to iterate, debug and validate your code. POSThere.io let's you see what is POSTed (or PUT or PATCHed) at any time in an easy, clear browser interface. After POSTing, point your web browser at the same URL and you’ll see a clear history and details of all the POST requests. Neat, huh? It’s written in Clojure and ClojureScript and it's open source! Check the code and verify we don’t do anything nefarious, or host it yourself. http://github.com/path/posthere.io Cheers, Sean -- 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: Newbie Gloss questions - dynamic buffer structure
Hi Zach
Thanks for the detailed response
On Wednesday, January 7, 2015 at 7:28:06 AM UTC+2, Zach Tellman wrote:
Hey Tzach,
If I understand what you're trying to do, you want something like this:
[ :uint32
:ubyte ;; or bit-seq, depending
(delimited-block (prefix uint24 #(- % 5) #(+ % 5))) ]
And then you'll need to parse the final block separately. I've left
defining the uint24 as an exercise for the reader (sorry, long day), but
using (compile-frame [:uint16 :uint8] ...) should be pretty straightforward.
This is what work for me, in case anyone is interested or want to comment
(defn valid-length [l]
(and ( l 16777216)
(= l 0)))
(def uint24 (compile-frame [:ubyte :uint16]
(fn [u]
{:pre [(valid-length u)]}
(let [u8 (bit-shift-right u 16)
u16 (- u (bit-shift-left u8 16))]
[u8 u16]))
(fn [[u8 u16]]
{:post [(valid-length %)]}
(+ (bit-shift-left u8 16) u16
(def avp
(compile-frame
[:uint32
:ubyte
(repeated :int32 :prefix (prefix uint24 #(- % 5) #(+ % 5))) ]
))
My next step is to parse the bits from the header :ubyte and base on it,
read an extra uint32 before the repeated part.
The header is probably the answer.
Hope that helps, happy to answer any followup questions.
It did help! Thanks
BTW, I spent too much time trying to use (compile-frame [:uint16 :uint8])
before realizing :uint8 is not defined.
The result is simply encoding of the :uint8 symbol.
I wonder if its a bug or a feature.
Zach
On Saturday, January 3, 2015 11:51:14 PM UTC-8, Tzach wrote:
I'm trying to work with Gloss binary encoder/decoder, and need some help
to kick start.
My first task is simple(not for me ;)
I have the following binary buffer to read/write:
- 4 byte (32 bit) - code (uint)
- 8 bit - misc flags
- 3 byte (24 bit) - the entire buffer length
- 4 byte (32 bit) uint value - optional, depending on on of the
flags.
- List of 4 byte (uints) data elements - size dependent on the
overall size
How should I represent this structure?
Clearly I need to use *prefix* and *repeated* for the last element, but
I failed to understand how.
I also struggle with the optional element and how to represent a 3 byte
element.
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 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: [ANN] Clojure 1.7.0-alpha5 now available
Do you have the full stack trace in the cases where you see this without core.async? On Sunday, January 11, 2015 at 7:17:27 PM UTC-6, Sean Corfield wrote: I tried upgrading a few more apps and ran into this same problem in the absence of core.async - but in the presence of core.cache and core.memoize so I'm trying to create a small test case to isolate the issue. Sean On Jan 11, 2015, at 5:07 PM, Sean Corfield se...@corfield.org javascript: wrote: The full Caused by stacktrace is this: Caused by: java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:555) at clojure.core.cache$eval1710$fn__1773$G__1699__1780.invoke(cache.clj:20) at clojure.core.cache$through.invoke(cache.clj:53) at clojure.core.memoize$through_STAR_.invoke(memoize.clj:52) at clojure.lang.Atom.swap(Atom.java:65) at clojure.core$swap_BANG_.invoke(core.clj:2236) at clojure.core.memoize$build_memoizer$fn__12665.doInvoke(memoize.clj:134) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.AFunction$1.doInvoke(AFunction.java:29) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.tools.analyzer.jvm$desugar_host_expr.invoke(jvm.clj:117) at clojure.tools.analyzer.jvm$macroexpand_1.invoke(jvm.clj:174) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:281) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:505) at clojure.tools.analyzer$fn__12469.invoke(analyzer.clj:530) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze_body.invoke(analyzer.clj:366) at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:520) at clojure.tools.analyzer$fn__12471.invoke(analyzer.clj:540) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze.invoke(analyzer.clj:123) at clojure.tools.analyzer.jvm$analyze$fn__14085.invoke(jvm.clj:476) at clojure.lang.AFn.applyToHelper(AFn.java:152) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.core$apply.invoke(core.clj:626) at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1864) at clojure.lang.RestFn.invoke(RestFn.java:425) at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:474) at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:467) at
Re: [ANN] Clojure 1.7.0-alpha5 now available
Rangel - I have filed http://dev.clojure.org/jira/browse/CLJ-1638 to replace the method, which seems like the best solution. On Monday, January 12, 2015 at 3:43:09 AM UTC-6, Rangel Spasov wrote: Hey guys, I noticed that PersistentVector.create() is missing one arity that used to exist before: PersistentVector.create(List items) ... which caused this library https://github.com/ninjudd/clojure-protobuf/blob/develop/src/flatland/protobuf/PersistentProtocolBufferMap.java#L479 to throw NoSuchMethodError clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector; I can fix the library, I don't think it will be a big problem, just making sure that's something you guys were OK with breaking - it's more like an implementation detail as far as I can see. Thanks, Rangel @raspasov On Sunday, January 11, 2015 at 6:34:07 AM UTC-8, Alex Miller wrote: I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok. We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one. Interested particularly in: regressions, performance +/-, and for this alpha, AOT. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
It seems a little odd that there is an ArrayList override but not List. Presumably that is there as an optimisation since ArrayList is such a common case? It seems to have happened in this commit for CLJ-1546, which replaces the List override with ArrayList https://github.com/clojure/clojure/commit/4afd4a7c14c48b5baf3c03196053066483cb4223 I'd probably recommend keeping the old List override around: it is more general, potentially useful for Interop and will help avoid breakage like this (even if it is just an implementation detail). On Monday, 12 January 2015 17:43:09 UTC+8, Rangel Spasov wrote: Hey guys, I noticed that PersistentVector.create() is missing one arity that used to exist before: PersistentVector.create(List items) ... which caused this library https://github.com/ninjudd/clojure-protobuf/blob/develop/src/flatland/protobuf/PersistentProtocolBufferMap.java#L479 to throw NoSuchMethodError clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector; I can fix the library, I don't think it will be a big problem, just making sure that's something you guys were OK with breaking - it's more like an implementation detail as far as I can see. Thanks, Rangel @raspasov On Sunday, January 11, 2015 at 6:34:07 AM UTC-8, Alex Miller wrote: I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok. We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one. Interested particularly in: regressions, performance +/-, and for this alpha, AOT. -- 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: [ANN] Leiningen 2.5.1 released
Hi there, On Monday, January 12, 2015 at 3:22:46 AM UTC+1, hba wrote: The message comes from wget [1] and to fix it i uninstalled it to let leiningen-win-installer [2] use curl instead. If it's more sensible to use curl over wget on Windows by default, then I'd like to have one of you creating a new issue in the lein issue tracker[1]. It's probably also possible to use the %HTTP_CLIENT% environment variable to solve this. If the Windows shell works anything like bash, then this should be something like SET HTTP_CLIENT=call curl -f -L -o [1]: https://github.com/technomancy/leiningen/issues -- Jean Niklas -- 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: [ANN] Clojure 1.7.0-alpha5 now available
Do the failing projects require AOT compilation? we used to see a similar exception in eastwood when reloading core.cache and one of the AOT patches committed can cause some namespaces to be reloaded Il giorno 12/gen/2015 02:17, Sean Corfield s...@corfield.org ha scritto: I tried upgrading a few more apps and ran into this same problem in the absence of core.async - but in the presence of core.cache and core.memoize so I'm trying to create a small test case to isolate the issue. Sean On Jan 11, 2015, at 5:07 PM, Sean Corfield s...@corfield.org wrote: The full Caused by stacktrace is this: Caused by: java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:555) at clojure.core.cache$eval1710$fn__1773$G__1699__1780.invoke(cache.clj:20) at clojure.core.cache$through.invoke(cache.clj:53) at clojure.core.memoize$through_STAR_.invoke(memoize.clj:52) at clojure.lang.Atom.swap(Atom.java:65) at clojure.core$swap_BANG_.invoke(core.clj:2236) at clojure.core.memoize$build_memoizer$fn__12665.doInvoke(memoize.clj:134) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.lang.AFunction$1.doInvoke(AFunction.java:29) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.tools.analyzer.jvm$desugar_host_expr.invoke(jvm.clj:117) at clojure.tools.analyzer.jvm$macroexpand_1.invoke(jvm.clj:174) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:281) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:505) at clojure.tools.analyzer$fn__12469.invoke(analyzer.clj:530) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze_body.invoke(analyzer.clj:366) at clojure.tools.analyzer$analyze_let.invoke(analyzer.clj:520) at clojure.tools.analyzer$fn__12471.invoke(analyzer.clj:540) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:284) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12392.invoke(analyzer.clj:295) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer.jvm$fn__13956.invoke(jvm.clj:66) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$fn__12389.invoke(analyzer.clj:283) at clojure.lang.MultiFn.invoke(MultiFn.java:238) at clojure.tools.analyzer$fn__12346.invoke(analyzer.clj:68) at clojure.lang.MultiFn.invoke(MultiFn.java:233) at clojure.tools.analyzer$analyze.invoke(analyzer.clj:123) at clojure.tools.analyzer.jvm$analyze$fn__14085.invoke(jvm.clj:476) at clojure.lang.AFn.applyToHelper(AFn.java:152) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.core$apply.invoke(core.clj:626) at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1864) at clojure.lang.RestFn.invoke(RestFn.java:425) at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:474) at clojure.tools.analyzer.jvm$analyze.invoke(jvm.clj:467) at clojure.core.async.impl.ioc_macros$state_machine.invoke(ioc_macros.clj:1062) at
Re: [ANN] Clojure 1.7.0-alpha5 now available
Yes, ArrayList is a particularly common case (see http://insideclojure.org/2015/01/07/vec-perf/). I'm going to reinstate the prior one though, no reason to break people (even if they are using an internal method). On Monday, January 12, 2015 at 3:59:09 AM UTC-6, Mikera wrote: It seems a little odd that there is an ArrayList override but not List. Presumably that is there as an optimisation since ArrayList is such a common case? It seems to have happened in this commit for CLJ-1546, which replaces the List override with ArrayList https://github.com/clojure/clojure/commit/4afd4a7c14c48b5baf3c03196053066483cb4223 I'd probably recommend keeping the old List override around: it is more general, potentially useful for Interop and will help avoid breakage like this (even if it is just an implementation detail). On Monday, 12 January 2015 17:43:09 UTC+8, Rangel Spasov wrote: Hey guys, I noticed that PersistentVector.create() is missing one arity that used to exist before: PersistentVector.create(List items) ... which caused this library https://github.com/ninjudd/clojure-protobuf/blob/develop/src/flatland/protobuf/PersistentProtocolBufferMap.java#L479 to throw NoSuchMethodError clojure.lang.PersistentVector.create(Ljava/util/List;)Lclojure/lang/PersistentVector; I can fix the library, I don't think it will be a big problem, just making sure that's something you guys were OK with breaking - it's more like an implementation detail as far as I can see. Thanks, Rangel @raspasov On Sunday, January 11, 2015 at 6:34:07 AM UTC-8, Alex Miller wrote: I would greatly appreciate hearing any feedback about this (or any other) alpha, even if it's just: everything looks ok. We've had a couple of regressions reported and that is hugely helpful as we can quickly turn around fixes for the next one. Interested particularly in: regressions, performance +/-, and for this alpha, AOT. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
Here’s what I see reproducing this in the REPL - this main project doesn't use core.async (but does use a very small AOT'd library). I'm going to try to cut this down to see if I can repro outside our main project (worldsingles.cache is a thin wrapper over core.cache and core.memoize - moving that exact same code to a fresh project, without any other dependencies, works so it's something in combination with our other dependencies): user= (require 'worldsingles.cache) nil user= (defn foo[n] (+ 13 n)) #'user/foo user= (worldsingles.cache/memo foo site) #clojure.lang.AFunction$1@7090307d user= (*1 42) IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization clojure.core/-cache-protocol-fn (core_deftype.clj:555) user= (pst *e) IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization clojure.core/-cache-protocol-fn (core_deftype.clj:555) clojure.core.cache/eval2178/fn--2241/G--2167--2248 (cache.clj:20) clojure.core.cache/through (cache.clj:53) clojure.core.memoize/through* (memoize.clj:52) clojure.lang.Atom.swap (Atom.java:65) clojure.core/swap! (core.clj:2236) clojure.core.memoize/build-memoizer/fn--12665 (memoize.clj:134) clojure.lang.AFunction$1.doInvoke (AFunction.java:29) user/eval2486 (form-init7972562298655212181.clj:1) clojure.lang.Compiler.eval (Compiler.java:6767) clojure.lang.Compiler.eval (Compiler.java:6730) clojure.core/eval (core.clj:3076) nil user= (clojure.stacktrace/print-stack-trace *e) java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:555) clojure.core.cache$eval2178$fn__2241$G__2167__2248.invoke (cache.clj:20) clojure.core.cache$through.invoke (cache.clj:53) clojure.core.memoize$through_STAR_.invoke (memoize.clj:52) clojure.lang.Atom.swap (Atom.java:65) clojure.core$swap_BANG_.invoke (core.clj:2236) clojure.core.memoize$build_memoizer$fn__12665.doInvoke (memoize.clj:134) clojure.lang.RestFn.applyTo (RestFn.java:137) clojure.lang.AFunction$1.doInvoke (AFunction.java:29) clojure.lang.RestFn.invoke (RestFn.java:408) user$eval2486.invoke (form-init7972562298655212181.clj:1) clojure.lang.Compiler.eval (Compiler.java:6767) clojure.lang.Compiler.eval (Compiler.java:6730) clojure.core$eval.invoke (core.clj:3076) clojure.main$repl$read_eval_print__7311$fn__7314.invoke (main.clj:239) clojure.main$repl$read_eval_print__7311.invoke (main.clj:239) clojure.main$repl$fn__7320.invoke (main.clj:257) clojure.main$repl.doInvoke (main.clj:257) clojure.lang.RestFn.invoke (RestFn.java:1523) clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__876.invoke (interruptible_eval.clj:67) clojure.lang.AFn.applyToHelper (AFn.java:152) clojure.lang.AFn.applyTo (AFn.java:144) clojure.core$apply.invoke (core.clj:626) clojure.core$with_bindings_STAR_.doInvoke (core.clj:1864) clojure.lang.RestFn.invoke (RestFn.java:425) clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:51) clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__918$fn__921.invoke (interruptible_eval.clj:183) clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__911.invoke (interruptible_eval.clj:152) clojure.lang.AFn.run (AFn.java:22) java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617) java.lang.Thread.run (Thread.java:745) nil user= On Jan 12, 2015, at 6:30 AM, Alex Miller a...@puredanger.com wrote: Do you have the full stack trace in the cases where you see this without core.async? -- 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: [ANN] Clojure 1.7.0-alpha5 now available
On Jan 12, 2015, at 3:00 AM, Bronsa brobro...@gmail.com wrote: Do the failing projects require AOT compilation? we used to see a similar exception in eastwood when reloading core.cache and one of the AOT patches committed can cause some namespaces to be reloaded We have one (very small) AOT’d library that interfaces with log4j. All our main projects depend on that. We did lein clean on all our projects and rebuilt all of them from scratch on Alpha 5. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: [ANN] Clojure 1.7.0-alpha5 now available
http://dev.clojure.org/jira/browse/CLJ-1639 http://dev.clojure.org/jira/browse/CLJ-1639 On Jan 12, 2015, at 10:37 AM, Alex Miller a...@puredanger.com wrote: I would be helpful to me at this point to have a jira regarding this problem which I will presume for the time being is the same in both Andy and Sean's case. -- 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: micrologic - A tiny, literate implementation of miniKanren/core.logic
This is fantastic! Thanks a lot. On Thu, Jan 8, 2015 at 9:26 PM, David Nolen dnolen.li...@gmail.com wrote: Nothing to add other than this is really cool. David On Thu, Jan 8, 2015 at 1:56 PM, Russell Mull russell.m...@gmail.com wrote: Hi fellow Clojurists, I've been working on a small miniKanren in Clojure. It started as a port of https://github.com/jasonhemann/microKanren. But this one is interesting because: - It's a literate program, with far more description and examples than actual code. - Many names have been changed to be more descriptive than that which is found in the literature, at least to my eye. - It's written in idiomatic Clojure. It should be a good introduction to the way miniKanren and core.logic work, especially if you're more software engineer than computer scientist. Is this useful, confusing? Wrong in places? please let me know if you have any feedback! http://mullr.github.io/micrologic/literate.html Cheers, Russell -- 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. -- Kind Regards, Atamert Ölçgen -+- --+ +++ www.muhuk.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.
[ANN] dformat 0.1.0
A tiny library, my first open-source Clojure release. Removes some head-scratching when formatting dates (is it or ? or YYY?) by building date format strings automatically based on a sample. For example: (dformat date March 1, 1999) ;; June 9, 2011 (dformat date Jan 1, 1999) ;; Jun 9, 2011 (dformat date Jan 01) ;; Jun 09 (dformat date Sunday, May 1, 2000) ;; Thursday, June 9, 2011 (dformat date Sun Aug 5) ;; Thu Jun 9 (dformat date 12/31/99);; 06/09/11 (dformat date DOB: 12/31/2000) ;; DOB: 06/09/2011 (dformat date March 15, 1999) ;; June 09, 2011 https://github.com/zirkonit/dformat All comments are welcome! -- 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: [ANN] dformat 0.1.0
It seems so obvious in retrospect... :) Good job. On Monday, January 12, 2015 at 4:43:08 PM UTC-5, zirkonit wrote: A tiny library, my first open-source Clojure release. Removes some head-scratching when formatting dates (is it or ? or YYY?) by building date format strings automatically based on a sample. For example: (dformat date March 1, 1999) ;; June 9, 2011 (dformat date Jan 1, 1999) ;; Jun 9, 2011 (dformat date Jan 01) ;; Jun 09 (dformat date Sunday, May 1, 2000) ;; Thursday, June 9, 2011 (dformat date Sun Aug 5) ;; Thu Jun 9 (dformat date 12/31/99);; 06/09/11 (dformat date DOB: 12/31/2000) ;; DOB: 06/09/2011 (dformat date March 15, 1999) ;; June 09, 2011 https://github.com/zirkonit/dformat All comments are welcome! -- 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: resolving eval-created ephemeral classes that do not get unloaded
There's no need to use eval when reflection will do. On Mon, Jan 12, 2015 at 6:45 PM Wei pw Peng write.to.peng@gmail.com wrote: I have a problem with stacking ephemeral dynamically generated classes that do not get unloaded, and therefore the host JVM's class count constantly increases. My situation is like this. I have a need in my program to dynamically interop with Java (see the example below for the exact meaning of dynamically interop with Java). I use the following trick to bypass the CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined error: (def ^:dynamic *hack*) (let [obj abc method replace args [\a \b]] (binding [*hack* (atom obj)] (eval `(. @*hack* ~(symbol method) ~@args ;; = bbc This works fine for my purpose---functionally. However, profiling shows that the JVM loads more classes over time without unloading. The classes that are get loaded have names like clojure.core$eval12345 (with the number constantly growing)., which suggests that the above code may be the culprit. Profiling also suggests that my program do not have other memory leak problem besides this class leak problem---the heap consumption is flat with repeated job. It is the non-heap memory usage that is associated with class loading that keeps on growing. Any suggestion on how to resolve this is appreciated. -- 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: [ANN] dformat 0.1.0
Very nice! On Monday, 12 January 2015 21:43:08 UTC, zirkonit wrote: A tiny library, my first open-source Clojure release. Removes some head-scratching when formatting dates (is it or ? or YYY?) by building date format strings automatically based on a sample. For example: (dformat date March 1, 1999) ;; June 9, 2011 (dformat date Jan 1, 1999) ;; Jun 9, 2011 (dformat date Jan 01) ;; Jun 09 (dformat date Sunday, May 1, 2000) ;; Thursday, June 9, 2011 (dformat date Sun Aug 5) ;; Thu Jun 9 (dformat date 12/31/99);; 06/09/11 (dformat date DOB: 12/31/2000) ;; DOB: 06/09/2011 (dformat date March 15, 1999) ;; June 09, 2011 https://github.com/zirkonit/dformat All comments are welcome! -- 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: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
b) It looks like you are consistently about 2x faster than JBlas for large matrices - wondering what is causing the difference, is that because of copying? That is the most probable cause, but I am not sure whether it is the only one. c) Would be interesting to see a few other operations: I do a lot of work with stochastic gradient descent for example so addition and multiply-and-add can be even more important than matrix multiply. Multiply-and-add is already there. See the docs. Neanderthal closely follows BLAS, so the default multiply is actually multiply-and-add. On Tuesday, 13 January 2015 09:13:13 UTC+8, Dragan Djuric wrote: I am pleased to announce a first public release of new *very fast *native matrix and linear algebra library for Clojure based on ATLAS BLAS. Extensive *documentation* is at http://neanderthal.uncomplicate.org See the benchmarks at http://neanderthal.uncomplicate.org/articles/benchmarks.html. Neanderthal is a Clojure library that Main project goals are: - Be as fast as native ATLAS even for linear operations, with no copying overhead. It is roughly 2x faster than jBLAS for large matrices, and tens of times faster for small ones. Also faster than core.matrix for small and large matrices! - Fit well into idiomatic Clojure - Clojure programmers should be able to use and understand Neanderthal like any regular Clojure library. - Fit well into numerical computing literature - programmers should be able to reuse existing widespread BLAS and LAPACK programming know-how and easily translate it to Clojure code. Implemented features - Data structures: double vector, double general dense matrix (GE); - BLAS Level 1, 2, and 3 routines; - Various Clojure vector and matrix functions (transpositions, submatrices etc.); - Fast map, reduce and fold implementations for the provided structures. On the TODO list - LAPACK routines; - Banded, symmetric, triangular, and sparse matrices; - Support for complex numbers; - Support for single-precision floats. Call for help: Everything you need for Linux is in Clojars. If you know your way around gcc on OS X, or around gcc and MinGW on Windows, and you are willing to help providing the binary builds for those (or other) systems, please contact me. There is an automatic build script, but gcc, atlas and other build tools need to be properly set up on those systems. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
On Jan 12, 2015, at 11:32 AM, Sean Corfield s...@corfield.org wrote: http://dev.clojure.org/jira/browse/CLJ-1639 http://dev.clojure.org/jira/browse/CLJ-1639 It turned out to be due to core.typed whose JAR includes AOT’d versions of core.cache and core.memoize amongst others. I’ve left this issue open with comments for input from Clojure/core and opened a new issue against core.typed instead. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: resolving eval-created ephemeral classes that do not get unloaded
Thanks for the reply, Gary. Indeed, reflection is a better solution in this scenario. On a closer look, those ephemeral classes are loaded by clojure.lang.DynamicClassLoader, each with a retained size of 2,576 bytes, and is only referred to with soft/weak references from GC roots. So, not much of a problem. On Monday, January 12, 2015 at 6:51:48 PM UTC-5, Gary Trakhman wrote: There's no need to use eval when reflection will do. On Mon, Jan 12, 2015 at 6:45 PM Wei pw Peng write.to...@gmail.com javascript: wrote: I have a problem with stacking ephemeral dynamically generated classes that do not get unloaded, and therefore the host JVM's class count constantly increases. My situation is like this. I have a need in my program to dynamically interop with Java (see the example below for the exact meaning of dynamically interop with Java). I use the following trick to bypass the CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined error: (def ^:dynamic *hack*) (let [obj abc method replace args [\a \b]] (binding [*hack* (atom obj)] (eval `(. @*hack* ~(symbol method) ~@args ;; = bbc This works fine for my purpose---functionally. However, profiling shows that the JVM loads more classes over time without unloading. The classes that are get loaded have names like clojure.core$eval12345 (with the number constantly growing)., which suggests that the above code may be the culprit. Profiling also suggests that my program do not have other memory leak problem besides this class leak problem---the heap consumption is flat with repeated job. It is the non-heap memory usage that is associated with class loading that keeps on growing. Any suggestion on how to resolve this is appreciated. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. 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: equivalent of Compojure resources in juxt/bidi
Hi Clifford,
First, br/resource-maybe can only appear as the second item of a route
pair, because it only satisfies the bidi.bidi/Matched protocol. The first
item of a route pair is for patterns only, i.e. types that satisfy
bidi.bidi/Pattern protocol.
What you are trying to do is easy (when you know how).
Let's assume you have a file in your project resources/public/foo.txt such
that
(io/resource public/foo.txt)
returns non-nil
Your route structure could look like this :-
(def routes
[ [
[/index.html :index]
[ (br/resources {:prefix public})]
]])
Note here I'm using a *vector-of-vectors* syntax, which I recommend when
you have ambiguous patterns because the order in which the patterns should
be tried is made explicit. (You can use maps, but I suggest using the more
verbose vector-of-vectors syntax in cases such as this)
(bidi/match-route routes /index.html) = {:handler :index}
as we should expect.
(bidi/match-route routes /foo.txt)
will try fail the /index.html pattern, and try the pattern with a
remainder of /foo.txt. The prefix of public is then preprending,
resulting in the string public/foo.txt, which is passed to io/resource -
and we get a hit.
The difference between resources and resources-maybe, is that resources
will always return a handler - if the resource doesn't exist the handler
will return {:status 404} - no other patterns will be tried. If you use
resources-maybe, then a nil is returned if there is no matching resource,
and any remaining patterns are then tried.
I hope this helps - let me know if you need more help.
Regards,
Malcolm
On Monday, 12 January 2015 07:27:16 UTC, cliff wrote:
Would something like this be correct?
(def routes
[ {
/ {[ (br/resources-maybe {:prefix public})]
:home-page-handler}}])
On Monday, 12 January 2015 08:39:19 UTC+2, cliff wrote:
Hi Dan
Thanks for that. I have read that section.
My question is, how do I associate the / route with both a handler and
the 'resources-maybe'?
I would like the resources to pick up the Google Closure library sitting
in 'resources/public/js/out' when navigating to '/index.html'
On Monday, 12 January 2015 00:36:59 UTC+2, Dan Kersten wrote:
Hi,
Take a look at https://github.com/juxt/bidi#resources-and-resourcesmaybe
Regards,
Dan
On 11 January 2015 at 19:27, cliff clifford...@gmail.com wrote:
Hi
I am trying to mimic the following Compojure behaviour, in juxt/bidi
(defroutes routes
(*resources* /)
(GET /* req (io/resource index.html)))
(def http-handler (reload/wrap-reload (api #'routes)))
In Compojure, the 'resources' function seems to load all resources by
default from /resources/public/.
When I try set up the equivalent routes in bidi, I keep getting errors
of resources not found.
How would you do this in, juxt/bidi ?
Thanks
Clifford
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@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+u...@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: [ANN] modularity.org
Hi James,
If I understand your pattern correctly, you assoc a :routes entry to each
component that contains routes. Then your router component depends on these
components, selecting those that have a :routes key, and call each :routes
value function in turn until one return a non-nil Ring response.?
I think the two approaches share the same essential design.
First, the db (or anything else) is injected via the closure's lexical
scope, which I think is one of the nicest aspects of the component pattern
(compared with alternative approaches listed
here http://stuartsierra.com/2013/03/29/perils-of-dynamic-scope)
The component-with-routes-to-try is 'marked' as such by having a :routes
key. With my bidi-based design I similarly 'mark' a component, but with a
protocol (modular.bidi.WebService). Essentially bidi works the same way as
Compojure - rather than calling functions, it keeps trying to match
patterns until it gets one that returns a non-nil map.
Aside: The reason I mark components with a protocol is because I need the
component to provide two maps - one from routes to keywords, the other from
keywords to handlers. This is not a core bidi idea, but something extra
I've built on top by extending bidi's protocols in modular.bidi, which has
to do with wanting the option of url formation (from the keyword back to
the path). I'm not yet sure if this is the right design.
In summary, yes, I think that the endpoint-component approach would work
very well with Modular and having a Compojure router component (together
with the endpoint-component function/pattern) would be very valuable.
Regards,
Malcolm
On Friday, 9 January 2015 16:34:05 UTC, James Reeves wrote:
On 8 January 2015 at 15:10, Malcolm Sparks mal...@juxt.pro javascript:
wrote:
The idea here is that you want individual components to be able to
'contribute' groups of routes. That way, you can avoid the common practice
of having one big 'god' namespace containing all the Ring routes, which is
then tightly coupled to all your Ring handlers. Instead, it's nice to have
the flexibility to compose systems from different combinations of
components.
One implementation approach is to have a 'router' component that
delegates to its dependencies. That way, routes can be 'plugged in' using
dependency declarations.
Currently I only implemented this with bidi, which I'm slightly biased
towards (because I wrote it). My 'router' implementation is here:
https://github.com/juxt/modular/blob/master/modules/bidi/src/modular/bidi.clj
That's an interesting setup. Are you merging the data-driven bidi routes
together?
If I may, let me run past you an idea I've been experimenting with that
has a similar goal.
I've been using functions that take in a configuration map (in practice, a
component) and return a handler. I call these endpoints (highly original,
I know).
(defn hello-endpoint [config]
(fn [request]
{:status 200
:headers {Content-Type text/plain}
:bodyHello World}))
Wrapping endpoints in a component is relatively straightforward:
https://github.com/weavejester/duct/blob/master/duct/src/duct/component/endpoint.clj
In Duct, the template/framework I'm designing, I use the Compojure
mechanism of trying endpoints in turn until one returns a non-nil value.
However, one could quite easily write a routing mechanism that dispatches
on a context path, or a regular expression.
This approach is pretty minimal, but has a few advantages:
1. It's not tied to a particular routing library
2. It's a simple interface
3. Configuration is passed down via a closure destructuring
As a more practical example, consider an endpoint that relies on a
database connection:
(defn product-endpoint [{db :db}]
(routes
(GET / [](list-products db)
(POST / [product] (add-product db product))
(GET /:id [id] (find-product db id
When we come to write our system, we wrap the endpoint in a component, and
have it depend upon the database component:
(defn new-system [config]
(- (component/system-map
:db (database (:db config))
:product (endpoint-component product-endpoint))
(component/system-using
{:product [:db]}))
(In the above example I've omitted the component that combines all the
endpoints together into a handler, as I think that's a more opinionated
component.)
Do you think this endpoint approach could work in Modular? I like the
idea of having a standard way of defining a subset of routes that depend on
a configuration.
- James
--
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
[ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
I am pleased to announce a first public release of new *very fast *native matrix and linear algebra library for Clojure based on ATLAS BLAS. Extensive *documentation* is at http://neanderthal.uncomplicate.org See the benchmarks at http://neanderthal.uncomplicate.org/articles/benchmarks.html. Neanderthal is a Clojure library that Main project goals are: - Be as fast as native ATLAS even for linear operations, with no copying overhead. It is roughly 2x faster than jBLAS for large matrices, and tens of times faster for small ones. Also faster than core.matrix for small and large matrices! - Fit well into idiomatic Clojure - Clojure programmers should be able to use and understand Neanderthal like any regular Clojure library. - Fit well into numerical computing literature - programmers should be able to reuse existing widespread BLAS and LAPACK programming know-how and easily translate it to Clojure code. Implemented features - Data structures: double vector, double general dense matrix (GE); - BLAS Level 1, 2, and 3 routines; - Various Clojure vector and matrix functions (transpositions, submatrices etc.); - Fast map, reduce and fold implementations for the provided structures. On the TODO list - LAPACK routines; - Banded, symmetric, triangular, and sparse matrices; - Support for complex numbers; - Support for single-precision floats. Call for help: Everything you need for Linux is in Clojars. If you know your way around gcc on OS X, or around gcc and MinGW on Windows, and you are willing to help providing the binary builds for those (or other) systems, please contact me. There is an automatic build script, but gcc, atlas and other build tools need to be properly set up on those systems. -- 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: Help with Incanter and Emacs
Wish this was in the Incanter docs and in the Readme
On Tuesday, August 13, 2013 at 12:09:20 PM UTC-7, Tim Visher wrote:
LOL. I just realized I'd been missing that all along.
It seems like the community is more and more leaning to something like
this, just FYI.
(ns default.core
(:require (incanter [core :refer :all]
[charts:refer :all]
[stats :refer :all]
[datasets :refer :all])))
`:use` has been discussed in the interest of deprecating it many times.
I did not test the above declaration.
On Tue, Aug 13, 2013 at 2:40 PM, Akhil Wali green.tr...@gmail.com
javascript: wrote:
Well this is embarrassing.
I was having a wrong use syntax ..
Changed the import line to this and it works.
(ns default.core
(:use [incanter core charts stats datasets]))
Thanks for the help though!!
On Tuesday, August 13, 2013 11:57:46 PM UTC+5:30, Akhil Wali wrote:
Yes, by nrepl-jack-in.
On Tuesday, August 13, 2013 11:54:24 PM UTC+5:30, Tim Visher wrote:
And you're connecting to the project how?
On Tue, Aug 13, 2013 at 2:11 PM, Akhil Wali green.tr...@gmail.com
wrote:
Well
Here's my project.clj.
(defproject someproj 0.1.0-SNAPSHOT
:dependencies [[org.clojure/clojure 1.5.1]
[incanter 1.5.2]])
Here's my .lein/profiles.clj as well.
{:user {:plugins [[lein-ritz 0.7.0]
[compojure-app/lein-template 0.2.7]]
:dependencies [[ritz/ritz-nrepl-middleware 0.7.0]]
:repl-options {:nrepl-middleware
[ritz.nrepl.middleware.javadoc/wrap-javadoc
ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}}}
On Tuesday, August 13, 2013 11:35:58 PM UTC+5:30, Tim Visher wrote:
On Tue, Aug 13, 2013 at 1:59 PM, Akhil Wali green.tr...@gmail.com
wrote:
Hi All,
A really noob question.
Why do I get FileNotFoundException Could not locate
incanter__init.class or
incanter.clj on classpath: clojure.lang.RT.load (RT.java:443)
when i
load
a file that uses incanter in emacs?
Here's the file...
(ns default.core
(:require incanter core charts stats datasets))
(defn plot []
(view (scatter-plot :Sepal.Length :Sepal.Width
:group-by :Species
:data (get-dataset :iris
(plot)
This works in lein repl just fine.
I'm using Emacs 24 and nrepl.el 0.1.8.
This issue was posted on Github way long back. Seems to be
solved,
but
by
simply upgrading emacs. Doesn't really work in my case.
Any advise?
Couple things.
1. I'm assuming you've declared the proper dependencies in your
`project.clj` file since this works from `lein repl`, however it's
worth checking.
2. How are you connecting to your project? Simply loading the
namespace won't work if you haven't properly jack in. There's a
number
of options here but the simplest is probably to use `M-x
nrepl-jack-in` (usually bound to `C-c M-j`) from this file. It
should
Just Work™.
If that doesn't work, I'd probably post some more details about the
project somewhere. At least the `project.clj` and the whole ns
would
be helpful in a gist of some sort.
--
In Christ,
Timmy V.
http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.com
javascript:
Note that posts from new members are moderated - please be patient with
your
first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
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
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
Looks cool Dragan, thanks for sharing! I would strongly encourage you to wrap this up and make it work as a core.matrix implementation. That would considerably improve interoperability with other libraries / tools in the Clojure numerical space e.g. it could be used as a drop-in replacement for Clatrix in Incanter 2.0 for example. The work to do this is fairly simple - you just need to implement a few mandatory protocols from clojure.core.matrix.protocols. Most of the protocols are optional: you only need to implement them if you want to provide a high performance override of the default behaviour. I'm particularly keen that we avoid API fragmentation in the Clojure numerical space (this has plagued many other language communities, e.g. Java). If every such library comes with its own API, then we won't be able to build a strong ecosystem of composable tools (which is in my view pretty fundamental to the Clojure style of development) Some quick thoughts on the benchmarks: a) I'm quite pleased to see that my little pure-Java matrix multiplication implementation comes within an order of magnitude of BLAS/ATLAS :-) thanks for giving me some further improvements to target! b) It looks like you are consistently about 2x faster than JBlas for large matrices - wondering what is causing the difference, is that because of copying? c) Would be interesting to see a few other operations: I do a lot of work with stochastic gradient descent for example so addition and multiply-and-add can be even more important than matrix multiply. On Tuesday, 13 January 2015 09:13:13 UTC+8, Dragan Djuric wrote: I am pleased to announce a first public release of new *very fast *native matrix and linear algebra library for Clojure based on ATLAS BLAS. Extensive *documentation* is at http://neanderthal.uncomplicate.org See the benchmarks at http://neanderthal.uncomplicate.org/articles/benchmarks.html. Neanderthal is a Clojure library that Main project goals are: - Be as fast as native ATLAS even for linear operations, with no copying overhead. It is roughly 2x faster than jBLAS for large matrices, and tens of times faster for small ones. Also faster than core.matrix for small and large matrices! - Fit well into idiomatic Clojure - Clojure programmers should be able to use and understand Neanderthal like any regular Clojure library. - Fit well into numerical computing literature - programmers should be able to reuse existing widespread BLAS and LAPACK programming know-how and easily translate it to Clojure code. Implemented features - Data structures: double vector, double general dense matrix (GE); - BLAS Level 1, 2, and 3 routines; - Various Clojure vector and matrix functions (transpositions, submatrices etc.); - Fast map, reduce and fold implementations for the provided structures. On the TODO list - LAPACK routines; - Banded, symmetric, triangular, and sparse matrices; - Support for complex numbers; - Support for single-precision floats. Call for help: Everything you need for Linux is in Clojars. If you know your way around gcc on OS X, or around gcc and MinGW on Windows, and you are willing to help providing the binary builds for those (or other) systems, please contact me. There is an automatic build script, but gcc, atlas and other build tools need to be properly set up on those systems. -- 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.
resolving eval-created ephemeral classes that do not get unloaded
I have a problem with stacking ephemeral dynamically generated classes that do not get unloaded, and therefore the host JVM's class count constantly increases. My situation is like this. I have a need in my program to dynamically interop with Java (see the example below for the exact meaning of dynamically interop with Java). I use the following trick to bypass the CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined error: (def ^:dynamic *hack*) (let [obj abc method replace args [\a \b]] (binding [*hack* (atom obj)] (eval `(. @*hack* ~(symbol method) ~@args ;; = bbc This works fine for my purpose---functionally. However, profiling shows that the JVM loads more classes over time without unloading. The classes that are get loaded have names like clojure.core$eval12345 (with the number constantly growing)., which suggests that the above code may be the culprit. Profiling also suggests that my program do not have other memory leak problem besides this class leak problem---the heap consumption is flat with repeated job. It is the non-heap memory usage that is associated with class loading that keeps on growing. Any suggestion on how to resolve this is appreciated. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
Oh, and all our apps now pass / work correctly on 1.7.0-alpha5 (I stripped Typed Clojure out of our code base to make it all work). Sean On Jan 12, 2015, at 6:25 PM, Sean Corfield s...@corfield.org wrote: On Jan 12, 2015, at 11:32 AM, Sean Corfield s...@corfield.org mailto:s...@corfield.org wrote: http://dev.clojure.org/jira/browse/CLJ-1639 http://dev.clojure.org/jira/browse/CLJ-1639 It turned out to be due to core.typed whose JAR includes AOT’d versions of core.cache and core.memoize amongst others. I’ve left this issue open with comments for input from Clojure/core and opened a new issue against core.typed instead. -- 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: equivalent of Compojure resources in juxt/bidi
It works, thanks Malcom. It is surprisingly easy once you understand how to wire it together. Thanks for your help and a great library. Clifford On Sunday, 11 January 2015 21:27:06 UTC+2, cliff wrote: Hi I am trying to mimic the following Compojure behaviour, in juxt/bidi (defroutes routes (*resources* /) (GET /* req (io/resource index.html))) (def http-handler (reload/wrap-reload (api #'routes))) In Compojure, the 'resources' function seems to load all resources by default from /resources/public/. When I try set up the equivalent routes in bidi, I keep getting errors of resources not found. How would you do this in, juxt/bidi ? Thanks Clifford -- 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: [ANN] Clojure 1.7.0-alpha5 now available
Can you try a custom version of clojure 1.7.0-alpha5 with commit e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still get the exception? Nicola Sean Corfield writes: Here’s what I see reproducing this in the REPL - this main project doesn't use core.async (but does use a very small AOT'd library). I'm going to try to cut this down to see if I can repro outside our main project (worldsingles.cache is a thin wrapper over core.cache and core.memoize - moving that exact same code to a fresh project, without any other dependencies, works so it's something in combination with our other dependencies): user= (require 'worldsingles.cache) nil user= (defn foo[n] (+ 13 n)) #'user/foo user= (worldsingles.cache/memo foo site) #clojure.lang.AFunction$1@7090307d user= (*1 42) IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization clojure.core/-cache-protocol-fn (core_deftype.clj:555) user= (pst *e) IllegalArgumentException No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization clojure.core/-cache-protocol-fn (core_deftype.clj:555) clojure.core.cache/eval2178/fn--2241/G--2167--2248 (cache.clj:20) clojure.core.cache/through (cache.clj:53) clojure.core.memoize/through* (memoize.clj:52) clojure.lang.Atom.swap (Atom.java:65) clojure.core/swap! (core.clj:2236) clojure.core.memoize/build-memoizer/fn--12665 (memoize.clj:134) clojure.lang.AFunction$1.doInvoke (AFunction.java:29) user/eval2486 (form-init7972562298655212181.clj:1) clojure.lang.Compiler.eval (Compiler.java:6767) clojure.lang.Compiler.eval (Compiler.java:6730) clojure.core/eval (core.clj:3076) nil user= (clojure.stacktrace/print-stack-trace *e) java.lang.IllegalArgumentException: No implementation of method: :has? of protocol: #'clojure.core.cache/CacheProtocol found for class: clojure.core.memoize.PluggableMemoization at clojure.core$_cache_protocol_fn.invoke (core_deftype.clj:555) clojure.core.cache$eval2178$fn__2241$G__2167__2248.invoke (cache.clj:20) clojure.core.cache$through.invoke (cache.clj:53) clojure.core.memoize$through_STAR_.invoke (memoize.clj:52) clojure.lang.Atom.swap (Atom.java:65) clojure.core$swap_BANG_.invoke (core.clj:2236) clojure.core.memoize$build_memoizer$fn__12665.doInvoke (memoize.clj:134) clojure.lang.RestFn.applyTo (RestFn.java:137) clojure.lang.AFunction$1.doInvoke (AFunction.java:29) clojure.lang.RestFn.invoke (RestFn.java:408) user$eval2486.invoke (form-init7972562298655212181.clj:1) clojure.lang.Compiler.eval (Compiler.java:6767) clojure.lang.Compiler.eval (Compiler.java:6730) clojure.core$eval.invoke (core.clj:3076) clojure.main$repl$read_eval_print__7311$fn__7314.invoke (main.clj:239) clojure.main$repl$read_eval_print__7311.invoke (main.clj:239) clojure.main$repl$fn__7320.invoke (main.clj:257) clojure.main$repl.doInvoke (main.clj:257) clojure.lang.RestFn.invoke (RestFn.java:1523) clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__876.invoke (interruptible_eval.clj:67) clojure.lang.AFn.applyToHelper (AFn.java:152) clojure.lang.AFn.applyTo (AFn.java:144) clojure.core$apply.invoke (core.clj:626) clojure.core$with_bindings_STAR_.doInvoke (core.clj:1864) clojure.lang.RestFn.invoke (RestFn.java:425) clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke (interruptible_eval.clj:51) clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__918$fn__921.invoke (interruptible_eval.clj:183) clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__911.invoke (interruptible_eval.clj:152) clojure.lang.AFn.run (AFn.java:22) java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617) java.lang.Thread.run (Thread.java:745) nil user= On Jan 12, 2015, at 6:30 AM, Alex Miller a...@puredanger.com wrote: Do you have the full stack trace in the cases where you see this without core.async? -- -- 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
Re: [ANN] Clojure 1.7.0-alpha5 now available
On Jan 12, 2015, at 8:09 AM, Nicola Mometto brobro...@gmail.com wrote: Can you try a custom version of clojure 1.7.0-alpha5 with commit e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still get the exception? Yes, reverting that one commit and creating Clojure 1.7.0-aot5 and rebuilding and testing our project against that version does still produce that same exception. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Newbie Gloss questions - dynamic buffer structure
I'm sorry, that should have been :ubyte. Being able to insert arbitrary
data into a codec is a feature, though.
On Mon, Jan 12, 2015 at 6:27 AM, Tzach tzach.livya...@gmail.com wrote:
Hi Zach
Thanks for the detailed response
On Wednesday, January 7, 2015 at 7:28:06 AM UTC+2, Zach Tellman wrote:
Hey Tzach,
If I understand what you're trying to do, you want something like this:
[ :uint32
:ubyte ;; or bit-seq, depending
(delimited-block (prefix uint24 #(- % 5) #(+ % 5))) ]
And then you'll need to parse the final block separately. I've left
defining the uint24 as an exercise for the reader (sorry, long day), but
using (compile-frame [:uint16 :uint8] ...) should be pretty straightforward.
This is what work for me, in case anyone is interested or want to comment
(defn valid-length [l]
(and ( l 16777216)
(= l 0)))
(def uint24 (compile-frame [:ubyte :uint16]
(fn [u]
{:pre [(valid-length u)]}
(let [u8 (bit-shift-right u 16)
u16 (- u (bit-shift-left u8 16))]
[u8 u16]))
(fn [[u8 u16]]
{:post [(valid-length %)]}
(+ (bit-shift-left u8 16) u16
(def avp
(compile-frame
[:uint32
:ubyte
(repeated :int32 :prefix (prefix uint24 #(- % 5) #(+ % 5))) ]
))
My next step is to parse the bits from the header :ubyte and base on it,
read an extra uint32 before the repeated part.
The header is probably the answer.
Hope that helps, happy to answer any followup questions.
It did help! Thanks
BTW, I spent too much time trying to use (compile-frame [:uint16 :uint8])
before realizing :uint8 is not defined.
The result is simply encoding of the :uint8 symbol.
I wonder if its a bug or a feature.
Zach
On Saturday, January 3, 2015 11:51:14 PM UTC-8, Tzach wrote:
I'm trying to work with Gloss binary encoder/decoder, and need some help
to kick start.
My first task is simple(not for me ;)
I have the following binary buffer to read/write:
- 4 byte (32 bit) - code (uint)
- 8 bit - misc flags
- 3 byte (24 bit) - the entire buffer length
- 4 byte (32 bit) uint value - optional, depending on on of the
flags.
- List of 4 byte (uints) data elements - size dependent on the
overall size
How should I represent this structure?
Clearly I need to use *prefix* and *repeated* for the last element, but
I failed to understand how.
I also struggle with the optional element and how to represent a 3 byte
element.
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 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 a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/NxsCPBk12mE/unsubscribe.
To unsubscribe from this group and all its topics, 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: [ANN] Clojure 1.7.0-alpha5 now available
Nicola, Sean:
I am _not_ testing with Sean's code, so can't comment whether my results
will correspond with his.
I have found that between Clojure 1.7.0-alpha4 and 1.7.0-alpha5, and the
latest Eastwood version 0.2.1 released, I get an exception trying to lint
the namespace clojure.reflect in Clojure itself with 1.7.0-alpha5, but not
with 1.7.0-alpha4, and the exception message is similar in that it has to
do with No implementation of method: ... for a protocol.
I went through several of the individual commits between alpha4 and alpha5,
and found it was the commit for CLJ-979 that introduced the change in
behavior. I can even take the CLJ-979 patch and patch it into Clojure
1.7.0-alpha4, and I get the same exception. Details of the exception and
stack trace I get below.
Andy
I created a project directory to run the command below in. It simply has a
dependency on my custom-built version of Clojure.
% lein do clean, eastwood '{:namespaces [clojure.reflect]}'
== Eastwood 0.2.1 Clojure 1.7.0-alpha4c979only JVM 1.7.0_45
== Linting clojure.reflect ==
Exception thrown during phase :analyze+eval of linting namespace
clojure.reflect
IllegalArgumentException No implementation of method: :do-reflect of
protocol: #'clojure.reflect/Reflector found for class:
clojure.reflect.JavaReflector
clojure.core/-cache-protocol-fn (core_deftype.clj:555)
clojure.reflect/eval6486/fn--6487/G--6470--6490
(form-init6080826551765301071.clj:1)
clojure.core/partial/fn--4490 (core.clj:2489)
clojure.reflect/type-reflect (reflect.clj:100)
clojure.core/apply (core.clj:632)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/type-reflect
(utils.clj:24)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members*--1293
(utils.clj:271)
clojure.core/apply (core.clj:626)
eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1072
(memoize.clj:66)
eastwood.copieddeps.dep4.clojure.core.cache/through/fn--872 (cache.clj:55)
eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1068/fn--1069
(memoize.clj:65)
eastwood.copieddeps.dep3.clojure.core.memoize/d-lay/reify--1063
(memoize.clj:54)
clojure.core/deref (core.clj:2202)
eastwood.copieddeps.dep3.clojure.core.memoize/build-memoizer/fn--1123
(memoize.clj:152)
clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members
(utils.clj:280)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-members
(utils.clj:289)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-methods
(utils.clj:299)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate-call
(validate.clj:91)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/eval2056/fn--2058
(validate.clj:148)
clojure.lang.MultiFn.invoke (MultiFn.java:229)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate
(validate.clj:264)
clojure.lang.Var.invoke (Var.java:379)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--579
(passes.clj:171)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
clojure.core/partial/fn--4492 (core.clj:2496)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191
(ast.clj:102)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192
(ast.clj:96)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182
(ast.clj:51)
clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)
clojure.core.protocols/fn--6433 (protocols.clj:103)
clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)
clojure.core.protocols/seq-reduce (protocols.clj:31)
clojure.core.protocols/fn--6414 (protocols.clj:65)
clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)
clojure.core/reduce (core.clj:6461)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children
(ast.clj:56)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced
(ast.clj:64)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191
(ast.clj:99)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192
(ast.clj:96)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182
(ast.clj:51)
clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)
clojure.core.protocols/fn--6433 (protocols.clj:103)
clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)
clojure.core.protocols/seq-reduce (protocols.clj:31)
clojure.core.protocols/fn--6414 (protocols.clj:65)
clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)
clojure.core/reduce (core.clj:6461)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children
(ast.clj:56)
Re: [ANN] Clojure 1.7.0-alpha5 now available
I have confirmed that reverting this commit addresses the problems we are encountering: https://github.com/clojure/clojure/commit/9f277c80258b3d2951128ce26a07c30ad0b47af0 CLJ-979: make clojure resolve to the correct Class instances Since we routinely run our test suite against master, and we hadn't seen this failure last week, it had to be one of the handful of commits made immediately prior to releasing Alpha 5. Sean On Jan 12, 2015, at 8:31 AM, Sean Corfield s...@corfield.org wrote: On Jan 12, 2015, at 8:09 AM, Nicola Mometto brobro...@gmail.com wrote: Can you try a custom version of clojure 1.7.0-alpha5 with commit e5a104e894ed82f244d69513918d570cee5df67d reverted and see if you still get the exception? Yes, reverting that one commit and creating Clojure 1.7.0-aot5 and rebuilding and testing our project against that version does still produce that same exception. -- 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: [ANN] Clojure 1.7.0-alpha5 now available
I said this already on twitter, but I see heavy (5-10x slower) perf regressions on my benchmark suite from 1.7-alpha5 vs 1.6. I am trying the other alphas now - I have a comprehensive benchmark suite that takes 4 hours or so to run, and it's a bit backed up right now (I only have one box to run it on). I'm also going to point YourKit at 1.7-alpha5 soon on the worst regressing benchmarks (not all of them have such heavy regressions, and a few benchmarks are dramatically faster) and see what happens - will report back here once I have something more to say. On Saturday, 10 January 2015 15:37:04 UTC, Alex Miller wrote: Clojure 1.7.0-alpha5 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha5/ - Leiningen: [org.clojure/clojure 1.7.0-alpha5] A few of the highlights in alpha5: 1) New transducer arities for map-indexed, distinct, and interpose. The transducer versions are generally faster than the sequence versions. See CLJ-1601 for more details. 2) The set and vec functions should now be faster in many cases. Some of the vec improvements will not kick in until CLJ-1499 is committed in the future. See CLJ-1546 and CLJ-1618 for more details. 3) Two particularly troublesome AOT classloading bugs have been addressed - CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of one of these as well. Big thanks to Nicola Mometto for doing the hard work on debugging and providing fixes for these. For all changes new in alpha5, see the issues marked (alpha5) in the full changes below. Clojure 1.7.0-alpha5 has the changes below from 1.6.0: ## 1 New and Improved Features ### 1.1 Transducers Transducers is a new way to decouple algorithmic transformations from their application in different contexts. Transducers are functions that transform reducing functions to build up a recipe for transformation. Also see: http://clojure.org/transducers Many existing sequence functions now have a new arity (one fewer argument than before). This arity will return a transducer that represents the same logic but is independent of lazy sequence processing. Functions included are: * conj (conjs to []) * map * mapcat * filter * remove * take * take-while * drop * drop-while * cycle * take-nth * replace * partition-by * partition-all * keep * keep-indexed * map-indexed (alpha5) * distinct (alpha5) * interpose (alpha5) Additionally some new transducer functions have been added: * cat - concatenates the contents of each input * de-dupe - removes consecutive duplicated values * random-sample - returns items from coll with random probability And this function can be used to make completing transforms: * completing There are also several new or modified functions that can be used to apply transducers in different ways: * sequence - takes a transformation and a coll and produces a lazy seq * transduce - reduce with a transformation (eager) * eduction - returns a reducible/seqable/iterable seq of applications of the transducer to items in coll. Applications are re-performed with every reduce/seq/iterator. * run! - run the transformation for side effects on the collection There have been a number of internal changes to support transducers: * volatiles - there are a new set of functions (volatile!, vswap!, vreset!, volatile?) to create and use volatile boxes to hold state in stateful transducers. Volatiles are faster than atoms but give up atomicity guarantees so should only be used with thread isolation. * array iterators - added support for iterators over arrays Some related issues addressed during development: * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511) * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497) * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549) * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537) * [CLJ-1554](http://dev.clojure.org/jira/browse/CLJ-1554) * [CLJ-1601](http://dev.clojure.org/jira/browse/CLJ-1601) (alpha5) * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) (alpha5) * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) (alpha5) * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) (alpha5) ### 1.2 Keyword and Symbol Construction In response to issues raised in [CLJ-1439]( http://dev.clojure.org/jira/browse/CLJ-1439), several changes have been made in symbol and keyword construction: 1) The main bottleneck in construction of symbols (which also occurs inside keywords) was interning of the name and namespace strings. This interning has been removed, resulting in a performance increase. 2) Keywords are cached and keyword construction includes a cache check. A change was made to only clear the cache reference queue when there is a cache miss. ### 1.3 Warn on Boxed Math One source of performance issues is the
Re: [ANN] Clojure 1.7.0-alpha5 now available
I would be helpful to me at this point to have a jira regarding this
problem which I will presume for the time being is the same in both Andy
and Sean's case.
On Monday, January 12, 2015 at 11:30:57 AM UTC-6, Andy Fingerhut wrote:
Nicola, Sean:
I am _not_ testing with Sean's code, so can't comment whether my results
will correspond with his.
I have found that between Clojure 1.7.0-alpha4 and 1.7.0-alpha5, and the
latest Eastwood version 0.2.1 released, I get an exception trying to lint
the namespace clojure.reflect in Clojure itself with 1.7.0-alpha5, but not
with 1.7.0-alpha4, and the exception message is similar in that it has to
do with No implementation of method: ... for a protocol.
I went through several of the individual commits between alpha4 and
alpha5, and found it was the commit for CLJ-979 that introduced the change
in behavior. I can even take the CLJ-979 patch and patch it into Clojure
1.7.0-alpha4, and I get the same exception. Details of the exception and
stack trace I get below.
Andy
I created a project directory to run the command below in. It simply has
a dependency on my custom-built version of Clojure.
% lein do clean, eastwood '{:namespaces [clojure.reflect]}'
== Eastwood 0.2.1 Clojure 1.7.0-alpha4c979only JVM 1.7.0_45
== Linting clojure.reflect ==
Exception thrown during phase :analyze+eval of linting namespace
clojure.reflect
IllegalArgumentException No implementation of method: :do-reflect of
protocol: #'clojure.reflect/Reflector found for class:
clojure.reflect.JavaReflector
clojure.core/-cache-protocol-fn (core_deftype.clj:555)
clojure.reflect/eval6486/fn--6487/G--6470--6490
(form-init6080826551765301071.clj:1)
clojure.core/partial/fn--4490 (core.clj:2489)
clojure.reflect/type-reflect (reflect.clj:100)
clojure.core/apply (core.clj:632)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/type-reflect
(utils.clj:24)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members*--1293
(utils.clj:271)
clojure.core/apply (core.clj:626)
eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1072
(memoize.clj:66)
eastwood.copieddeps.dep4.clojure.core.cache/through/fn--872 (cache.clj:55)
eastwood.copieddeps.dep3.clojure.core.memoize/through*/fn--1068/fn--1069
(memoize.clj:65)
eastwood.copieddeps.dep3.clojure.core.memoize/d-lay/reify--1063
(memoize.clj:54)
clojure.core/deref (core.clj:2202)
eastwood.copieddeps.dep3.clojure.core.memoize/build-memoizer/fn--1123
(memoize.clj:152)
clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/members
(utils.clj:280)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-members
(utils.clj:289)
eastwood.copieddeps.dep2.clojure.tools.analyzer.jvm.utils/instance-methods
(utils.clj:299)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate-call
(validate.clj:91)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/eval2056/fn--2058
(validate.clj:148)
clojure.lang.MultiFn.invoke (MultiFn.java:229)
eastwood.copieddeps.dep2.clojure.tools.analyzer.passes.jvm.validate/validate
(validate.clj:264)
clojure.lang.Var.invoke (Var.java:379)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--579
(passes.clj:171)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
eastwood.copieddeps.dep1.clojure.tools.analyzer.passes/compile-passes/fn--574/fn--581
(passes.clj:173)
clojure.core/partial/fn--4492 (core.clj:2496)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191
(ast.clj:102)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192
(ast.clj:96)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182
(ast.clj:51)
clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)
clojure.core.protocols/fn--6433 (protocols.clj:103)
clojure.core.protocols/fn--6395/G--6390--6404 (protocols.clj:19)
clojure.core.protocols/seq-reduce (protocols.clj:31)
clojure.core.protocols/fn--6414 (protocols.clj:65)
clojure.core.protocols/fn--6369/G--6364--6382 (protocols.clj:13)
clojure.core/reduce (core.clj:6461)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children
(ast.clj:56)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/update-children-reduced
(ast.clj:64)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191
(ast.clj:99)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/walk/walk--191/walk--192
(ast.clj:96)
eastwood.copieddeps.dep1.clojure.tools.analyzer.ast/-update-children/fn--182
(ast.clj:51)
clojure.lang.ArrayChunk.reduce (ArrayChunk.java:63)
clojure.core.protocols/fn--6433 (protocols.clj:103)
Clojure for Desktop UI Design Application
(Cross-posted on StackOverflow) I'm trying to design a desktop UI for schematics, layout, drawing stuff. Just looking for high level advice from actual software designers. Assuming an in-memory database, (clojure map of arbitrary depth for all user data, and possibly another one for application preferences, etc.), I'm examining how to do the model-view-controller thing on these, where the data may be rendered *and modified by* any one or more of: 1. A standalone text field that shows a single parameter, such as box width. 2. An inspector type of view that shows multiple parameters of a selected object, such as box width, height, color, checkboxes, etc. 3. A table/spreadsheet type of view that shows multiple parameters of multiple objects, potentially the whole database 4. A graphical rendering of the whole thing, such as both schematic and layout view. Modifying any one of these should show up immediately in every other active view, both text and graphical, not after clicking ok... so no modal boxes allowed. If for some reason the table view, an inspector view, and a graphical rendering are all in view, dragging the corner of the box graphically should immediately show up in the text, etc. The platform in question is JavaFX, but I'd like a clean separation between UI and everything else, so I want to avoid `bind`ing in the JFX sense, as that ties my design data very tightly to JFX Properties, increases the graininess of the model, and forces me to work outside the standard clojure functions for dealing with data, and/or deal heavily with the whole `getValue`/`setValue` world. I'm still assuming at least *some* statefulness/mutability, and the use of built-in Clojure functionality such as the ability to `add-watch` on an atom/var/ref and let the runtime signal dependent functions. Platform-specific interaction will rest tightly with the actual UI, such as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., and will attempt to minimize the reliance on things like JavaFX `Property` for actual application data. I'm not entertaining FRP for this. I don't mind too much extending JFX interfaces or making up my own protocols to use application-specific `defrecord`s, but I'd prefer for the application data to remain as straight Clojure data, unsullied by the platform. The question is how to set this all up, with closest adherence to the immutable model and minimal (or well-bounded) dependence on JFX. I see a few options: 1. Fine-grain: Each parameter value/primitive (ie Long, Double, Boolean, or String) is an atom, and each view which can modify the value reaches in as far as it needs to in the database to change the value. This could suck as there could potentially be thousands of individual values (for example points on a hand-drawn curve), and will require lots of `(deref...)` junk. I believe this is how JFX would want to do this, with giant arrays of Properties at the leaf nodes, etc., which feels bloated. With this approach it doesn't seem much better than just coding it up in Java/C++. 2. Medium-grain: Each object/record in the database is an atom of a Clojure map. The entire map is replaced when any one of its values changes. Fewer total atoms to deal with, and allows for example long arrays of straight-up numbers for various things. But this gets complicated when some objects in the database require more nesting than others. 3. Coarse-grain: There is just one atom: the database. Any time anything changes, the entire database is replaced, and every view needs to re-render its particular portion. This feels a bit like using a hammer to swat a fly, and a naive implementation would require everything to re-render all the time. But I still think this is the best trade off, as any primitive has a clear access path from the root node, whether it is accessed on a per-primitive level or per-record level. I also need the ability for one data template to be instantiated many times. So for example if the user changes a symbol or shape which is used in multiple places, a single edit will apply everywhere. I believe this also requires some type of pointer-like behavior. I think I can store a atom to the model, then instantiate as needed, and it can work in any of the above grain models. Any other approaches? Is trying to do a GUI editor-like tool in a functional language just stupid? 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 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
