Trying to set a relation between two entities.
Investigating with phpmyadmin showed no link between their tables.
/*
* #ORM\OneToOne(targetEntity="Otherentity")
*/
private $otherentity;
instead of:
/**
* #ORM\OneToOne(targetEntity="Otherentity")
*/
private $otherentity;
Even checking the coding standards did not helped me.
Answer found: typo in the comment structure itself.
After searching in dozens of loosely related topics and tutos, I had to copy-paste existing relations and replace-in-place word after word... to find that the /** is mandatory as it is.
And easily mistaken for /*. And no warning anywhere.
Hope that helps anyone (at least myself, when it will happen again in several years).
Related
I have built a gensim Doc2vec model. Let's call it doc2vec. Now I want to find the most relevant words to a given document according to my doc2vec model.
For example, I have a document about "java" with the tag "doc_about_java". When I ask for similar documents, I get documents about other programming languages and topics related to java. So my document model works well.
Now I want to find the most relevant words to "doc_about_java".
I follow the solution from the closed question How to find most similar terms/words of a document in doc2vec? and it gives me seemingly random words, the word "java" is not even among the first 100 similar words:
docvec = doc2vec.docvecs['doc_about_java']
print doc2vec.most_similar(positive=[docvec], topn=100)
I also tried like this:
print doc2vec.wv.similar_by_vector(doc2vec["doc_about_java"])
but it didn't change anything. How can I find the most similar words to a given document?
Not all Doc2Vec modes even train word-vectors. In particular, the PV-DBOW mode dm=0, which often works very well for doc-vector comparisons, leaves word-vectors at randomly-assigned (and unused) positions.
So that may explain why the results of your initial attempt to get a list-of-related-words seem random.
To get word-vectors, you'd need to use PV-DM mode (dm=1), or add optional concurrent word-vector training to PV-DBOW (dm=0, dbow_words=1).
(If this isn't the issue, there maybe other problems in your training setup, so you should show more detail about your data source, size, and code.)
(Separately, your alternate attempt code-line, by using doc2vec["doc_about_java"] is retrieving a word-vector for "doc_about_java" (which may not be present at all). To get the doc-vector, use doc2vec.docvecs["doc_about_java"], as in your first code block.)
Good Afternoon,
I have exhausted my googling and best-guess ideas, so I hope someone here has an idea of whether this is possible or not.
I am using Exchange Server 2010 (vanilla) in a test environment and trying to create a Hub Transport Rule using the Exchange Management Console. The requirements of the rules filtering are similar to the following scenario:
1.) If a recipient's address matches (ends with) "#testdomain.com" AND (begins with) "john"
2.) If the sender's address matches (ends with) "#testdomain.com"
3.) Copy the message to the "SupervisorOfJohns#testdomain.com" mailbox
I have no problems doing items 2 and 3, but I cannot figure out how to get item 1 in the same condition. I have come across some threads that simply concluded that MS goofed on this, but I am hesitant to fault them for something which seems like it should be really straightforward. I must be missing something. Expressions I have tried so far...:
1.) (^john)(#testdomain.com$)
2.) ^(john)(#testdomain.com)$
3.) (^john)#testdomain.com
4.) ^john #testdomain.com$
5.) ^(john)#testdomain.com
If you use the interface and +Add them as two separate entries, it treats them as an OR clause (if a recipient address begins with "john", OR it ends with "#testdomain.com"). As you can see from my simplistic attempts, I have barely any clue what can/should work in this case. Any suggestions or ideas would be appreciated.
Respectfully,
B. Whitman
Here's what I ended up using:
john\w*#testdomain.com
The reasoning behind the question is that I'm trying to make a service to catch certain e-mails and do some processing with them. I also wanted to restrict the senders/recipients to certain domains (though some checking will also be done with the processing service). Thanks to hjpotter92 for his solutions!
when i read through source files of opensource projects i often come across some weird phrases in the comments
/*
#brief ......
#usage.....
#remarks....
#par....
*/
questions
1.What are they?(were not mentioned when i was learning c++)
2.Do they have any documentation(where)
They are just comments and as such have no special meaning in C++. They are probably to allow a documentation generator (For example Doxygen) to extract the data from the comments.
Those are for some flavour of automatic documentation generator. Another program runs through the code looking for comments of like you see there. The #... keywords identify how the documentation should be laid out, and that program generates pretty HTML or printed documentation directly from the source code. It's a way to keep the docs up-to-date with the code more easily.
I have a fairly long cfc file, about 1800 lines long, that worked fine in ColdFusion 8, but after upgrading my development system to ColdFusion 9 and doing some testing I get a compile error for a cfc and the message says "Branch target offset too large for short". I modified the file to eliminate some unused functions and consolidated one to make it shorter and this resolved the problem to get it to work. But still, why did it die on me now when I upgraded to CF9? Anyone else run into this problem in previous or the current version of ColdFusion? Are there any solutions other than modifying the cfc file such as upgrading the jvm?
EDIT
If you have an answer to the questions I have, great! Post that, but don't waste time telling me something that I already know. If you are going to post a response, please read the question carefully and answer only if you know the answer. Don't do a google search and post crap that I already know and utilized to get the code to work. The question is, why did it work in CF8 and now not in CF9? Are there other solutions besides what I did?
This is a problem inherent with the JVM as you already know, CF9 has likely added more innate functions to a component and if the methods are all referenced via a giant switch statement with a short being used as the offset, we have less offset pointer space to work with each successive version. People moving from CF7 to CF8 also had the same problems.
So short answer is no.
Most recommendations you find basically tell you to split a large method into a smaller method and several helper methods. The first time I ran into an issue this worked for a large cfc I had. But then as it got bigger no number of helper functions would fix it. Eventually it had to be split into multiple cfcs.
PS: This guy said removing a transaction helped (CF7), there are none wrapping my calls though, so it's not a guaranteed fix I guess http://www.coldfusionmuse.com/index.cfm/2007/9/28/Branch.Target.Offset
Edit
Looks like my previous issue was a different function being too large, splitting the CFC into multiple CFCs was in error. I've since split that problem method into smaller methods, and have been able to consolidate all the functions in one CFC. So that is the solution it seems.
If you haven't already, try running the Code Analyzer in the CFAdmin page, "Debugging & Logging > Code Analyzer". This is a useful tool to find some changes which were made in the language between CF8 and CF9.
We had to change several variable names and function names as CF added them in 9.
Also check here:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7ff0.html
CF version: 10
OS: Linux CentOS 6.0
Did face a similar issue where I had 1300+ lines of code in my cfc and one fine day I get the "Branch Target offset.." error. I tried
Code Analyser to find any loopholes of legacy- DID NOT FIX
Edited the cfc to trim down any last bit of redundant code or comments - reduced around 20+ lines of code - DID NOT FIX
I split the code into 2 cfc and extended one to the other- DID NOT FIX
I removed any unwanted dump of queries and arrays (part of testing) : THIS WORKED
so I would suggest ensure you don't have any dumps of large data content. Hope this helps.
It seems to by my nightmare for the last 4 weeks,
I can't come up with a solution for a "related posts" app in django/python in which it takes the users input and comes out with a related post that matches closely with the original input. I've tried using like statements but it seems that they are not sensitive enough.
Such as which i need typos to also be taken into consideration.
is there a library that could save me from all my pain and suffering?
Well, I suppose there are a few different ways to normalize the user input to produce desirable results (although I'm not sure to what extent libraries exist for them). One of the easiest ways to get related posts would be to compare the tags present on that post (granted your posts have tags). If you wanted to go another route, I would take the following steps: remove stop words from the subject, use some kind of stemmer on the remainder, and finally treat the remaining words as "tags" to compare with other posts. For the sake of efficiency, it would probably be a good idea to run these steps in a batch process on all of your current posts and store off the resulting "tags." As far as typos, I'm sure there are a multitude of spelling corrector libraries exist (I found this one after a few seconds with Google).