Re: core.logic API confusion
On Mon, Jun 9, 2014 at 2:11 AM, JD jesus.diama...@gmail.com wrote: When I try to use core.logic's fact function I am getting a symbol not found error. What is the idiomatic way to do something like: (logic/fact Orbits :mercury :sun) Orbits here was previously bound in a defrel, which I ended up replacing with pldb/db-rel. (ns logic.orbit (:refer-clojure :exclude [==]) (:use [clojure.core.logic]) (:require [clojure.core.logic.pldb :as pldb])) (pldb/db-rel orbits satellite body) (def orbit-facts (pldb/db-facts pldb/empty-db [orbits :mercury :sun] [orbits :venus :sun] [orbits :earth :sun] [orbits :mars :sun] [orbits :moon :earth] [orbits :phobos :mars] [orbits :deimos :mars])) (pldb/with-db orbit-facts (run* [moon] (fresh [planet] (orbits moon planet) (orbits planet :sun -- 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: core.logic with functions
On Mon, Apr 28, 2014 at 8:36 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: I want to do the same thing where the second argument is a list of lists. So something like: [...] Is there a way to do this with functions -- or do I need to macro it? As was already mentioned, everyg is probably the best way to approach this problem (everyg (partial match-list member) lists), but if it helps, this would be my first thought at an implementation without everyg: (defne match-lists [member lists] ([_ []]) ([_ [h . t]] (match-list member h) (match-lists member t))) -- 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: LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure
On Tue, Feb 4, 2014 at 5:20 PM, Sean Corfield s...@corfield.org wrote: On Feb 4, 2014, at 10:21 AM, Colin Yates colin.ya...@gmail.com wrote: Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :) Like Emacs, it has its quirks(!) and it takes some adjustment after two years of using Emacs daily (and several years using Emacs twenty years back!). I'll provide a counterpoint to that. Let me preface by saying I do not hate Light Table. I supported the kickstarter, and I continue to follow the development as one of the best hopes for future Clojure development. I am now using Light Table for Clojurescript development on our not-small-but-not-massive Clojure/Clojurescript UI at Threatgrid. I find the live browser REPL interaction to be invaluable and finally makes me willing to invest more into the Clojurescript UI. Up until now I've found the Clojurescript REPL support to be lacking. Austin is promising, but I've still yet to find anyone who can demonstrate it functioning correctly in a non-demo environment. Light Table works for this, and it works quite well. That being said, Light Table is barely usable as text editor and is a really terrible editor for Clojure in specific. I hope (and believe) this will improve over time. The token paredit barf/slurp shows some attention to details, and work is ongoing for an extended paredit mode. But, I find that I spend a troubling large portion of my time in Light Table wrangling parenthesis and fighting the editor compared to the time I spend actually writing code. The exact opposite is true in emacs. I spend almost no mental effort on the syntax/structure. When I want to move an expression around or make a structural change, I can effect that change almost trivially with no distraction from the coding task at hand. Obvious, there's a lot of practice and experience goes into that, but it's only because emacs has those capabilities in the first place. While every developer is different, I have a hard time imaging any emacs/paredit user would find editing in Light Table a pleasurable experience, so far as the act of writing the code is concerned. There are many, many reasons to like Light Table and to use Light Table for now, but for day to day Clojure development, it's not even close to being ready for serious use. (only my opinion) Still, everyone should give it a try, if you approach it from the perspective of being a tool that might be able to provide some unique value in certain situations, I don't think you'll be disappointed. -- 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: David Nolen's sudoku solver not compatible with Peter Norvig's generator?
On Thu, Jan 30, 2014 at 8:01 AM, Jim - FooBar(); jimpil1...@gmail.comwrote: Now, I am trying to combine his solver with the `random-puzzle` generator shown here ( http://jkkramer.com/sudoku.html). [...] any clues? I'd like to be able to generate random-puzzles that can be passed to the core.logic solver. Currently `(random-puzzle)` returns something like this which at first glance seems compatible with David's solver: user= (random-puzzle 17) (0 0 0 0 0 2 0 0 6 8 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 7 0 0 0 0 0 0 3 0 8 2 0 0 0 0 0 0 0 1 0 0 0 3 0 0 0 0 2 7 0 0 0 5 0 8 0 3 0 2 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0) Well, first off, that isn't a sudoku. It has a large number of solutions, and a sudoku only has one solution. I'm using my slightly modified version of David's sudoku solver (https://gist.github.com/orb/8722569) but I haven't changed anything core to the problem - it's just the version I have laying around: logic.sudoku (def maybe-a-sudoku '(0 0 0 0 0 2 0 0 6 8 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 0 7 0 0 0 0 0 0 3 0 8 2 0 0 0 0 0 0 0 1 0 0 0 3 0 0 0 0 2 7 0 0 0 5 0 8 0 3 0 2 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0)) #'logic.sudoku/maybe-a-sudoku logic.sudoku (pprint (partition 9 (first (solve maybe-a-sudoku ((1 3 5 4 7 2 9 8 6) (8 4 7 1 6 9 2 3 5) (6 9 2 5 3 8 1 4 7) (4 1 6 2 9 5 3 7 8) (2 5 3 6 8 7 4 9 1) (9 7 8 3 4 1 5 6 2) (7 6 1 9 5 4 8 2 3) (3 2 9 8 1 6 7 5 4) (5 8 4 7 2 3 6 1 9)) nil Well, that's one, but clearly there's more. logic.sudoku (pprint (partition 9 (first (drop 100 (solve maybe-a-sudoku) ((1 3 4 9 7 2 5 8 6) (8 5 7 6 3 1 2 4 9) (6 9 2 5 4 8 1 3 7) (4 1 5 2 6 7 3 9 8) (2 6 3 4 8 9 7 5 1) (9 7 8 3 1 5 4 6 2) (7 4 9 1 5 6 8 2 3) (5 2 1 8 9 3 6 7 4) (3 8 6 7 2 4 9 1 5)) nil Lots more... logic.sudoku (pprint (partition 9 (first (drop 1 (solve maybe-a-sudoku) ((3 7 9 1 4 2 5 8 6) (8 1 5 7 6 3 2 4 9) (4 6 2 5 8 9 1 3 7) (1 4 6 2 7 5 3 9 8) (2 3 7 4 9 8 6 5 1) (9 5 8 3 1 6 4 7 2) (7 9 4 6 5 1 8 2 3) (5 2 1 8 3 7 9 6 4) (6 8 3 9 2 4 7 1 5)) I don't know how many solutions there are, but it seems like there are a lot... I think you are just generating all of them and it's taking a long time. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: core.logic 0.8.5
On Mon, Nov 25, 2013 at 10:51 PM, David Nolen dnolen.li...@gmail.comwrote: This release represents a fairly significant change to the simple DB functionality that core.logic provides - instead of a mess of mutable atoms thanks to Norman Richard we now store facts in a persistent data structure. This is likely a breaking change for some people, but it's a long outstanding issue that I'm happy to see finally remedied. I think we have some outdated documentation now. I'll try and fix that up. In the meantime, I'm happy to assist if anyone needs help migrating to the fact db. -- -- 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: core.logic merge substitutions map?
On Mon, Nov 18, 2013 at 6:26 PM, Kevin Downey redc...@gmail.com wrote: https://github.com/sonian/Greenmail/blob/master/src/clj/greenmail/db.clj#L98-L126 has an example, using clojure.core.logic/all to make a goal which is a conjunction of the clojure.core.logic/== goals Based on my experience writing pldb, using == in this situation is going to work better than using unify as shown in the code sample base on the video. I found that using unify for this type of custom relation appears to work but will not do the right thing with more complicated situations. I found constraints particularly problematic. Switching from unify to == makes sure everything you want to happen on unify actually happens. -- -- 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: cider status
On Tue, Nov 12, 2013 at 10:22 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: I have tried it a couple of times and keep reverting back to nrepl. One of the biggest issues is nrepl-ritz which depends on nrepl and not nrepl-client. So switching to cider appears to mean ditching ritz. Although I don't understand why anyone thought it was a good idea to change package names, I can confirm that for my daily clojure development, the transition was fairly painless (uninstall/reinstall packages and update some init.el configuration) and has not caused any problems with the set of emacs clojure tools I use. (which does not include ritz) I don't remember when I made the move, but it's been at least a week. -- -- 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: Maximize Fantasy Baseball Lineup
This sounds like a classic knapsack problem. For such a small problem space, a simple dynamic programming solution would suffice. If you are interested in exploring this problem at a larger scale, I high recommend coursera's Discrete Optimization class: https://class.coursera.org/optimization-001 -- -- 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 I can catch exception from cheshire.core?
On Wednesday, September 11, 2013 5:29:39 AM UTC-5, Алексей Александров wrote: Yes, json/decode return clojure.lang.LazySeq. I added (doall ) to force calculation. This bit me on a project yesterday. I also added a doall, but I haven't had time to investigate whether any of the interior items are also lazy, in which case I guess we'd need some sort of tree walking doall? -- -- 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] Austin — the ClojureScript browser-REPL, rebuilt stronger, faster, easier
On Mon, Aug 5, 2013 at 8:21 AM, Chas Emerick c...@cemerick.com wrote: As you might know, I've been tinkering with an easier-to-use variant of ClojureScript's browser-REPL for some time. I've finally wrapped that up into its own project, Austin: [...] Is anyone successfully using this with nrepl in emacs? I am able to make it work, but something is causing both emacs and the JVM it is connected to to use 100% CPU. I seem to be getting a long stream of Unable to resolve symbol: if-let in this context, compiling:(NO_SOURCE_PATH:1:1) See: https://gist.github.com/orb/6496320 *nrepl-connection* fills up with: d2:ex45:class clojure.lang.Compiler$CompilerException2:id6:1504207:root-ex45:class clojure.lang.Compiler$CompilerException7:session36:43e688aa-01c2-4824-b1f3-1bd05a1f02446:statusl10:eval-erroreed3:err128:CompilerException java.lang.RuntimeException: Unable to resolve symbol: if-let in this context, compiling:(NO_SOURCE_PATH:1:1) I'm not sure if this is a problem with austin or if it's nrepl.el or something on the emacs side. As a side note, I occasionally get a similar error message using straight nrepl when first starting up, but it usually only happens once. With austin/nrepl it appears to be stuck in some kind of loop erroring over and over... Does anyone have a known good setup I could try to reproduce? -- -- 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: Current state of the art in Web deployment?
On Sat, Aug 17, 2013 at 3:52 PM, John Jacobsen eigenhom...@gmail.comwrote: So, what do all y'all do? What is a good lightweight but robust way to get a fairly simple Compojure/Ring app backed by Datomic facing the outside world? Not too worried about massive scalability at this point; simplicity will be a plus (am worried that e.g. Immutant / JBoss are too heavyweight). If simplicity is the goal, then Immutant makes things pretty extremely easy while giving you some infrastructure to build on going forward. Our non-immutant deployment uses a custom jetty startup along with an uberjar build. Doing the uberjar lets us not worry about dependency resolution at deploy time, but that's really it. (I don't know if lein has some other mechanism for fixing dependencies or if the recommendation is to run your own internal caching maven proxy) Other than that, mechanically our deploy is not significantly different from a lein ring server, so maybe you can explain what your concerns with that are? -- -- 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: core.logic - getting good at writing non-terminating programs
On Mon, Aug 12, 2013 at 4:03 PM, Mark markaddle...@gmail.com wrote: At run level 6, I get all the permutations of [1 2 3], just as expected. However, at 7, the program does not terminate and I'd like to understand why. I feel like I need to constrain the relation between o-h and o better but I'm not sure what else to say about it. Looking at this, it's clear that this will never terminate. Your recursion is unbounded on the rembero. When you get to rembero, your l and o-h are both always fresh. (rembero :anyting (lvar) (lvar)) will produce an infinite set of results. After you've generated all your 6 results, remberallo will of course fail on everything rembero produces, but you've got nothing that stops rembero. Now, consider putting the remberallo BEFORE the rembero: (defne remberallo [s l o] ([() l l]) ([[h . r] _ _] (fresh [o-h] (remberallo r o-h o) (rembero h l o-h Now, imagine you are on a final remberallo call where h is some number and r is the empty list. The recursive remberallo will will only produce one answer, unifying o-h and o. Now o-h is no longer fresh and your rembero will have enough information to terminate. -- -- 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: Negation in core.logic
On Fri, Aug 9, 2013 at 4:19 PM, Alex Dowad alexinbeij...@gmail.com wrote: (== 0 (count (run* [arg] (goal arg What this is actually doing (run* [q] ;;... some stuff -- -- 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: Negation in core.logic
Sorry - gmail spasm What I was trying to say is that what I think your code is doing is running a Clojure expression once and unifying with 0. It's equivalent to precomputing that outside of the run*: (let [result (count (run* [arg] (goal arg))] (run* [q] ;; whatever-else-you-were doing (== 0 result))) Now, of course that expression could use some projected value or be embedded in a goal that gets tested multiple times, but chances are that the naive uses of that are probably not doing what you really want to do. -- -- 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: IDE feature
On Thu, Aug 8, 2013 at 7:44 AM, Lee Spector lspec...@hampshire.edu wrote: I was referring to Norman Richard's comment, which is what set me off: Structural editing, like paredit, is really the only sane way to do Clojure code. I honestly thing anyone who manually balances parenthesis or edits Clojure functions in a way that doesn't preserve the structural integrity of your expressions is just doing it wrong. (not just doing it poorly - but doing it wrong). I do stand by comment. You are free to disagree. It's so painful to watch people (experienced LISPers and newbies alike) manually balancing parenthesis and spending inordinate amounts of time to do the simplest tasks like pulling an expression up into a let or wrapping/unwrapping blocks. I've never once seen someone programming Clojure without paredit and thought to myself wow - that guy/gal really has this down. The scope of this statement is limited by the sadly small number of great Clojure coders I've had the pleasure of watching work. I would truly love to see some counter examples. If doing it by hand works for you, more power to you. I think you are doing it wrong, but my personal opinions thankfully don't really affect much of the world outside my head. -- -- 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: IDE feature
On Thu, Aug 8, 2013 at 7:20 PM, Sean Corfield seancorfi...@gmail.comwrote: Yes, paredit is a bit of a pain to get used to at first, but it really does remove a whole slew of issues around parentheses in code, and it really does make you a lot more productive, especially once you learn the structural editing commands (I am surprised at how many times I use paredit-convolute-sexpr to help reorganize code - I'm almost at the point of binding it to a key sequence!). It's almost like magic, when it fits the situation. I've been toying with the idea of starting a project to create a refactoring-like layer on top of paredit to give more of these types of operations - and hopefully with clearer names that convolute-sexpr... Is anyone else interested in working on refactoring tool? -- -- 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: IDE feature
On Wed, Aug 7, 2013 at 12:25 PM, Paul L. Snyder p...@pataprogramming.comwrote: If paredit is a hard sell (it was for me, the first three or four times that I tried it), realizing that you can break the balance when needed by judicious use of kill and yank may be helpful during the transition to a structural editing mindset. Structural editing, like paredit, is really the only sane way to do Clojure code. I honestly thing anyone who manually balances parenthesis or edits Clojure functions in a way that doesn't preserve the structural integrity of your expressions is just doing it wrong. (not just doing it poorly - but doing it wrong) So, of course, my advice to the original poster is to just jump in and learn paredit. It will probably seem awkward at first, but if you invest the effort (and it honestly doesn't take that much) to learn a better way to edit expressions, you'll be so much better off. In fact, I've sold several people on Clojure just by showing them how paredit makes it significantly easier to lisp-style expressions than to edit C-style languages with their irregular syntax. I would jumped on lisp years ago if I had realized how easy it was to edit instead of remembering those painful university lisp assignments where I spent all my time balancing parenthesis and being afraid to make simple structural changes for fear of getting my code all messed up. -- -- 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: core.logic - Using featurec to describe relationships around keys in a map
On Fri, Jul 5, 2013 at 1:06 PM, David Rocamora dro...@gmail.com wrote: I'm trying to use featurec to describe some relationships within a nested map. When I try to use it to find some keys in the map it returns nothing. Here is an example: I don't believe you can match on the keys in a map - only the values. One solution I have come up with is to massage the map into a vector like this: ... I would do this if the data I was dealing with was just the colors of food, but what I am really trying to do is use core.logic to create programs that understand relationships in AWS CloudFormationhttp://aws.amazon.com/cloudformation/ templates. A CFN template is a JSON file that is a bunch of nested maps that describe cloud computing infrastructure. I feel there are risks to massaging the templates and featurec feels right. What am I missing? Any guidance is appreciated. We do a similar type of JSON matching with core.logic at threatgrid. The approach we take (which was developed before core.logic had featurec or any map unification capabilities) is walk the JSON (we use zippers to search/extract) and make observations ( https://github.com/threatgrid/observations) about the data into a pldb dataset (https://github.com/threatgrid/observations) that our core.logic programs run against. Some of the advantages in my mind are: makes core logic code more robust to data changes (we can change the input in allows for simple data type transforms to structures core.logic can work with better (getting a year from a date, or splitting a string) allows for structural tranformations into more relational structures This has worked really well for us, so something in this direction would probably work for you too if you are going beyond what core.logic has to offer out of the box. -- -- 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: core.logic - using membero to generate list?
On Sat, Jul 6, 2013 at 3:16 PM, Adam Saleh adamthecam...@gmail.com wrote: = (run 1 [q] #= (membero :a q)) ((:a . _0)) Unfortunately when I try to do something \w it, it throws exception = (first *1) (1 . _0) = (first *1) IllegalArgumentException Don't know how to create ISeq from: clojure.core.logic.LCons clojure.lang.RT.seqFrom (RT.java:505) I guess I need to somehow convert the logic-based list to clojure-based, how do I do it? A cons cell doesn't really convert to a clojure list, especially when the last item is fresh. I guess the real question is: what result do you want from Clojure? If you just want to access the values you have now, you can get them with lfirst/lnext (in clojure.core.logic.protocols) but maybe the better question to ask is: what clojure result do you actually want? If you want all the possible proper lists, then I'd suggest constraining it to be such: (defn listo [l] (conde [(emptyo l)] [(fresh [a d] (conso a d l) (listo d))])) In my experience, calling core.logic from real application code works best when you write programs that produce fully realized results without any fresh values -- -- 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: Anybody has tried to (re)write re-match in core.logic?
On Thu, Jul 4, 2013 at 9:36 AM, Tassilo Horn t...@gnu.org wrote: Not sure if core.logic can do relations between infinite sets... Sure, why not? Here's a trivial example of combinations of all lists containing :x with all the lists containing :y, both infinite. (run 10 [x y] (membero :x x) (membero :y y)) ([(:x . _0) (:y . _1)] [(:x . _0) (_1 :y . _2)] [(_0 :x . _1) (:y . _2)] [(:x . _0) (_1 _2 :y . _3)] [(:x . _0) (_1 _2 _3 :y . _4)] [(_0 :x . _1) (_2 :y . _3)] [(:x . _0) (_1 _2 _3 _4 :y . _5)] [(:x . _0) (_1 _2 _3 _4 _5 :y . _6)] [(_0 _1 :x . _2) (:y . _3)] [(_0 :x . _1) (_2 _3 :y . _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.
Re: core.logic: question on ordering in conjunction
What you are trying to do is non-relational, and will only work when you put the non-relational pluso at the end. You can obviously use the finite domain extensions to core.logic to accomplish this: (defn fd-pluso [t1 t2 s] (fd/eq (= s (+ t1 t2 (run* [q] (fresh [a] (fd/in q a (fd/interval Integer/MAX_VALUE)) (fd-pluso q 4 a) (== a 7))) = (3) I don't know how you achieve this result in core.logic without the finite domain support. -- -- 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: core.logic: question on ordering in conjunction
On Sun, Jun 30, 2013 at 12:58 PM, Steven Devijver sdevij...@gmail.comwrote: How does one recognize a relational or non-relational goal? If you are using anything that doesn't decompose down to the core relational operators, like == and conde, you are likely non-relational. In this case, you are asking questions like is this value ground which is clearly a stateful question about where you are in the search. (what you are doing is very similar to core.logic's project, and if you search for that you'll probably find some discussion of the issues) As a general rule, if you can change the order of your goals and get different answers, you are probably doing something non-relational. That doesn't mean to are doing something wrong - it just means you are going beyond the pure relational model and are potentially more constrained in how you can express your problem. (in this case, being order dependant) -- -- 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: Translating simple path finding problem from prolog to core.logic
Just like the prolog, you are generating an infinite number of solutions. run* will try and give you all of them. You can use clojure's lazy seq operations (first, take, etc...) or just ask for however many you want: (run 10 [q] (path2 1 7 q)) ((1 4 3 7) (1 2 4 3 7) (1 4 5 7) (1 2 4 5 7) (1 4 3 6 5 7) (1 2 4 3 6 5 7) (1 4 5 6 5 7) (1 2 4 5 6 5 7) (1 4 3 7 5 7) (1 2 4 3 7 5 7)) -- -- 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: core.logic: Dividing the knowledge base
On Mar 14, 2013, at 4:15 PM, JvJ kfjwhee...@gmail.com wrote: I'm not sure how else to go about contacting you about this, but I've found some problems in pldb. The system just doesn't seem to work at all with the core.logic 0.8.0 builds. I'm not too familiar with the guts of pldb or core.logic, but I'm wondering if maybe some implementation changes lead to this? PLDB was written against the current core.logic release. I have not yet started testing with the 0.8 pre releases, but judging from the recent core.logic announcement, now is probably a good time to start. :) You can report issues on the github project page. Also, feel free to grab me on the clojure IRC channel at any time. -- -- 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: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 4:03 PM, JvJ kfjwhee...@gmail.com wrote: It states that retractions aren't yet implemented. Is there any way to delete facts? Retractions are now supported. DB merging and cross-DB logic queries are still coming. Feel free to comment on the github issues if you have specific use cases in mind you would like to see this support. I have some specific ideas for things we want to do with this at Threatgrid, but that's only one use case. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 4:32 PM, JvJ kfjwhee...@gmail.com wrote: One more thing I'd like to ask. Is it possible to combine the databases in a way? For instance, I'd like to have a universal database that every agent can access, as well as agent-specific databases. I understand that databases can be modified in a purely functional way (which is great), but I'm wondering if there's a way for changes in the universal database to be reflected in the others. I think it should be possible to support relations over multiple logic databases. I'm going to add that to the feature list. I will try to get a new release out this weekend. -- -- 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: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 2:50 PM, JvJ kfjwhee...@gmail.com wrote: I'm creating something with core.logic that involves multiple agents(not the same as a clojure agent!) which each have distinct knowledge. I'd like to know the best way of going about separating the knowledge base so that it can be accessed by each agent individually. The simplest thing I can think of is to define each relation with an additional agent parameter, but that seems sloppy and I'm not sure if it would be efficient. Is this a good approach, or is there something better I can do? Threatgrid had the problem of wanting to have distinct datasets over the same relations. Our solutions was to declare facts in to a persistent logic db and refer them explicitly when performing queries. I've released part of that work here: https://github.com/threatgrid/pldb There's a branch with indexing support on my fork, and I have a few other enhancements queued up. We use this code on some very large datasets and it is working well for us. -- -- 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: core.logic: Dividing the knowledge base
On Wed, Feb 27, 2013 at 4:03 PM, JvJ kfjwhee...@gmail.com wrote: It states that retractions aren't yet implemented. Is there any way to delete facts? This is something I want to add, and if it's something you could use now, I'll bump up priority of getting that in. What we do is just build a new logic db for each runs with different facts, which is why it hasn't been implemented yet. -- -- 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: *read-eval* vulnerability
On Wed, Jan 30, 2013 at 1:02 AM, Takahiro Hozumi fat...@googlemail.comwrote: As more and more projects are using edn format for config, communication and etc, I think that default value of *read-eval*, which is true, is source of vulnerability such as recently reported ring issue [1]. Slight diversion here - what is the approved and safe way to read data from an untrusted source? I had a task this week which required data to to be read via an API. I wanted to use clojure data/EDN, and ended up with three primary issues: 1 - *read-eval*, which I bound to false 2 - data literals - I don't know which data literals are truly safe from an external source. I rebound *data-readers* to make sure only the system readers were around, which I assume are thought to be safe 3 - read-string only reads one expression, silently ignoring additional characters. I assume I could solve this using read and checking for additional items and raising an error if more expressions were received than expected In the end, I re-implemented this API using JSON, where there are no safety issues parsing data. This is an unfortunate decision, and I'd like to enable the clojure data version. I'm just not sure whether or not using read/read-string is intended to be a safe reader in the long term. If it's not, maybe we need a set of functions that are blessed for use with untrusted data? -- -- 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.
