Ditz issue update

bugs/issue-39f8f5bfd85083fe4e3af1bea400cff87127f459.yaml

@@ -0,0 +1,34 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: add finalizer support for plain buffers
+desc: |-
+  Buffers very often need finalizer support because they can contain native
+  structures pointing to malloc()'d memory (or socket handles, etc).  Currently
+  user code must use an actual object and attach a finalizer for that object.
+  
+  Adding a fixed finalizer field would add buffer overhead for those buffers
+  that don't need finalization which is not ideal (but certainly a reasonable
+  approach anyway).
+  
+  Another approach would be to support finalizers only for dynamic buffers: add
+  a flag for "finalizer present" and if the flag is set, store a finalizer
+  pointer in the dynamic data area (before or after actual data).
+  
+  A third approach would be to similarly use dynamic buffers but put the pointer
+  in the duk_hbuffer_dynamic struct (depending on whether or not a finalizer is
+  needed).  However, this would require user to know beforehand when a finalizer
+  is needed because it affects the duk_hbuffer alloc size.
+type: :feature
+component: duk
+release: v1.1
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-06 08:59:55.754356 Z
+references: []
+
+id: 39f8f5bfd85083fe4e3af1bea400cff87127f459
+log_events: 
+- - 2014-10-06 08:59:56.282297 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-49cce34deaa9df3b034e55d5f4a67de9c1ca2c69.yaml

@@ -3,9 +3,9 @@ title: go through FIXMEs in ecmascript-testcases and fix the worst coverage issu
 desc: ""
 type: :task
 component: duk
-release: v1.0
+release: v1.1
 reporter: Sami Vaarala <sami.vaarala@iki.fi>
-status: :in_progress
+status: :unstarted
 disposition: 
 creation_time: 2014-09-01 20:26:21.841131 Z
 references: []
@@ -20,3 +20,7 @@ log_events:
   - Sami Vaarala <sami.vaarala@iki.fi>
   - changed status from unstarted to in_progress
   - ""
+- - 2014-10-07 11:24:50.853508 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - assigned to release v1.1 from v1.0
+  - ""

bugs/issue-7514d4ae323366dd2243d8e8823d70c0063a041f.yaml

@@ -0,0 +1,18 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: windows dllexport / dllimport symbol macros
+desc: Need to use different declspec when compiling Duktape and when compiling an application.
+type: :task
+component: duk
+release: v1.0
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-07 11:14:26.567577 Z
+references: []
+
+id: 7514d4ae323366dd2243d8e8823d70c0063a041f
+log_events: 
+- - 2014-10-07 11:14:26.743566 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-afdd37e32e5abfc07c1ff7bb8c8086c509847979.yaml

@@ -0,0 +1,24 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: document version compatibility expectations
+desc: |-
+  Most important is expectations for a maintained release (like 1.0), such as
+  backporting of fixes (what kind?) and features (what kind?).
+  
+  API change compatibility: outline the basic expectation that APIs will either
+  remain compatible or be removed entirely so that compile fails reliably.  Same
+  for feature options.
+type: :task
+component: duk
+release: v1.0
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-06 21:24:19.887598 Z
+references: []
+
+id: afdd37e32e5abfc07c1ff7bb8c8086c509847979
+log_events: 
+- - 2014-10-06 21:24:20.092617 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-b8d66be953b48a7975b2f12dbc0dd8cdda9103bf.yaml

@@ -0,0 +1,34 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: "platform header possibility: explicit duk_config.h which is built by a config script"
+desc: |-
+  The current model for feature options, compiler detection, etc is that a
+  single header file does all the necessary detection on the fly.  There is
+  no need to change Duktape sources or introduce new headers for this to work.
+  
+  Another model would be to expect a user to provide a ``duk_config.h`` header
+  in their include path.  For major platforms, a config script could generate
+  the duk_config.h.  For other platforms, a copied and manually edited
+  duk_config.h could be used instead.
+  
+  The upside of this would be that all the platform/compiler detection stuff
+  would become external.  Adding new platforms would have no impact on Duktape
+  sources at all.
+  
+  Even with this approach there could be a default duk_config.h which would
+  actually do feature detection for common platforms (Linux, Windows, OSX,
+  mobile phones).
+type: :task
+component: duk
+release: v1.1
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-07 10:32:37.312764 Z
+references: []
+
+id: b8d66be953b48a7975b2f12dbc0dd8cdda9103bf
+log_events: 
+- - 2014-10-07 10:32:37.600706 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-bf5ea58aef8e046806a2c71f1cf7ce301aa9c422.yaml

@@ -0,0 +1,18 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: "unify bitops tests: use shared test values and large matrix type tests for better coverage"
+desc: Add also coercions with side effects to the test value set.
+type: :task
+component: duk
+release: v1.1
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-06 20:39:51.311452 Z
+references: []
+
+id: bf5ea58aef8e046806a2c71f1cf7ce301aa9c422
+log_events: 
+- - 2014-10-06 20:39:51.492438 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""

bugs/issue-f3d60a9ea765a47372cb6ae0dbeb84d9a6d20444.yaml

@@ -0,0 +1,18 @@
+--- !ditz.rubyforge.org,2008-03-06/issue 
+title: "expression evaluation order test case: duktape may differ from standard now (e.g. bitops)"
+desc: ""
+type: :task
+component: duk
+release: v1.1
+reporter: Sami Vaarala <sami.vaarala@iki.fi>
+status: :unstarted
+disposition: 
+creation_time: 2014-10-06 20:32:56.215116 Z
+references: []
+
+id: f3d60a9ea765a47372cb6ae0dbeb84d9a6d20444
+log_events: 
+- - 2014-10-06 20:32:56.412102 Z
+  - Sami Vaarala <sami.vaarala@iki.fi>
+  - created
+  - ""