Re: Solving allocation problems; code review and core.logic
Hi everyone, On Thursday, March 6, 2014 12:54:22 AM UTC+1, puzzler wrote: The potential problem with modeling it as a knapsack problem is that it assumes that grant-giving is an all-or-nothing affair. Yes, exactly this. I realized I omitted this when I woke up in the middle of the night... Another reasonable way to model it is to assume that if I'm given, say $80 out of $100 requested, then I have an 80% chance of going. With such a model, let's say I have a score of 5 and a grant request of $100. Then, if I'm granted $100, I contribute 5 points of goodness to the overall value I'm optimizing. So $1 allocated to me contributes 0.05 points of expected goodness to the overall value. Yep. A big part of the issue is that the *real* function that maps grant fraction to probability of coming is of course unknowable. A linear approximation is an excellent start. Once I have some test data I'll be able to tell for sure, but I imagine a closer approximation might look more like x**2 than x over [0, 1] (e.g. when I give someone 50% of their grant, the odds they'll come are closer to 25% than to 50%). Are Choco/Loco limited to linear programming? Here's a gist, illustrating how to do this in Loco: https://gist.github.com/Engelberg/9379157https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2FEngelberg%2F9379157sa=Dsntz=1usg=AFQjCNH72EGcBLDO4Y8k93Urdn9DD13wbQ Wow! That's great; thanks. I guess I'll go produce some test data and see how the different code does :-) thanks again lvh -- 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: Solving allocation problems; code review and core.logic
On Thu, Mar 6, 2014 at 12:21 AM, Laurens Van Houtven _...@lvh.cc wrote: Yep. A big part of the issue is that the *real* function that maps grant fraction to probability of coming is of course unknowable. A linear approximation is an excellent start. Once I have some test data I'll be able to tell for sure, but I imagine a closer approximation might look more like x**2 than x over [0, 1] (e.g. when I give someone 50% of their grant, the odds they'll come are closer to 25% than to 50%). Are Choco/Loco limited to linear programming? No, it doesn't have to be linear. Let's say the probability p = (allocated/requested)^2 for a given person. So we're trying to maximize the sum of score*p. Let's reorganize score*p to isolate the variable we're solving for from the known quantities: score*p = score*(allocated/requested)^2 = allocated * allocated * (score/(requested^2)) The score and the requested amount are known in advance for a given person, so in the sample code I provided, the precomputed grant-value would no longer be based on score/requested, but score/(requested^2). Then when solving for the allocations, you instead maximize: (apply $+ (map $* (map $* allocation-vars allocation-vars) grant-values)) Those are the only changes you need to make for it to be based on quadratic versus linear. Here is the revised code, also incorporating the dynamic scaling suggestion I put in the comments of the other gist: https://gist.github.com/Engelberg/9385992 It definitely makes a difference for the toy example given in the problem. In both versions, it allocates $120 to Alex (guaranteeing the highest scored person). In the linear version, it gives the $80 to David (choosing the 4/5 probability of getting a 4 [an expected value of 16/5], over a certainty of getting a 3, since 16/53) In the non-linear version, it gives the $80 to Mark (guaranteeing a person worth 3, rather than a 16/25 probability of getting a 4). -- 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.
What's the best clojure library to access HBase?
the same as the title. -- tao Sent with Sparrow (http://www.sparrowmailapp.com/?sig) -- 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: What's the best clojure library to access HBase?
The last time i searched... i couldnt find any that is still being maintained. I ended up using the java api and its very simple. Josh On Thu, Mar 6, 2014 at 1:13 PM, tao tao.zhou2...@gmail.com wrote: the same as the title. -- tao Sent with Sparrow http://www.sparrowmailapp.com/?sig -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN Langohr 2.5.0 is released
Langohr [1] is a small, feature complete Clojure client for RabbitMQ. Release notes: http://blog.clojurewerkz.org/blog/2014/03/06/langohr-2-dot-5-0-is-released/ 1. http://clojurerabbitmq.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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: Solving allocation problems; code review and core.logic
Even though loco works on this small example, it doesn't scale well for this kind of problem. I did a test on some randomly generated 3000 people, and it's slow. (You can set the budget constraint to definitely spend the whole budget to speed things up, and set a timeout, but the quality of the solutions after a reasonable timeout is low. It's even worse with the quadratic versus linear model, and with the quadratic model you have to be careful in the scaling to avoid bumping into the upper bound on integer values.) This isn't too surprising. Constraint solvers like loco shine when the constraints really limit the number of feasible solutions, and you are simply minimizing/maximizing to optimize among those feasible solutions. In this case, every possible allocation of dollars among the 3000 users up to their requested limits is a *feasible* solution (doesn't violate any constraints), so this becomes primarily an optimization problem *not* a find-the-feasible-answer problem, which is not really what constraint solvers are good at. If you don't mind the linear formulation, you could either go with the greedy approach or use a linear programming solver (there aren't any good Java/Clojure lp solvers, but it's not too hard to use Clojure to generate a file that you can feed into something like SICP). Otherwise, you'd want to use a technique like local search (simulated annealing or tabu search), which is relatively easy to code up in Clojure (don't really need to use an external solver engine for this). If you want to become an expert at all these approaches, and deeply understand what techniques work best for what kinds of problems, I highly recommend the coursera course on Discrete Optimization, which coincidentally began a new session a few days ago: https://www.coursera.org/course/optimization -- 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: Solving allocation problems; code review and core.logic
On Thursday, March 6, 2014 12:19:25 PM UTC+1, puzzler wrote: Even though loco works on this small example, it doesn't scale well for this kind of problem. I did a test on some randomly generated 3000 people, and it's slow. (You can set the budget constraint to definitely spend the whole budget to speed things up, and set a timeout, but the quality of the solutions after a reasonable timeout is low. It's even worse with the quadratic versus linear model, and with the quadratic model you have to be careful in the scaling to avoid bumping into the upper bound on integer values.) The good news is that the entire conference has fewer than 3000 attendees, so definitely far fewer than 3000 people in the financial aid system, so as long as that's feasible we're good :-) This isn't too surprising. Constraint solvers like loco shine when the constraints really limit the number of feasible solutions, and you are simply minimizing/maximizing to optimize among those feasible solutions. In this case, every possible allocation of dollars among the 3000 users up to their requested limits is a *feasible* solution (doesn't violate any constraints), so this becomes primarily an optimization problem *not* a find-the-feasible-answer problem, which is not really what constraint solvers are good at. Hm. I realize we're unlikely to change the nature of the problem, but would it help if we limit the search space? For example, if we only care about grants in increments of $50 or $100? Instead of working with dollars, working with grant tokens each worth $50 or $100 or so? (By the way, I noticed that your examples use indices; I'm presuming there's nothing wrong with using the applications themselves? Perhaps it's just impractical in ways I haven't discovered yet?) If you don't mind the linear formulation, you could either go with the greedy approach or use a linear programming solver (there aren't any good Java/Clojure lp solvers, but it's not too hard to use Clojure to generate a file that you can feed into something like SICP). Otherwise, you'd want to use a technique like local search (simulated annealing or tabu search), which is relatively easy to code up in Clojure (don't really need to use an external solver engine for this). If you want to become an expert at all these approaches, and deeply understand what techniques work best for what kinds of problems, I highly recommend the coursera course on Discrete Optimization, which coincidentally began a new session a few days ago: https://www.coursera.org/course/optimization As much as I would love to learn, I'm convinced that this is probably way outside of how much time I can spend on it :) thanks! lvh -- 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.
transient map bug?
Try to use transient map, but it has size limit to 8 keys.
(let [hm (transient {})]
(doseq [x (range 100)]
(assoc! hm x -))
(persistent! hm))
{0 -, 1 -, 2 -, 3 -, 4 -, 5 -, 6 -, 7 -}
What's wrong with my code?
I think it is a bug.
Transient map don't change type from PersistentArrayMap to
PersistentHashMap.
--
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: transient map bug?
What your code is doing is sometimes called bashing transients in place.
See some discussion here:
http://clojuredocs.org/clojure_core/clojure.core/assoc!
As explained there, you should always use the return value of assoc!, just
as you would always use the return value of assoc.
Andy
On Thu, Mar 6, 2014 at 6:17 AM, Sergey Kupriyanov sku...@gmail.com wrote:
Try to use transient map, but it has size limit to 8 keys.
(let [hm (transient {})]
(doseq [x (range 100)]
(assoc! hm x -))
(persistent! hm))
{0 -, 1 -, 2 -, 3 -, 4 -, 5 -, 6 -, 7 -}
What's wrong with my code?
I think it is a bug.
Transient map don't change type from PersistentArrayMap to
PersistentHashMap.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: transient map bug?
Something like this would work:
(persistent!
(reduce
(fn [r x] (assoc! r x -))
(transient {})
(range 100)))
Which is just:
(reduce
(fn [r x]
(assoc r x -))
{}
(range 100))
...but with transient applied to the input, and persistent! applied to the
output.
On Thu, Mar 6, 2014 at 2:49 PM, Andy Fingerhut andy.finger...@gmail.comwrote:
What your code is doing is sometimes called bashing transients in
place. See some discussion here:
http://clojuredocs.org/clojure_core/clojure.core/assoc!
As explained there, you should always use the return value of assoc!, just
as you would always use the return value of assoc.
Andy
On Thu, Mar 6, 2014 at 6:17 AM, Sergey Kupriyanov sku...@gmail.comwrote:
Try to use transient map, but it has size limit to 8 keys.
(let [hm (transient {})]
(doseq [x (range 100)]
(assoc! hm x -))
(persistent! hm))
{0 -, 1 -, 2 -, 3 -, 4 -, 5 -, 6 -, 7 -}
What's wrong with my code?
I think it is a bug.
Transient map don't change type from PersistentArrayMap to
PersistentHashMap.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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: transient map bug?
Thanks for the answers. It's not my real code. It's just trivial demo for the bug report. I can rewrite it with no problems, but the question is - is it normal behavior or is it bug in transient map? -- 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: transient map bug?
It's undefined behaviour; you should use assoc! like assoc. Ambrose On Thu, Mar 6, 2014 at 11:16 PM, Sergey Kupriyanov sku...@gmail.com wrote: Thanks for the answers. It's not my real code. It's just trivial demo for the bug report. I can rewrite it with no problems, but the question is - is it normal behavior or is it bug in transient map? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: transient map bug?
Ohh, I realized my mistake. Thank you all for your answers. On Thursday, March 6, 2014 7:18:24 PM UTC+4, Ambrose Bonnaire-Sergeant wrote: It's undefined behaviour; you should use assoc! like assoc. Ambrose On Thu, Mar 6, 2014 at 11:16 PM, Sergey Kupriyanov sku...@gmail.comjavascript: wrote: Thanks for the answers. It's not my real code. It's just trivial demo for the bug report. I can rewrite it with no problems, but the question is - is it normal behavior or is it bug in transient map? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to replace code inside a macro
--On 5 Mar 2014 09:37:24 -0800 milinda milinda.pathir...@gmail.com wrote: Thanks Konrad. Your unquoting trick worked. But I am not exactly sure how to reason about these types of situations. Can you please shed some lights behind the logic of above unquoting if possible. I suppose you refer to the ~'defpop, right? That is indeed a bit subtle. An unquote followed by a quote should cancel, one might think. The difference comes from namespacing: `a resolves a in the current namespace, whereas `~'a returns a symbol without a namespace. This matters because macrolet (just like plain let) replaces only non-namespaced symbols. Konrad. -- 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: A faster clojure startup
I wonder how this compares with this change Rich made to enable lazy fn initialization: https://github.com/clojure/clojure/commit/71930b6b6537a796cdf13c4ffa7cf93eb53b6235 that he later reverted: https://github.com/clojure/clojure/commit/c5681382da775e898915b17f3ab18b49c65359ec If I read the first commit correctly that approach consisted in wrapping all fn objects that appears in a def init position in a FnLoaderThunk, which loads the fn class, creates a fn object and binds it to the Var's root the first time the fn is invoked. It's not clear to me why that change was reverted. Gal Dolber writes: Here're some notes on the lean compiler I've been working on for clojure-objc http://galdolber.tumblr.com/post/78110050703/reduce-startup Feedback's welcome -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Gorilla REPL initial release (0.1.2)
Thanks, I've just gotten around to playing with this and it's something I've been looking for. I think Incanter integration is the way to go, even if I have to figure it out myself I'd be happy to help (limited in my incanter knowledge as is, but this works great with it so far). Best, --Joseph On Wednesday, February 19, 2014 3:23:02 PM UTC-6, Jony Hudson wrote: Hi All, I'm pleased to announce the first release of Gorilla REPL, a rich REPL in the notebook style: https://github.com/JonyEpsilon/gorilla-repl From the README: You can think of it like a pretty REPL that can plot graphs, or you can think of it as an editor for rich documents that can contain interactive Clojure code, graphs, table, notes, LaTeX formulae. Whatever works for you! One of the main aims is to make it lightweight enough that you can use it day-to-day instead of the command-line REPL, but also offer the power to perform and document complex data analysis and modelling tasks. Above all else, Gorilla tries not to dictate your workflow, but rather to fit in to the way you like to work, hopefully putting a bit more power to your elbow. You might like to take a look at a video introduction that shows what it does better than my poor prose describes it: https://vimeo.com/87118206 I hope you like it and find it useful. In particular I really hope it fits in to your workflow, and if not it would be great to know why. Bear in mind it is very new and hasn't had a lot of testing, so caveat evaluator. In particular: * I've done very limited testing other than on Safari on Mac. I've checked that it works in most of the major browsers on Windows and Mac, but that's about it! * At the moment you can only open one window otherwise it breaks (silently!). I'd love some help on the bug that's blocking this from someone who understands nREPL better than me. https://github.com/JonyEpsilon/gorilla-repl/issues/10 * It relies on an internet connection at the moment, at least until it caches various fonts. Need to get in touch with someone at clojars about size limitations. I think there's a lot still to be done, and there are some areas that would really benefit from feedback from clojure developers more experienced than me. Directions I'd love to see explored: * More work on plotting. Still very green, and much could be improved. * Incanter integration. If I've understood correctly, Incanter can generate SVG, so shouldn't be too difficult. * Content-types. Currently values are tagged to indicate they should be rendered specially by the front-end. Is this the right way to do it? What about tagged literals? * UI as a value. There's a lot that could be done with custom rendering of values. Mathematica is particularly impressive in this regard, and it would be interesting to think where this could go with clojure. I know Kovas Boguta has thought about this a lot. * Clojurescript! I think this is a _really_ interesting one. I'd love to see a pure-client-version that uses a clojurescript REPL server in a web-worker or similar. I came to write Gorilla through thinking about this angle originally, having previously messed around with javascript based data analysis in the browser (see http://monkeycruncher.org - cute idea, but no-one wants to use js to analyse their data!). In my opinion there's some really important work to be done on opening up analysis - I'd love to publish scientific papers not with a snapshot of my analysis, but with my real, living, breathing analysis in them. And I love to do it on an open, ubiquitous platform :-) Anyway, let me know what you think. Comments, issues and pull requests all very, very welcome ;-) Jony -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: A faster clojure startup
Here's more on this: https://github.com/galdolber/clojurefast I'm stuck figuring out how to get AOT and dynamically compiled clj files to work nice together. Help is more than welcome! On Thu, Mar 6, 2014 at 4:06 PM, Nicola Mometto brobro...@gmail.com wrote: I wonder how this compares with this change Rich made to enable lazy fn initialization: https://github.com/clojure/clojure/commit/71930b6b6537a796cdf13c4ffa7cf93eb53b6235 that he later reverted: https://github.com/clojure/clojure/commit/c5681382da775e898915b17f3ab18b49c65359ec If I read the first commit correctly that approach consisted in wrapping all fn objects that appears in a def init position in a FnLoaderThunk, which loads the fn class, creates a fn object and binds it to the Var's root the first time the fn is invoked. It's not clear to me why that change was reverted. Gal Dolber writes: Here're some notes on the lean compiler I've been working on for clojure-objc http://galdolber.tumblr.com/post/78110050703/reduce-startup Feedback's welcome -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] New Caribou Release: Version 0.14.0
Congratulations to your team Ryan, I wasn't aware of Caribou until now and this release looks pretty good! the documentation is very complete, I'll be sure to try it soon. Regards, Denis El miércoles, 5 de marzo de 2014 22:24:13 UTC-3, Ryan Spangler escribió: Hello Clojure People, Happy to announce the release of a new version of Caribou! http://let-caribou.in/ There are a lot of improvements in this latest release. We have tried to incorporate all of the feedback we have received since its initial release (which has been massive!). A small selection of the improvements: * *Heroku support fully integrated.* This turned out to be a big deal for a lot of people, and there were some hoops to jump through before getting a database set up. I am happy to say this has been vastly streamlined and improved, as well as fully documenting the process from provision to deploy: http://caribou.github.io/caribou/docs/deploying.html(at the bottom of that page). * *Routing streamlined and simplified. *We had this split into two steps before, but it is way simpler now. Also fixed a couple issues people were having with HTTP methods in nested routes. Polaris is also now fully integrated: https://github.com/caribou/polaris * *Immutant removed as a direct dependency.* A lot of people complained about having to download all of Immutant even if they weren't using it! This is no longer necessary, as you can now deploy to Immutant with options directly in your project.clj without ever making it a dependency of your project. * *Templating engine can be swapped out for anything.* You can now use whatever you want for templating, including Selmer: https://github.com/yogthos/Selmer (yogthos himself contributed this pull request!) Check out the bottom of this page for more details: http://caribou.github.io/caribou/docs/templates.html And many more (check out the docs for a full list of features: http://caribou.github.io/caribou/docs/outline.html ). As there were a lot of changes (not all of them backwards compatible), we made a guide for upgrading Caribou to the latest version if you already have an instance running somewhere: http://caribou.github.io/caribou/docs/upgrading.html ! Hopefully that will help out for anyone has a Caribou site under development (let us know if anything comes up!) Thanks to everyone who contributed feedback, issues and pull requests, and thanks to everyone who is using it to build awesome things. We are working hard to make it as useful as possible, and having real world feedback has been invaluable to that cause. Lastly, check out the roadmap for the direction we are going: http://caribou.github.io/caribou/docs/roadmap.html (Spoiler: we got a UX person!) We are open to any and all feedback on this or anything else! Thanks again. - Caribou Team -- 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] Kria, an async driver for Riak 2
Kria (a right rotation of Riak) is an asynchronous Clojure driver for Riak 2.0 built on top of Java 7's NIO.2. It uses Riak's protocol buffer interface. https://github.com/bluemont/kria https://clojars.org/kria In my work projects, we have found that core.async works great as a layer on top of Kria. Just create a core.async channel in advance and have the callback put the desired return value in the core.async channel. (You might also try atoms or promises.) There are several Riak drivers in Clojure, and I hope some people find this one useful. I have a section in the README about why I made it. Feedback welcome! It does not yet support all of the Riak API, but the essentials are there. -David -- 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: Solving allocation problems; code review and core.logic
On Thu, Mar 6, 2014 at 4:56 AM, Laurens Van Houtven _...@lvh.cc wrote: Hm. I realize we're unlikely to change the nature of the problem, but would it help if we limit the search space? For example, if we only care about grants in increments of $50 or $100? Instead of working with dollars, working with grant tokens each worth $50 or $100 or so? Not really. Let's do a little back-of-the-napkin estimate. Let's say you have 3000 attendees, each of whom can be granted $0, $50, $100, $150, ..., or $500. (That's 30,000 possible $50 bins to put money in). Then let's say that you have $20,000 of funds to parcel out in increments of $50 (a total of 4000 parcels to give out). So the number of possible ways to divvy this up is 30,000 take 4000 which is nearly 10^5114 possibilities. Clearly that's intractable even with $50 buckets. I apologize for getting your hopes up about Loco as a tool for this problem. I've been using it a lot lately, and when I saw you describe your problem, and saw David Nolen suggest JaCoP for consideration, I immediately thought, Oh, I know how to model that in Loco. And yes, I did know how to model it, but I just didn't properly think through the ramifications of whether it would work for the size problem you're talking about. With further thought, I don't think any constraint solver would be able to tackle this. LP solvers exploit the linearity of the math constraints and the lack of any need for the result to be an integer in order to much more rapidly converge on a solution. Local search exploits the fact that you don't really care to prove that you have the optimal solution, you just need to find a solution that's really good. So, for example, you would start by divvying up the money in a greedy way, and then randomly shift around money looking for ways to improve the situation, occasionally taking a suboptimal choice in order to avoid getting stuck in a local optimum. Honestly, I do think that the greedy approach, based on the linear model we discussed at the beginning, will give you a good, practical solution that's close enough to optimal to be worthwhile. --Mark -- 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: How to replace code inside a macro
Thank you everyone for explanations. I think now I understand macros and how to use macro let better. Milinda On Thursday, March 6, 2014 1:51:59 PM UTC-5, Konrad Hinsen wrote: --On 5 Mar 2014 09:37:24 -0800 milinda milinda@gmail.comjavascript: wrote: Thanks Konrad. Your unquoting trick worked. But I am not exactly sure how to reason about these types of situations. Can you please shed some lights behind the logic of above unquoting if possible. I suppose you refer to the ~'defpop, right? That is indeed a bit subtle. An unquote followed by a quote should cancel, one might think. The difference comes from namespacing: `a resolves a in the current namespace, whereas `~'a returns a symbol without a namespace. This matters because macrolet (just like plain let) replaces only non-namespaced symbols. Konrad. -- 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.
Notes on objc subclassing for clojure-objc
http://gal.dolber.com/post/78830045901/defnstype-myclass As always, feedback is very welcome! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
