So I've been playing around with Neo4j recently and to my surprise I figured it is possible to set label, node or relationship name to Keyword (MATCH,CREATE,ORDER ... ). I am aware that this is very bad practice.
CREATE (s:CREATE{CREATE: "something"}) RETURN s
But my question is: "Does this result only in less transparet queries or are there consequently any possible errors? If errors could occur, why is it even allowed?"
I know it is a silly question, but nowhere in the neo4j docs I have not found the answer.
I believe the syntax tree is such that the parser shouldn't ever be confused by whether it's evaluating a keyword, label, property, or some other piece.
I don't believe we've seen any issues related to this, at least from versions 3.0 and up (I wasn't around in the pre-3.0 days).
Related
The question Stack overflow despite tail call position but only in 64-bit lead to uncovering a bug in the F# compiler.
After reading the answer I am curious as to the reasoning that lead to finding the bug as I would like to better improve my skills at resolving problems and understanding TCO.
My reasoning was something like this:
Talking about "tail calls" when looking at a computation expression can be misleading - in general there really isn't such a thing (see e.g. this other answer for one related discussion, though not related to sequence expressions).
So calling gauss will not itself ever overflow the stack, only the code iterating through it could make it overflow. But once I saw that the calling code was just something like Seq.nth, that meant that there was almost certainly a compiler bug, because the pattern of "tail yield!ing" in a sequence expression is supposed to get optimized (not sure if this is part of the spec, but I think it's fairly well known). So then it was just a case of seeing what parts of the initial repro were necessary.
Replacing loop in the original code with a non-recursive definition made the repro stop failing, as did removing the pattern match. I didn't find looking at the IL helpful (there's so much compiler-generated machinery involved in the compilation of sequence expressions), I just tried minimizing the repro at the source level and empirically testing the behavior.
Our goal is to write case insensitive collation for SQLite database. We did this for multiple platforms, but iOS seems to have consistent problems which (occasionally) manifest in corrupted DB indexes. After long experiments we concluded that the culprit is CFStringCompare() function, which violates theoretical rules.
Acc. to the theory the comparison function must be reflexive, symmtric and transitive.
What we did was to generate random strings and test whether CFStringCompare() fulfills above properties.
Here is a sample problem:
CFStringCompare with flags NSCaseInsensitiveSearch|NSDiacriticInsensitiveSearch yielded:
"Я7;1FC9" > "SДA`\"0l"
"SДA`\"0l" > "Я7;1FC9"
In other words A>B at the same time when B>A!
We tested more flag combinations:
kCFCompareNonliteral showed similar problems
kCFCompareLocalized prove to be the worst option (most problems)
Does anybody know about a safe way to realize case insensitive comparison under iOS?
Ok, no reply, so I'll try to reply myself.
First of all, the other people observed similar problems, for example this link. Note that we also observed a lot of problems with German ß. I selected another example by chance.
This should be enough to say that CFStringCompare has buggy implementation and cannot be used for sorting.
On the other hand there is ICU library and they declare full compliance to UCA (for example here), which in turn should obey all theoretical rules.
So my answer would be: CFStringCompare is buggy, use ICU.
(I hoped in another answer because of the huge size of the ICU library)
I'm trying to make z3 (I'm using z3py) to simplify some formulas for me (so that I can have more or less human-readable output). Using ctx-solver-simplify tactic seemed a good choice for me since in a couple of passes it would produce nice compact formulas. But soon I've run into a situation when the output of ctx-solver-simplify does not seem to be equivalent to the original formula (it looks more like being satisfiability-equivalent or so). Also, it might be the case that I'm not dealing with tactics correctly.
Here's what I was trying to do: http://rise4fun.com/Z3Py/g5sX. So, I construct a formula Set2 (everything before the definition of Set2 is just a setup needed to define it) which has a particular satisfying assignment. After applying ctx-solver-simplify, I get a single formula (as a goal) for which this assignment is not satisfying. So what am I dong wrong?
Am I wrong assuming that ctx-solver-simplify would produce an equivalent formula?
Am I handling the tactics and their output in the wrong way?
Anything else?
Thanks.
I have been looking into this, but have so far been unable to reproduce the bug directly
with our current branch. A bug in the context simplifier was fixed a little while ago, and it could
be manifesting itself with the online version of Z3.
There are still a few things I can do to double check if we can reproduce the bug
and I will update this post with what I find.
I've recently been receiving a lot of first name only entries in a form. While maybe I should have had 2 separate first and last name fields this always seemed to me a bit much. But I would like to try and get a full name which basically can only be determined by having at least one space.
I came up with this, but I'm wondering if someone has a better and possibly simpler solution?
/([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,}) ([a-zA-ZàáâäãåèéêëìíîïòóôöõøùúûüÿýñçčšžÀÁÂÄÃÅÈÉÊËÌÍÎÏÒÓÔÖÕØÙÚÛÜŸÝÑßÇŒÆČŠŽ∂ð,.'-]{2,})/
This is basically this /([a-zA-Z,.'-]) ([a-zA-Z,.'-])/ plus unicode support.
I'd first make sure that you really do need people to give you a last name. Is that a genuine requirement? If not, I'd skip it because it adds unnecessary complication and barriers to entry. If it really IS a requirement, it probably makes sense to have separate first and last name fields in your UI so that it's explicit.
The fact that you didn't do that to begin with suggests that you might not really need the last name as much as you think you do.
To answer your original question, this expression might give you what you're looking for without the guesswork:
/[\w]+([\s]+[\w]+){1}+/
It checks that the string contains at least 2 words separated by whitespace. Like Tim Pietzcker pointed out, validating the words themselves is prone to error.
In Ruby 1.9, you have access to Unicode properties (\p{L} is a Unicode letter). But trying to validate a name in any way (regex or not) is prone to failure because names are not what you think they are.
Your theory that "if there's a space, there must be a last name there" is incorrect, too - think of first and middle names...
I.e, if I have a record
-record(one, {frag, left}).
Is record_info(fields, one) going to always return [frag,
left]?
Is tl(tuple_to_list(#one{frag = "Frag", left = "Left"}))
always gonna be ["Frag", "Left"]?
Is this an implementation detail?
Thanks a lot!
The short answer is: yes, as of this writing it will work. The better answer is: it may not work that way in the future, and the nature of the question concerns me.
It's safe to use record_info/2, although relying on the order may be risky and frankly I can't think of a situation where doing so makes sense which implies that you are solving a problem the wrong way. Can you share more details about what exactly you are trying to accomplish so we can help you choose a better method? It could be that simple pattern matching is all you need.
As for the example with tuple_to_list/1, I'll quote from "Erlang Programming" by Cesarini and Thompson:
"... whatever you do, never, ever use the tuple representations of records in your programs. If you do, the authors of this book will disown you and deny any involvement in helping you learn Erlang."
There are several good reasons why, including:
Your code will become brittle - if you later change the number of fields or their order, your code will break.
There is no guarantee that the internal representation of records will continue to work this way in future versions of erlang.
Yes, order is always the same because records represented by tuples for which order is an essential property. Look also on my other answer about records with examples: Syntax Error while accessing a field in a record
Yes, in both cases Erlang will retain the 'original' order. And yes it's implementation as it's not specifically addressed in the function spec or documentation, though it's a pretty safe bet it will stay like that.