Oozie done-flag EL functions - oozie

I am trying to use the built in or EL functions provided by oozie in tag of oozie-coordinator xml, but seems like its not supported? Does anyone know of any other way to declare this?
Our done-flags have dates in them.
<done-flag>${YEAR}${MONTH}${DAY}.done</done-flag>
OR
<done-flag>${coord:formatTime(coord:actualTime(), 'yyyyMMdd')}</done-flag>
I get the following error when launching the oozie coordinator workflow.
Error: E1004 : E1004: Expression language evaluation error,
Unable to evaluate :${coord:formatTime(coord:actualTime(), 'yyyyMMdd')}:
Does anyone know of a way to achieve dynamic done-flag names?

Not 100% sure about what you want to do.
My understanding is that the Coordinator waits for a file named as "done-flag" before running a Workflow. Then the "coord:actualTime()" function can be used to know at what time the Workflow was actually started.
=> the documentation should stress that the phrase "coordinator action" actually means "workflow" in most cases...
If you want to check the clock time while the Coordinator is still waiting, the keywords YEAR - MONTH - DAY - HOUR - MINUTE are your only hope.

I got it working using the following way, by using the YEAR, MONTH, DAY variables in the uri-template and emptying out the .
<uri-template>
/donemarkers/dependency-job/${YEAR}${MONTH}${DAY}.done
</uri-template>
<!--<done-flag>${YEAR}${MONTH}${DAY}.done</done-flag>-->
<done-flag></done-flag>
I came to know from the logs that oozie first checks if there is a directory with the name specified by uri-template, if not then it checks if there is a file specified by the uri-template.
2015-07-28 19:40:46,225 INFO CoordActionInputCheckXCommand:539 - USER[-] GROUP[-] TOKEN[-] APP[-] JOB[0131647-140520191754742-oozie-oozi-C] ACTION[0131647-140520191754742-oozie-oozi-C#2] [0131647-140520191754742-oozie-oozi-C#2]::ActionInputCheck:: In checkResolvedUris...
2015-07-28 19:40:46,225 INFO CoordActionInputCheckXCommand:539 - USER[-] GROUP[-] TOKEN[-] APP[-] JOB[0131647-140520191754742-oozie-oozi-C] ACTION[0131647-140520191754742-oozie-oozi-C#2] [0131647-140520191754742-oozie-oozi-C#2]::ActionInputCheck:: In checkListOfPaths: /donemarkers/dependency-job/20150725.done is Missing.
2015-07-28 19:40:46,241 INFO CoordActionInputCheckXCommand:539 - USER[-] GROUP[-] TOKEN[-] APP[-] JOB[0131647-140520191754742-oozie-oozi-C] ACTION[0131647-140520191754742-oozie-oozi-C#2] [0131647-140520191754742-oozie-oozi-C#2]::ActionInputCheck:: File:/donemarkers/dependency-job/20150725.done, Exists? :true

Related

How to get the 'execution count' of the most recent execution in IPython or a Jupyter notebook?

IPython and Jupyter notebooks keep track of an 'execution count'. This is e.g. shown in the prompts for input and output: In[...] and Out[...].
How can you get the latest execution count programmatically?
The variable Out cannot be used for this:
Out is a dictionary, with execution counts as keys, but only for those cells that yielded a result; note that not all (cell) executions need to yield a result (e.g. print(...)).
The variable In seems to be usable:
In is a list of all inputs; it seems that In[0] is always primed with an empty string, so that you can use the 1-based execution count as index.
However, when using len(In) - 1, in your code, you need to take into account that the execution count seems to be updated before execution of that new code. So, actually, it seems you need to use len(In) - 2 for the execution count of the most recent already completed execution.
Questions:
Is there a better way to get the current execution count?
Can you rely on the above observations (the 'seems')?
After more digging, I found the (surprisingly simple) answer:
from IPython import get_ipython
ipython = get_ipython()
... ipython.execution_count ...
This does not show up in the IPython documentation, though could (should?) have been mentioned here: https://ipython.readthedocs.io/en/stable/api/generated/IPython.core.interactiveshell.html (I guess attributes are not documented). Here you do find run_line_magic (which was mentioned in a comment to my question).
The way I found this attribute is by defining ipython as above and then doing code completion (TAB) on ipython. (but it does not have documentation).
help(ipython)
gives you documentation about InteractiveShell, and it does mention execution_count (though it does not confirm its purpose):
| execution_count
| An int trait.

DateTimeParseException while trying to perform ZonedDateTime.parse

Using Java 8u222, I've been trying a silly operation and it incurs in an error that I'm not being able to fully understand. The line code:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Asia/Qostanay]");
The error:
java.time.format.DateTimeParseException: Text '2011-07-03T02:20:46+06:00[Asia/Qostanay]' could not be parsed, unparsed text found at index 25
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1952)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:597)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:582)
Using the same date (although the timezone could be incorrect, the intention is just testing here), I changed the square bracket's value and it works, I mean:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Europe/Busingen]);
It works as expected, as well as other values such:
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[Asia/Ulan_Bator]")
ZonedDateTime.parse("2011-07-03T02:20:46+06:00[SystemV/CST6CDT]")
I found some similar questions such as the one below, but not precisely the same usage that I'm trying / facing.
Error java.time.format.DateTimeParseException: could not be parsed, unparsed text found at index 10
Does someone have an understanding of Java Date API to help me out to grasp what I'm doing wrong here?
Thanks.
Asia/Qostanay is a zone which doesn't exist in the JDK8's list of timezones. It was added later.
If you don't care about the location of the timezone then just splice the [...] part of the string off the end before parsing. Knowing that the time is +06:00 is going to sufficient for almost all purposes.
Alternatively, upgrade to a more recent version of Java.

