just wondering what does the following command means? so hard to google topics related to pig:
pig -Dpig.usenewlogicalplan=false
i ran the pig script in map/reduce mode, it failed, by adding that flag(-D), it worked, but still have some issue. so what does it mean anyways? Thanks.
The larger problem is described here: PIG-1731
It looks like a work around is for you to break your FILTERs out onto multiple lines.
Pig 0.8.0 introduced some bugs in the logical optimizer. The -Dpig.usenewlogicalplan=false option forces a fallback to the earlier version. Alternatively upgrading to 0.8.1+ should also solve the problem.
Kindly see this for more information
https://books.google.com/books?id=RG-v6qUktSYC&pg=PA96&lpg=PA96&dq=pig.usenewlogicalplan&source=bl&ots=tRH-GSTEkD&sig=z76hSCS036JqQT26zM9lKrXjx-s&hl=en&sa=X&ved=0CD8Q6AEwA2oVChMIrfj2h-DXyAIVBs5jCh3vTQ7z#v=onepage&q=pig.usenewlogicalplan&f=false
https://cwiki.apache.org/confluence/display/PIG/Pig+0.9+Backward+Compatibility
Related
Is tf.py_func allowed at online prediction time?
If yes any examples of how to use it?
Does the answer change if I need to install additional pip packages?
My use-case: I work with text, I need to do word stemming (using porter stemmer), I know how to do it using python, tensorflow doesn't have Ops for that. I would like to use the same text processing at training and prediction time - thus I would like to encode it all into a tensorflow graph.
https://www.tensorflow.org/api_docs/python/tf/py_func comes with known limitations and I would like to know if it will work during training and online prediction before I invest more time into it.
Thanks
Unfortunately, no. Py_func can not be restored from a saved model. However, since your use case involves pre-processing, just invoke the py_func explicitly in all three (train, eval, serving) input functions. This won't work if the py_func is in the middle of your graph, but for stemming, it should work just fine.
I try to run a cppcheck analysis over my code, which has the following file structure:
/code/module_1/src/a.cpp
/code/module_1/src/b.cpp
/code/module_1/test/c.cpp
/code/module_2/src/d.cpp
/code/module_2/src/e.cpp
/code/module_3/test/f.cpp
I'd like to run an analysis excluding all test code. Is this possible with a command like "cppcheck -itest"? It doesn't work for me, although I think it should, according to the docs:
...Directory name is matched to all parts of the path.
I'm using version 1.69. I know I could mention all test directories separately (which does work, I checked), but the number of modules is too high to do this for many analyses reasonably.
Is this possible?
I installed Cppcheck to do some tests and it seems the -i implementation is a bit bonkers. However, I managed to achieve what you want.
Solution: use -itest\ instead of -itest (this was in Windows; maybe Linux needs -itest/)
Rationale: in my tests, -itest worked only if there was a .\test\ directory, in which case even .\a\test\a.cpp was excluded. With -itest\, however, such exclusion took place regardless of the presence of .\test\ directory.
This seems like a bug which the developers ought to weed out, but, in the meantime, you can succeed using the above workaround.
This is a late response to an old question, but perhaps this will help other latecomers like myself.
Disclaimer: This answer is for Windows.
It seems as if v1.79 has remedied the OP's issue. The following command line syntax has worked for me:
cppcheck -itest code
In this example, "-itest" weeds out any occurrence of the "test" directory, as originally (and correctly) assumed by the OP. In addition, the code folder is found next to the cppcheck.exe. This will be the root of the recursive source-code scan.
I'd use something like:
cppcheck /code/module_1/src /code/module_2/src /code/module_3/src
Since today, Eclipse locks up when an error is printed to the console during JUnit tests.
Using jstat, I can see that it hangs in java.util.regex.Pattern$Curly.match0(Pattern.java:3782)
How can I find out which regexp causes the problem?
Note that I didn't install anything nor did I change any prefs; my guess is that a change in the code triggered a lingering problem in an existing regexp.
Seems to be something with a {}-quantifier (http://www.docjar.com/html/api/java/util/regex/Pattern$Curly.java.html). Posting the actual regexp will maybe help.
This is Bug 175888 - ConsolePatternMatcher causes large delays with some large input
I have attached a patch which shows the regexp that causes the problem.
I wanted to know if anyone have used UniversalindentGUI.
I am trying to use and when run it get the following error.
There is no proper documentation or tutorial how to use it, if any one have used it please help me.
Indenter returned with exit code: 1
Indent console output was:
(STDOUT):
(STDERR):Cannot find file indentinput.cpp
Callstring was:
"/Users/rbang/Desktop/Tools/UniversalIndentGUI_macx/indenters/astyle"
indentinput.cpp
--options="/Users/rbang/Desktop/Tools/UniversalIndentGUI_macx/temp/.astylerc"
Open up indenters/uigui_astyle.ini in the directory where UniversalIndentGUI is installed and find the following properties:
inputFileName=indentinput
inputFileParameter=
outputFileName=indentinput
outputFileParameter=none
Change them to:
inputFileName=
inputFileParameter=stdin
outputFileName=
outputFileParameter=stdout
Voila!
I experienced the same problem, however if you switch to a different indenter in the pull down menu at the top of the ui(just below the text "Indenter Settings" and use a different indenter(i am using Uncrustify(C, C++, C#, Objective-C) it functions. I suspect it has to do with the fact that all the indenters may not be bundled with the download BUT uncrustify is. Most of the ones I tried have this issue, but the only one I care about is uncrustify.
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.