Contribute to Open Source. Search issue labels to find the right project for you!

[PRE REVIEW]: The o80 C++ templated toolbox: Designing customized Python APIs for synchronizing realtime processes

openjournals/joss-reviews

Submitting author: @vincentberenz (<a href=“http://orcid.org/0000-0003-2226-9660”>Vincent Berenz</a>) Repository: <a href=“https://github.com/intelligent-soft-robots/o80” target =“_blank”>https://github.com/intelligent-soft-robots/o80</a> Version: 1.0 Editor: Pending Reviewer: Pending Managing EiC: Kyle Niemeyer

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @vincentberenz. Currently, there isn’t an JOSS editor assigned to your paper.

@vincentberenz if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 10/07/2020 13:44 17 Comments

Fix SVG rendering problem on high DPI screens

Xmodal/dynamiclight

Qt’s Image class has an issue with rendering SVG files on high DPI screen, resulting in either pixelated or blurry looking images. This affects all SVG icons used in the application. This bug was noticed when we made the switch to all SVG assets in pull request #108.

This bug report gives more details about the problem, and provides a workaround that renders the SVG to a QImage from the C++ side of things. The image is then passed to QML. This avoids the issue because the SVG renderer’s image size can be decided independently from the scale at which it is drawn in QML. This is somewhat tedious to implement.

This stackoverflow thread gives a much simpler solution that relies entirely on QML to resolve the problem. I (@simondemeule) haven’t been able to make this work, but this is something we should investigate further, as it would be much simpler to implement than the other solution.

Updated 09/07/2020 04:18 1 Comments

[Sparse] Add a new kind of sparse structure: SNodeType=tree

taichi-dev/taichi

Concisely describe the proposed feature I would like to add a kind of SNode called tree so that tree methods, which is often useful in highly-scalable computer graphics & computational physics, could be easier to implemented and provide better optimization.

The tree method is extremely hard due to Taichi’s lack of recursion support, people have to simulate a stack poping&pushing nodes which is not intuitive at all, and a Taichi tree implementation could have even more LoC than C++ tree implementation.

Describe the solution you’d like (if any) But thanks to Taichi’s built-in sparse structure support, which demote a variety of complex structure into listgen, it could be eaiser if we built-in tree support based on struct-for’s. e.g.:

bitree = ti.root.tree(ti.i, 2)
qtree = ti.root.tree(ti.ij, 2)
octree = ti.root.tree(ti.ijk, 2)

octree.place(node_mass, node_center, node_masspole, ...)
# so, how to dintinguish per-node variables and per-leaf variables?

@ti.kernel
def search(id):
  for x in bitree:
    if node_id[x] == id:
      print('found!!!')

Additional comments We may add this as an experimental feature on the CPU backends (LLVM or C) first, where recursion could be easy.

Note that what I mean by tree is: have a maximum amount of nodes, and depth till leaf could be a variable; instead of having a maximum amount of depth using ad-hoc ti.root.pointer().pointer().pointer().pointer()....

Updated 10/07/2020 14:34 3 Comments

单例模式

imvan/myNote

懒汉式单例 , 只有在真的用到时才会初始化
线程安全
class Singleton{
    private:
        static Singleton * instance;
        Singleton();
        Singleton(const Singleton &) =delete;
        Singleton& operator=(const Singleton &) = delete;
    public:
        static Singleton * getInstance()
        {
            if(instance == NULL)
            {
                lock();
                if(instance == NULL)
                {
                    instance  = new Singleton();
                }
                unlock();
            }
            return instance;
        } 
}


饿汉式单例
class Singleton
{
    public:
        static Singleton * getInstance()
        {
            return  instance;    
        }
    private:
        static Singleton* instance = new Singleton();
        Singleton();
        Singleton(const Singleton &) = delete;

}
Updated 07/07/2020 03:12

如何让程序在main函数之前执行

imvan/myNote

全局变量的构造函数,会在main之前执行 ``` using namespace std;

class app { public: //构造函数 app() { cout<<“First”<<endl; } };

app a; // 申明一个全局变量

int main() { cout<<“Second”<<endl; return 0; }



全局变量的赋值函数,会在main之前执行

include <iostream>

using namespace std;

int f(){ printf(“before”); return 0; }

int _ = f();

int main(){ return 0; }

```

Updated 07/07/2020 03:08 1 Comments

C++多线程编程

imvan/myNote

C++11 有了标准的线程库

#include <thread>
#include <condition_variable>
#include <mutex>

std::thread C++11创建线程非常简单,使用std::thread类就可以。 构造对象时同时传入一个可调用函数作为参数,如果函数有参数,则同时把参数传入。 构造完成后,新的线程马上被创建,同时执行该可调用对象。 thread th1(func, var1,var2.....);

用thread默认构造函数构造的对象不关联任何线程 判断一个thread对象是否关联某个线程,可以使用joinable()接口。 如果返回true,则表明该对象关联某个线程

joinable的对象析构前,必须调用join()接口等到线程结束, 或者调用detach()接口接触对象与线程的关联,否则抛出异常

正在执行的线程从关联对象detach后自主执行直到结束,对应的对象变成不关联任何线程 这时候调用joinable()返回false。

std::thread类没有拷贝构造函数和拷贝复制函数,因此不支持复制操作 但是支持移动语义 这意味着没有两个thread对象执行同一个线程。

在下面情况下,thread对象不关联任何线程,对于这种对象调用join()或者detach()会抛出异常 默认构造的thread对象 被移动后的thared对象 detach或者join后的thread对象

std::mutex(轻松实现互斥) mutex用户保护共享数据避免被多个线程同时访问。 它提供了 lock,try_lock , un_lock等几个接口 调用线程从成功调用lock()或者 try_lock()开始,到unlock()为止 占用mutex对象 线程占有mutex对象时,如果其他线程试图占有mutex, 调用 lock() 将会被阻塞 如果调用 try_lock() 会收到false返回,非阻塞 调用线程调用lock()或者try_lock()前必须不占有mutex,否则导致死锁。

C++根据mutex的属性提供四种互斥量

std::mutex
最常用的默认互斥量 std::recursive_mutex,
允许同一线程使用recursive_mutex多次加锁,然后使用相同次数的解锁操作解锁。(如果是mutex,多次加锁将导致死锁) std::timed_mutex , 在mutex上添加了时间属性,并且增加两个成员函数 try_lock_for() 和 try_lock_until(), 分别接受一个时间范围,在给定时间内如果互斥量被锁住了,线程阻塞,超时返回false std::recursive_timed_mutex 增加了递归和时间属性

粗心大意的程序员可能忘记unlock,这样会导致死锁。 因此遵顼C++的 RAII原则, C++11引入了unique_lock和 lock_guard两种类 类似于智能指针一样,在他们离开作用域时,会自动调用unlock。

std::lock_guard lock_guard是mutex的封装器,通过RAII机制让其在作用域内占有mutex 从创建lock_guard对象时,它试图接收给定mutex的所有权 当离开作用域时,lock_guard自动销毁并且释放mutex。 lock_guard类不可复制 std::mutex mtx; std::lock_guard<std::mutex> guard(mtx);

std::unique_lock unique_lock比lock_guard更加灵活,但是代价是占用空间大一点,速度相对慢一点 unique_lock构造函数比lock_guard多,可以接受额外的参数 比如支持try_lock, try_lock_for,try_lock_until等等功能

Updated 07/07/2020 02:59

Find an efficient way to share vector / list data from C++ to QML

Xmodal/dynamiclight

For the application to be able to display certain graphics, it is necessary to find an efficient way to share vector / list based data from C++ to QML. This is made complex by the fact that sharing QSharedPointer with QML is difficult or impossible. Different solutions have to be tried out, and some profiling / efficiency testing has to be done. This is necessary for #8, #75, #76.

Updated 06/07/2020 17:17

[BUG] aws-doc-sdk-examples/cpp/example_code/s3

awsdocs/aws-doc-sdk-examples

What is the issue?

Compile error on code when using system has aws sdk cpp version 1.7.146

Found AWS SDK for C++, Version: 1.7.146, Install Root:/usr/local, Platform Prefix:, Platform Dependent Libraries: pthread;crypto;ssl;z;curl

This version is the publicly available version - aws sdk c++ version 1.8 is still “developer” version.

When running compilation, the following error occurs:

[ 48%] Building CXX object CMakeFiles/get_bucket_policy.dir/get_bucket_policy.cpp.o /space/workspace/eclipse-workspace/s3-example-code/list_objects_with_aws_global_region.cpp: In function ‘int main(int, char)’: /space/workspace/eclipse-workspace/s3-example-code/list_objects_with_aws_global_region.cpp:43:25: error: ‘AWS_GLOBAL’ is not a member of ‘Aws::Region’ config.region = Aws::Region::AWS_GLOBAL; ^ /space/workspace/eclipse-workspace/s3-example-code/list_buckets_disabling_dns_cache.cpp:42:10: error: ‘void MyCurlHttpClient::OverrideOptionsOnConnectionHandle(CURL) const’ marked override, but does not override void OverrideOptionsOnConnectionHandle(CURL connectionHandle) const override ^ /space/workspace/eclipse-workspace/s3-example-code/list_objects_with_aws_global_region.cpp: In function ‘int main(int, char)’: /space/workspace/eclipse-workspace/s3-example-code/list_objects_with_aws_global_region.cpp:43:25: error: ‘AWS_GLOBAL’ is not a member of ‘Aws::Region’ config.region = Aws::Region::AWS_GLOBAL; ^ /space/workspace/eclipse-workspace/s3-example-code/list_buckets_disabling_dns_cache.cpp:42:10: error: ‘void MyCurlHttpClient::OverrideOptionsOnConnectionHandle(CURL) const’ marked override, but does not override void OverrideOptionsOnConnectionHandle(CURL connectionHandle) const override ^ gmake[2]: [CMakeFiles/list_objects_with_aws_global_region.dir/list_objects_with_aws_global_region.cpp.o] Error 1 gmake[1]: [CMakeFiles/list_objects_with_aws_global_region.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs….

How can someone reproduce this issue (if applicable)?

Attempt compile of example code against aws cpp sdk version 1.7.x

What is the actual result when the preceding steps are followed (if applicable)?

compile error happens if you compile cpp code with aws sdk cpp version 1.7.x

What was the result you expected instead (if applicable)?

A full successful compile against code with aws sdk cpp version 1.7.x as this is the RELEASE version of aws sdk cpp - version 1.8 is developer ( in testing ) release.

Environment details to help us try to reproduce the issue (if applicable)

  • Operating system and version: Centos 7
  • SDK or tool name: AWS SDK C++
  • SDK or tool version: 1.7.146

Any other related details we should know about?

As a test - I was able to install AWS SDK C++ version 1.8.x on the machine. When that is done, compile of the code is successful. However on attempting to run the result - segmentation fault occurs.

Is it possible to “tag” this documentation or code to what sdk version it works on?

Updated 06/07/2020 20:08 2 Comments

[PRE REVIEW]: PyMatting: A Python Library for Alpha Matting

openjournals/joss-reviews

Submitting author: @99991 (<a href=“http://orcid.org/0000-0003-1355-7724”>Thomas Germer</a>) Repository: <a href=“https://github.com/pymatting/pymatting” target =“_blank”>https://github.com/pymatting/pymatting</a> Version: v1.0.6 Editor: @gkthiruvathukal Reviewer: Pending Managing EiC: Daniel S. Katz

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @99991. Currently, there isn’t an JOSS editor assigned to your paper.

@99991 if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 13/07/2020 01:01 27 Comments

Recursively manage layout display of a generator's parameters between C++ and QML

Xmodal/dynamiclight

Is your feature request related to a problem? Please describe. Generator parameters are currently hardcoded, both in the back- and front-end sides of the app. As we add more models with completely different parameter schemes, this method will eventually be very cost-heavy, poorly scalable and hard to maintain.

Describe the solution you’d like We would need to create an appropriate structure that allows to bridge a generator’s editable parameters with its associated interface components in the GUI. For example, a member property of Generator defined as an array of struct Parameters, which would fill in info such as parameter name, data type, page index, etc., could be created, populated in each generator subclass and dynamically implemented as QObject properties. Incidentally, the QML would accept a list of such structs and generate the Params rack accordingly, properly hooking the field with its respective C++ property on each instance.

Updated 04/07/2020 21:23 3 Comments

C++ version of neuron primitives

norse/norse

Using the libtorch C++ extension api it is relatively straightforward to implement the core neuron primitives in C++. This would have the advantage of facilitating integration with alternative backends, such as neuromorphic hardware. This issue tracks progress towards this goal.

Updated 01/07/2020 07:05 1 Comments

c++代码格式化 - sublime

tong-hao/tech-log

安装clang-format

brew search clang //mac os

安装clang format插件

风格定义

Preferences - Package Settings - Clang Format - Custom Style -User ```

{ “BasedOnStyle”: “google”, “AccessModifierOffset”: -4, “AlignAfterOpenBracket”: true, “AlignConsecutiveAssignments”: false, “AlignConsecutiveDeclarations”: false, “AlignEscapedNewlines”: true, “AlignOperands”: true, “AlignTrailingComments”: true, “AllowAllParametersOfDeclarationOnNextLine”: true, “AllowShortBlocksOnASingleLine”: false, “AllowShortCaseLabelsOnASingleLine”: false, “AllowShortFunctionsOnASingleLine”: “All”, “AllowShortIfStatementsOnASingleLine”: true, “AllowShortLoopsOnASingleLine”: true, “AlwaysBreakAfterDefinitionReturnType”: “None”, “AlwaysBreakAfterReturnType”: “None”, “AlwaysBreakBeforeMultilineStrings”: true, “AlwaysBreakTemplateDeclarations”: true, “BinPackArguments”: true, “BinPackParameters”: true, “BraceWrapping”: { “AfterClass”: false, “AfterControlStatement”: false, “AfterEnum”: false, “AfterFunction”: false, “AfterNamespace”: false, “AfterObjCDeclaration”: false, “AfterStruct”: false, “AfterUnion”: false, “AfterExternBlock”: false, “BeforeCatch”: false, “BeforeElse”: false, “IndentBraces”: false, “SplitEmptyFunction”: true, “SplitEmptyRecord”: true, “SplitEmptyNamespace”: true }, “BreakBeforeBinaryOperators”: “None”, “BreakBeforeBraces”: “Attach”, “BreakBeforeInheritanceComma”: false, “BreakBeforeTernaryOperators”: true, “BreakConstructorInitializersBeforeComma”: false, “BreakConstructorInitializers”: “BeforeColon”, “BreakAfterJavaFieldAnnotations”: false, “BreakStringLiterals”: true, “ColumnLimit”: 80, //“CommentPragmas”: “^ IWYU pragma:”, “CompactNamespaces”: false, “ConstructorInitializerAllOnOneLineOrOnePerLine”: true, “ConstructorInitializerIndentWidth”: 4, “ContinuationIndentWidth”: 4, “Cpp11BracedListStyle”: true, “DerivePointerAlignment”: true, “DisableFormat”: false, “ExperimentalAutoDetectBinPacking”: false, “FixNamespaceComments”: true, “ForEachMacros”: [ “foreach”, “Q_FOREACH”, “BOOST_FOREACH” ], “IncludeBlocks”: “Preserve”, “IncludeCategories”: [ { “Regex”: “^<ext/.\.h>”, “Priority”: 2 }, { “Regex”: “^<.\.h>”, “Priority”: 1 }, { “Regex”: “^<.”, “Priority”: 2 }, { “Regex”: “.”, “Priority”: 3 } ], “IncludeIsMainRegex”: “(-_)?$”, “IndentCaseLabels”: true, “IndentPPDirectives”: “None”, “IndentWidth”: 4, “IndentWrappedFunctionNames”: false, “JavaScriptQuotes”: “Leave”, “JavaScriptWrapImports”: true, “KeepEmptyLinesAtTheStartOfBlocks”: false, //“MacroBlockBegin”: “”, //“MacroBlockEnd”: “”, “MaxEmptyLinesToKeep”: 1, “NamespaceIndentation”: “None”, “ObjCBinPackProtocolList”: “Never”, “ObjCBlockIndentWidth”: 2, “ObjCSpaceAfterProperty”: false, “ObjCSpaceBeforeProtocolList”: true, “PenaltyBreakAssignment”: 2, “PenaltyBreakBeforeFirstCallParameter”: 1, “PenaltyBreakComment”: 300, “PenaltyBreakFirstLessLess”: 120, “PenaltyBreakString”: 1000, “PenaltyBreakTemplateDeclaration”: 10, “PenaltyExcessCharacter”: 1000000, “PenaltyReturnTypeOnItsOwnLine”: 200, “PointerAlignment”: “Left”, “RawStringFormats”: [ { “Language”: “Cpp”, “Delimiters”: [ “cc”, “CC”, “cpp”, “Cpp”, “CPP”, “c++”, “C++” ], “CanonicalDelimiter”: “”, “BasedOnStyle”: “google” }, { “Language”: “TextProto”, “Delimiters”: [ “pb”, “PB”, “proto”, “PROTO” ], “CanonicalDelimiter”: “”, “BasedOnStyle”: “google” } ], “ReflowComments”: true, “SortIncludes”: true, “SortUsingDeclarations”: true, “SpaceAfterCStyleCast”: false, “SpaceAfterTemplateKeyword”: true, “SpaceBeforeAssignmentOperators”: true, “SpaceBeforeCtorInitializerColon”: true, “SpaceBeforeInheritanceColon”: true, “SpaceBeforeParens”: “ControlStatements”, “SpaceBeforeRangeBasedForLoopColon”: true, “SpaceInEmptyParentheses”: false, “SpacesBeforeTrailingComments”: 2, “SpacesInAngles”: false, “SpacesInContainerLiterals”: true, “SpacesInCStyleCastParentheses”: false, “SpacesInParentheses”: false, “SpacesInSquareBrackets”: false, “Standard”: “Auto”, “TabWidth”: 4, “UseTab”: “Never” } ```

修改配置

Preferences - Package Settings - Clang Format - Settings -User "binary": "clang-format", "style": "Custom", "format_on_save": true, "languages": ["C", "C++", "C++11", "JavaScript", "Objective-C", "Objective-C++"]

Updated 28/06/2020 06:23

Implementation of Brick Sort/ Odd even sort

TesseractCoding/NeoAlgo

Algorithm: Implementation Of Brick Sort

an odd–even sort or odd–even transposition sort (also known as brick sort or parity sort) is a relatively simple sorting algorithm, developed originally for use on parallel processors with local interconnections. It is a comparison sort related to bubble sort, It is a comparison sort related to bubble sort, with which it shares many characteristics.

Languages Supported: - C [@jivthesh ] - C++ - C# - Java - Python [@sparkingdark ] - JavaScript - go - dart

Updated 08/07/2020 15:07 4 Comments

LGTM.com - false positive

github/codeql

“Resource th is acquired by class cleaner but not released anywhere in this class.”

The resource is acquired when main invokes start on the cleaner class. It is released when main invokes stop on it. It always do so (check src/main.cpp for main()). Note that the helper function join_thread is used for it which can be found in src/exec.cpp

https://lgtm.com/projects/g/flok99/constatus/snapshot/588bdaead6294fc99fc160d9f5ccfd829304696e/files/src/cleaner.cpp?sort=name&dir=ASC&mode=heatmap#L34

Updated 29/06/2020 14:27 1 Comments

[Backend] C language source to source backend

taichi-dev/taichi

Concisely describe the proposed feature Currently we have LLVM serve as a CPU backend, but LLVM is highly complicated and needs to be installed carefully, so that compiled Taichi program cannot run on a environment without a good environment support. e.g. 1. A 32-bit machine. 2. Cannot make python version happy anyway. 3. Cannot make LLVM happy like #1325. 4. A headless server without X11 support therefore GLFW can’t make a valid context). 5. For advanced optimization, compile-time may take too long for some huge programs, it would be great if we could store the pre-compile result in C source/object for Taichi applications to start up faster.

So, I would like to add a C language source to source backend, i.e. translate Taichi IR into C plain source code, which is aimed to be: 1. Easy to copy-and-paste. 2. Pure, computation only, not rely on any complicated library. 3. C99 portable, runs on any machine, any C compiler. 4. Can easily export result to file, so that anyone without Taichi could run the code. 5. Could also implement a pure JavaScript one for building Web shaders using Taichi?

Describe the solution you’d like (if any) Follow up the source to source attempt/infrastructure in OpenGL and Metal. For the ti.export, since currently Taichi is made in a JIT manner, some refactor may be done to make it only compile but not execute.

Additional comments Feel free to close me without a reason if you feel this useless.

Updated 30/06/2020 14:55 7 Comments

LGTM.com - false positive - missed conditional increment of a variable

github/codeql

Description of the false positive I keep getting a “Comparison is always false because dif_steering <= 0.” error on https://lgtm.com/projects/g/CleverRaven/Cataclysm-DDA/rev/pr-f7153dbafa3dbb084b7793d0d2ac10ebda2bca84

in https://lgtm.com/projects/g/CleverRaven/Cataclysm-DDA/snapshot/912bd27fe5b356ed2a34f3ce5b19e63ad5c9c4cd/files/src/veh_interact.cpp?sort=name&dir=ASC&mode=heatmap#L737, it’s clear that dif_steering can be incremented to be more than 5, so this result is in error.

Also, I didn’t actually change this part of the file, so I even if there was a false positive, I shouldn’t be getting warned about it for this particular PR.

https://lgtm.com/projects/g/CleverRaven/Cataclysm-DDA/rev/pr-f7153dbafa3dbb084b7793d0d2ac10ebda2bca84

Updated 25/06/2020 13:15 1 Comments

OpenFOAM Library

OxfordCodeReviewNet/forum

Brief project description

I’m a DPhil student in the Engineering Dept. I’m pretty happy with C++, but I don’t have any proper training, so it would be good to get some feedback.

The code is a small class to implement a radially varying pressure boundary condition in OpenFOAM (an open source computational fluid dynamics solver). The class is dynamically linked into OpenFOAM at runtime.

The code

Language: C++ Type: - [ ] Script or collection of scripts - [x] Library - [ ] Standalone software - [ ] I have no idea

Code review format

I’d rather - [ ] Meet in person - [x] Meet remotely - [ ] Other format: <Describe your format here> - [ ] No preference

Updated 29/06/2020 12:59 7 Comments

CI error: Valgrind: Syscall param write(buf) points to uninitialised byte(s)

ICB-DCM/AMICI

Only happening for this model. To be checked whether on HDF5 or AMICI side:

2020-06-23T06:18:43.1942719Z + valgrind --leak-check=full --error-exitcode=1 --trace-children=yes --show-leak-kinds=definite ./model_steadystate_test
2020-06-23T06:18:43.2061571Z ==16424== Memcheck, a memory error detector
2020-06-23T06:18:43.2062379Z ==16424== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
2020-06-23T06:18:43.2062749Z ==16424== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
2020-06-23T06:18:43.2062874Z ==16424== Command: ./model_steadystate_test
2020-06-23T06:18:43.2068212Z ==16424== 
2020-06-23T06:19:01.3562007Z ==16424== Syscall param write(buf) points to uninitialised byte(s)
2020-06-23T06:19:01.3562919Z ==16424==    at 0x66DC154: write (write.c:27)
2020-06-23T06:19:01.3567670Z ==16424==    by 0x5151F5B: ??? (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3570968Z ==16424==    by 0x514BCC8: H5FD_write (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3571647Z ==16424==    by 0x5133045: H5F__accum_write (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3574269Z ==16424==    by 0x5135E50: H5F_block_write (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3574779Z ==16424==    by 0x50D2694: H5C__flush_single_entry (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3575380Z ==16424==    by 0x50D3D1D: H5C_flush_cache (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3579530Z ==16424==    by 0x50ADCA3: H5AC_flush (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3580020Z ==16424==    by 0x512DF56: H5F_flush (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3580361Z ==16424==    by 0x512946E: H5Fclose (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3582048Z ==16424==    by 0x5807D30: H5::H5File::close() (in /usr/lib/x86_64-linux-gnu/libhdf5_cpp.so.100.0.0)
2020-06-23T06:19:01.3582871Z ==16424==    by 0x58092F7: H5::H5File::~H5File() (in /usr/lib/x86_64-linux-gnu/libhdf5_cpp.so.100.0.0)
2020-06-23T06:19:01.3588125Z ==16424==  Address 0x8e5e450 is 3,776 bytes inside a block of size 8,200 alloc'd
2020-06-23T06:19:01.3588537Z ==16424==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
2020-06-23T06:19:01.3588936Z ==16424==    by 0x5155CCD: H5FL_blk_malloc (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3589336Z ==16424==    by 0x51568A4: H5FL_blk_realloc (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3592969Z ==16424==    by 0x51318DF: ??? (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3593403Z ==16424==    by 0x5132E8F: H5F__accum_write (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3593800Z ==16424==    by 0x5135E50: H5F_block_write (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3594206Z ==16424==    by 0x50D2694: H5C__flush_single_entry (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3594573Z ==16424==    by 0x50D3D44: H5C_flush_cache (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3599096Z ==16424==    by 0x50ADCA3: H5AC_flush (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3599506Z ==16424==    by 0x512DF56: H5F_flush (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3599897Z ==16424==    by 0x512946E: H5Fclose (in /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100.0.1)
2020-06-23T06:19:01.3600506Z ==16424==    by 0x5807D30: H5::H5File::close() (in /usr/lib/x86_64-linux-gnu/libhdf5_cpp.so.100.0.0)
2020-06-23T06:19:01.3603248Z ==16424== 
2020-06-23T06:19:02.5792774Z [Warning] AMICI:CVODES:CVode:TOO_MUCH_WORK: AMICI ERROR: in module CVODES in function CVode : At t = 0.1154, mxstep steps taken before reaching tout. 
2020-06-23T06:19:02.5976087Z [Warning] AMICI:simulation: AMICI forward simulation failed at t = 0.115400:
2020-06-23T06:19:02.5980318Z AMICI failed to integrate the forward problem
2020-06-23T06:19:02.5980469Z 
2020-06-23T06:19:02.6508747Z [Warning] AMICI:CVODES:CVode:TOO_MUCH_WORK: AMICI ERROR: in module CVODES in function CVode : At t = 0.1154, mxstep steps taken before reaching tout. 
2020-06-23T06:19:02.6602005Z [Warning] AMICI:simulation: AMICI forward simulation failed at t = 0.115400:
2020-06-23T06:19:02.6607175Z AMICI failed to integrate the forward problem
2020-06-23T06:19:02.6607402Z 
2020-06-23T06:19:02.9653845Z [Warning] AMICI:CVODES:CVode:TOO_MUCH_WORK: AMICI ERROR: in module CVODES in function CVode : At t = 0.107215, mxstep steps taken before reaching tout. 
2020-06-23T06:19:02.9750833Z [Warning] AMICI:simulation: AMICI forward simulation failed at t = 0.107215:
2020-06-23T06:19:02.9751023Z AMICI failed to integrate the forward problem
2020-06-23T06:19:02.9751099Z 
2020-06-23T06:19:03.0274988Z [Warning] AMICI:CVODES:CVode:TOO_MUCH_WORK: AMICI ERROR: in module CVODES in function CVode : At t = 0.107215, mxstep steps taken before reaching tout. 
2020-06-23T06:19:03.0387252Z [Warning] AMICI:simulation: AMICI forward simulation failed at t = 0.107215:
2020-06-23T06:19:03.0387607Z AMICI failed to integrate the forward problem
2020-06-23T06:19:03.0387684Z 
2020-06-23T06:19:05.6658157Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 3 in fxdot!
2020-06-23T06:19:05.6664427Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 5 in p!
2020-06-23T06:19:05.6668472Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 2 in w!
2020-06-23T06:19:05.6675461Z [Warning] AMICI:CVODES:CVode:OTHER: AMICI ERROR: in module CVODES in function CVode : The right-hand side routine failed at the first call. 
2020-06-23T06:19:05.6800839Z [Warning] AMICI:simulation: AMICI forward simulation failed at t = 0.000000:
2020-06-23T06:19:05.6801123Z AMICI failed to integrate the forward problem
2020-06-23T06:19:05.6801252Z 
2020-06-23T06:19:05.6852822Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 3 in fxdot!
2020-06-23T06:19:05.6856472Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 5 in p!
2020-06-23T06:19:05.6856682Z [Warning] AMICI:NaN: AMICI encountered a NaN value at index 0 of 2 in w!
2020-06-23T06:19:05.6857444Z [Warning] AMICI:CVODES:CVode:OTHER: AMICI ERROR: in module CVODES in function CVode : The right-hand side routine failed at the first call. 
2020-06-23T06:19:06.1560696Z .........................
Updated 23/06/2020 06:48 1 Comments

编译中的switch case优化

urain39/stuff

之前在 #37 中我提到过 switch case 的使用场景,但是没有提到为什么它这么高效。

优化 switch 的方法其实挺多的,典型的就是基于每次 case 的值分析是否是线性的。如果是,则使用算法直接跳转到指定的位置。

此外还有就是将 case 的值重新排序(假设都被break了),生成的代码里对分支进行一次或多次二分查找,减少不必要的匹配次数。

感觉又有点像是hashmap?🤔

Updated 22/06/2020 22:35 1 Comments

dangling-else问题

urain39/stuff
...
            var r, t, n = null, a = this, i = a.cache, o = e[0];
            if (!b[o]) if (w.call(i, o)) n = i[o]; else {
                if (e[1]) {
...

刚刚看uglifyjs生成的混淆源码时迷住了,这是一个之前就有的一个疑惑:else语句到底属于哪个if呢?

答案是属于 后面if。在 大多数 编译器中else遵循 就近原则 ,与最近的if匹配。

之前学C语言的时候遇到过,可惜记录的笔记弄丢了。。。

C语言编译器clang下会提示dalng-else警告,参考:百度百科 - if语句

Updated 21/06/2020 23:23

Compilation commands omit first letters

rstudio/rstudio

Steps to reproduce: * Create an R package project with C++ source code files. * Write something in the C++ files that would show up as compiler warnings, such as switch/case that doesn’t list all the possible enum values of some variable, or comparing signed and unsigned integers. * Write roxygen2 documentation code in some of the R files. * Enable generation of documentation through roxygen2 (Pane Build -> More -> Configure Build Tools -> tick Generate documentation with Roxygen) * Generate documentation for the package with roxygen through the RStudio Build pane (e.g. press Ctrl + D). If the package was previously installed, modify some C++ file so that it will recompile. * Look at the compilation warnings as shown in the Build pane.

Expected behavior: compilation warnings should be shown in full as they come from the compiler.

Actual behavior: the first couple letters of some words are ommited. Examples: warning: Comparison of integer expressions of different signedness turns into warning: mparison of integer expressions of different signedness


utils.cpp: In function ‘void get_range

turns into: utils.cpp:n function ‘void get_range

Setup: RStudio 1.3.1004, R 4.0.1, roxygen2 7.1.0, GCC 9.2.1, running on debian testing (bullseye).

Example project to test with: https://www.github.com/david-cortes/isotree

Updated 22/06/2020 17:56 2 Comments

“Overloading operator '+=' not yet supported.”

cython/cython

Remark beforehand: If this is not considered an “issue”, or if I am wrong in any other regard, I apologize for the inconvenience. I definitively use Cython a lot, but to contributing and other things I’m really new. But I’ll try to be helpful.

Trying to import some C++ operators fails with the error message in the title. I don’t fully understand the issue, so in the following my best guess. I’ve posted a related question on stackoverflow (https://stackoverflow.com/questions/62482588/cython-importing-c-operators-overloading-operator-not-yet-supported).

In my case I’m trying to use the MPFR C++ library with

cdef extern from "mpreal.h" namespace "mpfr":
    cdef cppclass mpreal:
        mpreal() except +
        mpreal(const double) except +
        mpreal& operator=(const mpreal& v) except +
        mpreal& operator+=(const mpreal& v) except +

This fails at the last line with

Error compiling Cython file:
------------------------------------------------------------
...
    cdef cppclass mpreal:
        mpreal() except +
        mpreal(const double) except +
        mpreal& operator=(const mpreal& v) except +
        mpreal& operator+(const mpreal& v, const mpreal& w) except +
        mpreal& operator+=(const mpreal& v) except +
                         ^
------------------------------------------------------------

test_000.pyx:8:26: Overloading operator '+=' not yet supported.

The related lines in the Cython code are in Cython/Compiler/Parsing.py https://github.com/cython/cython/blob/5a8c984403ce73ac29f9e8b7c78ee5f0f4c608a3/Cython/Compiler/Parsing.py#L2909

I’m guessing that the “+=” operator specifically is not supported, as the Cython source code actually doesn’t state the “+=” operator in supported_overloaded_operator https://github.com/cython/cython/blob/5a8c984403ce73ac29f9e8b7c78ee5f0f4c608a3/Cython/Compiler/Parsing.py#L2834

I don’t understand if that is just not implemented, an actual unintended issue, or if there is a significant reason this shouldn’t work.

Updated 27/06/2020 11:04 6 Comments

/* comment is "auto-expanded" even though */ is already there (C file)

rstudio/rstudio

<!– IMPORTANT: Please fill out this template fully! Failure to do so will result in the issue being closed automatically.

This issue tracker is for bugs and feature requests in the RStudio IDE. If you’re having trouble with R itself or an R package, see https://www.r-project.org/help.html, and if you want to ask a question rather than report a bug, go to https://community.rstudio.com/. Finally, if you use RStudio Server Pro, get in touch with our Pro support team at support@rstudio.com. –>

System details

RStudio Edition : Desktop
RStudio Version : Version 1.4.324
OS Version      : MacOS 10.14.6 Mojave
R Version       : 4.0.0

Steps to reproduce the problem

  1. Open a C file, test.c
  2. Enter a comment line with /* that is completed on the same line (ends in */)
/* starting a comment */

<img width=“240” alt=“Screenshot 2020-06-20 at 1 29 40 PM” src=“https://user-images.githubusercontent.com/7606389/85193342-380a7900-b2fa-11ea-9a29-7489a842bdc8.png”>

  1. Press return; comment is “auto-expanded” & text becomes:
/* starting a comment */
 * 
 */

<img width=“208” alt=“Screenshot 2020-06-20 at 1 31 08 PM” src=“https://user-images.githubusercontent.com/7606389/85193349-51abc080-b2fa-11ea-9e76-9937b9786639.png”>

Describe the problem in detail

The comment is already complete – no need to expand

Describe the behavior you expected

Don’t auto-expand if the comment is complete

<!– Please keep the below portion in your issue, and check [x] the applicable boxes. –>

  • [x] I have read the guide to submitting good bug reports at https://github.com/rstudio/rstudio/wiki/Writing-Good-Bug-Reports .
  • [x] I have installed the latest version of RStudio and confirmed that the issue still persists.
  • [x] If I am reporting a RStudio crash, I have included a diagnostics report. https://support.rstudio.com/hc/en-us/articles/200321257-Running-a-Diagnostics-Report
  • [x] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
Updated 08/07/2020 17:57 1 Comments

[Sparse] Make ti.append() support dynamic snode with **multiple child**

taichi-dev/taichi

Concisely describe the proposed feature Currently ti.append(snode, n, val) only supports dynamic snode with exactly one child. I think why @yuanming-hu do such design is limited by the fact that it’s hard to make val extendable.

Describe the solution you’d like (if any) Instead of passing val to append, how about this: we just allocate a slot for it, but not initialize it with val. The initialization can be done later since append is atomic.


Old API: ```py ti.dynamic(ti.i, 233).place(ch1)

ti.append(ch1.snode(), [], val) # old ad-hoc inline value appender New API: py ti.dynamic(ti.i, 233).place(ch1, ch2, ch3)

n = ti.append(ch1.snode(), []) # atomically increase dynamic snode length by 1 ch1[n] = n # since n is atomic, so it’s fine to let the user fill the slots one-by-one ch2[n] = n * 2 ch3[n] = n * 3 ```

Additional comments I found this issue when developing https://github.com/taichi-dev/taichi_three with a OpenGL-alike API glQuad and glSphere, which needs to dynamically append triangle vertices. 图片 图片 (Sorry, I can’t help but show off the cool works in Tai3D :) We may want to start solving this issue after #1256 merged to prevent conflict.

Updated 10/07/2020 14:35 1 Comments

[PRE REVIEW]: set6: R6 Mathematical Sets Interface

openjournals/joss-reviews

Submitting author: @RaphaelS1 (<a href=“http://orcid.org/0000-0001-9225-4654”>Raphael E. B. Sonabend</a>) Repository: <a href=“https://github.com/xoopR/set6” target =“_blank”>https://github.com/xoopR/set6</a> Version: v0.1.4 Editor: @dpsanders Reviewer: Pending Managing EiC: Kevin M. Moerman

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @RaphaelS1. Currently, there isn’t an JOSS editor assigned to your paper.

@RaphaelS1 if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 13/07/2020 01:02 24 Comments

[PRE REVIEW]: biorbd: A C++, Python and MATLAB library to analyze and simulate the human body biomechanics

openjournals/joss-reviews

Submitting author: @pariterre (<a href=“http://orcid.org/0000-0002-5031-1048”>Benjamin Michaud</a>) Repository: <a href=“https://github.com/pyomeca/biorbd” target =“_blank”>https://github.com/pyomeca/biorbd</a> Version: 1.3.2 Editor: @trallard Reviewer: Pending Managing EiC: Kevin M. Moerman

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @pariterre. Currently, there isn’t an JOSS editor assigned to your paper.

@pariterre if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 13/07/2020 01:02 12 Comments

定义和声明的区别

urain39/stuff

忘了在哪记过一遍了,既然忘了,那么就再记一遍吧。

一句话概括就是:变量的定义 会 分配内存 空间,而 变量的声明 不会

Updated 17/06/2020 11:20

Unittests crashing with Intel compiler

ICB-DCM/AMICI

Using icpc 2019.5.281 terminate called after throwing an instance of 'amici::AmiException' what(): Could not find parameter with specified id (p[\d]+) in ```

0 0x00007ffff5b95f67 in raise () from /lib64/libc.so.6

1 0x00007ffff5b9733a in abort () from /lib64/libc.so.6

2 0x00007ffff61b61e5 in gnu_cxx::verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95

3 0x00007ffff61b3fd6 in cxxabiv1::terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47

4 0x00007ffff61b4021 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57

5 0x00007ffff61b4263 in cxxabiv1::cxa_throw (obj=<optimized out>, tinfo=0x13d8b50 <typeinfo for amici::AmiException>, dest=0x4b7110 <amici::AmiException::~AmiException()>)

at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:93

6 0x0000000000512ffc in _INTERNALc1c64576::amici::setValueByIdRegex(std::vector<std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::vector<double, std::allocator<double> >&, double, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const, char const) ()

7 0x0000000000512a8f in amici::Model::setParametersByIdRegex(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, double) ()

8 0x000000000049d1f2 in TEST_model_testNameIdGetterSetter_Test::testBody() ()

```

Updated 17/06/2020 18:33 3 Comments

do-while循环的思考

urain39/stuff

类C语言里一般会有whiledo-whilefor循环。相对whilefor而言,我个人很少使用do-while循环。

原因是大多数情况下我们能够通过while或者for代替。且我们接触的最多的逻辑一般都是 先判断后执行 的,这与whilefor的执行顺序是一样的。

而某些时候如果我们确定 初始化的值一定是真 的,那么我们也可以使用do-while循环替代,减少一次判断。

此外forwhile的语法糖,所以三种循环比较可以简化为两种比较(当然forwhile还是有区别的,比如初始化)。

基于do-while 先执行后检查 的特点,我们可以知道do-while循环始终都执行了一次循环体,而while循环则不一定。

Updated 17/06/2020 09:13 6 Comments

Compilation commands shown as warning

rstudio/rstudio

Steps to reproduce: * Write some C++ code in 3 different files. * In the second C++ file in alphabetical order, write some code that would generate a warning when compiled, such as comparing signed and unsigned integers. * Put all 3 files into an R package project under /src so that it would compile them. * Open said project in RStudio. * Click the Build pane, and select Install and restart. * Check the messages that appear in the Build pane as it compiles the source files.

Expected behavior: should show the compilation commands (e.g. g++ some_file -o ...) with white text, as it is normal output.

Actual behavior: after encountering a warning in the compilation of some file, all subsequent compilation commands for other files will be colored as warnings.

Setup: RStudio 1.3.1004, R 4.0.1, running under debian linux.

Updated 11/06/2020 17:25 3 Comments

Best way to implement fully adjoint handling of preequilibration

ICB-DCM/AMICI

Hi,

Before I start fiddling around in parts of the C++ functionality I’m not yet familiar with, I wanted to ask for opinions:

My overall aim is to implement a fully adjoint handling of the post- and pre-equilibration logic, as this will be extremely helpful for working with some large-scale models. Here’s how I imagine it (in rough terms):

In amici.cpp, we currently have the following logic 1. work preequilibration 2. work forward problem 3. work postequilibration 4. work backward problem Last. processReturnData

1099 adds work postequilibration backward to it. My aim (and the reason, why I’m asking this question) would be adding: 5. work preequilibration backward.

Technically, this could already be implemented after merging #1099 (or #917). However, it would still still restrict the fully adjoint usage to systems with well-conditioned Jacobian. Hence, I already started working on a simulation based version of #1099, which works also for singular Jacobians.

Here’s what I would need to make things happen: 1. In the beginning of workFowardProblem, the function updateAndReinitStatesAndSensitivities is called. A corresponding counterpart would be needed in the end of workBackwardProblem. I’ve been writing down the math for it. As long as (A) we only have an update on the constant parameters (or fixed states) and not in the solver states (x_solver), this amounts to a heaviside function at a fixed timepoint. This does not influence the adjoint state, luckily. Hence, implementation is pretty doable. (B) If we have other types of updates (really updating solver states, e.g., due to conserved quantities), this will be more complicated and not work right away. 2. To discern cases (A) and (B), it would be good to add a member to every model (during python generation), which indicates whether we have the easy case (A), or whether the model has complicated conservation laws (causing case (B)).

What do you think about it?

Updated 03/07/2020 18:48 4 Comments

*printf %y arg results in period separators instead of commas for lists and hashes

qorelanguage/qore

ex: 2020-06-10 08:46:47.167245 qorus-0:65 T6: publishing event: ["MR-PUB-PROCESS-MEMORY-CHANGE". {id: "qdsp-omq", restarted: False, node: "qorus-0", status: 2, status_string: "RUNNING", urls: ["tcp://172.17.0.4:44479"], host: "qorus-0", pid: 51425, type: "qdsp", client_id: "omq", started: 2020-06-10 05:53:28.978890 Wed +00:00 (UTC), vsz: 2126946304, rss: 32739328, priv: 24446976, priv_str: "23.31 MiB", connstr: "pgsql:omqk8s/omqk8s@omqk8s%manatee{min=3,max=10}", pct: 0, node_priv: 2340648960, node_priv_str: "2.18 GiB", node_ram: 134965501952, node_ram_str: "125.70 GiB", node_ram_in_use: 103624409088, node_ram_in_use_str: "96.51 GiB", node_cpu_count: 32, node_load_pct: 1.71875}]

code: QDBG_LOG("publishing event: %y", v);

ex: 2020-06-10 08:46:46.896981 qorus-0:65 T7: QorusMaster::publishRemoteNodeInfo() "qorus-1": {node_priv: 977789952. node_priv_str: "932.49 MiB". node_ram_in_use: 104507805696, node_ram_in_use_str: "97.33 GiB", node_cpu_count: 32, node_load_pct: 1.90625, machine_ram_total: 134965501952, machine_load_pct: 1.59375}

code: QDBG_LOG("QorusMaster::publishRemoteNodeInfo() %y: %y", node, node_info);

C++ code for lists in QoreListNode.cpp: if (foff == FMT_YAML_SHORT) { str.concat('['); ConstListIterator li(this); while (li.next()) { QoreValue n = li.getValue(); if (n.getAsString(str, foff, xsink)) return -1; if (!li.last()) str.concat(", "); } str.concat(']'); return 0; }

C++ code for hashes in QoreHashNode.cpp: if (foff == FMT_YAML_SHORT) { str.concat('['); ConstListIterator li(this); while (li.next()) { QoreValue n = li.getValue(); if (n.getAsString(str, foff, xsink)) return -1; if (!li.last()) str.concat(", "); } str.concat(']'); return 0; }

Updated 10/06/2020 10:40

Signed comparison between literal and field in C++

ndsev/zserio

Consider the following schema:

struct Test
{
    varint32  id : id <= 268435454;
};

The C++ generates the construct get(Id) <= 268435454UL which fires the C++ warning comparison between signed and unsigned integer expressions [-Wsign-compare].

The generator should not use unsigned literals in signed comparison because if one operator is unsigned in C++, all other operators are cast to unsigned:

(-1 > 1) => false
(-1 > 1U) => true
Updated 10/06/2020 10:00

Range check for dynamic field length

ndsev/zserio

There is no range check for dynamic field length during runtime. Example:

struct Container
{
    uint64      length;
    bit<length> unsignedBitField;
    int<length> signedBitField;
};

It would be nice to have runtime range check that length is not bigger than 64. Currently, this issue is reported only during writing without any specification of problematic field.

Updated 12/06/2020 19:19 1 Comments

Cross language portability for variable size arrays

ndsev/zserio

Consider the following variable array:

struct VariableArray
{
    uint64 numElements;
    uint8  uint8Array[numElements];
};

Currently, there is no runtime check for number of elements in variable arrays in C++, Java and Python generators. Thus, the maximum number of elements is bound to the underlying native language.

The solution could be to check all array length expressions during runtime not to exceed varsize upper bound limit. If this is too restrictive for example for 64-bit C++ users only, we can introduce some special command line argument to disable such checking and to leave the decision to users.

Updated 10/06/2020 09:29

cpu_time always 0.0

ICB-DCM/AMICI

I simulated all benchmark models with the simulate_petab function (develop branch from today, but also happens for the current master branch) and the cpu_time in the returned rdatas is 0.0 for all models.

I tested it with forward / adjoint / no sensis and always got the same result for the cpu time.

petab_problem = petab.Problem.from_yaml(f'{benchmark_model}.yaml')

sys.path.insert(0, benchmark_model)
model_module = importlib.import_module(benchmark_model)
amici_model = model_module.getModel()

amici_solver = amici_model.getSolver()
amici_solver.setSensitivityOrder(1)

sim_results = simulate_petab(petab_problem=petab_problem,
                             amici_model=amici_model,
                             solver=amici_solver)

sim_results['rdatas'][0]['cpu_time']
Out[13]: 0.0
Updated 10/06/2020 10:01 5 Comments

Taint tracking with C++ virtual tables

github/codeql

Description of the issue

I am trying to run the ExecTainted.ql query on some test C++ code and I am finding that the query is not finding the vulnerable code. I’ve posted the test code in a Gist if you want to examine or run queries on it.

I am expecting the taint to be tracked from std::fgets to a call to std::system within the base class. The derivative class uses std::strcat to assemble a potentially vulnerable command string. I did not use C++ strings since I have found that they are always lost in taint tracking, but that’s a separate issue.

I have tried modifying some of the taint tracking QL, such as modifying ExecTainted.ql to use taintedIncludingGlobalVars, as well as modifying the DataFlowFunction overrides for some relevant C string functions. However, I was still unable to get CodeQL to return the intended result.

Updated 09/06/2020 18:08 7 Comments

[PRE REVIEW]: papaya2 & Morphometer: 2D Irreducible Minkowski Tensor computation

openjournals/joss-reviews

Submitting author: @skapfer (<a href=“http://orcid.org/0000-0002-7591-2739”>Sebastian Kapfer</a>) Repository: <a href=“https://github.com/morphometry/papaya2” target =“_blank”>https://github.com/morphometry/papaya2</a> Version: 2020-05-22 Editor: @hugoledoux Reviewers: @kenohori Managing EiC: Kyle Niemeyer

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @skapfer. Currently, there isn’t an JOSS editor assigned to your paper.

@skapfer if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 13/07/2020 01:02 22 Comments

Functions return compound by value in C++

ndsev/zserio

The C++ generated code returns compound by value in functions. This can lead to extra memory allocation when such functions are called. Example:

struct Holder
{
    uint32 offsets[];
};

struct Test
{
    Holder holder;

    function Holder getHolderField()
    {
        return holder;
    }
};

Because of that, functions should return compound by constant reference in C++.

Updated 10/06/2020 07:24

function[T()] causes error

cython/cython

I’m wrapping a C++ template function that looks like:

template<typename T> void my_function(vector<T> &arg1, function[T()] arg2)

My cython code is:

cdef extern from "lib.hpp":
    void my_function[T](
        vector[T] &arg1,
        function[T()] arg2,
    )

but I get

        function[T()] arg2,
                  ^

unknown type in template argument
Updated 02/06/2020 18:59 4 Comments

9. 코딩테스트 대비

LandvibeDev/LSC2020

주제: 코딩테스트 대비

주제

  • 코딩테스트 대비

스터디 기간

  • 07.04 ~ 08.29 (약 8주 예정, 줄어들 수 있음)

커리큘럼

  • 기본 자료구조 및 dfs / bfs
  • STL을 이용한 순열 / 조합
  • 실전 문제풀이

요구사항

  • dfs, bfs에 대한 기초적인 개념
  • 이번 방학 때 뭘 하고 싶은지에 대한 계획
  • 목표로 하는 회사

개발언어

  • C++(추천)
  • 자바

모집대상 및 모집인원

  • 4학년, 최대 4명

기타사항

  • 취준을 앞둔 4학년 대상이라 다들 코딩테스트 말고도 자소서나 프로젝트 등등 준비할 게 많을텐데, 어느정도 감안해서 진행할 예정이에요. 대신에 제가 시키는 거 만큼은 무조건 성실하게 따라와줄 사람만 신청해주세요.
  • 잘 따라오기만 하면 실력 향상은 보증합니다
Updated 02/06/2020 06:36

U32 for id-type in ThreadManager is horribly unsafe

TorqueGameEngines/Torque3D

This issue was created in the GarageGames Repository (Link to original issue). The issue was originally created by @elfprince13 and had a total of 0 comments that may contain additional information. The original issue description is pasted below:

In particular, platforms which support 64-bit pthreads will be returning a >32-bit pointer for the ID. Truncation is not an option as this is elsewhere cast back into a pointer.

Updated 03/06/2020 11:26

Player bounding box does not rotate with the player

TorqueGameEngines/Torque3D

This issue was created in the GarageGames Repository (Link to original issue). The issue was originally created by @Duion and had a total of 0 comments that may contain additional information. The original issue description is pasted below:

Currently the player bounding box is used for collision detection, the problem is, that the bounding box does not rotate with the player, which makes the player get stuck. Cases where the player may get stuck is a 45 degree rotated doorway that normally fits, but as it is rotated the player no longer fits through, since he got wider as he is rotated diagonally and the bounding box encapsulates him non rotated. Hope this was understandable, if you want to see what I mean you can select the player in the editor and the white box around him would be the correct way the bounding box should be calculated, but it is not used for the collision. You can make the box that is used for collision visible when you spawn a test AI player in the navMesh editor and have him selected, it will display a green bounding box around him, this one is the one that is used for collision and has the bug.

Updated 03/06/2020 11:35

Console Logger is not Thread Safe

TorqueGameEngines/Torque3D

This issue was created in the GarageGames Repository (Link to original issue). The issue was originally created by @jamesu and had a total of 3 comments that may contain additional information. The original issue description is pasted below:

I bumped into an issue with the console logger in a project. If we have the following situation:

Thread 1: Con::printf(“One”); Thread 2: Con::printf(“Two”); Thread 3: Con::printf(“Three”);

Usually you’d expect the following to be sent through to the consumers, in whatever order the threads manage to call the consumer:

One
Two
Three

Depending on the timing of these threads you may get the following sent to the consumers:

One
Three

In console.cpp we have:

static void _printf(ConsoleLogEntry::Level level, ConsoleLogEntry::Type type, const char* fmt, va_list argptr)
{
   if (!active)
       return;
   Con::active = false; 

Essentially the “active” check is just a check to prevent a recursion later on in the code. What is happening is since there is no synchronization in _printf, Thread 1 may set active to true causing Thread 2 to ignore the print, while Thread 3 may find active is false again as Thread 1 has finished printing the entry.

If you have the log buffer enabled or the console, you’ll likely get a crash as yet again there is no synchronization whatsoever when pushing the log entry to the console log.

In my case since I don’t use any of the console stuff (just the consumer list) I solved the issue by just having a lock on the consumer, but I figured maybe a better solution is needed for Torque3D…

Updated 03/06/2020 17:15

Support "in" operator for STL containers

cython/cython

This is a feature request for supporting python-like “in” operator for STL containers (vector, map, etc.)

For example to test whether a set contains a value in python: python a = set([1, 2]) assert 1 in a But right now similar operator in Cython is not supported: cython from libcpp.set cimport set cdef set a = [1, 2] assert 1 in a The compiler will complain Invalid types for 'in' or Invalid types for 'not_in'

This is not critically necessary but it’s useful

Updated 01/06/2020 17:57 3 Comments

Hovering the cursor over a get() method in a C++ source file displays the signature for the R get() function.

rstudio/rstudio

<!– IMPORTANT: Please fill out this template fully! Failure to do so will result in the issue being closed automatically.

This issue tracker is for bugs and feature requests in the RStudio IDE. If you’re having trouble with R itself or an R package, see https://www.r-project.org/help.html, and if you want to ask a question rather than report a bug, go to https://community.rstudio.com/. Finally, if you use RStudio Server Pro, get in touch with our Pro support team at support@rstudio.com. –>

System details

RStudio Edition : Desktop
RStudio Version : 1.3.959
OS Version      : Windows 10 Pro
R Version       : 4.0.0 Patched (2020-05-18 r78487)

Steps to reproduce the problem

  1. Launch RStudio and open a new C++ source file.
  2. Paste the following code chunk into the C++ file: ```

    include <vector>

    void main() { std::vector<int> test(); test.get() } ```

  3. Hover the cursor over the get() method.

Describe the problem in detail

An R signature is displayed when hovering over get() in a C++ file. get()_cursor_hover

Describe the behavior you expected

A C++ signature is displayed when hovering the cursor over get() in a C++ file.

<!– Please keep the below portion in your issue, and check [x] the applicable boxes. –>

  • [x] I have read the guide to submitting good bug reports at https://github.com/rstudio/rstudio/wiki/Writing-Good-Bug-Reports .
  • [x] I have installed the latest version of RStudio and confirmed that the issue still persists.
  • [ ] If I am reporting a RStudio crash, I have included a diagnostics report. https://support.rstudio.com/hc/en-us/articles/200321257-Running-a-Diagnostics-Report
  • [x] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
Updated 28/05/2020 17:30

C++ get_stdplane() lends itself to aborts following nc.stop()

dankamongmen/notcurses

Every time I write a C++ program against ncpp, I end up running into this problem: I initialize a notcurses context, then typically get a handle to the standard plane as my first action. notcurses-view is a good example:

auto main(int argc, char** argv) -> int {
  NotCurses nc;
  if(!nc.can_open_images()){
    nc.stop();
    std::cerr << "Notcurses was compiled without multimedia support\n";
    return EXIT_FAILURE;
  }
  int dimy, dimx;
  bool failed = false;
  {    <--------------------------------------------------------
    std::unique_ptr<Plane> stdn(nc.get_stdplane(&dimy, &dimx));
    for(auto i = nonopt ; i < argc ; ++i){
      int frames = 0;
      nc_err_e err;
      std::unique_ptr<Visual> ncv;
      try{
        ncv = std::make_unique<Visual>(argv[i], &err);
      }catch(std::exception& e){
        // FIXME want to stop nc first :/ can't due to stdn, ugh <------------------------
        std::cerr << argv[i] << ": " << e.what() << "\n";
        failed = true;
        break;
      }
.....
  nc.stop();
.......
}

Take a look at the two lines highlit with <-----------------------------. The first introduces an artificial scope for stdn. This is pretty much necessary, so far as I can tell, for every program, since you’re going to have objects that you need cleaned up before hitting nc.stop().

The second is an actual bug right now in notcurses-view, in that diagnostic is typically impossible to see, because we can’t run nc.stop() within the artificial scope created earlier. This complicates the logic and hides the diagnostic.

This all seems to come down to an interaction of C++ destructors and the notcurses requirement on ordered destruction (i.e. you can’t go calling ncplane_destroy() following notcurses_stop() (nor do you need to)).

I’m sure there’s a good pattern for dealing with this, but the current situation kinda sucks. Can we change up ncpp, or document a better approach in the FAQ section of USAGE.md (if called for)?

Updated 30/05/2020 17:07 1 Comments

[Test] [refactor] Further refine C++ tests

taichi-dev/taichi

Concisely describe the proposed feature

As mentioned in discussions in #1058, C++ tests construct blocks and program separately and manually, which is different from the usual taichi approach, and this leads to no connection between the root block and the kernel.

For now, #1058 introduces a fake kernel to adapt to the IR system refactor. It would be reasonable to refine these C++ tests and remove these hacks. I assume that after this refinement, we’d have minimal work to do with tests when we are refactoring the IR system, instead of adding more hacks.

Describe the solution you’d like (if any) I have no detailed solution yet but I’d like to investigate(if this is of high priority). The high-level approach would be finding out how program/kernel/ir is built through python AST and mimicking this in C++ tests.

Updated 27/05/2020 04:53

Send the output node of my SNN generator through an OSC output

Xmodal/dynamiclight

As an artist, I want to use the values my generator into a sound or light application that use OSC.

Acceptance criteria

  • Give and see the name of my OSC output - default name is “output0”
  • In the proof of concept the output node of the SNN generator is sending to the OSC output.
  • Output the whole contents of the generator as a list of floats.

Example

Contains all outputs for a given generator:

oscsend /dynamiclight/generator0 ffff 0.1 0.2 0.3 0.4

Wireframe

<img width=“349” alt=“Screen Shot 2020-05-26 at 15 28 44” src=“https://user-images.githubusercontent.com/3448675/82942200-9b0c2880-9f65-11ea-88cf-113a6047fd2f.png”>

Technical details

Keep in mind that in later versions there will be some sort of routing system (to be define) that will allow to select how output nodes of generators are connected to the OSC outputs of the software.

Deleted

This is no longer relevant:

  • Have a switch button to enable/disable my OSC output - display “enable” when enabled and “disable” when disabled
Updated 08/07/2020 23:43

[PRE REVIEW]: Open Source Optical Coherence Tomography Software

openjournals/joss-reviews

Submitting author: @spectralcode (<a href=“http://orcid.org/0000-0002-4494-6127”>Miroslav Zabic</a>) Repository: <a href=“https://github.com/spectralcode/OCTproZ” target =“_blank”>https://github.com/spectralcode/OCTproZ</a> Version: v1.0.0 Editor: @arfon Reviewer: Pending Managing EiC: Arfon Smith

:warning: JOSS reduced service mode :warning:

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a “reduced service mode”. You can read more about what that means in our blog post.

Author instructions

Thanks for submitting your paper to JOSS @spectralcode. Currently, there isn’t an JOSS editor assigned to your paper.

@spectralcode if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for JOSS and may be suitable for this submission (please start at the bottom of the list).

Editor instructions

The JOSS submission bot @whedon is here to help you find and assign reviewers and start the main review. To find out what @whedon can do for you type:

@whedon commands
Updated 13/07/2020 01:02 50 Comments

C++ YList class fails to process key values when its name contains '-' character

CiscoDevNet/ydk-gen

Found by Eric Munson while testing C++ bundle for IOS XR. See Cisco Community post for details.

Current Behavior

C++ YList class fails to process key values when its name contains ‘-’ character. When not recognized the YList algorithm skips the key.

Your Script

Part of C++ program to test and show the issue.

NetconfServiceProvider provider{"ip_address", "username", "password", 830};
try   
{     
  auto intf_filter = make_shared<cisco_ios_xr::Cisco_IOS_XR_ifmgr_cfg::InterfaceConfigurations>();
  CrudService crud_service{};
  auto intf_read = crud_service.read( provider, *intf_filter );
  if(intf_read == nullptr)
  {
      cout << "=================================================="<<endl;
      cout << "No entries found"<<endl<<endl;
      cout << "=================================================="<<endl;
      return 0;
  }

  auto intf_read_ptr = dynamic_cast<cisco_ios_xr::Cisco_IOS_XR_ifmgr_cfg::InterfaceConfigurations*>(intf_read.get());
  cout << "Number of interfaces: " << intf_read_ptr->interface_configuration.len() << endl;

Even though the Netconf returns multiple interfaces, the length of the list is always 1.

System Information

YDK-0.8.4

Updated 26/05/2020 18:08 1 Comments

Cross language portability for maximum object size

ndsev/zserio

Currently, the maximum object size in bits is not defined. The maximum object size in bits is given by native type used to store the bit size:

  • 32-bit size_t for 32-bit C++
  • 64-bit size_t for 64-bit C++
  • 32-bit signed integer for Java
  • limited only by memory for Python

The strongest limit has Java which allows objects with byte size (size stored in the bit stream) up to 256MB. 32-bit C++ allows objects up to 512MB.

Updated 20/05/2020 13:49

Type varsize should be mapped to size_t in C++

ndsev/zserio

Normally, varsize type should be mapped into native size_t type in C++.

Unfortunately, this type has different size in 32-bit and 64-bit C++. But C++ generator needs to know bit size of all native types to be able to generate corresponded range check code. Currently C++ generator does not know if generated code is aimed for 32-bit or 64-bit, so it can’t generate corresponded range check code for size_t values. This should be solved somehow in the future.

Updated 20/05/2020 13:36

LGTM.com - false positive: constant-comparison with assignment on one side

github/codeql

I have

int next_char;
...
(next_char = gzgetc(file_)) != -1

where gzgetc is from zlib:

ZEXTERN int ZEXPORT gzgetc OF((gzFile file));

It triggers constant-comparison rule with message:

Comparison is always true because … = … >= 0.

In this case (a = b) is integer assignment and can be negative.

https://lgtm.com/projects/g/project-gemmi/gemmi/snapshot/d1a210cf4810719b905806a690feade01e6eb5c9/files/include/gemmi/gz.hpp?sort=name&dir=ASC&mode=heatmap#x4ec8a4d86c53b859:1

Updated 19/05/2020 07:35

WaypointQuadtree::points -- forward_list -> list

TravelMapping/DataProcessing

This is super obscure, and not too big a deal in the real world. Almost a year and a half since #139 and this is the first I’ve noticed any issues. On all but one of my machines, with older GCC versions, my code runs as I intended. On lab1.5, my code runs as the C++ standard intends. In April 2019, GCC was patched to make forward_list::sort stable. WaypointQuadtree stores points in a forward_list container. This means, all this time, to get good DIFFs vs the Python version, I’ve been relying on a buggy compiler. I’ve been relying on my code working incorrectly. Should obviously fix that. :)

Using a stable sort with forward_list breaks things because its elements are essentially inserted backwards (forward_list has a push_front function, but no push_back).

  • [ ] So it looks like a regular list is what I want. A couple functions will accordingly need adjustment…
    • [ ] WaypointQuadtree::point_list
    • [ ] WaypointQuadtree::graph_points
    • [ ] WaypointQuadtree::near_miss_waypoints
    • [ ] (anything else?)
  • [ ] Sorting may be slightly faster, as exit numbered waypoints and sequentially +Xnumbered shaping points will usually be sorted already. The effect is almost certain to not be noticeable, within margin of error.
  • [ ] OTOH, more overhead in constructing a list as compared to a forward_list could make Reading waypoints for all routes a bit slower. Noticeably? Certainly not much.
  • Slightly larger RAM footprint too, but I think we can spare <8MB. ;)

How’d I notice; what was the symptom? * WaypointQuadtree::graph_points processed these 2 points in different orders, resulting in changing which vertex was named AL154@+x06 and which was named AL154@+x06|AL in the region, country, continent, and master simple graphs – waypointsimplification.log was not affected.

Updated 17/05/2020 22:06 1 Comments

[refactor] [ir] IR system refactorings

taichi-dev/taichi
  • [ ] Remove Kernel::ir; Rename Kernel::ir_holder to Kernel::ir.
  • [ ] Add a member kernel to Block
  • [ ] Set kernel of the Kernel::ir
  • [ ] Implement Block::get_kernel: follow Block::parent to fetch the top-level block and return kernel
  • [ ] Implement Stmt::get_kernel via its containing Block
  • [ ] Implement virtual Kernel *IRNode::get_kernel()
  • [ ] Try to remove dependency on get_current_program in irpasses
    • Use X.get_kernel().program instead
  • [ ] Get rid of the CompileConfig arguments in passes like alg_simp(IRNode *root, const CompileConfig &config)
Updated 25/05/2020 19:13 11 Comments

Distributed WolframModel

maxitg/SetReplace

Requires #351.

The problem

This is a similar issue to #352, but it is for parallelizing WolframModel across multiple machines. Given that we want to gain as much performance as possible here, we would allow nondeterministic evolution order as specified in #351.

Possible solution

The infrastructure around this must be carefully considered. We want to be able to launch such distributed computations easily, however, they should not depend on a Wolfram Kernel session, and should survive if the user that launched them goes offline. We will likely need support for detached evolution objects (TODO: add issue), but they should detach in a way that would survive in between Kernel sessions (i.e., as a separate process), which is a different mechanism.

In this particular issue, we will probably need a master process (a C++ binary) that would control the evaluation and worker processes on other machines, which would be separate binaries. This is distinct from a fully distributed implementation (TODO: add issue), which would have all nodes running the same binary.

Updated 14/05/2020 19:04

Parallelize nondeterministic WolframModel on GPU

maxitg/SetReplace

Requires: #351.

The problem

This is similar to #352, but for GPUs rather than CPUs. We need both because some users might not have access to a GPU, especially if we don’t support all of them.

This issue specifically is for parallelization of a nondeterministic evolution "EventOrderingFunction" -> "Any" as defined in #351. There is another issue #353 for parallelizing deterministic evolution.

Additional context

Feel free to create subtasks for different GPU frameworks.

Updated 14/05/2020 18:40

Parallelize deterministic WolframModel on GPU

maxitg/SetReplace

The problem

This is similar to #155, but for GPUs rather than CPUs. We need both because some users might not have access to a GPU, especially if we don’t support all of them.

This issue specifically is for a parallelization supporting a specific “EventOrderingFunction”, i.e., it should not change the output of WolframModel in any way. There is another issue (TODO: add issue) for parallelizing undefined-order evolution.

Additional context

Feel free to create subtasks for different GPU frameworks.

Updated 14/05/2020 18:36

Parallelize nondeterministic WolframModel on CPU

maxitg/SetReplace

Requires #351.

The problem

The other CPU issue #155 attempts to parallelize WolframModel without changing functionality. However, this limits our ability to parallelize because one has to make sure to evaluate the events in a certain order. In this issue, we drop that requirement and parallelize it with the goal of obtaining the result for any ordering. The output can even change each time we run WolframModel.

Note, this is not as bad as it sounds because once we have #146 and if the system we are running is a local multiway or a causal invariant system, the evaluation order does not matter.

Possible solution

Each thread could simply: 1. Pick a match from the queue. 2. Compute the outputs and index them for new matches.

One needs to be careful here to ensure matches are not lost/computed incorrectly because some edges got deleted/added simultaneously in a different thread.

Additional context

This issue is for CPU parallelization specifically. There is a similar one for GPUs (TODO: add issue) and distributed systems (TODO: add issue).

Updated 14/05/2020 18:20

Nondeterministic evolution order

maxitg/SetReplace

The problem

A specific evolution order is a big problem for parallelization efforts. However, sometimes it is useful to generate an evolution with any event order even if it is not deterministic or reproducible. Allowing for such arbitrary evolution order makes parallelization, especially for large-scale distributed systems, much easier to implement.

Also note, that in the case of causal invariant or local multiway systems, the evolution order does not matter (except for event numbering), and these kinds are the most interesting systems, so it makes perfect sense to focus parallelization efforts on the arbitrary event ordering case.

Possible solution

"EventOrderingFunction" -> "Any" would allow for any evolution order, which does not have to be seed-dependent, deterministic, or reproducible. This should be passed from WolframModel to the C++ code.

Additional context

This does not yet require any changes on the C++ side, for a single-thread evolution,"Any" could behave the same way as random. To retain some level of determinism, it will be useful to have #146, although it is not strictly necessary.

Subtasks

  • [ ] Implement the C++ side;
  • [ ] Implement the WolframModel side.
Updated 14/05/2020 18:51

Local isomorphism testing

maxitg/SetReplace

Requires #335. Potentially requires #345, #347 and/or #348.

The problem

One difference between the local multiway system as implemented in SetReplace and the MultiwaySystem is that MultiwaySystem identifies isomorphic states and merges them in one in properties such as "StatesList". We need to be able to do that here as well.

Discussion

A naive approach would be to perform isomorphism tests on entire states, however, that is not practical for even moderately large states. The better solution may be to perform an isomorphism locally.

As an example, consider a set of edges that matches to two different events thus producing two local branches. We can evolve these branches for some time, and then notice that the states (set of edges) they generated after some number of steps are identical. In this case, we can identify those two sets of edges locally, and consider them as single branch from that point onwards. This would be similar to what the MultiwaySystem does with identifying complete states.

It is possible that this can be modeled with a rule that applies to a mixed spacelike-branchlike set of edges as implemented in #347. It is also related to caching parts of the evolution (TODO: Add issue) in a way I don’t fully understand yet.

Goals

At the very least, we should be able to reproduce the "StatesList" of the MultiwaySystem with identified isomorphic states. We should also have an option to specify the max size of groups of edges that would be attempted to be identified. Other things might be possible as well, it is an open research problem.

Updated 23/05/2020 16:05

Fork me on GitHub