First token could not be read or is not the keyword 'FoamFile' in OpenFOAM

I am a beginner to programming. I am trying to run a simulation of a combustion chamber using reactingFoam.
I have modified the counterflow2D tutorial.
For those who maybe don't know OpenFOAM, it is a programme built in C++ but it does not require C++ programming, just well-defining the variables in the files needed.
In one of my first tries I have made a very simple model but since I wanted to check it very well I set it to 60 seconds with a 1e-6 timestep.
My computer is not very powerful so it took me for a day aprox. (by this I mean I'd like to find a solution rather than repeating the simulation).
I executed the solver reactingFOAM using 4 processors in parallel using
mpirun -np 4 reactingFOAM -parallel > log
The log does not show any evidence of error.
The problem is that when I use reconstructPar it works perfectly but then I try to watch the results with paraFoam and this error is shown:
From function bool Foam::IOobject::readHeader(Foam::Istream&)
in file db/IOobject/IOobjectReadHeader.C at line 88
Reading "mypath/constant/reactions" at line 1
First token could not be read or is not the keyword 'FoamFile'
I have read that maybe some files are empty when they are not supposed to be so, but I have not found that problem.
My 'reactions' file have not been modified from the tutorial and has always worked.
edit:
Sorry for the vague question. I have modified it a bit.
A typical OpenFOAM dictionary file always contains a Foam::Istream named FoamFile. An example from a typical system/controlDict file can be seen below:
FoamFile
{
version 2.0;
format ascii;
class dictionary;
location "system";
object controlDict;
}
During the construction of the dictionary header, if this Istream is absent, OpenFOAM ceases its operation by raising an error message that you have experienced:
First token could not be read or is not the keyword 'FoamFile'
The benefit of the header is possibly to contribute OpenFOAM's abstraction mechanisms, which would be difficult otherwise.
As mentioned in the comments, adding the header entity almost always solves this problem.

Qt error is printed on the console; how to see where it originates from?

I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).

Clear console for each run of Testacular/Karma + Jasmine

It is difficult for me to catch with the eye a boundary between test runs.
Is it possible to clear console for each run of Testacular/Karma + Jasmine or at least put there something easily catched by the eye, for example a series of newlines?
Note
Currently it is an abandoned question because I am no longer trying to perform tasks described in it. Please do not ask for additional info. Write only if you know for sure what to do. It will help other people.
Write your own reporter, and do whatever you want with it.
Also, if you're on a Mac and use Growl, take a look at karma-growl-reporter
I am not sure to fully understand your need but karma-spec-reporter can give you a detailed review of your test execution. Output example from karma-spec-reporter-example:
array:
push:
PASSED - should add an element
PASSED - should remove an element
FAILED - should do magic (this test will fail) expected [] to include 'magic'
at /home/michael/development/codecentric/karma-spec-reporter-example/node_modules/chai/chai.js:401
...
PhantomJS 1.8.1 (Linux): Executed 3 of 3 (1 FAILED) (0.086 secs / NaN secs)
There's now a reporter available for this: https://github.com/arthurc/karma-clear-screen-reporter
It's working for me on OSX.

Resources