Without using any non-deafult switches (i.e. no --harmony), are there language features, global properties, etc. that exist in V8 (at 69a0664) but not in JSC (at f27bfeb) and vice versa?
I'm doing Android/iOS work and want to make sure the same scripts will work on both.
In terms of ECMAScript 5 features, going by this table, both have attempted to implement everything.
test262 failures for Mobile Safari (iOS 6.1.3):
10.4.2_1.1 eval within global execution context
10.4.2_1.2 eval within global execution context
15.5.4.9_3 Tests that String.prototype.localeCompare treats a missing "that" argument, undefined and "undefined" as equivalent
15.5.4.9_CE Tests that String.prototype.localeCompare returns 0 when comparing Strings that are considered canonically equivalent by the Unicode standard.
15.9.3.1_5 multi-argument Date construction
test262 failures for Chrome 28:
11.2.3-3_3 Call arguments are not evaluated before the check is made to see if the object is actually callable (undefined member)
15.5.4.9_6 Checking String.prototype.localeCompare.prototype
15.5.4.9_7 Checking if creating the String.prototype.localeCompare object fails
15.8.2.8_6 Checking if Math.exp is approximately equals to its mathematical values on the set of 64 argument values; all the sample values is calculated with LibC
15.9.3.1_5 multi-argument Date construction
Caveat: these aren't necessarily the corresponding versions, but are just what I have to hand.
Related
In Android, we can use HIDL data types in lieu of normal C++ data types. Their functionality remains mostly the same, and this proxy code is for behind-the-scenes serialization and IPC which HIDL takes care of.
Now when I try to check if a HIDL vector is empty, I get the error that empty is not a member of hidl_vec. How then can I check this? Some other functions that work on a normal vector work with hidl_vec such as foo.size(), foo.begin(), foo.end() but I prefer to not use the size check for this reason.
#include "gmock/gmock.h"
using ::android::hardware::hidl_vec;
using ::android::hardware::hidl_string;
hidl_vec<hidl_string> foo;
ASSERT_FALSE(foo.empty());
Throws the error:
error: no member named 'empty' in 'android::hardware::hidl_vecandroid::hardware::hidl_string'
ASSERT_FALSE(foo.empty());
I am deploying my tf model to android, and I just want to ask what are considered as 'const op' in tf? Also, if your going to save you variables into a checkpoint and be saved into an optimized file that will be used in an android app, should you explicitly name all of them? Or does tf automatically assigns a name for all the variables?
What is 'Const Op' in Tensorflow?
This is an op that manages constants created with tf.constant (or similar function in another language). Basically, it's just a constant tensor.
Or does tf automatically assigns a name for all the variables?
Tensorflow automatically gives names to the variables, but you should better give the names to those variables that you care about to find them easily later on. Automatic names can be sometimes cryptic and misleading. For instance, gru_def/rnn/gru_cell/gates/kernel is one of the variables inside a GRU cell and most of the scopes are defined with the library, not in your code.
Or, you might see Placeholder_1 and think that this is the first placeholder in your model, but it would be wrong, because the true first placeholder is Placeholder, while Placeholder_1 is the second one (in fact, that was a real bug).
I am running some unit tests using GTest/GMock on Android. I have noticed that it ignores my argument of --gtest_filter=MyTestCase.MyTest - all of my tests run no matter what I put in the filter. I've made sure that it gets passed in to InitGoogleMock.
Has anyone managed to use --gtest_filter when running their tests on Android?
Mystery solved, --gtest_filter was my first argument, but GTest parses arguments from index 1 rather than 0, as argument 0 is expected to be the executable name in unix land :).
In dex code (e.g., as produced by the dexdump tool), for each method definition I see "ins" and "outs" in addition to other metadata such as "registers", "insns size".
I am instrumenting dex code to introduce new registers. The instrumentation is failing, and I suspect that I may have to change the "ins" and "outs" values based on the number of new registers I add.
So my question is: What do those "ins" and "outs" represent?
(fyi: I am using dexlib2 for this.)
These fields are documented at http://source.android.com/devices/tech/dalvik/dex-format.html.
ins_size | the number of words of incoming arguments to the method that this code is for
outs_size | the number of words of outgoing argument space required by this code for method invocation
ins_size is mostly self-explanatory - it's the number of 32-bit words required to store the method arguments (including the implicit "this" argument, for non-static methods). All arguments require 1 "word" except longs (J) and doubles (D), which require 2 words.
outs_size basically the opposite. outs_size must be set large enough to hold the arguments for any method call that occurs within the method.
If you want to instrument a dex file without having to worry about details like this, you might consider using dexlib2 (the library developed for and used by smali/baksmali to read/write dex files). The library is available in the maven repository, so it's easy to link against if you're using gradle/mvn.
I am writing my first Android application and I am liberally using asserts() from junit.framework.Assert
I would like to find a way to ensure that the asserts are only compiled into the debug build, not in the release build.
I know how to query the android:debuggable attribute from the manifest so I could create a variable and accomplish this in the following fashon:
static final boolean mDebug = ...
if (mDebug)
Assert.assertNotNull(view);
Is there a better way to do this? i.e. I would prefer not to use an if() with each assert.
thanks
I think the Java language's assert keyword is likely what you want. Under the covers, the assert keyword essentially compiles into Dalvik byte code that does two things:
Checks whether the static variable assertionsDisabled (set in the class' static constructor via a call to java.lang.Class.desiredAssertionStatus()) is != 0 and if so, does nothing
If it is 0, then it checks the assertion expression and throws a java.lang.AssertionError if the expression resolves to false, effectively terminating your application.
The Dalvik runtime by default has assertions turned off, and therefore desiredAssertionStatus always returns 1 (or more precisely, some non-zero value). This is akin to running in "retail" mode. In order to turn on "debug" mode, you can run the following command against the emulator or the device:
adb shell setprop debug.assert 1
and this should do the trick (should work on the emulator or any rooted debugging-ready device).
Note however that the aforementioned Dalvik code that checks the value of assertionsDisabled and throws an AssertionError if the expression is false is always included in your byte code and liberal sprinkling of asserts in your code may lead to byte code bloat.
Please see this for a bit more detail: Can I use assert on Android devices?
If you're concerned about shipping code with the JUnit asserts in (or any other class path), you can use the ProGuard config option 'assumenosideeffects', which will strip out a class path on the assumption that removing it does nothing to the code.
Eg.
-assumenosideeffects class junit.framework.Assert {
*;
}
I have a common debug library I put all my testing methods in, and then use this option to strip it from my released apps.
This also removes the hard to spot problem of strings being manipulated that are never used in release code. For example if you write a debug log method, and in that method you check for debug mode before logging the string, you are still constructing the string, allocating memory, calling the method, but then opting to do nothing. Stripping the class out then removes the calls entirely, meaning as long as your string is constructed inside the method call, it goes away as well.
Make sure it is genuinely safe to just strip the lines out however, as it is done with no checking on ProGuard's part. Removing any void returning method will be fine, however if you are taking any return values from whatever you are removing, make sure you aren't using them for actual operational logic.
I mean if you were using a language feature, like assert(), the compiler should be able to strip that out. But this is an actual class and if a class is referenced by executable code it will be included or assumed included in the final product by the compiler.
However there is nothing stopping you from creating a script that removes all the references to the Assert class in all of your code base before compilation.
Another approach would be to make a test project that targets your application and within JUnit tests actually calls the Assert on the areas which you want to make sure work. I personally like this approach because it is a nice and clean separation of test and application.
If you are just worried about the having an if-statement everywhere, then just wrap Assert with your own class, DebuggableAssert which does that check before each call to Assert.X. It will be sort of less performant because of the method entry/exit and the conditionals but if you can maintain your code better then it might be worth it.