Re: Suggested 'server' for hosting clojure web app
On Sat, Jun 29, 2013 at 7:47 AM, Ravindra Jaju wrote: > I want to deploy a small web app - serving mostly static content. I'm using > Luminus (http://www.luminusweb.net/) - which is quite neat in the way it > builds itself from well-known components. > > I'm having trouble deciding how to deploy it. I want some automation while > deploying upgrades, and would like it to be light-weight. Jetty, http-kit, > or immutant? > (I tried immutant - but it seems to be taking up too much memory for my > comfort, on my modest server.) > > Jetty and http-kit - I would like to hear about how I can deploy them as > nice system daemons, with monitoring etc. so that they can be brought up > automatically if something goes wrong. I'm also unable to find out how I can > do a re-deploy without restarting. If you are looking for advanced features like hot redeploy, you probably want to consider if you really are after a "small" solution or not -- if you can't tolerate that small downtime, are you sure you won't need the clustering, XA transaction capabilities, and other advanced features that a toolkit like immutant brings to the table soon? Regardless, you could use the `ring.reload` middleware in production, or bring your own solution to the table for code reloading and use a var as your ring handler to allow dynamic change. (eg: in cgrand's moustache, `(app #'my-handler-function)` allows redefining the handler fn at runtime, transparently.) Given either of those solutions you can then use jetty, netty, http-kit, or anything else. Personally, though, if you really want automated deployment and zero-downtime upgrades, I would totally look to a full blown - and heavy - stack. :) -- Daniel Pittman ♲ Made with 100 percent post-consumer electrons -- -- 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: End user applications
On Thu, Jun 13, 2013 at 2:41 AM, Philip Potter wrote: > > PuppetDB is another: > http://docs.puppetlabs.com/puppetdb/latest/index.html > > We use PuppetDB at GOV.UK for host management and reporting purposes. > Nobody else on my team really knows clojure, but nobody has to care > because PuppetDB is self-contained. That has a fair bit of "air-play" in the wild, and has been trouble-free the whole time. I can probably dig out some numbers from our marketing department about how widely used it is, if y'all are interested. -- Daniel Pittman ♲ Made with 100 percent post-consumer electrons -- -- 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 web-like protocol
On Sat, Dec 8, 2012 at 10:31 AM, Adam Perry-Pelletier wrote: > Are there any clojure projects/frameworks that would help me write a brand > new web-like protocol (e.g. newprotocol://)? I've written basic > servers in clojure, but would like to forego the low-level stream reading > and get write to higher-level constructs. I assume you mean implementing the bits and bytes layer of the protocol; last time I had to do something like that (to talk to my Onkyo amp) I found that gloss was quite useful. It was associated with Aleph, which is a good framework for asynchronous message handling on top of streaming protocols. Gloss: https://github.com/ztellman/gloss/wiki Alpeh: https://github.com/ztellman/aleph/wiki In confirming the URLs, http://paulosuzart.github.com/blog/2012/07/09/tcp-server-with-clojure-aleph-and-gloss/ seems like a good introduction to the basic flow of the tool. -- Daniel Pittman ♲ Made with 100 percent post-consumer electrons -- 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
Re: edn
On Fri, Sep 7, 2012 at 3:45 AM, Rich Hickey wrote: > On Sep 7, 2012, at 12:33 AM, Daniel Pittman wrote: >> On Thu, Sep 6, 2012 at 6:01 PM, Rich Hickey wrote: >> >>> I've started to document a subset of Clojure's data format in an effort to >>> get it more widely used as a data exchange format, e.g. as an alternative >>> to JSON. >>> >>> Please have a look: >>> https://github.com/richhickey/edn >> >> The current specification has two problems that have bitten us on >> other projects (and with other formats): it has no specified encoding >> for strings, and it has no native mechanism for binary data. It would >> be awesome if you could consider both in the format. >> >> Strings without encoding are an interoperability headache, even if >> they allow binary data - someone will forget to tag the data, or will >> just throw whatever random 8-bit encoding in, and problems arise. > > I'd like to simply specify UTF-8 for edn in toto. *nod* >> Strings with a specific encoding (like JSON and UTF-8) are great, but >> they can't carry binary, so something specific is needed - and >> hopefully something better than "base64 into the string". > > Do you object to the size of base64, or the use of convention? edn is opposed > to convention, since how do you know when to apply an approach to a > particular string? That's the problem people have today with JSON - they cram > things into strings but only know to deal with them from context. The "use of convention" is by far the worst problem, for exactly the reasons you identify. The size expansion and encode/decode phase for base64 are small annoyances shipping binary data through JSON, and would be so here, so while I would like something that allowed raw binary content unmodified, base64 would be fine. > We're going to get a standard tagged literal for binary data, was considering: > > #bin "base64data" > > I'm interested in feedback on problems with that, or alternatives. #base64 feels more explicit to me, since it would also allow for other specific encodings later, but that seems reasonable enough to me. It makes explicit the form - and is what we had through YAML, which was successfully used. -- Daniel Pittman ♲ Made with 100 percent post-consumer electrons -- 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
Re: edn
On Thu, Sep 6, 2012 at 6:01 PM, Rich Hickey wrote: > I've started to document a subset of Clojure's data format in an effort to > get it more widely used as a data exchange format, e.g. as an alternative to > JSON. > > Please have a look: > https://github.com/richhickey/edn The current specification has two problems that have bitten us on other projects (and with other formats): it has no specified encoding for strings, and it has no native mechanism for binary data. It would be awesome if you could consider both in the format. Strings without encoding are an interoperability headache, even if they allow binary data - someone will forget to tag the data, or will just throw whatever random 8-bit encoding in, and problems arise. Strings with a specific encoding (like JSON and UTF-8) are great, but they can't carry binary, so something specific is needed - and hopefully something better than "base64 into the string". -- Daniel Pittman ♲ Made with 100 percent post-consumer electrons -- 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
Re: Storing clojure lists and maps in Redis
On Tue, Jan 3, 2012 at 22:30, Shoeb Bhinderwala wrote: > I am trying to use Redis as a data structure cache for my clojure > application. Does anybody have experience/code/ideas that can write/ > read a clojure complex data structure to the Redis cache. […] > How can I store the above to Redis and read it back to recreate it? Personally, I would use JSON, MesssagePack, Protocol Buffers, or something else language independent to encode the data. This has two advantages: one, someone else already worked out how to do it, and ported it to Java or Clojure, and two, you can also access it from some other language. (When, eventually, you find you need that.) Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Distributed transactions
Well, I can't speak for Michael, but we want them because we need to update the database *and* send events notifying other parts of the distributed system about the change. We really don't want to do only one *or* the other, because that requires that we get into the fun world where distributed tools in multiple languages can't trust the events we send, or need to implement client polling to notice change. Distributed database transactions? Not much fun. Transactions that cover more than just one technology? More useful. Daniel On Sat, Dec 31, 2011 at 09:39, Leonardo Borges wrote: > Distributed transactions slow u down Why the hell would you want that? > I'm yet to see a valid use case! They require sticky sessions which suck for > scalability! Keep in mind it's 4am on the 31st of December :-) > > Leonardo Borges > www.leonardoborges.com > Sent from my Galaxy Nexus(IceCreamSandwhich) > > On Jan 1, 2012 3:42 AM, "Bronsa" wrote: >> >> maybe avout is what you're looking for? >> https://github.com/liebke/avout >> >> 2011/12/31 Michael Jaaka >>> >>> Is there any attempt to make distributed transactions? >>> The usage scenario is the same like in JEE apps. >>> I mean, there is a web service call, the transaction is started, there >>> are some changes to db, some jms sends and when there is no failure >>> all is commited. >>> Maybe someone is already using glassfish or spring from clojure? Some >>> reference to github? >>> >>> -- >>> 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 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 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 -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Colliding hashes
http://www.kb.cert.org/vuls/id/903934 should give you pointers to understand the problems, and http://www.ocert.org/advisories/ocert-2011-003.html has details about what is vulnerable from an HTTP request processing point of view. Fixing the underlying map / hash tools would be awesome, of course, because it makes the fundamental attack inaccessible. I have no knowledge of either the Java or Clojure hash maps that would allow me to know if this actually applies here. Daniel On Sat, Dec 31, 2011 at 05:06, Hubert Iwaniuk wrote: > Should we watch the whole video to see what you mean? > At what time is it important? > > Cheers, > Hubert > > > > On Sat, Dec 31, 2011 at 1:39 PM, Brian Mosley > wrote: >> Saw this in a scala mailing list thread: >> >> http://www.youtube.com/watch?v=R2Cq3CLI6H8 >> >> Should the clojure hash be fixed? >> >> -- >> 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 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 -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Another newbie question
On Sun, Nov 6, 2011 at 03:56, pron wrote: > Hi. I'm new to Clojure, and enjoy using it very much. It's been years since > I learned Scheme back in college, and it's a pleasure going back to lisp. > I do, however, have a question regarding real-world Clojure use in large > teams. While I clearly understand the pros of common data > access/manipulation, doesn't the lack of encapsulation prove problematic in > large projects with many developers? E.g., one developer may add a keyword > to a map for one purpose, and another, use the same keyword for a different > purpose. Is this in any way different to how the developer might use a slot on a class, or a get/set method pair for different purposes? > With classes, all data manipulation for a single type is located in > one place, so such clashes can easily be prevented, let alone the fact that > encapsulation helps delineate legal operations with the data. > I realize there are always tradeoffs, and perhaps the pros outweigh the > cons, but I would like to know how you deal with such problems, that > invariably arise in large-team development. >From my experience, if you have an architecture that encourages developers to think in terms of discrete functional units, and to have documented interfaces between the functional units, you wind up with a system that works - regardless of the control the language expresses over access to members. On the other hand, if you have an architecture (or culture) that encourages poking into the implementation details, or just getting things done - the pragmatic solution - rather than doing things right, you will wind up with problems no matter which approach you take. In other words I question your "invariably", rather than any other part of your statement. These are not automatic problems, and they are not all that, in my experience, related to the degree that your language forces you to go through a single channel for all access to a particular bit of data. Do you have more concrete concerns here, or is it just the general assumption that without data hiding and a "one object, one file" model you can't have a working large scale system? Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: ANN: Korma - a SQL DSL for Clojure
On Wed, Nov 2, 2011 at 12:49, Chris Granger wrote: > I'm officially releasing Korma 0.2.0 today with a wonderful new > project site: http://sqlkorma.com ;) That looks pretty awesome. I do have one question: arrays. Specifically, do you have any plans to support SQL ARRAY columns as part of this work, together with their query operations (eg: PostgreSQL style any/all extensions). Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: ANN: core.match 0.2.0-alpha5
On Mon, Oct 10, 2011 at 06:57, David Nolen wrote: > On Sun, Oct 9, 2011 at 11:19 PM, Ambrose Bonnaire-Sergeant > wrote: >> On Mon, Oct 10, 2011 at 3:31 AM, David Nolen wrote: >>> >>> - return nil instead of throwing if no match found to mirror the behavior >>> of cond >> >> I don't like this. > > I'm definitely open to talking about it. Strong opinions appreciated :) > >> Why are we emulating cond? clojure.core/case, for example, seems closer to >> what `match` provides, >> and that throws an IllegalArgumentException if there is no match. >> Seems arbitrary to me. >> Is there more to it? > > A good point. I'm mostly thinking about user friendliness here. I'm also OK > w/ the idea of providing two versions of match - one w/ verbose error > reporting that throws and perhaps the default one that doesn't So, I have one other argument in favour of "just return nil", which I prefer: If you just return `nil`, I can use :else to throw fairly cheaply, and quite visibly. If you throw then I have to wrap any non-exhaustive pattern in a try/catch block to avoid the exception propagating up the stack. Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: ANN: core.match 0.2.0-alpha5
On Sun, Oct 9, 2011 at 12:31, David Nolen wrote: > I've removed some fairly big bugs in the algorithm. This will probably the > be the last alpha release before I cut a beta. Would love to hear any and > all feedback. > In particular if people have strong opinions about the remaining issues, let > me know now - http://dev.clojure.org/jira/browse/MATCH > Two things not listed there that I'm considering: > - clojure.core.match instead of clojure.core.match.core That would have been a lot less surprising to me when I started working with the library; it feels "right" that the main library is named `match`, and extensions `match.whatever`, under the core namespace. > - return nil instead of throwing if no match found to mirror the behavior of > cond Given `:else (throw ...)` I would entirely support that from my use of the library. Thanks, Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Thoughts on a polyglot app server?
On Thu, Sep 29, 2011 at 13:48, Jim wrote:
>
> The TorqueBox[1] team is toying with the idea of exposing to Clojure
> the abstractions we currently expose to Ruby. We're looking for
> feedback from you guys to see what you use now to solve these
> problems, what you'd like to see in a possible Clojure "App Server",
> and if you might actually use it.
Well, we would be seriously interested in it at Puppet Labs. At the
moment we have a pile of Ruby code, and are using Clojure in some
newer parts of the overall project. The move toward Clojure is
motivated by the scale and especially parallel operation benefits that
it brings to the table.
The obvious attraction is that TorqueBox would bring an integrated
layer below our Ruby and Clojure code; we would have the same services
available to both, exposing coherent interfaces between the parts, and
would also allow more intimacy around Java interop and cross-language
direct calling.
In terms of Clojure integration, comments around what we care about:
> * asynchronous processing (with futures)
Ideally we would want something compatible with Clojure futures, but
if you offer (eg) bounded thread pools then having compatible syntax
would be a win. Right now we can get away with the default unbounded
pool size, but the choice would be awesome.
> * scheduled jobs
> * XA transactions
> * companion services (daemons)
Being able to bring these up in Clojure also would be awesome.
> * distributed caching
External memcache compatibility would be a big win here, for us right
now, but isn't long term essential.
> * messaging (via JMS)
We currently use ActiveMQ to provide STOMP services for MCollective,
and for some internal queue needs. AMQP/JMS messaging would be
valuable, especially if it can interoperate with ActiveMQ, or supports
easy broker clustering, but not essential.
Access to configuring those things from Clojure would be valuable.
On the client side we use clamq (https://github.com/sbtourist/clamq)
to wrap up interactions with the queue service; having that, or
something with similar abstractions, would be valuable. We especially
like the model of a queue consumer as an infinite lazy sequence.
In addition to those features, having a working and supported Ring
adapter "free" as part of the distribution would be of great value.
That is approximately the Ruby Rack feature, and means we can drop
whatever front-end we want in place.
I have not looked at JBossAS, but having a pleasant way to cooperate
with lein project descriptions, or support an uber{war,jar} for
getting our application in place, would be awesome.
> Coming from a Ruby background, all of the above were pain points for
> us. Do these same pain points exist for Clojure apps?
Aside from futures, all of those have been, or are, pain points for us
getting bootstrapped in our Clojure project.
> TorqueBox also supports clustering, which allows load balancing of the
> web component as well as cache distribution and horizontal scaling of
> async tasks, scheduled jobs, and services. Clojure has built in async
> processing and futures, but they use an in VM thread pool, correct?
> How would you scale that?
More or less the same way, as near as I can tell.
> A common TorqueBox idiom is to leverage Ruby in the web tier and Java
> in the services/data tier. Are there any Ring-based frameworks that
> make Clojure more appealing than Ruby in the web tier?
>From our point of view, Clothesline is an Erlang WebMachine clone and
has been awesome for getting our RESTful service working nicely. It
decomposes the process of correct HTTP request handling effectively.
For strictly user-facing design we are mostly interested in richer
client side code, so having something focused more on good API than on
easy click-refresh page design makes that kind of moot.
> Or does integrating a Ruby web app with a colocated Clojure service
> make more sense? It should be fairly easy to loosely couple them via
> messaging.
We expect to be doing both of those things over the next year or so.
> Speaking of which, if you are using Clojure to process data generated
> by other apps/languages, how is that data communicated? Would language
> agnostic messaging be useful here?
We encode to JSON, which is sufficiently rich, as well as sufficiently
feature poor, that it hits a good balance. We can express and
document interfaces well between components around those basic
structures, and that in turn makes it easy to get interoperability and
third party developer support built in effectively.
>From where we sit the three things that would be convenient are:
1. REST API for messaging which accepts JSON. (I see HornetQ delivers :)
2. Built in JSON encoding and decoding in the message queue wrapper.
3. Clojure multimethod-like dispatch on messages.
For 3, right now we have a structure { "command": "some name here",
... }, and dispatch on that top level command key (and, possible, a
version tag) to our top level handl
Re: Idiomatically returning one or two values from a function.
On Wed, Sep 28, 2011 at 12:15, Daniel Solano Gomez wrote: > On Wed Sep 28 18:52 2011, Daniel Pittman wrote: >> >> I have problem that I have been thrashing back and forth over the best >> design of for a week now, and I can't work out the nicest way to >> handle it. Specifically, I have a collection of functions that return >> a primary result, and might also return a secondary "annotation" about >> that result. > > Why not always return a vector? That is more or less what a tuple is. *nod* Thanks, to you, and the other contributors. That feels like the right answer, and I guess I was hung up on not forcing a single value to be returned in a wrapper so much that I couldn't see it staring at me. Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Idiomatically returning one or two values from a function.
G'day.
I have problem that I have been thrashing back and forth over the best
design of for a week now, and I can't work out the nicest way to
handle it. Specifically, I have a collection of functions that return
a primary result, and might also return a secondary "annotation" about
that result.
The current implementation is:
(fn [] true) ; primary only
(fn [] (annotated-return true {:foo 12})) ; with annotation
`annotated-return` actually wraps a record, and then the handling code
can determine if the result is specifically that type, or if it is
anything else, to select between the two cases.
In a bunch of other languages I would use a `pair` or `tuple`, but
Clojure doesn't have a native type that maps closely to that. Worse,
though, it doesn't have a native type that isn't a valid return from
one of these methods. (Set, Vector, List, and Map are all used. :)
The alternatively I can think of are limited: I don't like the idea of
guessing based on a two element vector return or so, since I want this
to be pretty much impossible to accidentally break.
I considered using meta-data, but that can't attach to a primitive
value, and those are definitely valid results.
So, is there a better way to do this? At this point I am tempted to
step aside from functional code, and use stateful mutation of some
sort to maintain the annotations:
(fn [] (annotate-by-side-effort {:foo 12}) true)
Daniel
--
♲ Made with 100 percent post-consumer electrons
--
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
Clojure sort: is it specified to be stable for all targets?
G'day. The API documentation for clojure doesn't specify if the sort method is stable, unstable, or "implementation defined". Java defines sort to be stable, but Clojure also has two other targets, and I can't tell if I am safe making the assumption that the stable behaviour will carry over to them, or if they will just have whatever the implementor decided. Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: Clojure in Emacs Seemingly Impossible
On Sat, Sep 10, 2011 at 10:29, Curran wrote: > I would greatly appreciate any guidance on where to find a working and > complete set of instructions for how to set up Emacs with swank- > clojure. I am in Ubuntu. > > I have followed exactly every step of the instructions on this page > http://dev.clojure.org/display/doc/Getting+Started+with+Emacs, and > also (with a fresh install of Emacs) the version using Git in the > comment on that page by Martin Blais. With both methods, when I > execute "M-x clojure-jack-in", the message "Starting swank server" > appears and hangs. Swank never starts, the message never changes, and > I don't see any error messages anywhere (not sure where to look, maybe > I'm missing them?). I do believe that is the same error I recently hit. To use `clojure-jack-in` you need a quite recent version of the `lein-swank` plugin. You *also* need to make sure that nothing else on the load path has an older version. That means anything in your current project, *and* any either leinengein plugins. (I got bitten be the later.) You need to see ";;; proceed to jack in" output from `lein jack-in 1234` for that all to work together. This was tricky to diagnose, and the bundled version in the other plugin stumped me for quite some time. Daniel -- ♲ Made with 100 percent post-consumer electrons -- 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
Re: ANN: Clojure Cookbook
Tim Daly writes:
> There is a movement afoot in the common lisp community to implement
> quicklisp which is similar to the perl cpan site or debian. It would be
> useful if there was a quicklisp (or asdf) for Clojure. Thus you could
> "apt-get" a library for clojure.
FWIW, having just started out playing with Clojure with a view to building a
Google App Engine web service — and from a Perl and Debian background:
The single biggest thing that I have missed has been 'lein search' or so,
which would allow me to search an index of the modules it can access and tell
me what is available for meeting my current need.
The second biggest is the lack of a CPAN-alike central service on the web that
would allow me to do the same, plus review the documentation for candidate
libraries.
So, um, that would be nice. :)
Daniel
--
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
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
