This question represents a proposed bug for Globalize. The owners of that project ask that it first be published as a SO question, so here we go...
With the new version 1.2.1 (and 1.2.2) of Globalize we're noticing that number-parsing an empty string returns 0 (seemingly independent of culture). This behavior is different to the previous version 1.1.2, where it returned NaN. Reproduction:
var g = new Globalize("en-US");
g.numberParser()(''); // returns 0 in v1.2.1 and NaN in v1.1.2.
Intuition tells me that parsing an empty string should not return 0. Vanilla JavaScript parse functions (e.g. parseInt) return NaN in such cases, supporting this intuition.
Furthermore, the relevant unit test in the Globalize project does not seem to cover this case, so it's unclear whether or not the changed behavior is intended. From a brief look at the changelog of the 1.2.* releases I can't seem to find any note of an intention to change this behavior.
Note that parsing whitespace in the new version does indeed return NaN:
var g = new Globalize("en-US");
g.numberParser()(' '); // returns NaN in both v1.2.1 and v1.1.2.
We're hoping that one of the project members will either confirm that this is a bug and raise a corresponding issue in the Globalize project, or explain why this is now expected behavior.
It's a bug, thanks for reporting, will be tracked in https://github.com/globalizejs/globalize/issues/682
Related
I get a parse error with an AQL query that includes a numeric literal with a value 'x' where
-1 < x < 1 and x != 0, and where the leading zero is omitted, such as x < .5 or x > -.2.
I think this may be a bug, but the documentation doesn't clearly state whether a leading zero is required or not (seems odd that it would be required).
I'm only running version 3.4 rc4, so I can't verify if this behavior is present with any officially released versions. Can someone confirm? Or are there any ArangoDB devs on here that care to comment?
Thanks!
AQL does not support floating point number literals without leading digit.
The documentation shows examples of supported notations, and one like .5 is not among them.
If you want to propose this as feature, create an issue on GitHub.
You can find the code that defines the language tokens for numbers here:
https://github.com/arangodb/arangodb/blob/devel/arangod/Aql/tokens.ll#L447
(0|[1-9][0-9]*) {
/* a numeric integer value */
...
(0|[1-9][0-9]*)((\.[0-9]+)?([eE][\-\+]?[0-9]+)?) {
/* a numeric double value */
As can be seen from these regular expressions, literals like 00 and 00.123 are not supported either - there must not be more than one leading 0 in the integer part.
Ran this in 3.3.19 and runs fine:
let tmp = [0.2,3,4,0.5]
for t in tmp
filter t > 0.5
return t
This throws a parsing error
let tmp = [0.2,3,4,0.5]
for t in tmp
filter t > .5
return t
So, I would think it is safe to say that the 0 is mandatory
Update
We recently merged a pull request into the devel branch of ArangoDB that adds support for fractional numbers without leading zeros to AQL. This is available in the ArangoDB development version from next build onwards, but not available in any release yet. So far, target release would be 3.5.
If there is popular demand for the feature, it should be easy to backport the pull request to ArangoDB 3.4 as well.
In a let block, I sometimes see ^let annotations before my statements, and it's not clear to me what they mean or why they are there.
Is it to indicate that a value will be returned as the value of the let call?
Screenshot:
These do in fact show you that those values are going to be returned from the let expression. If you move to cursor to one of these hints and open intention actions (Alt + Enter), you get the option "Do not show lambda return expression hints", which I suppose is the name for this new feature.
This change was introduced in Kotlin 1.2.20, see IntelliJ IDEA Plugin Improvements in this post.
Your screenshot demonstrates two new IDE features that were introduced with Kotlin Plugin 1.2.20:
KT 20533 Show "this" and "it" type hints in lambdas.
KT-20067 Return label hints
Here’s the description of KT-20066 that’s related to the question:
Returns from lambdas can be confusing, especially when lambdas are nested or crossinline. It is often difficult to determine the lambda's return type and where a block is returning to, which may cause subtle compilation errors or runtime bugs. One solution is to always use explicit labeled returns and type signatures, however this can add extra noise to the source code. One suggestion for improving readability is to use IDE hinting (like in parameter hints), for lambda returns in Kotlin.
I have code like that:
def a1 = [[1],[2],[3]]
def a2 = [[2],[3],[4]]
a1.intersect(a2)
and as result got:
[]
After some time of research i found out that elements of lists must be instance of Comparable. In DefaultGroovyMethods we can see implementation of intersect method. First thing i noted was the collection (TreeSet) used for checking existence of objects in one of our lists (btw. if HashSet used it worked fine).
I checked the NumberAwareComparator there are two options for checking in compareTo method. The first is the delegation of comparison to another class (eaten exception ?!) and the second is hashCode checking.
The first option DefaultTypeTransformation explained us the behavior.
We can see that only allowed object to be compare are Comparable in other case we got exception eaten later.
My question is why is it like that? There is lack of information in documentation (or am i wrong?) about it. Did i missed something?
Can't find it documented.
Feels like a great pull request contribution to the project on github with a change to the existing documentation/javadoc to make this more explicit?
The elements have to be comparable, as otherwise you can't compare them to check for an intersection, but you're right the documentation isn't explicit.
You could write your own implementation like so:
Collection.metaClass.equalityIntersect = { Collection other ->
delegate.findAll { a -> other.find { it == a } }
}
So that a1.equalityIntersect(a2) == [[2], [3]]
This behavior has been introduced somewhere down the line - haven't pin-pointed it, maybe 2.4.2 or 2.4.2 as per this commit. It used to work in 2.2.1 and 2.4.0 and is broken on 2.4.6... but it's fixed in 2.4.7.
$ groovy -v
Groovy Version: 2.4.7 JVM: 1.8.0_92 Vendor: Oracle Corporation OS: Mac OS X
$ groovy intersect.groovy
[[2], [3]]
How can such breaking change roll out to a release is a mystery to me. Lack of testing?
I tried the following snippet of Alloy4, and found myself confused by the behavior of the util/Natural module. The comments explain more in detail what was unexpected. I was hoping someone could explain why this happens.
module weirdNatural
private open util/natural as nat
//Somehow, using number two obtained from incrementing one works as I expect, (ie, there is no
//number greater than it in {0,1,2}. but using number two obtained from the natrual/add function
//seems to work differently. why is that?
let twoViaAdd = nat/add[nat/One, nat/One]
let twoViaInc = nat/inc[nat/One]
pred biggerAdd {
some x: nat/Natural | nat/gt[x, twoViaAdd]
}
pred biggerInc {
some y: nat/Natural | nat/gt[y, twoViaInc]
}
//run biggerAdd for 10 but 3 Natural //does not work well, it does find a number gt2 in {0,1,2}
run biggerInc for 10 but 3 Natural //works as expected, it finds a number gt2 in {0,1,2,3}, but not in {0,1,2}
Thanks for this bug report. You are absolutely right, that is a weird behavior.
Alloy4.2 introduced some changes to how integers are handled; namely, the + and - operators in Alloy4.2 are always interpreted as set union/difference, so built-in functions plus/minus have to be used to express arithmetic addition/subtraction. On the other side, the util/natural module (mistakenly) hasn't been updated to use the latest syntax, which was the root cause of the weird behavior you experienced (specifically, the nat/add function uses the old + operator instead of plus, whereas nat/inc doesn't).
To work around this issue, you can either
open the util/natural module (choose "File -> Open Sample Models" from the main menu)
edit the file and replace the two occurrences of <a> + <b> with plus[<a>, <b>]
save the new file in the same folder with your model als file (e.g., as "my_nat.als")
open it from your main module (e.g., open my_nat as nat)
or
download the latest unofficial version where this bug is fixed (you might need to manually delete the Alloy temp folder to make sure that the Alloy Analyzer is not using the old (cached) version of the util/natural library).
I have date string return by ServiceStack : 2013-08-25T12:06:32.8770000 but error when convert to date of Dart
DateTime.parse(mapAccount[Account.RECCREATED]);
it ok when call
DateTime.parse((mapAccount[Account.RECCREATED] as String).substring(0, 26));
Is there anyway to fix it. Thanks you.
Looks like the string don't match the internally used regular expression:
r'^([+-]?\d?\d\d\d\d)-?(\d\d)-?(\d\d)(?:[ T](\d\d)(?::?(\d\d)(?::?(\d\d)(.\d{1,6})?)?)? ?([zZ])?)?$'
But the regular expression doesn't support more that 6 digits for the milliseconds (and microseconds) part, but you supply 7 digits.
The documentation does not state which formats are supported, but gives some examples. They only state that they support a subset of ISO 8601.
Looks like your solution is the only one a the moment.
Not sure if this should be treaded as a bug, but if you think it is a bug, create a bug report here.
See the docs about DateTime.parse for more details. Looks like the problems with the parse function is already in the bug tracker.