<< Back to previous view

[TGEN-5] Defspec leaks :tag from args into generated code Created: 13/Dec/13  Updated: 13/Dec/13

Status: Open
Project: test.generative
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Nicola Mometto Assignee: Stuart Halloway
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-Don-t-leak-tag-from-defspec-args-into-generated-code.patch    
Patch: Code

 Description   

See http://dev.clojure.org/jira/browse/TANAL-24 and https://groups.google.com/d/msg/clojure-dev/hRZFuaiB_50/mzKLirgZWmUJ for more info






[TGEN-4] Typo in defspec docstring Created: 11/Mar/13  Updated: 11/Mar/13

Status: Open
Project: test.generative
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Trivial
Reporter: Ambrose Bonnaire-Sergeant Assignee: Stuart Halloway
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The docstring for `defspec` misspells "metdata".






[TGEN-3] binding *seed* does not change the basis Created: 13/Oct/12  Updated: 03/Feb/13  Resolved: 03/Feb/13

Status: Closed
Project: test.generative
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Ben Smith-Mannschott Assignee: Stuart Halloway
Resolution: Completed Votes: 0
Labels: None


 Description   

This is what I'm observing:

user=> (binding [gen/*seed* 7] (gen/uniform))
-6880819372607069048
user=> (binding [gen/*seed* 7] (gen/uniform))
5065957067589062886

This is what I'm expecting:

user=> (binding [gen/*seed* 7] (gen/uniform))
-4967725919621401576
user=> (binding [gen/*seed* 7] (gen/uniform))
-4967725919621401576

The work-around is to bind *rnd* to a new java.util.Random constructed appropriately:

(binding [gen/*rnd* (java.util.Random. 7)] (gen/uniform))

I'm not sure: Is this is a bug in the doc string of *seed*? Is the bug the very existence of *seed*? (*seed* is never used.) Should the doc-string for *rnd* suggest something like the code above as a way to get a consistent basis? Should generators provide a with-seed macro to do this for us?



 Comments   
Comment by Stuart Halloway [ 03/Feb/13 7:13 AM ]

this is fixed on master in the data.generators project





[TGEN-2] ASCII DEL (0x7f, 127) is not a printable character Created: 13/Oct/12  Updated: 14/Oct/12  Resolved: 14/Oct/12

Status: Resolved
Project: test.generative
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Ben Smith-Mannschott Assignee: Ben Smith-Mannschott
Resolution: Completed Votes: 0
Labels: None

Attachments: File ascii-127-is-not-printable.diff    
Patch: Code
Approval: Accepted

 Description   

ASCII 127 is a control character.

Dec Hex    Dec Hex    Dec Hex  Dec Hex  Dec Hex  Dec Hex   Dec Hex   Dec Hex  
  0 00 NUL  16 10 DLE  
  1 01 SOH  17 11 DC1  
  2 02 STX  18 12 DC2  
  3 03 ETX  19 13 DC3  
  4 04 EOT  20 14 DC4  
  5 05 ENQ  21 15 NAK  
  6 06 ACK  22 16 SYN  
  7 07 BEL  23 17 ETB  
  8 08 BS   24 18 CAN  
  9 09 HT   25 19 EM   
 10 0A LF   26 1A SUB  
 11 0B VT   27 1B ESC  
 12 0C FF   28 1C FS   
 13 0D CR   29 1D GS   
 14 0E SO   30 1E RS   
 15 0F SI   31 1F US                                                 127 7F DEL


 Comments   
Comment by Ben Smith-Mannschott [ 14/Oct/12 11:14 AM ]

Fixed by a73c11e3 on test.generative.





[TGEN-1] generators/shuffle violates contract of Comparable Created: 13/Oct/12  Updated: 14/Oct/12  Resolved: 14/Oct/12

Status: Resolved
Project: test.generative
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Ben Smith-Mannschott Assignee: Ben Smith-Mannschott
Resolution: Completed Votes: 0
Labels: None
Environment:

Mac OS X 10.8.2
java version "1.7.0_06"
Java(TM) SE Runtime Environment (build 1.7.0_06-b24)
Java HotSpot(TM) 64-Bit Server VM (build 23.2-b09, mixed mode)


Attachments: File fisher-yates-shuffle.diff    
Patch: Code
Approval: Accepted

 Description   

JDK 7's sort function is stricter about verifying that implementations of the comparison function actually obey their contract. It will even helpfully throw an exception when this is not the case:

java.lang.IllegalArgumentException: Comparison method violates its general contract!

The root cause is this gem:

generators.clj
(defn shuffle
      "Shuffle coll"
      [coll]
      (sort-by (fn [_] (long)) coll))

Which does not work on JDK7 since TimSort is clever enough to detect that the ordering function is behaving inconsistently, resulting in the previously mentioned exception.

Also, this is just a bad idea:

A variant of the above method that has seen some use in languages that support sorting with user-specified comparison functions is to shuffle a list by sorting it with a comparison function that returns random values. However, this is an extremely bad method: it is very likely to produce highly non-uniform distributions, which in addition depends heavily on the sorting algorithm used.

(wikipedia)



 Comments   
Comment by Ben Smith-Mannschott [ 14/Oct/12 11:13 AM ]

Fixed by 5a59bf0f on test.generative.





Generated at Sat Apr 19 07:31:41 CDT 2014 using JIRA 4.4#649-r158309.