[ANN] stripe-tester-clj (simulate stripe webhooks in tests)
Hi, We've put together a simple library to help simulate Stripe webhooks in order to test the end points in your application. https://github.com/buttercloud/stripe-tester-clj Feedback welcome. -- Ahmad -- 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] thi,ng/geom 0.0.856 (new dataviz module)
this is quickly becoming my clojurescript goto viz api. keep up the great work! -- 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: Making Java serializables transparently printable and readable
On 17 June 2015 at 09:51, Thomas Heller th.hel...@gmail.com wrote: On another note: Sessions in cookies should be VERY VERY small. java.io.Serializable usually isn't small and especially if you go java object - binary - base64 - base64 (yes twice) - encrypt. The size of the cookie matters as it is transmitted with EVERY request. The cookie is only transmitted when the session changes. However, several browsers place limits on the size of stored cookies, and so it's generally not a good idea to serialize anything large into a cookie. On 17 June 2015 at 10:10, Fluid Dynamics a2093...@trbvm.com wrote: If you really do need to store session state that can potentially grow that large, your best bet is to stick it in a server-side database and put that table's primary key in the client-side cookie, looking up the state object on receiving it back. This also prevents the end-user or a MITM from monkeying with the state, which might prevent some types of attacks (typically, session hijacking methods that aren't simple replay attacks, or cheating to give yourself the super-duper armor for free in an online game, or whatever). This is generally sound advice, but session cookies in Ring are encrypted and MACed, so they can't be changed by the client and remain valid. However, cookie sessions do have the disadvantage that they're hard to revoke. On 17 June 2015 at 14:27, Surgo morgon.kan...@gmail.com wrote: I don't think the fault lies here with ring. It doesn't seem right to expect that library callers of these functions expose their full API to their own users...that would put a serious burden on them to more closely track the API as well. Better to have some alterable var so this can all run transparently. I don't think an alterable var is the solution. Dynamic vars tend to touch too many things. I think my preferred solution to this would be to add :serialize and :deserialize keys to the cookie-store's options. - 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 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] lambada - using clojure with AWS Lambda
Hi, I've just released lambada, a tiny library that provides a way to write AWS Lambda [1] functions in clojure: https://github.com/uswitch/lambada The slightly tricky part with using clojure on Lambda was getting the clojure runtime to load classes using the correct class loader and this library solves that problem, and provides a simple macro to generate named classes that can be used as Lambda handlers. Cheers, Ragnar [1]: http://docs.aws.amazon.com/lambda/latest/dg/welcome.html -- 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: Making Java serializables transparently printable and readable
On 18 June 2015 at 00:54, Thomas Heller i...@zilence.net wrote: On Wed, Jun 17, 2015 at 9:50 PM, James Reeves ja...@booleanknot.com wrote: On 17 June 2015 at 09:51, Thomas Heller th.hel...@gmail.com wrote: On another note: Sessions in cookies should be VERY VERY small. java.io.Serializable usually isn't small and especially if you go java object - binary - base64 - base64 (yes twice) - encrypt. The size of the cookie matters as it is transmitted with EVERY request. The cookie is only transmitted when the session changes. However, several browsers place limits on the size of stored cookies, and so it's generally not a good idea to serialize anything large into a cookie. They are transmitted for every request client - server. If you host images/css/js on the same host each request will contain the cookie. 2kb cookie for 100 requests (quite common for webapps) and all the optimizations done to keep javascript small go out the window. Ah yes, sorry; I misread your original message as response instead of request. - 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 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
Just another +1 to include a core.matrix implementation -- 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: Making Java serializables transparently printable and readable
On Wed, Jun 17, 2015 at 9:50 PM, James Reeves ja...@booleanknot.com wrote: On 17 June 2015 at 09:51, Thomas Heller th.hel...@gmail.com wrote: On another note: Sessions in cookies should be VERY VERY small. java.io.Serializable usually isn't small and especially if you go java object - binary - base64 - base64 (yes twice) - encrypt. The size of the cookie matters as it is transmitted with EVERY request. The cookie is only transmitted when the session changes. However, several browsers place limits on the size of stored cookies, and so it's generally not a good idea to serialize anything large into a cookie. They are transmitted for every request client - server. If you host images/css/js on the same host each request will contain the cookie. 2kb cookie for 100 requests (quite common for webapps) and all the optimizations done to keep javascript small go out the window. -- 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: clojure-maven-plugin 1.7.1
Released 1.7.1 of of the clojure-maven-plugin yesterday with support for `.cljc` files and an improved test runner script. https://github.com/talios/clojure-maven-plugin Thanks to Alex Miller and Robert Evens whose pull requests made up this small release ( with a version number bounce to align with the upcoming 1.7 clojure release ). Mark -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt -- 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. signature.asc Description: OpenPGP digital signature
Re: Making Java serializables transparently printable and readable
Altering root vars is a bit of an annoying hack but it's the only way I've found so far to be fully transparent with already-existing code and libraries. For anyone who needs Java serialization support I've wrapped all of this up into a simple library, which can be found here: https://bitbucket.org/morgon/jfreeze Cheers, -- Morgon On Wednesday, June 17, 2015 at 3:51:02 PM UTC-4, James Reeves wrote: On 17 June 2015 at 09:51, Thomas Heller th.h...@gmail.com javascript: wrote: On another note: Sessions in cookies should be VERY VERY small. java.io.Serializable usually isn't small and especially if you go java object - binary - base64 - base64 (yes twice) - encrypt. The size of the cookie matters as it is transmitted with EVERY request. The cookie is only transmitted when the session changes. However, several browsers place limits on the size of stored cookies, and so it's generally not a good idea to serialize anything large into a cookie. On 17 June 2015 at 10:10, Fluid Dynamics a209...@trbvm.com javascript: wrote: If you really do need to store session state that can potentially grow that large, your best bet is to stick it in a server-side database and put that table's primary key in the client-side cookie, looking up the state object on receiving it back. This also prevents the end-user or a MITM from monkeying with the state, which might prevent some types of attacks (typically, session hijacking methods that aren't simple replay attacks, or cheating to give yourself the super-duper armor for free in an online game, or whatever). This is generally sound advice, but session cookies in Ring are encrypted and MACed, so they can't be changed by the client and remain valid. However, cookie sessions do have the disadvantage that they're hard to revoke. On 17 June 2015 at 14:27, Surgo morgon...@gmail.com javascript: wrote: I don't think the fault lies here with ring. It doesn't seem right to expect that library callers of these functions expose their full API to their own users...that would put a serious burden on them to more closely track the API as well. Better to have some alterable var so this can all run transparently. I don't think an alterable var is the solution. Dynamic vars tend to touch too many things. I think my preferred solution to this would be to add :serialize and :deserialize keys to the cookie-store's options. - 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 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
First of all, nice work :-) In the docs you keep referring to core.matrix as though it was a particular implementation, saying things like X times faster than core.matrix. This is misleading; core.matrix is an abstract API, which can have many implementations. Saying something is faster than it doesn't mean anything. In particular, it's misleading to compare Neanderthal to core.matrix by comparing it to Vectorz and jBlas, since faster implementations could be written and are underway. Perhaps something a little more verbose like Neanderthal to the fastest (current?) core.matrix implementations would be less misleading. On a stylistic note, I like the website design overall, but the graph paper lines on the back ground are a bit distracting in relation to the text. Perhaps a white background behind the text, with the graph lines on the margins would capture the same effect but be less distracting? At the risk of being a nag, I'd also like to reiterate the desire of the community to avoid library fragmentation and see Neanderthal implement the core.matrix protocols. Mike elegantly explicated the reasons for this in his earlier post: if we all build around a common abstract API, we maximize the Clojure dream of composability of anything written towards and for that API. This is important to a lot of Clojurians. Earlier in the thread you expressed concerns about whether it would really be so easy to have Neanderthal's as a core.matrix API. Mike Anderson's response to me suggests he thought you were questioning whether swapping core.matrix implementations was really so easy. Just in case you were doubtful of the former more so than the latter, perhaps I can clarify. Core.matrix is built entirely around abstract protocols which represent the various matrix operations one might care about for a matrix computation library. There are protocols for addition, inner product, outer product, multiply and add, invert, etc. All you would have to do to make Neanderthal functional as a core.matrix implementation is implement these protocols in some namespace within your project (perhaps ` uncomplicate.neanderthal.core-matrix`). As Mike pointed out, you wouldn't even have to implement _all_ the protocols, since core.matrix comes with default implementations of the things you don't define. Once you'd made the implementations, you register an example matrix object with core.matrix at the end of your namespace, and then when a user requires that namespace, the Neanderthal implementation would be registered, and users could start instantiating Neanderthal matrices that are 100% compatible with the core.matrix API. Setting things up this way, you wouldn't even have to abandon your own API. The two could live in harmony along side each other, letting folks require and use whichever they like. It really is just that simple; implement a few protocols, and the API will work. It sounds too good to be true, and I didn't believe it at first either, but it works. I get that you've put a lot of energy into this, and commend you for it. I personally would love to take advantage of that hard work, and am sure others would as well. However, I think you're going to find adoption difficult if Neanderthal risks fragmenting the presently coherent state of numerical computing in Clojure, and imposes inflexibilities upon those who would use it in their own code. I personally am not willing to boost performance at the cost of flexibility. OK; I'll leave it at that. Respectfully, Chris On Wed, Jun 17, 2015 at 8:07 AM, Dragan Djuric draga...@gmail.com wrote: Version 0.2.0 has just been released to Clojars New features: * implemented BLAS support for floats * implemented fmap!, freduce, and fold functions for all existing types of matrices and vectors Changes: No API changes were required for these features. On Tuesday, January 13, 2015 at 2:13:13 AM UTC+1, 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); -
Re: [ANN] thi,ng/geom 0.0.856 (new dataviz module)
Mine too, this is fantastic work and the charts are very pretty :) On Wed, 17 Jun 2015 at 20:05 Ivan L ivan.laza...@gmail.com wrote: this is quickly becoming my clojurescript goto viz api. keep up the great work! -- 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: Component: lists of components, possibly changing
Take a look at Peripheral (https://github.com/xsc/peripheral). It's based on Component and may provide some of the functionality you need. -- 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-RC2
Migrated a library from cljx to reader conditionals and tested it with both RC1 and RC2, everything works perfectly. Thank you for your work on Clojure and looking forward to the final release. On Wed, Jun 17, 2015, at 19:44, Alex Miller wrote: Clojure 1.7.0-RC2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/ - Leiningen: [org.clojure/clojure 1.7.0-RC2] 1.7.-RC2 has the following changes since 1.7.0-RC1: 1) CLJ-1735 - Throwable-map was missing docstring 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and forth between chunked and unchunked many times This was an old problem that was amplified in 1.7, but has now been fixed. 3) CLJ-1738 - Seqs over Java iterators that return the same mutating object on every next() call Seqs are fundamentally incompatible with Java iterators that return the same mutating object on every call to next(). Some Clojure libraries incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs are chunked, which will cause many of these incorrect usages to return incorrect results immediately. The `seq` and `iterator- seq` docstrings have been updated to include an explicit warning. Libraries that incorrectly use `seq` and `iterator-seq` will need to be fixed before running against 1.7. 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional CompilerException This was a regression from CLJ-1169 and most of that change has been rolled back. For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- 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.
[ANN] piton - SQL-targeting migrations and seeding
Just put up a little library for sql migrations and seeding. I wanted something really simple; naturally at the cost of generality. Thus this is a weaker take on migrations and seeding that focuses specifically on SQL databases. Comes with a plugin to help with managing things--specifically for writing an edn file for handling migrations and seeding from an uberjar (keeping my database credentials out of version control). *https://github.com/thomasmeier/piton https://github.com/thomasmeier/piton* -- 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] CIDER 0.9
Bozhidar Batsov bozhi...@batsov.com writes: Yeah, I'm aware of those problems, but as you already know they have to fixed in leiningen. At least these days leiningen has an alternative ( https://github.com/boot-clj/boot). Good point - this is an opportunity for me to try out boot. :-) Alexis. -- 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.
stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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] CIDER 0.9
Bozhidar Batsov bozhi...@batsov.com writes:
nREPL 0.2.6 is pretty old and has some serious bugs in it (alas
there hasn't been a lein release for a while). You'll have to
pull in a newer nREPL manually to get rid of this.
{:user {:dependencies [[org.clojure/tools.nrepl 0.2.10”]]}}
Unfortunately this doesn't necessarily work - it certainly doesn't
work for me! - as per the following:
https://github.com/technomancy/leiningen/issues/1900
https://github.com/technomancy/leiningen/issues/1901
Alexis.
--
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-RC2
Thanks Alex (hope you had a great vacation)! Everything is looking good for us with RC2. On Wednesday, June 17, 2015 at 10:44:39 AM UTC-7, Alex Miller wrote: Clojure 1.7.0-RC2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/ - Leiningen: [org.clojure/clojure 1.7.0-RC2] 1.7.0-RC2 has the following changes since 1.7.0-RC1: 1) CLJ-1735 - Throwable-map was missing docstring 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and forth between chunked and unchunked many times This was an old problem that was amplified in 1.7, but has now been fixed. 3) CLJ-1738 - Seqs over Java iterators that return the same mutating object on every next() call Seqs are fundamentally incompatible with Java iterators that return the same mutating object on every call to next(). Some Clojure libraries incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs are chunked, which will cause many of these incorrect usages to return incorrect results immediately. The `seq` and `iterator-seq` docstrings have been updated to include an explicit warning. Libraries that incorrectly use `seq` and `iterator-seq` will need to be fixed before running against 1.7. 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional CompilerException This was a regression from CLJ-1169 and most of that change has been rolled back. For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- 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.
Component: lists of components, possibly changing
Whats the pattern for creating lists of components? I have N of components of the same type, which get some dependencies from the system map along with instance-specific config data. I want them in a single vector (or hashmap) keyed from the system map. Do I need to create an intermediary component to contain all of these? Somewhat annoying as I actually have several of these lists, so I'd need several corresponding records that do the same thing but have different dependency details. Part 2: I want to be able to add/remove components from the list. I know Stuart said this is a problem, was wondering if there are any known solutions out there. 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.
[ANN] Clojure 1.7.0-RC2
Clojure 1.7.0-RC2 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/ - Leiningen: [org.clojure/clojure 1.7.0-RC2] 1.7.0-RC2 has the following changes since 1.7.0-RC1: 1) CLJ-1735 - Throwable-map was missing docstring 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and forth between chunked and unchunked many times This was an old problem that was amplified in 1.7, but has now been fixed. 3) CLJ-1738 - Seqs over Java iterators that return the same mutating object on every next() call Seqs are fundamentally incompatible with Java iterators that return the same mutating object on every call to next(). Some Clojure libraries incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs are chunked, which will cause many of these incorrect usages to return incorrect results immediately. The `seq` and `iterator-seq` docstrings have been updated to include an explicit warning. Libraries that incorrectly use `seq` and `iterator-seq` will need to be fixed before running against 1.7. 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional CompilerException This was a regression from CLJ-1169 and most of that change has been rolled back. For a full list of changes since 1.6.0, see: https://github.com/clojure/clojure/blob/master/changes.md Please give it a try and let us know if things are working (or not). The more and quicker feedback we get, the sooner we can release 1.7.0 final! - Alex -- 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] CIDER 0.9
Yeah, I'm aware of those problems, but as you already know they have to
fixed in leiningen. At least these days leiningen has an alternative (
https://github.com/boot-clj/boot).
On 18 June 2015 at 07:51, Alexis flexibe...@gmail.com wrote:
Bozhidar Batsov bozhi...@batsov.com writes:
nREPL 0.2.6 is pretty old and has some serious bugs in it (alas there
hasn't been a lein release for a while). You'll have to pull in a newer
nREPL manually to get rid of this.
{:user {:dependencies [[org.clojure/tools.nrepl 0.2.10”]]}}
Unfortunately this doesn't necessarily work - it certainly doesn't work
for me! - as per the following:
https://github.com/technomancy/leiningen/issues/1900
https://github.com/technomancy/leiningen/issues/1901
Alexis.
--
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: Weird behaviour in re-matches ?
On Tuesday, June 16, 2015 at 7:40:24 AM UTC-4, Jeroen van Dijk wrote: Ah thanks James, I missed the pending nil. The actual value is still nil indeed: user= (def m (re-matches #.*(foo\.gif).* foo.gif\n)) foo.gif\n#'user/m user= m nil Not sure what would be the cause here then, but the random printing of the second argument of re-matches also happens when I evaluate an arbitrary function after the exception PatternSyntaxException Unmatched closing ')' near index 13 .*(foo\.gif).*) ^ java.util.regex.Pattern.error (Pattern.java:1924) RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException (Util.java:221) user= (list 1 2) foo.gif\n(1 2) cider doesn't have this problem either it seems Looks like something in re-matches is printing the second argument, but without a terminating newline. A subsequent print, such as of nil\n or (1 2)\n, by the REPL evaluator, with a newline, then completes the line and flushes the output buffer. There seem to be three separate errors here, two of them in re-matches: 1. The one case where you slipped in an extra close parenthesis, which is what caused the exceptions. 2. The peculiar printing (without flushing) of the second argument by re-matches. (I don't know where it's going with some of the different REPLs but perhaps those ones maintain a different output stream for *out* and for REPL evaluation result printing.) 3. The regexp *should* match foo.gif\n from the looks of it, but seems not to be doing so. -- 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] CIDER 0.9
Yeah, that's an unfortunate problem with package.el. See https://github.com/clojure-emacs/cider/issues/1050#issuecomment-112595451 On 17 June 2015 at 05:38, Avi Avicenna maverick.avice...@gmail.com wrote: Wow!! Many thanks to all CIDER contributors. I didn't get it to work at first, but deleting all previous *.elc files and restarting emacs solves the problem. Congratulations! Yours, Avicenna On Tuesday, 16 June 2015 21:33:48 UTC+7, Bozhidar Batsov wrote: Hey everyone, CIDER 0.9 is finally out! You can read more about the release here http://batsov.com/articles/2015/06/16/cider-0-dot-9/ Enjoy (responsibly)! :-) -- 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] CIDER 0.9
leiningen use org.clojure/tools.nrepl 0.2.6 cider-nrepl throw warning On Tuesday, June 16, 2015 at 10:33:48 PM UTC+8, Bozhidar Batsov wrote: Hey everyone, CIDER 0.9 is finally out! You can read more about the release here http://batsov.com/articles/2015/06/16/cider-0-dot-9/ Enjoy (responsibly)! :-) -- 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: Making Java serializables transparently printable and readable
From glancing at the source, I think you should be able to do what you want
with clojure.core/*data-readers* and/or
clojure.core/*default-data-readers-fn*.
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/*data-readers*
It is not clearly documented that the edn reader checks them, so maybe it
won't be reliable across versions.
On Wednesday, 17 June 2015, Surgo morgon.kan...@gmail.com wrote:
I've been working on a Ring app that involves storing sessions as cookies,
and within the session there are a couple Java objects that implement
java.io.Serializable. I was somewhat surprised to find that the print-dup
multimethod didn't have native support for Java Serializables, though I can
understand why (they aren't really meant for long-term storage because
version changes are troublesome). It wasn't too much trouble to come up
with a basic implementation that could cover all of java.io.Serializable:
https://bitbucket.org/snippets/morgon/jkjyA
The trouble I'm having comes with reading it back in, though. In the above
snippet, we output as a function call and depend on the behavior of
clojure.core/read{,-string} to evaluate the function where the magic
happens. This obviously doesn't work with the safer and recommended
clojure.edn/read{,-string}. According to the EDN specification I should be
able to set a dispatch tag like, say, #java base64 and attach a
deserialization function to :readers for the tag. This isn't transparent
though: I can't just include the library and have it work with Ring's
already-existing (de)serialization, nor anywhere else that doesn't
explicitly pass my special function to clojure.edn/read{,-string}.
Is there anything I can do without filing a ticket and hoping something
comes to be a part of the core library? To the best of my knowledge there's
no binding I can alter for the :readers or :default options for
clojure.edn/read{,-string}; that needs to be passed directly into the
function at the call site. I could maybe alter the clojure.edn/read and
clojure.edn/read-string vars themselves to wrap them so I can pass in a
:readers option with my tag, though that seems kind of nasty and I'm not
sure it will work in 100% of cases. What is there that can be done for this
problem?
Thanks,
-- Morgon
--
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
javascript:_e(%7B%7D,'cvml','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
javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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
javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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] CIDER 0.9
I upgraded to version 0.9 I get the following error when starting cider in emacs: Starting nREPL server via lein repl :headless... nREPL server started on 55266 nREPL: Establishing direct connection to localhost:55266 ... nREPL: Direct connection established error in process filter: cider-repl-mode: Symbol's function definition is void: clojure-mode-variables error in process filter: Symbol's function definition is void: clojure-mode-variables ... I didn't get it to work at first, but deleting all previous *.elc files and restarting emacs solves the problem. Welcome to the wonderful world of emacs, where when you upgrade a module you have to hunt down all of the dependencies manually to upgrade them all separately *and* lift the hood to perform additional arcane rituals in place of simply download, install, run or even download, configure, make, make install, run. We hope you enjoy your stay. And that you are, or know, a good mechanic. :) (OK, OK, it is aimed at an audience of mainly computer programmers, so it can be forgiven I guess for assuming every user is one, but even so, I prefer my tools to download, install, and then get out of the way and let me program *my* project rather than needing me to program parts of *them* first...) -- 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: Making Java serializables transparently printable and readable
Hey,
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring. Should be a
fairly simple fix though, doing anything to clojure.edn won't help as it is
not used.
On another note: Sessions in cookies should be VERY VERY small.
java.io.Serializable usually isn't small and especially if you go java
object - binary - base64 - base64 (yes twice) - encrypt. The size of
the cookie matters as it is transmitted with EVERY request.
I would recommend writing print-method implementation for the Java objects
you need to serialize and keeping those to a minimum. Session cookies are
not arbitrary storage and writing a transparent serialization format that
doesn't check the size will lead to uncontrolled growth. I have seen way
too many web apps with cookies above 4kb. One even had Apache configured to
reject requests (well, default config) that had too large cookies and no
one even noticed except for the users that left confused and never came
back.
Just as a warning. :)
Cheers,
/thomas
On Wednesday, June 17, 2015 at 3:47:39 AM UTC+2, Surgo wrote:
I've been working on a Ring app that involves storing sessions as cookies,
and within the session there are a couple Java objects that implement
java.io.Serializable. I was somewhat surprised to find that the print-dup
multimethod didn't have native support for Java Serializables, though I can
understand why (they aren't really meant for long-term storage because
version changes are troublesome). It wasn't too much trouble to come up
with a basic implementation that could cover all of java.io.Serializable:
https://bitbucket.org/snippets/morgon/jkjyA
The trouble I'm having comes with reading it back in, though. In the above
snippet, we output as a function call and depend on the behavior of
clojure.core/read{,-string} to evaluate the function where the magic
happens. This obviously doesn't work with the safer and recommended
clojure.edn/read{,-string}. According to the EDN specification I should be
able to set a dispatch tag like, say, #java base64 and attach a
deserialization function to :readers for the tag. This isn't transparent
though: I can't just include the library and have it work with Ring's
already-existing (de)serialization, nor anywhere else that doesn't
explicitly pass my special function to clojure.edn/read{,-string}.
Is there anything I can do without filing a ticket and hoping something
comes to be a part of the core library? To the best of my knowledge there's
no binding I can alter for the :readers or :default options for
clojure.edn/read{,-string}; that needs to be passed directly into the
function at the call site. I could maybe alter the clojure.edn/read and
clojure.edn/read-string vars themselves to wrap them so I can pass in a
:readers option with my tag, though that seems kind of nasty and I'm not
sure it will work in 100% of cases. What is there that can be done for this
problem?
Thanks,
-- Morgon
--
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: Weird behaviour in re-matches ?
Looks like something in re-matches is printing the second argument, but without a terminating newline. A subsequent print, such as of nil\n or (1 2)\n, by the REPL evaluator, with a newline, then completes the line and flushes the output buffer. There seem to be three separate errors here, two of them in re-matches: 1. The one case where you slipped in an extra close parenthesis, which is what caused the exceptions. Yeah I was quickly aware of this one 2. The peculiar printing (without flushing) of the second argument by re-matches. (I don't know where it's going with some of the different REPLs but perhaps those ones maintain a different output stream for *out* and for REPL evaluation result printing.) This caused all my confusion about the result. Not sure at what level this happens. 3. The regexp *should* match foo.gif\n from the looks of it, but seems not to be doing so. Can be solved by using a multiline flag (?is) [1]: user= (re-matches #(?is).*(foo\.gif).* foo.gif\n) [foo.gif\n foo.gif] [1] Found this here http://stackoverflow.com/questions/15020669/clojure-multiline-regular-expression -- 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: Making Java serializables transparently printable and readable
On Wednesday, June 17, 2015 at 4:52:00 AM UTC-4, Thomas Heller wrote:
Hey,
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring. Should be a
fairly simple fix though, doing anything to clojure.edn won't help as it is
not used.
On another note: Sessions in cookies should be VERY VERY small.
java.io.Serializable usually isn't small and especially if you go java
object - binary - base64 - base64 (yes twice) - encrypt. The size of
the cookie matters as it is transmitted with EVERY request.
I would recommend writing print-method implementation for the Java objects
you need to serialize and keeping those to a minimum. Session cookies are
not arbitrary storage and writing a transparent serialization format that
doesn't check the size will lead to uncontrolled growth. I have seen way
too many web apps with cookies above 4kb. One even had Apache configured to
reject requests (well, default config) that had too large cookies and no
one even noticed except for the users that left confused and never came
back.
Just as a warning. :)
If you really do need to store session state that can potentially grow that
large, your best bet is to stick it in a server-side database and put that
table's primary key in the client-side cookie, looking up the state object
on receiving it back. This also prevents the end-user or a MITM from
monkeying with the state, which might prevent some types of attacks
(typically, session hijacking methods that aren't simple replay attacks, or
cheating to give yourself the super-duper armor for free in an online game,
or whatever). Remember when ATT was embarrassed by some guy finding he
could peek at every customer's data just by changing an custID=nnn sort of
URL parameter? Same thing can happen with a cookie that just says logged
in as user#6178 or equivalent. Change it to 6179 and boom you're someone
else. But if the cookie is something like a random UUID that points to a
server-side DB entry that says logged in as user#6178 fiddling with the
UUID will just produce error messages. Just don't use an autoincrement
integer PK or you are right back where you started. :)
--
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] CIDER 0.9
I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. On Tuesday, June 16, 2015 at 4:33:48 PM UTC+2, Bozhidar Batsov wrote: Hey everyone, CIDER 0.9 is finally out! You can read more about the release here http://batsov.com/articles/2015/06/16/cider-0-dot-9/ Enjoy (responsibly)! :-) -- 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] CIDER 0.9
Nevermind, I found the solution. (require 'cl) manually before compiling cider. On Wednesday, June 17, 2015 at 3:01:47 PM UTC+2, Leon Grapenthin wrote: I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. On Tuesday, June 16, 2015 at 4:33:48 PM UTC+2, Bozhidar Batsov wrote: Hey everyone, CIDER 0.9 is finally out! You can read more about the release here http://batsov.com/articles/2015/06/16/cider-0-dot-9/ Enjoy (responsibly)! :-) -- 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: Making Java serializables transparently printable and readable
Let's not get into the motivation behind this too much -- the exact same
serialization problems exist if you write out the session to a database.
Ring also encrypts the cookies so the above issue is not a problem, it's
only on you to actually choose and protect your encryption key.
I came across *data-readers* as well.I did not find it possible to make it
completely transparent if one was to use the REPL though because it is
bound on entering the REPL. Furthermore I don't think it works with
clojure.edn as well. However, it seems that
clojure.core/default-data-readers does work with both clojure.core and
clojure.edn functions. Thus I've solved the issue by altering
clojure.core/default-data-readers to include my library's tag. This seems a
bit hackish because I'm not sure you're supposed to be modifying this var,
but it's the only thing I can find that both clojure.core/read{,-string}
and clojure.edn/read{,-string} respect.
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring.
I don't think the fault lies here with ring. It doesn't seem right to
expect that library callers of these functions expose their full API to
their own users...that would put a serious burden on them to more closely
track the API as well. Better to have some alterable var so this can all
run transparently.
it uses clojure.tools.reader.edn/read-string
Ugh, thanks. I forgot about that one as well.
On Wednesday, June 17, 2015 at 5:10:24 AM UTC-4, Fluid Dynamics wrote:
On Wednesday, June 17, 2015 at 4:52:00 AM UTC-4, Thomas Heller wrote:
Hey,
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring. Should be a
fairly simple fix though, doing anything to clojure.edn won't help as it is
not used.
On another note: Sessions in cookies should be VERY VERY small.
java.io.Serializable usually isn't small and especially if you go java
object - binary - base64 - base64 (yes twice) - encrypt. The size of
the cookie matters as it is transmitted with EVERY request.
I would recommend writing print-method implementation for the Java
objects you need to serialize and keeping those to a minimum. Session
cookies are not arbitrary storage and writing a transparent serialization
format that doesn't check the size will lead to uncontrolled growth. I have
seen way too many web apps with cookies above 4kb. One even had Apache
configured to reject requests (well, default config) that had too large
cookies and no one even noticed except for the users that left confused and
never came back.
Just as a warning. :)
If you really do need to store session state that can potentially grow
that large, your best bet is to stick it in a server-side database and put
that table's primary key in the client-side cookie, looking up the state
object on receiving it back. This also prevents the end-user or a MITM from
monkeying with the state, which might prevent some types of attacks
(typically, session hijacking methods that aren't simple replay attacks, or
cheating to give yourself the super-duper armor for free in an online game,
or whatever). Remember when ATT was embarrassed by some guy finding he
could peek at every customer's data just by changing an custID=nnn sort of
URL parameter? Same thing can happen with a cookie that just says logged
in as user#6178 or equivalent. Change it to 6179 and boom you're someone
else. But if the cookie is something like a random UUID that points to a
server-side DB entry that says logged in as user#6178 fiddling with the
UUID will just produce error messages. Just don't use an autoincrement
integer PK or you are right back where you started. :)
--
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] CIDER 0.9
On Wednesday, June 17, 2015 at 9:06:58 AM UTC-4, Leon Grapenthin wrote: Nevermind, I found the solution. (require 'cl) manually before compiling cider. On Wednesday, June 17, 2015 at 3:01:47 PM UTC+2, Leon Grapenthin wrote: I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. I must say, though, that every time something is upgraded it *is* quite amusing watching you emacs users running around chasing your tails for several hours afterwards while the rest of us are already getting useful work done. :) -- 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] CIDER 0.9
Ouch. That's an oversight on my part. Seems we've used a few functions straight from `cl` instead of the newer `cl-lib`. Thought I had all those usages fixed, but I guess I haven't. On 17 June 2015 at 16:06, Leon Grapenthin grapenthinl...@gmail.com wrote: Nevermind, I found the solution. (require 'cl) manually before compiling cider. On Wednesday, June 17, 2015 at 3:01:47 PM UTC+2, Leon Grapenthin wrote: I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. On Tuesday, June 16, 2015 at 4:33:48 PM UTC+2, Bozhidar Batsov wrote: Hey everyone, CIDER 0.9 is finally out! You can read more about the release here http://batsov.com/articles/2015/06/16/cider-0-dot-9/ Enjoy (responsibly)! :-) -- 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] CIDER 0.9
On 17 June 2015 at 20:56, Fluid Dynamics a2093...@trbvm.com wrote: On Wednesday, June 17, 2015 at 9:06:58 AM UTC-4, Leon Grapenthin wrote: Nevermind, I found the solution. (require 'cl) manually before compiling cider. On Wednesday, June 17, 2015 at 3:01:47 PM UTC+2, Leon Grapenthin wrote: I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. I must say, though, that every time something is upgraded it *is* quite amusing watching you emacs users running around chasing your tails for several hours afterwards while the rest of us are already getting useful work done. :) Yeah, that's one of emacs's powers: provide amusement for people. I am happy that you are entertained :) -- 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/Qv77aUTWbOo/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] CIDER 0.9
Go do something useful with your IDE (or whatever) for a change and stop trolling on this thread... On 17 June 2015 at 16:56, Fluid Dynamics a2093...@trbvm.com wrote: On Wednesday, June 17, 2015 at 9:06:58 AM UTC-4, Leon Grapenthin wrote: Nevermind, I found the solution. (require 'cl) manually before compiling cider. On Wednesday, June 17, 2015 at 3:01:47 PM UTC+2, Leon Grapenthin wrote: I think I managed to get almost everything to work. The only thing that doesn't work is the nrepl history. When I hit M-p or M-n, I get Symbol's function definition is void: assert When I run (require 'cl) it changes to Invalid function: assert Am I the only one with this problem? Because I found no reports of it. I must say, though, that every time something is upgraded it *is* quite amusing watching you emacs users running around chasing your tails for several hours afterwards while the rest of us are already getting useful work done. :) -- 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] CIDER 0.9
nREPL 0.2.6 is pretty old and has some serious bugs in it (alas there
hasn't been a lein release for a while). You'll have to pull in a newer
nREPL manually to get rid of this.
{:user {:dependencies [[org.clojure/tools.nrepl 0.2.10”]]}}
On 17 June 2015 at 10:04, Isaac Zeng ndtm.i...@gmail.com wrote:
leiningen use org.clojure/tools.nrepl 0.2.6 cider-nrepl throw warning
On Tuesday, June 16, 2015 at 10:33:48 PM UTC+8, Bozhidar Batsov wrote:
Hey everyone,
CIDER 0.9 is finally out! You can read more about the release here
http://batsov.com/articles/2015/06/16/cider-0-dot-9/
Enjoy (responsibly)! :-)
--
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: Clojure on AWS Lambda?
You can get the initial startup time down by AOT compiling. I also believe that Lambda will re-use the same runtime and lambda function instance until a certain period of inactivity. For example, in the example below I invoke the function (AOT compiled this time) three times. First invocation takes ~7s, the two following ~1.5ms. START RequestId: b555c9c2-14c1-11e5-8a31-03153568534c HELLO FROM CLOJURE :) #object[lambdainternal.api.LambdaClientContext 0x3419866c lambdainternal.api.LambdaClientContext@3419866c] END RequestId: b555c9c2-14c1-11e5-8a31-03153568534c REPORT RequestId: b555c9c2-14c1-11e5-8a31-03153568534c Duration: 7882.62 ms Billed Duration: 7900 ms Memory Size: 512 MB Max Memory Used: 98 MB START RequestId: bd876a51-14c1-11e5-94fc-f9606cb38b63 HELLO FROM CLOJURE :) #object[lambdainternal.api.LambdaClientContext 0x63e31ee lambdainternal.api.LambdaClientContext@63e31ee] END RequestId: bd876a51-14c1-11e5-94fc-f9606cb38b63 REPORT RequestId: bd876a51-14c1-11e5-94fc-f9606cb38b63 Duration: 1.66 ms Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 98 MB START RequestId: bdf4aa6f-14c1-11e5-a6b0-e9e3f6fa14c8 HELLO FROM CLOJURE :) #object[lambdainternal.api.LambdaClientContext 0x68fb2c38 lambdainternal.api.LambdaClientContext@68fb2c38] END RequestId: bdf4aa6f-14c1-11e5-a6b0-e9e3f6fa14c8 REPORT RequestId: bdf4aa6f-14c1-11e5-a6b0-e9e3f6fa14c8 Duration: 1.56 ms Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 98 MB On Tuesday, 16 June 2015 16:46:36 UTC+1, Kyle Sexton wrote: Answering my own question about performance, it looks like almost 14 seconds for the Lambda function to run. Doing the math1 #m2mvzzr704.fsf@mocker.org_fn.1 if I were to run this 300 times in a month bill would be about $342.56. Probably not the ideal solution for clojure in the cloud just yet. :) START RequestId: 48614bcd-143b-11e5-b2c5-b704df8ab2eb HELLO FROM CLOJURE :) #object[lambdainternal.api.LambdaClientContext 0x26a7b76d lambdainternal.api.LambdaClientContext@26a7b76d] END RequestId: 48614bcd-143b-11e5-b2c5-b704df8ab2eb REPORT RequestId: 48614bcd-143b-11e5-b2c5-b704df8ab2ebDuration: 13680.53 ms Billed Duration: 13700 ms Memory Size: 512 MB Max Memory Used: 104 MB Kyle Sexton Footnotes: Footnotes: 1 #m2mvzzr704.fsf@mocker.org_fnr.1 Used http://aws.amazon.com/lambda/pricing/ and came up with (* (* (* 13.7 300) (/ 512 1024.0)) 0.1667) where 300 is number of times run per month, 13.7 is seconds of billable time, 512 is MB of RAM allocated to the function. -- 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] ClojureCL - OpenCL 2.0 Clojure library (GPGPU and high performance parallel computing)
superb! are there any plans to include opengl context sharing for visualisation ? -- 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] ClojureCL - OpenCL 2.0 Clojure library (GPGPU and high performance parallel computing)
Certainly, but that is not a priority, since I do not use (nor need) OpenGL myself. I would be very interested to include contributions as soon as I get them, and the foundations are already there (in JOCL), so it is not that hard at might look at first glance - I just do not have time to be sure that I do it properly now. On Wednesday, June 17, 2015 at 4:54:45 PM UTC+2, Bobby Bobble wrote: superb! are there any plans to include opengl context sharing for visualisation ? -- 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
Version 0.2.0 has just been released to Clojars New features: * implemented BLAS support for floats * implemented fmap!, freduce, and fold functions for all existing types of matrices and vectors Changes: No API changes were required for these features. On Tuesday, January 13, 2015 at 2:13:13 AM UTC+1, 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: Making Java serializables transparently printable and readable
Well, the exact same serialization problems do not exist with a database
because size doesn't matter so much. Security does matter more also because
of replay attacks, it is not just about keeping your key secret. Anyways,
that was meant as a warning.
I don't agree with the alterable var approach and changing the ring
handler to properly handle the API of read is less work than typing out
this email but if you want to alter a var you can probably alter
#'clojure.tools.reader/*data-readers* to get what you want. I prefer
explicit configuration over transparent vars spread all over but YMMV.
/thomas
On Wednesday, June 17, 2015 at 3:27:44 PM UTC+2, Surgo wrote:
Let's not get into the motivation behind this too much -- the exact same
serialization problems exist if you write out the session to a database.
Ring also encrypts the cookies so the above issue is not a problem, it's
only on you to actually choose and protect your encryption key.
I came across *data-readers* as well.I did not find it possible to make it
completely transparent if one was to use the REPL though because it is
bound on entering the REPL. Furthermore I don't think it works with
clojure.edn as well. However, it seems that
clojure.core/default-data-readers does work with both clojure.core and
clojure.edn functions. Thus I've solved the issue by altering
clojure.core/default-data-readers to include my library's tag. This seems a
bit hackish because I'm not sure you're supposed to be modifying this var,
but it's the only thing I can find that both clojure.core/read{,-string}
and clojure.edn/read{,-string} respect.
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring.
I don't think the fault lies here with ring. It doesn't seem right to
expect that library callers of these functions expose their full API to
their own users...that would put a serious burden on them to more closely
track the API as well. Better to have some alterable var so this can all
run transparently.
it uses clojure.tools.reader.edn/read-string
Ugh, thanks. I forgot about that one as well.
On Wednesday, June 17, 2015 at 5:10:24 AM UTC-4, Fluid Dynamics wrote:
On Wednesday, June 17, 2015 at 4:52:00 AM UTC-4, Thomas Heller wrote:
Hey,
the issue is not in clojure.core. It is with ring in this case, it uses
clojure.tools.reader.edn/read-string which supports an optional {:readers
{...}} argument but there is no way to specify those in ring. Should be a
fairly simple fix though, doing anything to clojure.edn won't help as it is
not used.
On another note: Sessions in cookies should be VERY VERY small.
java.io.Serializable usually isn't small and especially if you go java
object - binary - base64 - base64 (yes twice) - encrypt. The size of
the cookie matters as it is transmitted with EVERY request.
I would recommend writing print-method implementation for the Java
objects you need to serialize and keeping those to a minimum. Session
cookies are not arbitrary storage and writing a transparent serialization
format that doesn't check the size will lead to uncontrolled growth. I have
seen way too many web apps with cookies above 4kb. One even had Apache
configured to reject requests (well, default config) that had too large
cookies and no one even noticed except for the users that left confused and
never came back.
Just as a warning. :)
If you really do need to store session state that can potentially grow
that large, your best bet is to stick it in a server-side database and put
that table's primary key in the client-side cookie, looking up the state
object on receiving it back. This also prevents the end-user or a MITM from
monkeying with the state, which might prevent some types of attacks
(typically, session hijacking methods that aren't simple replay attacks, or
cheating to give yourself the super-duper armor for free in an online game,
or whatever). Remember when ATT was embarrassed by some guy finding he
could peek at every customer's data just by changing an custID=nnn sort of
URL parameter? Same thing can happen with a cookie that just says logged
in as user#6178 or equivalent. Change it to 6179 and boom you're someone
else. But if the cookie is something like a random UUID that points to a
server-side DB entry that says logged in as user#6178 fiddling with the
UUID will just produce error messages. Just don't use an autoincrement
integer PK or you are right back where you started. :)
--
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
