ditz issue update

bugs/issue-d351318e427eec601f6d5e2fe2068081a7551e43.yaml

@@ -0,0 +1,32 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: fix function instance refcount collection to deal with prototype reference loop
+desc: |-
+  If there is some easy fix, this should be attempted: a majority of plain
+  functions don't even need the automatic prototype object so it shouldn't
+  prevent collection.
+  
+  A few approaches:
+  
+  * Implement a "dirty" bit for objects.  If the prototype object (and
+    function object) are not dirty, we can be sure that the reference loop
+    can be broken internally.  Internal code can then e.g. set f.prototype
+    to null and resume normal collection.
+  
+  * If function prototype object "autospawning" is implemented, this can
+    also be used to detect that the prototype object hasn't been created
+    (because it hasn't been needed), so the function would be collectable.
+type: :task
+component: duk
+release: 
+reporter: sva <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-03-14 15:19:24.301647 Z
+references: []
+
+id: d351318e427eec601f6d5e2fe2068081a7551e43
+log_events: 
+- - 2014-03-14 15:19:24.541523 Z
+  - sva <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-f66994426dcf0f477e1fd1952608345e1304014d.yaml

@@ -0,0 +1,20 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: fix named function expression internal reference loop with scope object
+desc: |-
+  This is quite a problematic issue because there is no way for a user to break this
+  reference cycle: the other part is a hidden internal object.
+type: :task
+component: duk
+release: 
+reporter: sva <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-03-14 15:17:12.815146 Z
+references: []
+
+id: f66994426dcf0f477e1fd1952608345e1304014d
+log_events: 
+- - 2014-03-14 15:17:12.990741 Z
+  - sva <sami.vaarala@iki.fi>
+  - created
+  - ""