GitHub actions #23
Closed
GitHub actions #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a workaround for the issue reported as [Another fatal error C1001: Internal compiler error](https://developercommunity.visualstudio.com/t/another-fatal-error-c1001-internal-compiler-error/1441527)
…ependentElements, remove scene update part as it is not needed with REve stamping.
Before this patch we skipped running CleanUpTask if the status of the TTreeReader after a single-thread event loop over ROOT data encountered an error.
When found special codes which correspond to utf8 coding, convert them to string like \u0444. Let use non-latine symbols in ROOT7 graphics
Checks that creating and parsing JSON with UTF-8 characters works properly
On some platforms external nlohmann/json.hpp installed without such special include. In this case full version has to be used. Provide special define when compile EVE7 which indicates if json_fwd.hpp can be used. In the macros such define is not exported and therefore full version of nlohmann/json.hpp will be used.
When using default REveRefCnt implementation, wrong **this** value used with delete operator because of double inheritance
No longer required
Only final class can make proper "delete this" call
To ensure that all derived classes properly implement it
Fixing same kind of error as in REve classes, but do not declare method in base class as abstract
This fixes test failure: 745/1157 Test root-project#729: tutorial-multicore-mp102_readNtuplesFillHistosAndFit ................***Failed 1.55 sec Processing /builddir/build/BUILD/root-6.25.01/tutorials/multicore/mp102_readNtuplesFillHistosAndFit.C... IncrementalExecutor::executeFunction: symbol '_ZN4ROOT16TTreeProcessorMPC1Ej' unresolved while linking [cling interface function]! You are probably missing the definition of ROOT::TTreeProcessorMP::TTreeProcessorMP(unsigned int) Maybe you need to load the corresponding shared library? IncrementalExecutor::executeFunction: symbol '_ZN4ROOT16TTreeProcessorMP11ReplyToIdleEP7TSocket' unresolved while linking [cling interface function]! You are probably missing the definition of ROOT::TTreeProcessorMP::ReplyToIdle(TSocket*) Maybe you need to load the corresponding shared library? CMake Error at /builddir/build/BUILD/root-6.25.01/x86_64-redhat-linux-gnu/RootTestDriver.cmake:237 (message): error code: 1
The first call to `frame->updateNormVars(*frame->getPlotVar())` should be made before the first call to `frame->getNormVars()` in the `RooAbsPdf::plotOn` function. This fixes the Jira issue ROOT-5529.
The downsteam code, -- like RooAddPdf::getValV for example -- assume that a nullptr is passed when no normalization is requested. The case of an empty norm set is not handled correctly in RooAddPdf::getValV, leading to wrong results. However, some calling code passes an empty norm set to RooAbsReal::getVal instead of a `nullptr` in an attempt to disable normalization. This commit suggests to solve this ambiguity at the highest possible level: right at the beginning of RooAbsReal::getVal. If the normalization set is empty, the pointer pointing to it will be set to `nullptr`. This fixes issue root-project#8307.
Cosmetic changes
Adding a missing closing double quote.
Recent changes that added support for jitted Book actions broke the
edge case in which the action helper takes no columns:
`df.Book(Helper{}, {})` now means "jit this action" rather than "this
action does not take any columns".
With this patch, we resolve this ambiguity at runtime by looking at
the list of column names. A helper type is used to make sure that
compilation is fine in all cases.
No need for intermediate RAttrBox, which makes syntax too long
Do not use RAttrOnFrame class which just contains these both values
Always define const/non-const methods like:
RAttrLine &AttrLine() { return fAttrLine; }
const RAttrLine &AttrLine() const { return fAttrLine; }
Do not provide extra setter methods for attribute classes
Should be used for rect drawing, which optionally can have "rx" and "ry" attributes. Important that class inherits RAttrLine and all its properties and methods
Remove default value for the entry parameter in TTree::GetEntry and GetEvent.
The rf503_wspaceread tutorial mus be run after the rf502_wspacewrite tutorial in the unit tests. This dependency was already defined for the C++ tutorial tests. The lines added to `tutorials/CMakeLists.txt` in this commit make the same definitions for the Python tutorials, and also indicate that the Python tests rf502 and rf503 should be run after the C++ tests to avoid a race condition on the output file.
Rename output file of rf502_wspacewrite Python tutorial to be different from output file name of the rf502_wspacewrite C++ version. This allows the tutorials in both languages to run concurrently.
It was inadvertently introduced in 82fad76 In TBranchElement::Print use the correct StreamerInfo in case of schema evolution
Before, only the using decl itself was forward declared, causing undeclared identifiers in forward declaration code, as witnessed in root-project#8499 Given the similarity of using and typedef, merge both into a single function, making sure both have the same featureset, and through that fixing this issue as a side-effect.
These engines can be used to obtain the same sequences of numbers
as RANLUX generators using recursive subtract-with-borrow steps,
but with enhanced performance. Apart from the choice of parameters,
the main difference between the various implementations is the way
of seeding the initial state of the generator.
This commit includes engines for compatibility with:
* the original implementation by Fred James, with parameters for
- luxury level 3 (p = 223), also matching gsl_rng_ranlux
- luxury level 4 (p = 389), also matching gsl_rng_ranlux389
producing floating point numbers from 24 bits of randomness;
* the family of generators using a second-generation version of the
RANLUX algorithm as implemented in the GNU Scientific Library:
- gsl_rng_ranlxs[012] using 24 bits per floating point number, and
- gsl_rng_ranlxd[12] using 48 bits per floating point number;
* the implementation by Martin Lüscher written in C that uses four
states per generator; similar to GSL, there are ranlxs[012] with
24 bits per number and ranlxd[12] with 48 bits per number; and
* the generators std::ranlux{24,48} defined by the C++ standard.
The values in the tests were extracted directly from the mentioned
implementations, showing that the LCG implementation is equivalent
to the RANLUX algorithm.
I am not adding compatibility engines for CLHEP because its semantics
are very weird: While CLHEP::RanluxEngine::setSeed yields the same
sequences as the original implementation by James, the seed is treated
differently when passed as an argument to the constructor.
This fixes warnings in the CentOS 7 build in the nightlies.
This fixes warnings in the CentOS 7 build in the nightlies.
Uses example in as of yet unmerged PR actions/checkout#213
I thought clang-tools would include clang-format, but apparently not.
Now that we correctly fetch the base_ref, we can put the format_script back into Travis-compatible state.
It is not possible to use the base branch name in the GitHub Actions workflow to get the base SHA hash, because the branch name is not known there. To keep the format_script.sh universal, we just pass the SHA hash in from both the Travis and the GH Actions configurations instead.
2 tasks
egpbos
pushed a commit
that referenced
this pull request
Oct 27, 2021
This tutorial crashed with the following stacktrace when run
interactively. Avoiding to register a canvas with the same name
multiple times fixes the crash:
```
#8 0x00007f5b7876967d in TCanvas::Resize(char const*) (this=0x55e768e126c0) at ../graf2d/gpad/src/TCanvas.cxx:1740
#9 0x00007f5b3e90d668 in TRootCanvas::HandleContainerConfigure(Event_t*) (this=0x55e76852b460) at ../gui/gui/src/TRootCanvas.cxx:1789
#10 0x00007f5b3e8464fd in TGFrame::HandleEvent(Event_t*) (this=0x55e767938e70, event=0x7f5b79adff40) at ../gui/gui/src/TGFrame.cxx:476
#11 0x00007f5b3e7f4c9a in TGClient::HandleEvent(Event_t*) (this=0x55e768de2290, event=0x7f5b79adff40) at ../gui/gui/src/TGClient.cxx:846
#12 0x00007f5b3e7f531d in TGClient::ProcessOneEvent() (this=0x55e768de2290) at ../gui/gui/src/TGClient.cxx:656
#13 TGClient::ProcessOneEvent() (this=0x55e768de2290) at ../gui/gui/src/TGClient.cxx:648
#14 0x00007f5b3e7f536b in TGClient::HandleInput() (this=0x55e768de2290) at ../gui/gui/src/TGClient.cxx:703
#15 0x00007f5b8dcb0ff8 in TUnixSystem::DispatchOneEvent(bool) (this=0x55e75ccfd080, pendingOnly=<optimized out>) at ../core/unix/src/TUnixSystem.cxx:1067
#16 0x00007f5b8dbd0dca in TSystem::ProcessEvents() (this=0x55e75ccfd080) at ../core/base/src/TSystem.cxx:424
#17 0x00007f5b8130600d in ()
#18 0x00007f5b79ae0450 in ()
#19 0x00007f5b8de5215f in WrapperCall(Cppyy::TCppMethod_t, size_t, void*, void*, void*) (method=94452242807424, nargs=0, args_=0x7f5b79ae01d7, self=0x55e75ccfd080, result=0x7f5b79ae01d7) at ../bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:778
#20 0x00007f5b8de527cf in CallT<unsigned char> (args=<optimized out>, nargs=<optimized out>, self=<optimized out>, method=<optimized out>) at ../bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:816
#21 Cppyy::CallB(long, void*, unsigned long, void*) (method=<optimized out>, self=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../bindings/pyroot/cppyy/cppyy-backend/clingwrapper/src/clingwrapper.cxx:833
#22 0x00007f5b8decdc0f in GILCallB (ctxt=0x7f5b79ae0430, self=<optimized out>, method=<optimized out>) at ../bindings/pyroot/cppyy/CPyCppyy/src/Executors.cxx:69
#23 CPyCppyy::(anonymous namespace)::BoolExecutor::Execute(Cppyy::TCppMethod_t, Cppyy::TCppObject_t, CPyCppyy::CallContext*) (this=<optimized out>, method=<optimized out>, self=<optimized out>, ctxt=0x7f5b79ae0430) at ../bindings/pyroot/cppyy/CPyCppyy/src/Executors.cxx:148
#24 0x00007f5b8deba4c9 in CPyCppyy::CPPMethod::ExecuteFast(void*, long, CPyCppyy::CallContext*) (self=<optimized out>, offset=<optimized out>, ctxt=<optimized out>, this=<optimized out>, this=<optimized out>) at ../bindings/pyroot/cppyy/CPyCppyy/src/CPPMethod.cxx:74
#25 0x00007f5b8debd3a8 in CPyCppyy::CPPMethod::ExecuteProtected(void*, long, CPyCppyy::CallContext*) (this=this entry=0x55e760617f50, self=0x55e75ccfd080, offset=0, ctxt=0x7f5b79ae0430) at ../bindings/pyroot/cppyy/CPyCppyy/src/CPPMethod.cxx:149
root-project#26 0x00007f5b8debb6fa in CPyCppyy::CPPMethod::Execute(void*, long, CPyCppyy::CallContext*) (this=this entry=0x55e760617f50, self=self entry=0x55e75ccfd080, offset=<optimized out>, ctxt=ctxt entry=0x7f5b79ae0430) at ../bindings/pyroot/cppyy/CPyCppyy/src/CPPMethod.cxx:728
root-project#27 0x00007f5b8debc46c in CPyCppyy::CPPMethod::Call(CPyCppyy::CPPInstance*&, _object*, _object*, CPyCppyy::CallContext*) (this=0x55e760617f50, self= 0x7f5b8080ef50: 0x7f5b808043c0, args=0x7f5b8e1ab040, kwds=<optimized out>, ctxt=0x7f5b79ae0430) at ../bindings/pyroot/cppyy/CPyCppyy/src/CPPMethod.cxx:783
root-project#28 0x00007f5b8dec09fe in CPyCppyy::(anonymous namespace)::mp_call(CPyCppyy::CPPOverload*, PyObject*, PyObject*) (pymeth=0x7f5b8080ef40, args=0x7f5b8e1ab040, kwds=0x0) at ../bindings/pyroot/cppyy/CPyCppyy/src/CPPOverload.cxx:566
root-project#29 0x00007f5b8e941333 in _PyObject_MakeTpCall () at /usr/lib/libpython3.9.so.1.0
root-project#30 0x00007f5b8e93d218 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.9.so.1.0
root-project#31 0x00007f5b8e936fd9 in () at /usr/lib/libpython3.9.so.1.0
root-project#32 0x00007f5b8e948b8e in _PyFunction_Vectorcall () at /usr/lib/libpython3.9.so.1.0
root-project#33 0x00007f5b8e93aec9 in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.9.so.1.0
root-project#34 0x00007f5b8e94896b in _PyFunction_Vectorcall () at /usr/lib/libpython3.9.so.1.0
root-project#35 0x00007f5b8e93858e in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.9.so.1.0
root-project#36 0x00007f5b8e94896b in _PyFunction_Vectorcall () at /usr/lib/libpython3.9.so.1.0
root-project#37 0x00007f5b8e93858e in _PyEval_EvalFrameDefault () at /usr/lib/libpython3.9.so.1.0
root-project#38 0x00007f5b8e94896b in _PyFunction_Vectorcall () at /usr/lib/libpython3.9.so.1.0
root-project#39 0x00007f5b8e95795b in () at /usr/lib/libpython3.9.so.1.0
root-project#40 0x00007f5b8ea3cac6 in () at /usr/lib/libpython3.9.so.1.0
root-project#41 0x00007f5b8ea17554 in () at /usr/lib/libpython3.9.so.1.0
root-project#42 0x00007f5b8e62c259 in start_thread () at /usr/lib/libpthread.so.0
root-project#43 0x00007f5b8e7425e3 in clone () at /usr/lib/libc.so.6
```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.