<< Back to previous view

[LOGIC-137] OOM when setting (interval 1 2) for 20 logic vars Created: 11/May/13  Updated: 11/May/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Gary Fredericks Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Clojure 1.5.1, both 0.8.3 and 0.8.4--994a7a3

Running on a 1GB VM.


 Description   

The following two programs (presumably equivalent) both give me OOM (heap space):

(let [vs (repeatedly 20 l/lvar)]
  (l/run 1 [q]
     (l/== q vs)
     (l/everyg (fn [v] (fd/in v (fd/interval 1 2))) vs)))
(l/run 1 [q]
         (l/fresh [x1 x2 x3 x4 x5 x6 x7 x8 x9
                   x10 x11 x12 x13 x14 x15
                   x16 x17 x18 x19 x20]
                  (l/== q [x1 x2 x3 x4 x5 x6 x7 x8 x9
                           x10 x11 x12 x13 x14 x15
                           x16 x17 x18 x19 x20])
                  (fd/in x1 x2 x3 x4 x5 x6 x7 x8 x9
                         x10 x11 x12 x13 x14 x15
                         x16 x17 x18 x19 x20
                         (fd/interval 1 2))))

I assume the expected value is something like ([1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1]).



[LOGIC-136] Make benchmark suite as easy to run as `lein test` Created: 09/May/13  Updated: 09/May/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Austin Haas Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

`lein benchmark` (or some other non-lein-based incantation) prints a report listing the name of each benchmark and its timing.

Example:

$ lein benchmark
membero 2839
zebra 152738
$ lein benchmark comparison-report {:baseline "benchmark-5.9.2013-1"
                                    :runs 5
                                    :diffs-only true
                                    :threshold 25} ; only consider different if the delta is > 25 ms.                                     
membero +68ms
zebra -122ms
$ lein benchmark {:pretty true}
Thu May  9 11:21:41 PDT 2013

Linux mars 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux

java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

membero     2839 ms
zebra     152738 ms

I haven't looked for any Clojure benchmarking libs, but ideally this would be a trivial script that automates the repetitive manual task of running benchmark tests. Unlike the test suite, we aren't looking for binary success or failure. Every run will generate unique results, so the script should accommodate a fuzzier comparison.

A "pretty" output that includes system info would be great for bug reports.



 Comments   
Comment by David Nolen [ 09/May/13 1:44 PM ]

Sounds like an excellent enhancement to me. Patch welcome for this.




[LOGIC-133] Add label goal Created: 29/Apr/13  Updated: 29/Apr/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This goal should enumerate any fd vars found in a fresh/ground var bound to a sequence. This would avoid some unintuitive behavior that came up on the mailing list:

(defne weighted-listo [l w]
  ([() _] (fd/== w 0))
  ([[h . t] _]
    (fresh [n]
      (fd/in n (fd/interval 0 java.lang.Integer/MAX_VALUE))
      (fd/in h (fd/interval 1 java.lang.Integer/MAX_VALUE))
      (fd/+ h n w)
      (weighted-listo t n))))



[LOGIC-128] add mod/rem/abs/min/max Created: 02/Apr/13  Updated: 02/Apr/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

SWI-Prolog's CLP(FD) module has this functionality http://www.swi-prolog.org/man/clpfd.html



