mirror of https://github.com/svaarala/duktape.git
Sami Vaarala
10 years ago
19 changed files with 261 additions and 11 deletions
@ -0,0 +1,18 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: "compiler/executor: atomic inc/dec primitive to avoid multiple opcodes used now" |
|||
desc: "" |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-21 15:04:42.578272 Z |
|||
references: [] |
|||
|
|||
id: 3078863bb06ec9af3c2ec4d0f7bf66a741473f9d |
|||
log_events: |
|||
- - 2014-08-21 15:04:42.770186 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,25 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: move testcase knownissue status to an external file? |
|||
desc: |- |
|||
The known issue status of a test case changes when bugs are fixed and introduced, |
|||
and it's tedious diff on the test case itself. The other test case metadata is |
|||
more static; e.g. if a testcase tests for non-standard real world behavior, that |
|||
fact doesn't change often. |
|||
|
|||
A single knownissues file would be more easier to maintain and would also provide |
|||
a more concise description of still open issues. |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-21 21:56:21.233924 Z |
|||
references: [] |
|||
|
|||
id: 3d4480f1a7cb079085bf84e256fae778ba180988 |
|||
log_events: |
|||
- - 2014-08-21 21:56:21.422913 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,18 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: "softint: add softint marker to Duktape.env" |
|||
desc: E.g. 'i' after duk_tval packing indicator. |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-22 08:41:28.746188 Z |
|||
references: [] |
|||
|
|||
id: 68a5328a4af21b48d912d366a5b043e01d5c3c2b |
|||
log_events: |
|||
- - 2014-08-22 08:41:28.906128 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,33 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: "softint: enable if soft fp in use" |
|||
desc: |- |
|||
Enable FASTINT support automatically when soft floating points are in use |
|||
and other requirements are met. |
|||
|
|||
Soft FP usage can be detected e.g. with __SOFTFP__ on GCC. It's critical |
|||
to detect that actual soft FP library calls are being generated by the |
|||
compiler - not that soft floats are supported, or that a soft float ABI is |
|||
being used. |
|||
|
|||
The user should then have two defines to force FASTINT one way or another: |
|||
|
|||
* DUK_OPT_FASTINT48: force fastint into use |
|||
|
|||
* DUK_OPT_NO_FASTINT48: disable fastints forcibly |
|||
|
|||
Both yes/no flags are needed if Duktape defaults based on the environment. |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-22 08:41:06.842133 Z |
|||
references: [] |
|||
|
|||
id: 74f1c80ef1dc38fd26bec23122bc70526a66b8c0 |
|||
log_events: |
|||
- - 2014-08-22 08:41:07.258009 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,18 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: "executor/compiler: make TONUM an inplace operation (it is always used that way now)" |
|||
desc: "" |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-21 15:24:27.567694 Z |
|||
references: [] |
|||
|
|||
id: 9fb59099fc344a02efcdbf5095a2d1c18a6f74ab |
|||
log_events: |
|||
- - 2014-08-21 15:24:27.871636 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,21 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: add internal structures to duktape.h to facilitate better footprint optimization |
|||
desc: |- |
|||
The macros implementing public Duktape API calls should have access to |
|||
the internal structures so that they can read/write internal values and |
|||
flags directly without going through an actual helper call. |
|||
type: :task |
|||
component: duk |
|||
release: v1.1 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-20 10:10:54.385283 Z |
|||
references: [] |
|||
|
|||
id: a272462323504bffd23ed7462fa409928f40472e |
|||
log_events: |
|||
- - 2014-08-20 10:10:54.606249 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,29 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: optimized 'iswhole' primitive |
|||
desc: |- |
|||
To support the FASTINT branch, there needs to be an optimized primitive |
|||
for checking whether a number is a whole number which be represented with |
|||
N bits (e.g. signed 48 bits). |
|||
|
|||
For the FASTINT branch, a quick reject is not useful, as numbers are |
|||
usually expected to be integers. A quick accept is useful if that is at |
|||
all possible. |
|||
|
|||
In any case, the DUK_SET_TVAL_NUMBER() handler should have a fast inlined |
|||
version because the check is made by default for all numbers where FASTINT |
|||
fast paths are not explicitly implemented. |
|||
type: :task |
|||
component: duk |
|||
release: |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-20 10:10:02.391046 Z |
|||
references: [] |
|||
|
|||
id: a862974a855fd448d5650559a1194c50d087bad9 |
|||
log_events: |
|||
- - 2014-08-20 10:10:02.748091 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
@ -0,0 +1,44 @@ |
|||
--- !ditz.rubyforge.org,2008-03-06/issue |
|||
title: mark-and-sweep _finalizer access error causes uncaught error |
|||
desc: |- |
|||
If _finalizer access fails with error due to prototype loop or perhaps |
|||
because a devious user has set it to an accessor value, mark-and-sweep |
|||
and/or reference counting can now throw an uncaught error during GC |
|||
handling (which is quite fatal). |
|||
|
|||
Finalizer checks should tolerate _finalizer lookup errors and assume |
|||
there is no finalizer if the property cannot be read? |
|||
type: :bugfix |
|||
component: duk |
|||
release: v0.12 |
|||
reporter: Sami Vaarala <sami.vaarala@iki.fi> |
|||
status: :unstarted |
|||
disposition: |
|||
creation_time: 2014-08-20 10:49:54.364530 Z |
|||
references: [] |
|||
|
|||
id: c5f6b9485d7e2e7359ed7a01b631784ec32ae0d4 |
|||
log_events: |
|||
- - 2014-08-20 10:49:54.567675 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- created |
|||
- "" |
|||
- - 2014-08-20 11:00:59.838404 Z |
|||
- Sami Vaarala <sami.vaarala@iki.fi> |
|||
- commented |
|||
- |- |
|||
The culprit seems to be a duk_hobject_hasprop_raw() check inside mark-and-sweep. |
|||
This wouldn't throw an error for an accessor (which is as intended) but does |
|||
throw for a prototype loop. |
|||
|
|||
Possible fixes: |
|||
|
|||
* Put the duk_hobject_hasprop_raw() check inside a duk_safe_call(). This is |
|||
quite expensive as 99% objects don't have a finalizer. |
|||
|
|||
* Add a variant of duk_hobject_hasprop_raw() (or a flag) which will check for |
|||
property existence but never throws an error - if prototype loop occurs, |
|||
pretend that the property doesn't exist. |
|||
|
|||
* Deny prototype loops also for C code. This means a prototype walk when the |
|||
prototype is set, which is more expensive than ideal. |
|||
Loading…
Reference in new issue