Re: Clojure, floats, ints and OpenGL
On Tuesday, 10 September 2013 01:03:12 UTC+8, Jozef Wagner wrote: You can typehing ints for locals (let, loop), restrictions are just for function arguments. AFAIK the reason is combinatorial explosion at https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91 I never understood the point of these restrictions surely primitive function invocation is much better handled by: a) generating the exact primitive function required in an AFn subclass (e.g. invokePrim(long, char, byte, Object); ) b) Creating a direct invocation of the method in a) at any function call site c) The usual IFn.invoke(...) methods can handle the dynamic use cases when you pass this AFn to a higher order function i.e. you don't really need these interfaces at all. As a bonus, the same method could also improve performance by avoiding type casts for non-primitive type-hinted arguments like String, since you aren't limited to casting every non-primitive argument via Object either. Or am I missing something obvious? I have the same problem with char. Because I cannot typehint e.g. my whitespace? function with ^char, I recieve a boxed Object and thus cannot use == for comparison. JW On Mon, Sep 9, 2013 at 6:02 PM, Mikera mike.r.an...@gmail.comjavascript: wrote: +1 for supporting all the JVM primitive types properly. It is worth noting that the benefits would extend much further than just OpenGL, e.g.: - int is a commonly used type in Java interop. Casting to/from it all the time is a minor annoyance/overhead - int is the type used for array indexing on the JVM - all the small ( 8 byte) primitive types save memory footprint, which is important since memory bandwidth is the limiting factor in some workloads - int/float fit into a register (and therefore perform much better) on 32 bit machines (which still exist, believe it or not) - char is a pretty useful primitive type if you are doing text processing - byte is also frequently useful, especially for IO I believe that with some enhancements to the Clojure compiler, supporting all the JVM primitive types shouldn't be too difficult, and it would provide many benefits both in terms of overall performance and interop convenience. On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote: Hello! With this letter I would like to receive an answer from somebody from the development team (if anyone else has something to say, you're surely welcome :) ). I am working for a big multimedia company and recently I have been considering moving to Clojure as the main language of development. We have been doing Java and Scala before, but now when I tried Clojure and see the possibilities it provides, I would definitely stand for it to be our ground. However, while I am so satisfied with everything - the language, the community, the Java interop, there is still something that hinders and makes me linger. Namely, the lack of good support of floats and ints in the language. While many people would not consider it to be a huge disadvantage or even notice it, things are not so bright when it comes to OpenGL. The case is that OpenGL and 3D graphics hardware in general has no support for doubles or longs. Therefore, all libraries, all data and all computations are meant to be performed with floats and ints (shaders too). Due to the lack of good support of these data types in Clojure (for example, there are no ^float and ^int typehints, float and int values can only be typecasted to, all calculations always retain doubles and longs), results in too many extra typecasts, which are absolutely unnecessary and take too much time. So, calculations become very cumbersome, even if we do not take mandatory boxing into account. Considering that such kinds of calculations are usually abuntant in the aforementioned types of applications, the penalty grows really huge. I have endeavoured several discussions on the IRC to find out possible workarounds. Although many good proposals by many good people were made, aimed at improving the situation, none of them could solve the fundamental lack of the ability to manipulate 32bit primitive (or even boxed) data types. That lack renders Clojure not really suitable for heavy-load OpenGL applications that require somewhat extensive calculations: some kinds of games, simulations, generative graphics and so on. Considering how superior Clojure is to any other language available for JVM, that black spot looks especially embarrasing. And I could imagine falling back to Java for fast computations, just like we fall back to ASM in, say C, that is very undesirable and discouraging, since we want to pick Clojure for Clojure and it will be too cumbersome to make 50/50% Java/Clojure apps just to work around that design decision. Therefore, while deciding if to pick Clojure as the base for our development, I would
Re: Best way to pass through named arguments (destructured map)?
You can also checkout whether my library [1] suits you. Passing option maps to other functions with options and managing doc strings for these options (transitively) are the features it was written for. It will simplify functions with options in your own code but the calls to functions of third party libraries will remain the same. [1] https://github.com/guv/clojure.options/ -- -- 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/groups/opt_out.
Functional purity and globals in Clojure
I'm trying to determine how to best deal with the concept of globals in Clojure. Say I have a map of configuration values for my Ring app, populate at app startup from disk or env, and I need to reference the contents of this map from all over the project. Assuming MVC, models and controllers all would be interested in its contents. I just want to clarify that the question is not so much about configuration as it is about dealing with state that many different components in an application might be all interested in. This is an issue that seems to arise very often. I'm seeing a couple of options here: - Pass the configs map along with each Ring request with some middleware, and then down every subsequent function call that might eventually need it. It's a bit of a hassle since now you're passing more data, potentially increasing the # of parameters, or forcing you to use a parameter map everywhere where you might have passed along just 1 primitive. Nonetheless, this is as pure as it gets. - Def the configs map in a namespace somewhere and refer to it from wherever, just like global state. The trick is now that now you're no longer certain what e.g. your model functions are expecting there to be in the system and testing becomes trickier. Now you have to either lein test with a separate set of configurations (which doesn't actually give you much per-test granularity) or use with-redefs everywhere to make sure the right test config state is being used. - Something in the middle where perhaps you agree to never directly reference the configs map from your models (again, thinking MVC here) and instead only ever access it from controllers, and pass the necessary options along down to the model functions. This way you can test both controllers and models in isolation in purity. Ultimately I want to contain the chaos of having to know internal implementation details of my functions at different layers and want them to be easily testable in isolation. It does seem like the first option is the most straightforward, but I'd be curious to find out what those of you who have deal with the problem for a while would recommend. Purity all the way, or are there patterns that can give you the best of both worlds? Or what else? -- -- 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/groups/opt_out.
Re: Functional purity and globals in Clojure
Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin: - Something in the middle where perhaps you agree to never directly reference the configs map from your models (again, thinking MVC here) and instead only ever access it from controllers, and pass the necessary options along down to the model functions. This way you can test both controllers and models in isolation in purity. I'd do the following: for every layout of your application (persistence, datamodel, web) define one or more vars that hold the configuration specific for that layer. Testing a layer is easy and documentation of the layer gives you the necessary information about the configuration vars. -billy. -- -- 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/groups/opt_out.
Re: Clojure newbie code review
Am Dienstag, 10. September 2013 01:24:10 UTC+2 schrieb Igor Demura: Hi Clojure community, (I tried codereview.stackaxchange.com before, but no responses where) I'm Clojure newbie, and feel very excited about it and functional programming in general. I wrote tiny app (59 lines of code) which renders a directory tree to the terminal, filtering with a regex. I'm sure that my code is not perfect and something could be done much better. I'll appreciate if you could spent sometime to review it: https://github.com/idemura/incub/tree/master/tree. Don't know where to get help with this. (str (reduce #(str %1 %2) coll) can be replaced with clojure.string/join (iterate inc 1) = (rest (range)) may be more clear (alter-var-root #'*read-eval* (constantly false)) = why do you think this is necessary? You can convert the regex string into a pattern once in line 51: (when regex (re-pattern regex)) (assoc m p (conj (m p []) f)) = (update-in m [p] (fnil conj []) f)) In general I would separate the different task: * directory tree walking - tree representation * render tree into line definitions * render tree lines into string * print string -billy -- -- 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/groups/opt_out.
Re: Functional purity and globals in Clojure
I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller... This allows you to later change where you store and how you manage your configuration underneath, calls to the configuration are traceable in your code (conf/...) and you can easily stub it for testing purposes. Yes you need some discipline to avoid accessing it from everywhere (it could be tempting) but in general I refer to it at the top level and pass bits of the configuration data downward. Downward in your code you refer to semantics that have little to do with what the configuration data may represent as a whole. E.g. when trying to create a socket, you do not matter where the host/port came from in your configuration, you just need the values as args. It helps keeping your functions as pure a possible or at least with a clearly delimited side effect scope and still allows tests to be written. Attaining 100% purity is in my view a nice but rarely reachable objective. I would say that 80 to 90% is more realistic :) Luc P. Am Dienstag, 10. September 2013 09:19:35 UTC+2 schrieb Alexandr Kurilin: - Something in the middle where perhaps you agree to never directly reference the configs map from your models (again, thinking MVC here) and instead only ever access it from controllers, and pass the necessary options along down to the model functions. This way you can test both controllers and models in isolation in purity. I'd do the following: for every layout of your application (persistence, datamodel, web) define one or more vars that hold the configuration specific for that layer. Testing a layer is easy and documentation of the layer gives you the necessary information about the configuration vars. -billy. -- -- 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/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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/groups/opt_out.
[ANN] core.typed 0.2.5, News
Hi, Pushing another release of core.typedhttps://github.com/clojure/core.typed, mostly bug/documentation fixes. We now push a slim jar which does not include AOT file. See the README for dependency information. See the CHANGELOG for specific changes. I'm also starting to provide functions that will help integrate core.typed with IDE's. eg. check-form-infohttp://clojure.github.io/core.typed/#clojure.core.typed/check-form-info returns a map of data summarising the results of type checking, including type errors. This is towards Counterclockwise supporthttp://dev.clojure.org/display/design/Typed+CLJS . I'm planning to fix a bunch of things that have proven problematic with the type syntax. I'll be adding to this design wikihttp://dev.clojure.org/display/design/Cleaning+up+Type+Syntaxif you want to follow along, or contribute. These may end up being breaking changes. Also, recursive deftype and protocols have proven to be tricky. Herehttp://dev.clojure.org/display/design/Recursive+Definitionsare my thoughts. Finally, I wrote a blog posthttp://frenchy64.github.io/2013/09/08/simple-reasoning-assertions-core-typed.htmlexplaining how core.typed understands assertions. Enjoy! Ambrose PS. If you have questions, try #typed-clojure on Freenode! -- -- 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/groups/opt_out.
Re: [ANN] core.typed 0.2.5, News
Thanks for all your work ambrose! Core.typed is quite a feat. And I can confirm ambrose is amazingly responsive on freenode. Every time I bug him, it works :) On 10/09/2013 9:57 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Hi, Pushing another release of core.typedhttps://github.com/clojure/core.typed, mostly bug/documentation fixes. We now push a slim jar which does not include AOT file. See the README for dependency information. See the CHANGELOG for specific changes. I'm also starting to provide functions that will help integrate core.typed with IDE's. eg. check-form-infohttp://clojure.github.io/core.typed/#clojure.core.typed/check-form-info returns a map of data summarising the results of type checking, including type errors. This is towards Counterclockwise supporthttp://dev.clojure.org/display/design/Typed+CLJS . I'm planning to fix a bunch of things that have proven problematic with the type syntax. I'll be adding to this design wikihttp://dev.clojure.org/display/design/Cleaning+up+Type+Syntaxif you want to follow along, or contribute. These may end up being breaking changes. Also, recursive deftype and protocols have proven to be tricky. Herehttp://dev.clojure.org/display/design/Recursive+Definitionsare my thoughts. Finally, I wrote a blog posthttp://frenchy64.github.io/2013/09/08/simple-reasoning-assertions-core-typed.htmlexplaining how core.typed understands assertions. Enjoy! Ambrose PS. If you have questions, try #typed-clojure on Freenode! -- -- 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/groups/opt_out.
Re: Functional purity and globals in Clojure
Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc: I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller... You can always use a global config system and pass through the configuration information into the sub 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/groups/opt_out.
Re: Functional purity and globals in Clojure
This Clojure/West talk deals with many of these concepts. http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques Timothy On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier phme...@gmail.com wrote: Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc: I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller... You can always use a global config system and pass through the configuration information into the sub 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/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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/groups/opt_out.
Re: Functional purity and globals in Clojure
This presentation is funny from Stuart is interesting and funny to watch as usual :) The mud ball issue is not new and you can face it in other languages than Lisp that lack a single straight jacket with which anything needs to be defined (like classes). Freedom comes with a price, you cannot always rely on some fixed rail guards to tell you how to do things. I guess that a decade of OOP frenzy took its toll and now some folks suffer from vertigo when they switch to a muddy language :) Luc P This Clojure/West talk deals with many of these concepts. http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques Timothy On Tue, Sep 10, 2013 at 6:35 AM, Philipp Meier phme...@gmail.com wrote: Am Dienstag, 10. September 2013 12:58:46 UTC+2 schrieb Luc: I agree more or less, I hate having my configuration data spread everywhere. I prefer to dedicate a name space to maintain/access configuration data. I usually split access to resources using bundles. A bundle can reflect anything you want in your design, including a controller... You can always use a global config system and pass through the configuration information into the sub 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/groups/opt_out. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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/groups/opt_out. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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/groups/opt_out.
Re: Clojure newbie code review
Philipp Meier phme...@gmail.com writes: (alter-var-root #'*read-eval* (constantly false)) = why do you think this is necessary? Some versions of the Leiningen `app` template put this in the skeleton initial source file. I assume that’s where this came from. -Marshall -- -- 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/groups/opt_out.
Re: Functional purity and globals in Clojure
I do a hybrid in Bulwark. github.com/bitemyapp/bulwark/ Defaults to accepting a closure of a config map for nice testing and hygiene, with a fallback to a global atom map for configuration for muggles. Works well for me. On Tuesday, September 10, 2013 12:19:35 AM UTC-7, Alexandr Kurilin wrote: I'm trying to determine how to best deal with the concept of globals in Clojure. Say I have a map of configuration values for my Ring app, populate at app startup from disk or env, and I need to reference the contents of this map from all over the project. Assuming MVC, models and controllers all would be interested in its contents. I just want to clarify that the question is not so much about configuration as it is about dealing with state that many different components in an application might be all interested in. This is an issue that seems to arise very often. I'm seeing a couple of options here: - Pass the configs map along with each Ring request with some middleware, and then down every subsequent function call that might eventually need it. It's a bit of a hassle since now you're passing more data, potentially increasing the # of parameters, or forcing you to use a parameter map everywhere where you might have passed along just 1 primitive. Nonetheless, this is as pure as it gets. - Def the configs map in a namespace somewhere and refer to it from wherever, just like global state. The trick is now that now you're no longer certain what e.g. your model functions are expecting there to be in the system and testing becomes trickier. Now you have to either lein test with a separate set of configurations (which doesn't actually give you much per-test granularity) or use with-redefs everywhere to make sure the right test config state is being used. - Something in the middle where perhaps you agree to never directly reference the configs map from your models (again, thinking MVC here) and instead only ever access it from controllers, and pass the necessary options along down to the model functions. This way you can test both controllers and models in isolation in purity. Ultimately I want to contain the chaos of having to know internal implementation details of my functions at different layers and want them to be easily testable in isolation. It does seem like the first option is the most straightforward, but I'd be curious to find out what those of you who have deal with the problem for a while would recommend. Purity all the way, or are there patterns that can give you the best of both worlds? Or what else? -- -- 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/groups/opt_out.
Re: new ClojureDocs experiment
Thanks :) By the way, it's probably *not* a good idea to use this github-wiki version of clojuredocs. Everyone's still using clojuredocs.org, and we don't want to scatter data (examples, etc) between two websites. My reason for posting this was to hear the community's thoughts on this alternate implementation and its viability. -Steven On Mon, Sep 9, 2013 at 5:39 AM, Alex Fowler alex.murat...@gmail.com wrote: That's really cool! Was always wondering if there's gone be something like that ever.. Gonna be visiting often! Wish also that it'd be near clojuredocs in search results if you google like clojure parse, but that'a a different effort, I suppose.. keep up! воскресенье, 8 сентября 2013 г., 12:07:33 UTC+4 пользователь Steven Degutis написал: ClojureDocs.org is pretty awesome, I think I use it nearly every day, especially for the Examples and See Also sections. But sometimes I've been wishing it had Clojure 1.5.1 support. For example, I think as- and cond- would have been easier for me to pick up had there been entries for these with community-driven Examples. A while back, someone told me complaining is laziness. So I worked on an experiment that I'd like to propose to you all. It's a github wiki that's been seeded with data scraped from in-process docs and clojuredocs.org's API. Here it is: https://github.com/sdegutis/clojuredocs/wiki Pros: - Docs are for Clojure 1.5.1 - Anyone logged into github can edit it - Any part of it can be edited (to fix typos in docstring, etc) - All namespaces are shown on the Home page for easy searching - Free hosting, free database storage :) Cons: - Doesn't have dynamic relevance-based search field - Doesn't have an API (but an external one could be built) - Doesn't have Quick Ref tables (yet) - A few URLs are kind of ugly - The namespace-navigation bar is gone, you'd have to click Home - Doesn't store nearly as much data as clojuredocs.org does (But as usual, pros/cons are totally subjective to individual needs. This is just how I saw it. These tables may be reversed for you, who knows.) Right now, it only has core namespaces. But I've made it easy to add data from new namespaces, so long as the right dependencies are added to project.clj. Thoughts? -Steven -- -- 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/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 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/groups/opt_out.
finding retained head
From jmap output it's pretty clear I'm retaining the head of a seq somehow, but I have no idea how, or where. Is there any way to find the reference, besides staring at code waiting for enlightenment? -- -- 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/groups/opt_out.
Re: finding retained head
Trying jhat now, reference chain here: -- cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:) -- clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:) -- clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:) This looks to me like the head is being retained as a parameter to a function. load_exp signature is like so: defn load-exp [file timestamp filehash matrix] But surely passing a seq to a function doesn't retain the head? Here's the body of the function: (defn load-exp [file timestamp filehash matrix] (kdb/transaction (let [cid (merge-cohort file) exp (merge-exp file (format-timestamp timestamp) filehash cid) sids (load-samples cid (:samples (meta matrix)))] (load-exp-samples exp sids) (load-exp-matrix exp matrix load-exp-matrix calls (dorun (map)) on matrix. There's one other reference here, where we pull the metadata. Does any of this retain the head? On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote: From jmap output it's pretty clear I'm retaining the head of a seq somehow, but I have no idea how, or where. Is there any way to find the reference, besides staring at code waiting for enlightenment? -- -- 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/groups/opt_out.
[ANN] Blackwater 0.0.8
https://github.com/bitemyapp/blackwater Single-line SQL query formatting, separate Korma and c.j.j namespaces, ability to use a custom fn with set-logger! now as well. Any additional feature requests/changes should continue to hit the Github issues. Cheers all. --- Chris -- -- 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/groups/opt_out.
[ANN] Introducing VDD Core - Visualization Driven Development in Clojure
I've just released a new open source tool, VDD Core, to help enable Visualization Driven Development in Clojure. Visualization Driven Development and VDD Core are the subject of my Strange Loop talk ( https://thestrangeloop.com/sessions/visualization-driven-development) next week. VDD Core's goal is to make it easy to capture and send data to be visualized in a web browser. This is an early alpha release. I hoping to get others interested and testing it out. You can read more about VDD Core and Visualization Driven Development at the following places: * Blog Announcement: http://www.element84.com/announcing-vdd-core.html * Github Page: https://github.com/Element84/vdd-core * Wiki: https://github.com/Element84/vdd-core/wiki * Example Project: https://github.com/Element84/vdd-core-examples Thanks, Jason Gilman -- -- 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/groups/opt_out.
Re: Clojure newbie code review
Regarding your question about join: The clojure.string namespace contains the join function recommended to you. All functions in the clojure.string namespace, and several other namespaces (see below for a complete list) are part of the Clojure JAR file, and in that sense come at no additional charge over and above that Clojure JAR file size. Whether you regard that Clojure JAR file bloated or not is your judgement call (Clojure 1.5.1 is ~3.5 Mbytes). $ java -cp $HOME/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar clojure.main user= (use 'clojure.pprint) nil user= (clojure.pprint/pprint (sort (map str (all-ns (clojure.core clojure.core.protocols clojure.instant clojure.java.browse clojure.java.io clojure.java.javadoc clojure.java.shell clojure.main clojure.pprint clojure.repl clojure.string clojure.uuid clojure.walk user) nil If you add other libraries with their own separate JAR files, you can look at each one to decide whether you think its size is worth it. Many that are written purely in Clojure tend to be source-code only, and thus quite small. For example, Ring + Compojure + Hiccup JAR files total about 40 Kbytes. Andy On Tue, Sep 10, 2013 at 10:46 AM, Igor Demura ig...@google.com wrote: Thank you Philipp, this is really helpful! Marshall's guess where *read-eval* from is right. I didn't googled what does it mean, just left as-is from the Leiningen template. Talking on replacement to join. For this function I'll link additional library. My question how this works: in C++ world, linker will eliminate all unused symbols (classes in this case?) from output binary. Is the same true for JVM/Clojure world? Will it bloat binary? Why do you recommend update-in instead of assoc? First time I did this, than I saw using assoc in similar situation on ClojureDocs and changed my mind. I see your point about architecture. You suggest to make it more sequential (composition like: (f (g x))), instead of injecting actions like this: (defn action [subaction] ;; subaction is a function to pass control to (do ... (subaction ...))) Thank you again. On Monday, September 9, 2013 4:24:10 PM UTC-7, Igor Demura wrote: Hi Clojure community, (I tried codereview.stackaxchange.com before, but no responses where) I'm Clojure newbie, and feel very excited about it and functional programming in general. I wrote tiny app (59 lines of code) which renders a directory tree to the terminal, filtering with a regex. I'm sure that my code is not perfect and something could be done much better. I'll appreciate if you could spent sometime to review it: https://github.com/* *idemura/incub/tree/master/treehttps://github.com/idemura/incub/tree/master/tree **. Don't know where to get help with this. Igor. -- -- 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/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 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/groups/opt_out.
Re: Clojure newbie code review
Thank you Philipp, this is really helpful! Marshall's guess where *read-eval* from is right. I didn't googled what does it mean, just left as-is from the Leiningen template. Talking on replacement to join. For this function I'll link additional library. My question how this works: in C++ world, linker will eliminate all unused symbols (classes in this case?) from output binary. Is the same true for JVM/Clojure world? Will it bloat binary? Why do you recommend update-in instead of assoc? First time I did this, than I saw using assoc in similar situation on ClojureDocs and changed my mind. I see your point about architecture. You suggest to make it more sequential (composition like: (f (g x))), instead of injecting actions like this: (defn action [subaction] ;; subaction is a function to pass control to (do ... (subaction ...))) Thank you again. On Monday, September 9, 2013 4:24:10 PM UTC-7, Igor Demura wrote: Hi Clojure community, (I tried codereview.stackaxchange.com before, but no responses where) I'm Clojure newbie, and feel very excited about it and functional programming in general. I wrote tiny app (59 lines of code) which renders a directory tree to the terminal, filtering with a regex. I'm sure that my code is not perfect and something could be done much better. I'll appreciate if you could spent sometime to review it: https://github.com/idemura/incub/tree/master/tree. Don't know where to get help with this. Igor. -- -- 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/groups/opt_out.
Re: finding retained head
It seems to be something about the jdbc/transaction macro. If I rewrite load_exp so it does nothing but walk the seq, it still consumes the heap: (defn load-exp [file timestamp filehash matrix] (jdbc/transaction (dorun (map identity matrix If I remove the jdbc/transaction call, it's fine. (defn load-exp [file timestamp filehash matrix] (dorun (map identity matrix))) On Tuesday, September 10, 2013 3:24:29 PM UTC-7, Brian Craft wrote: Trying jhat now, reference chain here: -- cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:) -- clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:) -- clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:) This looks to me like the head is being retained as a parameter to a function. load_exp signature is like so: defn load-exp [file timestamp filehash matrix] But surely passing a seq to a function doesn't retain the head? Here's the body of the function: (defn load-exp [file timestamp filehash matrix] (kdb/transaction (let [cid (merge-cohort file) exp (merge-exp file (format-timestamp timestamp) filehash cid) sids (load-samples cid (:samples (meta matrix)))] (load-exp-samples exp sids) (load-exp-matrix exp matrix load-exp-matrix calls (dorun (map)) on matrix. There's one other reference here, where we pull the metadata. Does any of this retain the head? On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote: From jmap output it's pretty clear I'm retaining the head of a seq somehow, but I have no idea how, or where. Is there any way to find the reference, besides staring at code waiting for enlightenment? -- -- 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/groups/opt_out.
Re: finding retained head
Copying the pattern of jdbc/transaction*, I tried this: (defn blah [func] (func)) (defn load-exp [file timestamp filehash matrix] (blah (fn [] (dorun (map identity matrix) which also consumes the heap. Can anyone explain to me what's happening here? Something about creating a anonymous function? On Tuesday, September 10, 2013 5:24:44 PM UTC-7, Brian Craft wrote: It seems to be something about the jdbc/transaction macro. If I rewrite load_exp so it does nothing but walk the seq, it still consumes the heap: (defn load-exp [file timestamp filehash matrix] (jdbc/transaction (dorun (map identity matrix If I remove the jdbc/transaction call, it's fine. (defn load-exp [file timestamp filehash matrix] (dorun (map identity matrix))) On Tuesday, September 10, 2013 3:24:29 PM UTC-7, Brian Craft wrote: Trying jhat now, reference chain here: -- cavm.h2$load_exp$fn__165@0x2aaab4b04660 (56 bytes) (field matrix:) -- clojure.lang.LazySeq@0x2aaab4b05388 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab4b0fe08 (48 bytes) (field _more:) -- clojure.lang.LazySeq@0x2aaab4b10330 (48 bytes) (field s:) -- clojure.lang.Cons@0x2aaab6543ec0 (48 bytes) (field _more:) This looks to me like the head is being retained as a parameter to a function. load_exp signature is like so: defn load-exp [file timestamp filehash matrix] But surely passing a seq to a function doesn't retain the head? Here's the body of the function: (defn load-exp [file timestamp filehash matrix] (kdb/transaction (let [cid (merge-cohort file) exp (merge-exp file (format-timestamp timestamp) filehash cid) sids (load-samples cid (:samples (meta matrix)))] (load-exp-samples exp sids) (load-exp-matrix exp matrix load-exp-matrix calls (dorun (map)) on matrix. There's one other reference here, where we pull the metadata. Does any of this retain the head? On Tuesday, September 10, 2013 2:36:29 PM UTC-7, Brian Craft wrote: From jmap output it's pretty clear I'm retaining the head of a seq somehow, but I have no idea how, or where. Is there any way to find the reference, besides staring at code waiting for enlightenment? -- -- 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/groups/opt_out.
Re: [ANN] Introducing VDD Core - Visualization Driven Development in Clojure
Thanks for posting this - at first glance it looks very cool :) See you at Strangeloop - I've been looking forward to this talk :) Mark On Wed, Sep 11, 2013 at 10:13 AM, Jason Gilman jason.gil...@gmail.comwrote: I've just released a new open source tool, VDD Core, to help enable Visualization Driven Development in Clojure. Visualization Driven Development and VDD Core are the subject of my Strange Loop talk ( https://thestrangeloop.com/sessions/visualization-driven-development) next week. VDD Core's goal is to make it easy to capture and send data to be visualized in a web browser. This is an early alpha release. I hoping to get others interested and testing it out. You can read more about VDD Core and Visualization Driven Development at the following places: * Blog Announcement: http://www.element84.com/announcing-vdd-core.html * Github Page: https://github.com/Element84/vdd-core * Wiki: https://github.com/Element84/vdd-core/wiki * Example Project: https://github.com/Element84/vdd-core-examples Thanks, Jason Gilman -- -- 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/groups/opt_out. -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com 2 Devs from Down Under Podcast http://www.2ddu.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/groups/opt_out.
Re: finding retained head
Can anyone explain to me what's happening here? Something about creating a anonymous function? The problem is not creating the anonymous function but that it closes over the matrix argument. The closure passed on to blah will keep a reference to matrix until blah returns. This won't happen if the anonymous function takes the matrix as a parameter: (defn blah [func v] (func v)) (defn load-exp [matrix] (blah (fn [m] (dorun (map identity m))) matrix)) -- -- 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/groups/opt_out.
Re: Clojure Jruby (Ruby on Rails) Interop
Rodrigo, We went with RabbitMQ over ZeroMQ mostly because we were more familiar with it. As I understand it, ZeroMQ is less of a message-queueing system and more sockets on steroids. Which one is best will depend pretty strongly on your particular usecase. In our case, our messages are pretty simple: they're just mongodb docIds plus some extra data. We use the queue the message goes into as the meta-data for the message. If a docId appears in the word-count queue, for example, the Clojure workers know to calculate the avg word count stats for the given document. For us, security comes in the form of username/password authentication for RabbitMQ, plus blocking the ports to everyone save the Ruby and Clojure servers that need to communicate with it. If we were firing off messages with more sensitive data (e.g., passwords), we'd look at encryption then. The performance of the pipeline so far has been great. Ruby can offload the heavy processing to Clojure, so the user can continue working on the site without interruption. Clojure gets to focus on just the processing side, so we can optimize and scale it separately. As for portability, we started with everything on Heroku, but we've been slowly migrating to aws as our needs scale up. Our configuration makes this really easy: we can move the rabbitmq piece over one week, then the clojure the next, without changing anything but a few lines in a config file. Ron On Monday, September 9, 2013 7:47:54 AM UTC-7, rdelcueto wrote: Hey Ron, Thanks for your response. Digging deeper into my question... When I read about the Torquebox Immutant duet, I thought it was particularly interesting solution, because it was fairly easy to deploy and both processes would live inside a JVM environment. I was impressed by how Clojure data structures mapped to Ruby structures and vice-versa, it seemed to provide a very clean and idiomatic messaging platform. Plus it would provide tools for caching, clustering, and what not. Still I wasn't very keen on the JRuby subject, since It's known to have compatibility issues with certain gems. Yesterday while researching on the subject I found about ZeroMQ. Do you have any particular reason to use RabbitMQ over other messaging libraries? Are there any caveats to your interop model? How portable is deploying a site using a messaging solution such as RabbitMQ? I also found out about Google's Protocol Buffers, they seemed like a lightweight solution to pass language agnostic data structures through the messaging infrastructure. Do messages need to be encapsulated somehow, or is this actually unnecessary? How it's done in your case? Regarding security and sensible information interop; Should messages be encrypted? Should they be encrypted as a whole message or partially (only sensible data)? What are the performance implications of this pipeline? Is the overhead and footprint of such setup (Ruby + Messaging Broker + ClojureJVM) big enough, for it to be worth thinking on writing everything in Clojure (using the Luminus framework)? On Monday, September 9, 2013 8:10:41 AM UTC-5, Ron Toland wrote: At Rewryte, we use Rails for the web frontend and Clojure for the data processing backend for exactly the reasons you described. We use RabbitMQ to communicate between the two. This maintains separation between the two apps (no JRuby required), and lets us scale them both independently, while taking advantage of each language/framework's strengths. -- -- 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/groups/opt_out.
Re: finding retained head
FWIW, Brian and I were looking at this off-list and we changed (dorun (map identity matrix)) to (doseq [x matrix] (identity x)) and that seemed to work just fine - even in Brian's more complicated case. Given that dorun specifically says it doesn't hold on to the head, I would have expected the two to behave identically. I also suspected the closure over the matrix argument as being the root cause but was puzzled when using doseq instead made the problem go away... Sean On Tue, Sep 10, 2013 at 7:34 PM, Armando Blancas abm221...@gmail.com wrote: Can anyone explain to me what's happening here? Something about creating a anonymous function? The problem is not creating the anonymous function but that it closes over the matrix argument. The closure passed on to blah will keep a reference to matrix until blah returns. This won't happen if the anonymous function takes the matrix as a parameter: (defn blah [func v] (func v)) (defn load-exp [matrix] (blah (fn [m] (dorun (map identity m))) matrix)) -- -- 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/groups/opt_out. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ 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/groups/opt_out.
Re: finding retained head
Ah. So the root of my problem is that the jdbc/transaction macro creates a closure in my function.. (defmacro transaction On Tuesday, September 10, 2013 7:34:32 PM UTC-7, Armando Blancas wrote: Can anyone explain to me what's happening here? Something about creating a anonymous function? The problem is not creating the anonymous function but that it closes over the matrix argument. The closure passed on to blah will keep a reference to matrix until blah returns. This won't happen if the anonymous function takes the matrix as a parameter: (defn blah [func v] (func v)) (defn load-exp [matrix] (blah (fn [m] (dorun (map identity m))) matrix)) -- -- 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/groups/opt_out.
Re: finding retained head
(defmacro transaction [ body] `(transaction* (fn [] ~@body))) I'm not sure how to avoid that. The anonymous function created here doesn't take parameters. On Tuesday, September 10, 2013 8:55:42 PM UTC-7, Brian Craft wrote: Ah. So the root of my problem is that the jdbc/transaction macro creates a closure in my function.. (defmacro transaction On Tuesday, September 10, 2013 7:34:32 PM UTC-7, Armando Blancas wrote: Can anyone explain to me what's happening here? Something about creating a anonymous function? The problem is not creating the anonymous function but that it closes over the matrix argument. The closure passed on to blah will keep a reference to matrix until blah returns. This won't happen if the anonymous function takes the matrix as a parameter: (defn blah [func v] (func v)) (defn load-exp [matrix] (blah (fn [m] (dorun (map identity m))) matrix)) -- -- 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/groups/opt_out.
Re: finding retained head
I also suspected the closure over the matrix argument as being the root cause but was puzzled when using doseq instead made the problem go away... Right, it doesn't seem to be a hold in the closure, unless the compiler could tell when to release it, which is the case when the code is macro expanded (doseq) or placed inline, but not when you call a function like dorun. That's really kind of puzzling. -- -- 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/groups/opt_out.
Re: new ClojureDocs experiment
On Sunday, September 8, 2013 4:07:33 AM UTC-4, Steven Degutis wrote:
https://github.com/sdegutis/clojuredocs/wiki
{snip}
Thoughts?
Hi Steven,
This is a nice piece of work. Thank you.
Some thoughts:
* Wikis are difficult to keep nice. And, seemingly contradictory to that,
it's difficult to find contributors.
* There is already a Clojure wiki,
http://en.wikibooks.org/wiki/Clojure_Programming, but it does not see
many updates.
* I really like clojuredocs.org's clean (and enforced) separation of
examples, see-also, and comments.
* Although github's wiki feature is handy, for a pure wiki there are
better solutions, IMO (for example, my favorite is
[gitit](http://www.gitit.net/)).
* I think some of the work necessary to replace/rewrite clojuredocs.org
has already been done by dakrone. Dunno the status of it though.
* I think it's worthwhile to pull docstrings directly from Clojure
itself. Fixing docstring typos in a wiki is nice, but I'd rather see fixed
the actual source docstrings themselves...
-- John
--
--
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/groups/opt_out.
Re: new ClojureDocs experiment
All very good points.
One of my assumptions was that people don't use wikis simply because
it's Yet Another Account to sign up for, so this being hosted on
github would be a much lower barrier-to-entry for contributing
examples. But I'm not sure that's a valid assumption for anyone
besides just me.
And I wasn't suggesting that the structure be edited. I was imagining
an unwritten rule where only examples would be edited/added, and the
rest of the structure of each page remain the same. That would make
parsing the wiki partially manageable. But I'm not sure how realistic
that is in practice.
Thanks for your feedback.
-Steven
On Wed, Sep 11, 2013 at 12:39 AM, John Gabriele jmg3...@gmail.com wrote:
On Sunday, September 8, 2013 4:07:33 AM UTC-4, Steven Degutis wrote:
https://github.com/sdegutis/clojuredocs/wiki
{snip}
Thoughts?
Hi Steven,
This is a nice piece of work. Thank you.
Some thoughts:
* Wikis are difficult to keep nice. And, seemingly contradictory to that,
it's difficult to find contributors.
* There is already a Clojure wiki,
http://en.wikibooks.org/wiki/Clojure_Programming, but it does not see many
updates.
* I really like clojuredocs.org's clean (and enforced) separation of
examples, see-also, and comments.
* Although github's wiki feature is handy, for a pure wiki there are
better solutions, IMO (for example, my favorite is
[gitit](http://www.gitit.net/)).
* I think some of the work necessary to replace/rewrite clojuredocs.org
has already been done by dakrone. Dunno the status of it though.
* I think it's worthwhile to pull docstrings directly from Clojure itself.
Fixing docstring typos in a wiki is nice, but I'd rather see fixed the
actual source docstrings themselves...
-- John
--
--
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/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 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/groups/opt_out.