[LOGIC-119] tie disequality Created: 12/Mar/13  Updated: 12/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description    
(deftest test-tie-disequality
  (is (= (run* [q]
           (nom/fresh [a b]
             (!= (nom/tie a a) 'hello)))
        '(_0)))
  (is (= (run* [q]
           (nom/fresh [a b]
             (!= (nom/tie a a) (nom/tie b b))))
        ())))

Currently, the first causes an error, because IPersistentMap (which gets called because Tie is a record!) assumes that the the other term is also a record (that seems like a bug). If we revert the commit which makes Tie a record, this works.

The other one succeeds, when it should fail. This is regardless of whether Tie is a record or not.



 Comments   
Comment by Nada Amin [ 12/Mar/13 5:52 AM ]

quick fix in https://github.com/clojure/core.logic/commit/8af0f45f8d1cb515ec7a00e5acd751562a31bb37

for actually doing != modulo alpha equivalence requires the opposite of nom/hash.




[LOGIC-118] prep does not make lvar of ?x if ?x is in a vector Created: 11/Mar/13  Updated: 17/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jonas Enlund Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File LOGIC-118.diff    

 Description   

In latest master:

user=> (use 'clojure.core.logic.unifier)
user=> (prep '([?x]))
([<lvar:?x>]) ;; ok. ?x turned into an lvar
user=> (prep '([?x] . ?xs))
([?x] . <lvar:?xs>) ;; fail. ?x is not an lvar

The last expression should return ([<lvar:?x>] . <lvar:?xs>)

 Comments   
Comment by Jonas Enlund [ 12/Mar/13 12:11 AM ]

patch LOGIC-118.diff fixes this issue. I'm not sure if it does so correctly.

Comment by David Nolen [ 17/Mar/13 11:42 AM ]

It's seem to me that this should be corrected in prep*? It looks like the issue is that prep* only handles seqs and not collections in general.




[LOGIC-117] one-shot constraints with multiple rands may run more than once Created: 11/Mar/13  Updated: 19/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Nada Amin Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Here are two examples using fixc:

(run* [q]
  (fresh [x y]
    (fixc [x y]
      (fn [[x y] a _] (!= x 1))
      (fn [[x y] a] (= (walk a x) (walk a y)))
      '...)
    (== x y)))

(run* [q]
  (fresh [x y c d]
    (fixc [x y]
      (fn [[x y] a _] (!= x y))
      (fn [[x y] a] (or (not (lvar? (walk a x))) (not (lvar? (walk a y)))))
      '...)
    (== [x y] [[c] [d]])))

The constraint != is reified twice in each example, showing that the fixc constraint indeed ran twice.

 Comments   
Comment by David Nolen [ 17/Mar/13 7:27 PM ]

For the first example I see the following as a result on master:

((_0 :- (!= (_1 1))))

Is this what you're seeing? As x isn't even part of the answer I wonder if we should show these constraints?

Comment by Nada Amin [ 19/Mar/13 1:36 AM ]

I changed the reifier by setifying the set of constraints, hence you get only one result now. So my illustration is now out-of-date but the problem remains. It's a separate issue to filter out irrelevant constraints, and I agree it should be done (I try to do it for the nominal constraints).




[LOGIC-114] stack overflow with conda/u Created: 14/Feb/13  Updated: 17/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Austin Haas Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description    
(ns test
  (:refer-clojure :exclude [==])
  (:require
   [clojure.core.logic :refer :all]))
 
(defn foo [in out]
  (matcha 
   [in out]
   ([('and a b . ()) ('and x y . ())] (foo a x) (foo b y))
   ([a ('bar ('baz a . ()) . ())])))
 
;; I get a stack overflow with the following, but if I remove one conjunct, then it will run.
 
(run 1 [q] (foo
            '(and p
                  (and p
                       (and p
                            (and p
                                 (and p
                                      (and p
                                           (and p
                                                (and p
                                                     (and p
                                                          (and p
                                                               (and p p)))))))))))
            q))

 Comments   
Comment by David Nolen [ 14/Feb/13 1:22 PM ]

It looks this issue still exists even if you swap the matcha with matche

Comment by Austin Haas [ 14/Feb/13 8:06 PM ]

I think the overflow is occurring during reification.

I was getting this error when returning a result from run, but now that I'm using the same value as the input to another goal there is no overflow.

If you replace q in the foo call with a fresh variable, it will not overflow.

Comment by David Nolen [ 17/Mar/13 7:30 PM ]

This works for me on master. Can you give me more specifics about your setup so I can try to recreate? I'm on OS X 10.8 running JDK 7 64bit.

Comment by Austin Haas [ 17/Mar/13 8:50 PM ]

I don't see the issue anymore, but I believe I was using Java 1.6 when I reported it and now I am using:

$ java -version
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

Comment by David Nolen [ 17/Mar/13 9:02 PM ]

OK, thanks for the quick response, I'll double check how things look under 1.6.




[LOGIC-99] StackOverflow for large `appendo` Created: 05/Jan/13  Updated: 07/Jan/13

Status: In Progress
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description    
(def l (range 0 2000))
(run* [q] (appendo l l q))

Stacktrace

user=> (def l (range 0 2000))
#'user/l
user=> (run* [q] (appendo l l q))
StackOverflowError   clojure.core.logic.LVar (logic.clj:1307)
user=> (pst)
StackOverflowError 
    clojure.core.logic.LVar (logic.clj:1307)
    clojure.lang.KeywordLookupSite$1.get (KeywordLookupSite.java:45)
    clojure.core.logic.LVar (logic.clj:1325)
    clojure.lang.Util.equiv (Util.java:32)
    clojure.lang.PersistentHashMap$BitmapIndexedNode.find (PersistentHashMap.java:601)

    clojure.lang.PersistentHashMap$ArrayNode.find (PersistentHashMap.java:370)
    clojure.lang.PersistentHashMap$ArrayNode.find (PersistentHashMap.java:370)
    clojure.lang.PersistentHashMap.entryAt (PersistentHashMap.java:133)
    clojure.lang.RT.find (RT.java:720)
    clojure.core/find (core.clj:1432)
    clojure.core.logic.Substitutions (logic.clj:1134)
    clojure.core.logic/walk*/fn--2847 (logic.clj:1005)

 Comments   
Comment by David Nolen [ 05/Jan/13 2:44 PM ]

I cannot recreate on my machine but should try a large N & wait and see.




[LOGIC-89] Allow application again in pattern matches Created: 01/Jan/13  Updated: 07/Jan/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: 0.8.0


 Description   

Perhaps we can support simple function application in the following manner.

(defne substo [e new a out]
  (['(var ~a) _ _ new])
  (['(var ~y) _ _ '(var ~y)] (nom/hash a y))
  (['(app ~rator ~rand) _ _ '(app ~rator-res ~rand-res)]
     (substo rator new a rator-res)
     (substo rand new a rand-res))
  (['(lam ~(nom/tie c body)) _ _ '(lam ~(nom/tie c body-res))]
     (nom/hash c a) (nom/hash c new)
     (substo body new a body-res)))

If we have a seq in an unquote then we know we have an application. All function symbols are left alone, all arguments are considered to be fresh vars or locals.



[LOGIC-68] add Prolog meta-logical predicates bagof, setof, findall Created: 16/Nov/12  Updated: 13/Feb/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-LOGIC-68-Add-run-a-run-a-logic-functions-to-support-.patch    

 Description   

This can be done by annotating logic variables and embedding a run within a run by passing in the current substitution, running on it, and extracting out the reified values and unifying it back into the current substitution.

 Comments   
Comment by Aaron Brooks [ 16/Nov/12 1:23 PM ]

I'm working on understanding the answers given for this StackOverflow question:

http://stackoverflow.com/questions/7647758/prolog-findall-implementation

Comment by Aaron Brooks [ 16/Nov/12 10:02 PM ]

For discussion — Initial working patch supporting nested version of 'run-a/'run-a*. Binding symbols must match existing lvars with which vectors of all returned values will be unified.

Comment by Aaron Brooks [ 17/Nov/12 4:07 PM ]

Should we provide wrappers that emulate each of bagof, setof and findall?

I'm still not sold on the current names run-a/run-a*. "a" is really an internal implementation detail. Expect a revised patch with better names when I think of them (any ideas?).

Comment by David Nolen [ 17/Nov/12 8:32 PM ]

Yes please. Yeah I don't think the names of run-a/etc are critical - implementation details for now until we really understand the implications and it gets some use.

Comment by Aaron Brooks [ 21/Nov/12 10:51 AM ]

I'm considering simply making run/run* conditionalized on the first argument, using the nesting form if we are being called with a substitution map as the first argument.

My current understanding of bagof and findall makes me think they're not worth implementing beyond the nesting run functionality.

I'm still thinking about setof which is quite useful and will want help from the infrastructure to be fully efficient.

I'll submit a new patch after Thanksgiving.

Comment by David Nolen [ 21/Nov/12 10:57 AM ]

Excellent, thanks much.

Comment by Aaron Brooks [ 06/Dec/12 12:30 AM ]

I have not forgotten, I've just gotten swamped.

There's a small chance I'll get to this before Christmas, otherwise, it's after the new year.

Comment by Aaron Brooks [ 04/Feb/13 5:50 PM ]

After a car accident, travel to London and Morocco, getting caught up at work and getting caught up on the apparently very busy stream of core.logic activity (great work!), I'm back on this.

I found some bugs in my implementation after porting the patch forwards and realized these issues highlighted my sloppy understanding of some of the semantics I had created.

I'm fairly convinced now that we don't want to name this after run or run*. It's too much of a strain to try to make it mean the same thing in a nested context.

The current mechanism is still not quite a match for findall/bagof/setof, however, so I'm seeing what a good fit would be. I'll post meaningful thoughts for review as I have them.

Comment by David Nolen [ 13/Feb/13 1:50 PM ]

Glad to hear you're OK! No worries, will take a patch whenever you get around to one.




[LOGIC-47] is macro needs to be improved Created: 30/Aug/12  Updated: 30/Aug/12

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None


 Description   

the is macro should work like the following:

(is x (- (+ a b) c))

All locals appearing in the right expression should be walked.



[LOGIC-38] Logic Threading Macro Created: 13/May/12  Updated: 13/May/12

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Jason Jackson Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-added-logic-threading-macro.patch     Text File 0001-added-logic-threading-macro.patch    

 Description   

This macro was somewhat useful when I was implementing static analysis for a compiler with core.logic.

(defmacro ==>> [expr-in & rel-forms]
"Thread the expr-in through rel-forms then unify with last rel-forms
(the 'out expression').

Example:
(==>> [[1]] (firsto) (firsto) x))
;; 'x' will become bound to value 1

This macro expands to:
(fresh [_A _B]
(firsto [[1]] _A)
(firsto _A _B)
(== _B q))

If you imagine that the 'return value' of firsto is its last parameter,
then it works just like clojure.core/-> as return value of each form is
first argument of the following form."

 Comments   
Comment by Jason Jackson [ 13/May/12 11:08 AM ]

There might be a better name, not sure.

Comment by Jason Jackson [ 13/May/12 11:18 AM ]

renamed ==>> to ==->




[LOGIC-30] Add persistent memory tables Created: 09/Mar/12  Updated: 17/Mar/13

Status: Open
Project: core.logic
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Brian Goslinga Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-Added-persistent-memory-tables.patch    
Patch: Code and Test

 Description   

Rels currently complect identity and value, and are not first class. This enhancement provides a single-arity relation as a first class persistent value. Equality (and hash code) is defined in terms of the ITableRel protocol, leaving the door open for alternative implementations.

The implementation provide in the attached patch is a hair faster than Rels in the single index case. The query strategy used in the multiple index case may or may not be faster than the one employed by Rels depending on the data. This could easily be made configurable, if desired.

 Comments   
Comment by David Nolen [ 17/Mar/13 6:53 PM ]

ThreatGRID has a really nice simple implementation going here that they are already using in production - http://github.com/threatgrid/pldb. We should probably just integrate it.




Generated at Thu May 23 11:26:57 CDT 2013 using JIRA 4.4#649-r158309.