text:
improve msbuild instance scoring

We pick msbuild using a scoring system, by looking at VS msbuild instances, the msbuild bundled with OmniSharp and Mono if available.
Current status:

we always give preference to VS msbuild instance
we use the bundled msbuild only if VS/Mono is not available
minimum Mono is 5.2.x

This worked well when VS 2017 was the latest one - now that VS 2019 is there, and .NET Core 3.0 is there, things break down a bit.
Currently, when the user has VS 2017 installed, we pick MsBuild from there, however that doesn't work with .NET Core 3.0.
We might also sometimes pick VS 2017 over VS 2019.
New status:

we still give highest preference to VS
additionally we score extra points for msbuild 16 (VS 2019, msbuild bundled in OmniSharp, new Mono)
minimum Mono is 5.18.x (which is inline with the fact we moved to 472)

With this change, since the msbuild bundled with OmniSharp is v16, it gets picked over VS 2017.
VS 2017 is never picked over VS 2019 anymore.
If the user has VS 2019 installed, we will still pick that one over our bundled version, as it gets scored higher.
The consequence of this change is that we will actually never pick VS2017 anymore on Windows, since we'll always prefer our bundled version. I think this is fine, since I would expect OmniSharp to always be aligned with the latest VS, and if that's not found, to use its own bundled msbuild.
Fixes #1541
It should fix some other issues / behavioral inconsistencies we have.

Curious to know what validation you did for this change, eg what os/vs/sdk matrix did you test? :)

I tested on:

Windows with VS2017 + OmniSharp (picks standalone)
Windows with VS2019 + OmniSharp (picks VS2019)
Windows with VS2017 + VS2017 + OmniSharp (picks VS2019)
macOS with Mono 5.18.1 + OmniSharp (picks mono)

At the end it's a small change really, we just score msbuild 16 higher now.
There might be a negative side effect if you relied on VS2017 msbuild - now you will be getting standalone. But as soon as you install VS2019, we pick the VS instance again.
And as we have seen many people complain when VS2017 is picked over standalone instance cause .NET Core 3.0 doesn't work then.

In the past, we've talked @nguererra about adding an option to let you select the build in msbuild over the one in VS. Now that we're flipping the default, do you think it makes sense for us to add an option to request VS 2017 msbuild over the built in one? That might help people who encounter

There might be a negative side effect if you relied on VS2017 msbuild -

I know we've had people mention that they're unable to upgrade to later VS versions.

We could maybe expose the ability to configure MS build or to change the msbuild version at runtime.

makes sense

@filipw Are there any more changes that you would be making here? Also will we need a change log for this?
We were thinking to merge this and put it out for the C# extension release next week. Thoughts ?

I will just add the ability to manually override the path to a predefined one (or to manually choose the preferred flavor VS2019, VS2017, Mono, StandAlone) and it will be good to go.
I should have some time tomorrow to finish this.
We'll handle changelog separately since there is a bunch of other changes that needs describing anyway so we'll just to it in one go.

Thanks, lgtm!

@rchande @david-driscoll as discussed, I added an option to provide custom MSBuild Path.
It's done via msbuild section in the omnisharp.json config.
For example, to force VS2017 (name is for display purposes only and is optional):
{
    "MSBuild": {
        "MSBuildOverride": {
            "MSBuildPath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\MSBuild\\15.0\\Bin",
            "Name": "filip's msbuild"
        }
    }
}

To force a specific Mono:
{
    "MSBuild": {
        "MSBuildOverride": {
            "MSBuildPath": "~/mono/5.18.1/lib/mono/msbuild/15.0/bin",
            "Name": "filip's msbuild"
        }
    }
}

And more advanced example, with custom property overrides:
{
    "MSBuild": {
        "MSBuildOverride": {
            "MSBuildPath": "C:\\code\\msbuild\\Current\\Bin",
            "Name": "filip's msbuild"
             "PropertyOverrides": {
                 "MSBuildToolsPath": "C:\\code\\msbuild\\Current\\Bin",
                 "MSBuildExtensionsPath": "C:\\code\\msbuild"
                 "CscToolPath": "C:\\code\\msbuild\\Current\\Bin\\Roslyn",
                 "CscToolExe": "csc.exe"
             }
        }
    }
}

The override from the user is always picked over any other candidate.

authors: akshita31 david-driscoll filipw rchande


text:
ms-dotnettools.csharp-1.23.17

Issue Type: Bug
When I tried to switch between projects file:
[error] Error: Extension 'ms-dotnettools.csharp' CANNOT use API proposal: quickPickSeparators.
Its package.json#enabledApiProposals-property declares:  but NOT quickPickSeparators.
The missing proposal MUST be added and you must start in extension development mode or use the following command line switch: --enable-proposed-api ms-dotnettools.csharp
Extension version: 1.23.17
VS Code version: Code 1.63.0 (7db1a2b88f7557e0a43fec75b6ba7e50b3e9f77e, 2021-12-07T06:26:56.179Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 x 2592)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
63.75GB (50.46GB free)

Process Argv
--crash-reporter-id f4120432-0ac5-4510-8f46-3752362169d7

Screen Reader
no

VM
0%

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30384385
pythondataviewer:30285071
vscod805cf:30301675
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
pythonrunftest32:30373476
pythonf5test824:30373475
javagetstartedt:30391933
pythonvspyt187:30373474
vsaa593cf:30376535
pythonvs932:30410667
vscop804:30404766
vscop940:30404999
vsrem710cf:30405999
vscexrecpromp3t2:30407763

I was told in a previous issue that this is fixed in a prerelease:
https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.23.18-beta2

I have the same problem. I'm using Mac. I downloaded the beta version mentioned, but it still has the same problem.

Same issue.
Extension version: 1.23.17
VS Code version: 1.63.2
OS version: macOS 11.6.1
Restricted Mode: No

Same issue as well.

Same issue 👍
I just installed v1.24.0-beta1 and got an error

Any help around this?

Same issue happening on my Linux machine.
Extension version: 1.23.17
VS Code version: 1.63.2
OS version: Ubuntu 20.04
Restricted Mode: No

Same issue happening on my Linux distro
Extension version: 1.23.17
VS Code Version: 1.63.2
OS Version: Pop Os! 21.10
Restricted Mode: No
.Net SDK: 6.0

Same issue happening on my Linux distro
Extension version: 1.23.17
VS Code Version: 1.63.2
OS Version: Pop Os! 21.10
Restricted Mode: No
.Net SDK: 6.0

Duplicate of https://github.com/OmniSharp/omnisharp-vscode/issues/4970

Duplicate of https://github.com/OmniSharp/omnisharp-vscode/issues/4970

how much size it will take (mbs)

source: gharchive/issue

authors: 1thorsheikh0 ALENTL PsychoNineSix alan994 aureliosaraiva dethmourne explorest faeizazizi gregg-miskelly kellan-cartledge

repo: OmniSharp/omnisharp-vscode

license: mit

license_type: permissive

license_source: bigquery


text:
Extension Authoring: Goto Implementation, New Item:class, interface

In VS Code 1.3 it looks like it's possible to add custom menu items to context menu and etc. What about add GotoImplementation possibility? And also I would like to see in project file's context menu option to add class, interface with automatically generated right namespace. PLEASE

VS Code now supports Go To Implementation as a feature. We'll be tracking the work to add this with https://github.com/OmniSharp/omnisharp-vscode/issues/37.

authors: DustinCampbell agoretsky


text:
Multiple Languages

Is your feature request related to a problem? Please describe.
I'm currently self hosting OneUptime and I'm very happy with it. As we currently only serve customers in Germany it would be nice to offer a translation for the basic UI elements.
Describe the solution you'd like
Use a library like i18n to create translations and let us contribute to the multiple language "packs". Also add the possibility to save a specific language to the profile and/or load based on browser.
Describe alternatives you've considered
Let everything in English only and deal with the customers. Preferably we could use different languages.

yes, it's a good function

This is a duplicate of #462. Although the requests are different, it is asking the same thing. I18N is possible, it needs to be done on the front end. react-i18next looks like a suitable fit for this. We need to discuss how we will get additional languages as well.

Closed because of Duplicate #372

authors: kashalls teger torbenraab

repo: OneUptime/oneuptime

license_source: github-api


text:
🛑 Google is down

In f18e1c8, Google (https://www.google.com) was down:

HTTP code: 429
Response time: 271 ms

Resolved: Google is back up in 822176e after 19 minutes.

license: MIT


text:
Short solution needed: "Get timestamp with Lua" (nginx-lua)

Please help us write most modern and shortest code solution for this issue:
Get timestamp with Lua (technology: nginx-lua)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments to make solution explained.
Link to this issue in comments of pull request.

Get timestamp with Lua

repo: Onelinerhub/onelinerhub


text:
Policy gets stuck trying to save lumber when it needs to discard resources

Two options:

rather than select keep, select discard to encourage making a decision and not getting stuck in a loop
Remove this part of the game, and randomly discard appropriate number of resources - makes game state-action space smaller.

Will work on this tomorrow

Working on this today. I think I have to also update the Neural Net for the DQN since we are shrinking the action space

removed road builder card in push to main.

authors: dreyesol jmvantreeck

repo: OnlyUseMeRocket/auto-catan


text:
Commit 8af6042 causes cyclic dependencies if multiple RunAlways targets exist

The recent commit cleaning up executes handling broke projects with multiple targets with an always: tag.
Line 162 in buildcontent.go causes every executes statement with an always: tag to depend on every other executes statement with an always tag. This causes dependency cycles and breaks the generated CMakeLists.txt.
Otherwise that commits works really well, commenting out that line makes the build work fine.

@EaselinkBachmann Thanks for this finding. Could you please confirm that the proposed fix https://github.com/Open-CMSIS-Pack/cbuild2cmake/pull/228 also works correctly for your use cases?

@EaselinkBachmann Thanks for this finding. Could you please confirm that the proposed fix #228 also works correctly for your use cases?

The fix works great! Thanks for the quick fix.

I noticed that always targets are now dependencies of every other target, regardless of which project they came from. In our case this is not much of an issue since our always steps are mostly pre-build steps and avoid modifying output files in case the content would be unchanged, but it is something to consider if creating such cross-project dependencies for every always target is intended.

authors: EaselinkBachmann brondani


text:
visitors and github added #354 done

Title and Issue number
Title : Total visitors and Star us button added in github
Issue No. : #354
Code Stack : React
Close #354
Video (mandatory)

Checklist:

[ X] I have mentioned the issue number in my Pull Request.
[X ] I have commented my code, particularly in hard-to-understand areas
[ X] I have created a helpful and easy to understand README.md if its a new page/tech stack
[X ] I have gone through the  contributing.md file before contributing

Are you contributing under any Open-source programme?

[X ] I'm a GSSOC-EXT contributor
[X ] I'm a HACKTOBERFEST contributor

@VinayLodhi1712 update in latest footer

now you can check @jeevan10017

@VinayLodhi1712, resolve conflicts and make the footer as you showed in this upper. Visitors count background colour amk=tch to the dark.

Visitors count background colour amk=tch to the dark. what does this mean

Visitors count background colour amk=tch to the dark. what does this mean

sorry typing error, make that visitors count the background to dark, match the footer theme

source: gharchive/pull-request

repo: Open-Code-Crafters/FitFlex


text:
Support disposable messages

Hey,
My producer creates disposable messages that are consumed by readallasync.
Is it possible for you to dispose it automatically without needing me to do it manually?
Thanks!

I'm a little confused about the question.  Dispose what?
Channels are not disposable objects.  Once it's empty and complete, that's it.
If you await channelReader.ReadAllAsync(e=>/*do something*/), then once it's done, it's done.
Could you clarify more?

Are you suggesting making a disposable extension?  It would probably be a .DisposeAsync() method and you'd have to use await using.
And so if the .DisposeAsync() is called, it would call .Complete() and then wait for all the results to be finished.
There is already a .CompleteAsync() extension.  https://github.com/Open-NET-Libraries/Open.ChannelExtensions/blob/master/Open.ChannelExtensions/Extensions._.cs#L127-L142
So you'd expect a .CreateDisposable() extension that would return an IAsyncDisposable struct?

No. In the channel, im reading from an tcpclient and push the data in a wrapped object to the queue.
This data is essentially borrowed from ArrayPool and needs to be returned.
Without that addition, my consumer needs to call message.dispose on itself, but thats something, ChannelExtensions could do for me i guess

And: The channel theoretically never completes as long as a client is connected to the socket.

So aren't you doing this?
channelReader.ReadAllAsync(async e => {
  await e.Data;
  await e.DisposeAsync();
}):

I want to help. :)

This is exactly what i currently do. But cant it be integrated into the library?
If the message is disposable, it should be disposed?

So it's not the intention of the library to get too far into the woods of individual implementations.
The primary goal is to reduce the boiler plate for common scenarios.
To simply 'automatically' dispose of objects is inadvisable.
That said, you can very easily write your own extension that does exactly that.

If these objects require manual disposal, then it still seems like the above code example is the right way to go.
It's explicit, and readable.  If it's a common operation that you do, writing your own extension inside your code be a great improvement.
channelReader.ProcessMessages();

Another way to do this, is with .Pipe() or .PipeAsync().  Look into them.
Basically this can happen:
Producer writes to channel .Pipe() reads the data and passes on the message to another channel that does the disposal.
This can decouple the processing in a way that can (or won't [depending]) improve overall performance.
You'd want to be sure to have a capacity value set on the pipe operation so you don't pile up disposal operations.
Now on to another point.  If the objects don't require disposal, manual disposal can (but might not) degrade your overall performance as the GC might actually do a better job at it.
If you are using an ArrayPool, then it can be tricky to be sure to get the array back to that pool.
But again, that's a custom implementation.
I'm sorry if this isn't helpful.  I still might not understand the problem fully.

Probably going offline for tonight.  But I'll try to get back to you asap.

authors: JKamsker electricessence


text:
star citizen gamefixes

remove un-needed overrides
add environment variable radv_zero_vram

radv_zero_vram should never be a permanent setting. if it needs to fix a graphics isssue then it needs to be report to upstream mesa

thanks for the feedback, holding off for upstream

authors: GloriousEggroll mactan-sc

repo: Open-Wine-Components/umu-protonfixes


text:
fix(packages): lock datasets version

Description

There seems to be a bug with newer datasets version. Ref: https://discord.com/channels/1104757954588196865/1111279858136383509/1230806736127004674
It seems that downgrading to the current locked version fixes it for them.
File "/usr/local/lib/python3.10/dist-packages/fsspec/core.py", line 316, in _un_chain
    if "::" in path
TypeError: argument of type 'PosixPath' is not iterable

Motivation and Context

How has this been tested?

Screenshots (if appropriate)
Types of changes

Social Handles (Optional)

Also solves #1544

repo: OpenAccess-AI-Collective/axolotl


text:
fix: masetr-slave maybe inconsistent due to bgsave may provide a wrong binlog offset

该PR修复了 Issue #2805
问题重述：
Pika做bgsave时会给DB::dbs_rw_这把大锁上写锁，而所有命令执行时都会在链路上给这把dbs_rw_上读锁。所以bgsave上了写锁以后，相当于暂时阻写来打快照，在bgsave对dbs_rw_的写锁范围内，做了两件事：1 打快照  2 获取此时的最新binlog offset(从节点全量传输完快照之后才知道该从哪里开始续传binlog)
问题在于：在命令执行链路上的读锁，其范围只覆盖了DoCommand()，也就是写DB，Dobinlog()是在该读锁放开以后采取执行的。这就意味着：当bgsave处成功独占了dbs_rw_之后，写链路上可能还有未执行完的DoBinlog（也就是还有Binlog正在写入），那么bgsave此时获取的binlog offset实际上是一个偏前的位置，按照正确预期bgsave应该等到这些Binlog完全落盘了才能去获取Binlog offset，因为pika的binlog目前不幂等，得到一个偏前的位置，会在后续造成Slave重复消费某部分Binlog，进而导致主从不一致。
解决方案：
本PR将命令执行链路上针对dbs_rw_的读锁修改了覆盖范围，让他将DoCommand，Dobinlog都覆盖进去。换而言之，一条普通命令在执行前会先获取dbs_rw_的读锁，之后在完成了WriteDB, WriteBInlog之后才会放开读锁。这就能确保当bgsave能给dbs_rw_加上独占的写锁时，之前的所有请求/命令对应的Binlog也已经落盘，这样获取到的Binlog Offset就是准确的。
另外由于调整了锁范围，所以进行了性能测试对比（本PR vs 原代码），大致结论为：

1 每次负载500W请求，共测试4次，平均值如下：
原代码：QPS为153401， P99为3.279ms
本PR：QPS为152590， P99为3.359ms
结论，本PR在500万请求量下，QPS降幅在0.08%，P99的增幅在2%左右，未见明显性能下降。

2 每次负载1亿请求，共测试1次，具体如下：
原代码：QPS为144849， P99为3.615ms
本PR：QPS为145694， P99为3.335ms
结论：本PR在1亿请求量下未引起性能下降。

PS:

单条负载大小512KB，具体测试命令如下：
./redis-benchmark -h  * -p 9221 -t set -n 100000000/5000000 -r 10000000000000 -d 512 -c 300 --threads 20
详细测试数据请见下方附1
This PR fixes Issue #2805.

Problem Restatement:
When Pika performs bgsave, it acquires a write lock on the DB::dbs_rw_ mutex, while all command executions acquire a read lock on the same dbs_rw_ mutex. Consequently, when bgsave acquires the write lock, it temporarily blocks writes to take a snapshot. Within the scope of bgsave's write lock on dbs_rw_, two tasks are performed: 1) taking a snapshot and 2) obtaining the latest binlog offset (to determine where to resume binlog transmission after the slave completes the snapshot).
The issue lies in the fact that the read lock on the command execution path only covers DoCommand(), which involves writing to the DB. DoBinlog() is executed after the read lock is released. This means that when bgsave successfully acquires the exclusive write lock on dbs_rw_, there may still be pending DoBinlog operations (i.e., binlogs still being written). Thus, the binlog offset obtained by bgsave is prematurely captured. Ideally, bgsave should wait for all pending binlogs to be fully written before capturing the binlog offset. Since Pika's binlog is currently non-idempotent, obtaining a premature binlog offset can lead to the slave repeatedly consuming certain portions of the binlog, resulting in master-slave inconsistencies.
Solution:
This PR modifies the read lock coverage on the command execution path for dbs_rw_. It extends the read lock to encompass both DoCommand and DoBinlog. In other words, a normal command will first acquire a read lock on dbs_rw_, and it will only release this read lock after completing both WriteDB and WriteBinlog. This ensures that when bgsave acquires the exclusive write lock on dbs_rw_, all previous requests/commands and their corresponding binlogs have been fully written. As a result, the binlog offset obtained will be accurate.

附1：
1 bgsave PR
参数: 500W负载，benchmark 50线程数：
./redis-benchmark -h  * -p 9221 -t set -n 5000000 -r 10000000000000 -d 512 -c 300 --threads 50
本PR:
平均QPS: 152590
平均p99: 3.359
第一次：
Summary:
throughput summary: 152257.98 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.955     0.832     1.871     2.415     3.735    20.815
第二次：
Summary:
throughput summary: 152239.45 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.949     1.040     1.863     2.407     3.391    27.967
第三次：
Summary:
throughput summary: 152457.61 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.947     0.576     1.855     2.407     3.423   124.287
第四次：
Summary:
throughput summary: 153407.19 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.940     0.704     1.855     2.407     3.295   119.295
2 原版
平均QPS: 153401
平均p99: 3.279
第一次：
Summary:
throughput summary: 154573.84 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.923     1.320     1.847     2.391     2.927    23.999
第二次：
Summary:
throughput summary: 152452.97 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.946     1.064     1.871     2.399     3.023    19.279
第三次：
Summary:
throughput summary: 153407.19 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.935     0.560     1.855     2.415     3.279    84.991
第四次：
Summary:
throughput summary: 152225.53 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
1.951     0.560     1.871     2.407     3.535   187.391
参数: 1亿负载，benchmark 20线程数：
./redis-benchmark-cjh -h  * -p 9221 -t set -n 100000000 -r 10000000000000 -d 512 -c 300 --threads 20
1 本PR:
Summary:
throughput summary: 145694.02 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
2.051     0.296     1.887     2.455     3.335  2142.207
2 原版代码：
Summary:
throughput summary: 144849.66 requests per second
latency summary (msec):
avg       min       p50       p95       p99       max
2.063     1.064     1.895     2.455     3.615  2351.103

repo: OpenAtomFoundation/pika


text:
🛑 Bot API is down

In 21fc6aa, Bot API ($BOTS_API_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bot API is back up in 05b5a24.

repo: OpenBB-finance/uptime


text:
🛑 Bot Platform is down

In 0534715, Bot Platform ($PAYMENTS_BACKEND_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bot Platform is back up in ab1385e.


text:
Tooltips not fully visible in a flex table

Any reason this element is "overflow: hidden"?
.flexRow [class |= "flexCol"] {
  box-sizing: border-box;
  position: relative;
  overflow: hidden;
}

It breaks tooltips in tables:

It may also be the reason why the "add region" dropdown box gets partially hidden.

Not just "add region" but any dropdown box.

Well, that' shows me to test more thoroughly
It was added because the length of the guid sometimes breaks the layout, and as a precaution against other elements doing the same. But clearly not a good idea..

Removing the overflow for the said element and adding these lines
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;

to an element like .fieldItem would truncate long strings as in the screen below.

However we should use it with care, because sometimes we may need more lines per a table row. I'd suggest we add a class ".ellipsis" with above properties where we know it may break the layout.
I can create a PR if you're ok with such solution (?).
If an ellipsis is not desirable then we can just use the plain "overflow: hidden". Either way, the overflow shouldn't be set for the parent element (like flexCol-*).

This was fixed in #1362.
There's already a noOverflow class that can be used to selectively add ellipses, it should only be used on divs and spans that contain text.

This was fixed in #1362.
There's already a noOverflow class that can be used to selectively add ellipses, it should only be used on divs and spans that contain text.

authors: Dekker3D jjeffryes mariodian

repo: OpenBazaar/OpenBazaar-Client


text:
Fix Linux scaling

Fixes #79

Ok @rmisio how's this look?

repo: OpenBazaar/openbazaar-desktop


text:
Consideration of test leakage?

In section 4.3 of Observed versus latent features for knowledge base and text inference, Toutanova and Chen describe the issue of generating training/test sets of edges from networks that contain inverse relationships - if the triple (h, r, t) is in the training test set and its corresponding inverse triple (t, r', h) is in the test set, the learner will be able to easily pick up the pattern and there will likely be an overly-optimistic evaluation.
I think this is applicable both to random splitting and to some extent time-based splitting. Since this represents a significant advancement in the generation of benchmark datasets, I would encourage you check their workflow (which is described pretty well in the paper) and include an implementation in your package.

Yes, we took great care to not have this kind of trivially inferred relationships (inverse relations, super-relations) in the test set!

Awesome! How would this work for anyone who wants to take the same care with generation of new benchmark data sets using your package?
It would be worth mentioning that you did this in the manuscript and referencing this paper to serve as a proper warning for downstream users on the dangers that can come from this. For example, the machine learning community loves using the UMLS hierarchy as a benchmark dataset, but I think very few understand the kinds of relationships in it and they are often making unfair evaluations on it.

This is briefly mentioned (as much as the 2-page limit allowed) in the manuscript.
"Special focus was put on the robustness and difficulty of the test set, which
contains only entities that are also present in the training set and does not
contain relations that can be trivially inferred from the training set (such as
reverse edges of symmetric relations, inverse relations or super-relations)."
Filtering of these trivially inferred relations from the test set is done by the scripts that generate the train-test split.
@annabreit Do you want to add something here?

I've also written an application note for Bioinformatics. I found it very tricky to get the right kind of information into the manuscript, and totally understand.
Since this is about a software application, these types of explanations (in long form) are crucial. I've found they're pretty effective when including them in full in the documentation, along with code examples on how to deal with the problems in practice. I also really enjoyed this talk when thinking about how to write documentation (that was more like writing a manuscript in the end) https://www.youtube.com/watch?v=t4vKPhjcMZg. Documentation is also a place where you can be much more liberal/granular in references, since these also take a lot of space in the manuscript and I found myself skipping a few when I did one...
I wouldn't say I'm perfect either, but you could consider the difference between my paper describing PyBEL (https://academic.oup.com/bioinformatics/article/34/4/703/4557184) and the documentation on ReadTheDocs (https://pybel.readthedocs.io) as an example.

authors: cthoyt matthias-samwald

repo: OpenBioLink/OpenBioLink


text:
Data set list visually cut off

This is happening in Chrome and Firefox:

Not critical, but visually unappealing.

I dont see this anymore. Ill reopen if it comes back

repo: OpenChemistry/distiller


text:
Redesign of consent screen

Includes feedback from #456 and testing on test2:

styled for smaller screens, tested in many browsers
removed IE8 support

Todo:

[ ] Fix failing SSO test

Thanks! I've fixed the failing SSO test and prevented the page from scrolling to the top when opening a slide-in.

repo: OpenConext/OpenConext-engineblock


text:
Add support for the claims parameter

This issue is imported from pivotal - Originaly created at May 9, 2019 by Bart Geesink
See: https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
This feauture would allow an RP to request claims in an id_token: This would enable us to support client implementations that are only tested with the Google openID Connect server.

@bartgeesink do we only include the requested claims in the ID Token if the RP uses the response_type=id_token - e.g. is not asking for an access_token? Or do we also include them when the client is also requesting an access_token with which this client can access the user_info endpoint? And what naming convention with regards to the claims do we support? I propose using the `oidc` attribute in https://github.com/OpenConext/OpenConext-oidcng/blob/master/src/main/resources/oidc/saml_mapping.json as this maps 1-1 with the user attributes converted from the SAML response. (Okke Harsta - May 13, 2019)

Implementation based on https://connect2id.com/products/server/docs/guides/requesting-openid-claims (Okke Harsta - May 13, 2019)

repo: OpenConext/OpenConext-oidcng


text:
Terminal Output Bug

I asked to delete all files and then it started to bug and I got multiple replies at the same time in the terminal

Wow, that was a fun read! What model were you running?
tar -czvf backup.tar.gz rm -rf * 🤣
I think what you mean by multiple replies in the same time was reported here: https://github.com/OpenDevin/OpenDevin/issues/476 and a fix is in progress: https://github.com/OpenDevin/OpenDevin/pull/531

Wow, that was a fun read! What model were you running?
tar -czvf backup.tar.gz
rm -rf * 🤣
If I understand correctly the report, I think multiple replies in the same time was reported here: #476 and a fix is in progress: #531

I'm running OPENAI because Claude 3 is rate limited I heard.

GPT-4 or GPT-3.5?

GPT-4 or GPT-3.5?

GPT 4

Sorry, the LLM was so amazing, it worked so hard to decide to make a backup only to delete it immediately after!
On a serious note, though, perhaps we should clarify somewhere that the agent's abilities are not limited to /workspace. They cannot be too limited if we need it to install software, so it can also "delete all" software. I don't know what to recommend, I'm not sure it was clear that it can destroy more than its previous files? You may want to tell it clearly next time what files to delete. I really don't know how likely it is that it makes a mess, really, GPT-4 is pretty smart. And you can always restore the docker container from the image, anew.

Let's close this in favor of https://github.com/OpenDevin/OpenDevin/issues/565
Thanks for the report!

authors: PierrunoYT enyst rbren

repo: OpenDevin/OpenDevin


text:
feat(frontend): Add file picker to choose the working directory #221

Added a file picker feature to top of the chat window.
Now a user can select the directory to work with.
Once a directory is chosen the user has the option to edit the directory also.(i.e choose another directory)
I require backend help to initialise the model within the directory.

awesome! we may want to redesign this to match the agent/model pickers at some point, but this is a great start. I think good to ship as-is if others are happy w/ it

authors: Yashwanth-Chandrakumar rbren


text:
Frequency-Domain Hydrodynamic Analysis about OC4

Dear @jjonkman ,
Today, I attempted to use ANSYS AQWA as an alternative to WAMIT (since I do not have access to the latter) to calculate the frequency-domain hydrodynamic parameters for the OC4 wind turbine. Below, I have attached some of the geometric parameters and wave conditions used during the calculations. I have modeled the geometry of the floating platform and defined the baseline parameters following the reference (Robertson, A., Jonkman, J., Masciola, M., Song, H., Goupee, A., Coulling, A., Luan, C., 2014. Definition of the Semisubmersible Floating System for Phase II of OC4 (No. NREL/TP-5000-60601, 1155123).However, it seems there were some errors in my settings.
Beacuse when I imported the hydrodynamic parameter files generated by AQWA (.1, .3, .hst, .12s, .12d) into OpenFAST, the simulation produced incorrect results. Under a steady unidirectional wind of  U = 9 m/s and unidirectional irregular waves with Hs = 1.2646 m and Tp = 10 s, the wind turbine exhibited unreasonable platform displacements.
I have also included the erroneous simulation results below. Could you kindly help identify where my settings might be incorrect?
**AQWA settings below:

**Unreasonable results:

Thanks in advance.

Dear @axxyyyyyyyy378,
It looks like your OpenFAST model is physically or numerically unstable.
To isolate the problem, I would first disable second-order hydrodynamics.  Is your solution stable then?
If not, I would check that your ANSYS AQWA-developed first-order solution (.1, .3, .hst) is consistent with the first-order solution provided in the OpenFAST r-test, which was derived from WAMIT.
FYI: the body mass and inertia should not be needed to compute the first-order solution (.1, .3, .hst).  But the values you say you are using for the second-order solution are not correct because they only represent the platform itself, not the mass/inertia of the full floating offshore wind turbine.
Best regards,

Dear @jjonkman,
Thank you for your patient response. After reading your reply, I first disabled the second-order hydrodynamic calculations, but the results were still incorrect. I then manually compared the first-order solution generated by ANSYS AQWA with the reference solution provided by OpenFAST, and I found some mismatches in the hydrodynamic parameters. For instance, the hydrostatic stiffness coefficients for roll and pitch in the .hst file showed significant differences. I discovered that this issue was caused by an incorrect center of gravity setting in the model.
After correcting this, the .hst file (hydrostatic stiffness coefficients) results became consistent with the reference solution, and the results stabilized when the second-order hydrodynamic calculations were disabled. However, it is worth noting that there are still significant differences in the results of the .1 and .3 files (as shown in the attached figure). I am unsure if this indicates that the AQWA calculations are still incorrect. Could you kindly provide some guidance on this?
**significant differences in the results of the .1 files：

Thank you in advance!

Dear @axxyyyyyyyy378,
I'm not sure why your first-order AQWA solution differs from the WAMIT solution provided by NREL.  If it helps, the dimensional NREL solution is plotted in Figure 4-3 of the NREL/TP-5000-60601 report you reference.  How do your results compare when plotted on top of each other?
The full-system mass, center of mass, and inertias of the NREL 5-MW baseline wind turbine atop the OC4-DeepCwind semisubmersible are documented in my post dated Feb 13, 2020 in the following topic on our forum: https://forums.nrel.gov/t/oc4-deepcwind-semisubmersible-wamit-files/2203.
Best regards,

Dear @jjonkman,
Thank you for your response. As you mentioned, I compared the AQWA results with the NREL solution in Figure 4-3 of the NREL/TP-5000-60601 report. From the comparison, most results match well; however, there are significant differences in the surge-pitch elements (A15, B15) and sway-roll elements (A24, B24). What could be the possible reasons for this? Could you kindly provide some suggestions?

Best regards,

Dear @axxyyyyyyyy378,
Good question.  In addition to the sign flip on the 15 (surge-pitch) and 24 (sway-roll) coupling terms, I also see that the AQWA results are quite a bit smaller than WAMIT in magnitude for the 15, 24, 44, and 55 terms, while the results look nearly identical for the 11, 22, 33, and 66 terms.  Are you using the same reference point in AQWA as used by the WAMIT results, which is the intersection of the vertical centerline of the platform and still water level?
Best regards,

Dear @jjonkman,
Thank you for your patient response. It turns out you were absolutely correct—I mistakenly set the reference point at the actual center of gravity of the platform (13.46m below the waterline). When I adjusted the reference point to the intersection of the vertical centerline of the platform and the SWL, the results in .1 matched perfectly (see the figure below).
Subsequently, I recalculated the second-order hydrodynamic coefficients (.12s and .12d) with the reference point returned to the actual center of gravity of the platform (without considering the full wind turbine yet). Afterward, I conducted a comparison of the six-degree-of-freedom responses of the platform under a specific load condition (steady wind speed  U = 8 m/s , irregular waves H_s = 1.2646 m, T_p = 8 s) using AQWA results (.hst, .1, .3, .12s, .12d) and WAMIT reference results (see the figure below). The comparison shows excellent agreement between the two.
However, as you previously pointed out, when calculating second-order hydrodynamic coefficients, I need to account for the full wind turbine system, including the mass and inertia parameters of the tower, nacelle, and blades. Yet, based on the current results, it seems that considering only the floating platform has already yielded accurate outcomes, which leaves me somewhat puzzled.
**the results in .1 matched perfectly :

**comparison of the six-degree-of-freedom responses of the platform :

Best regards,

Dear @axxyyyyyyyy378,
When calculating the second-order potential-flow solution for HydroDyn, the full system mass, center of mass, and inertia should be used and the reference point for the hydrodynamic outputs should be the same as the first-order solution.  The reference point is user-specified in HydroDyn via PtfmRefxt/PtfmRefyt/PtfmRefzt and need not be the intersection of the vertical centerline of the platform and still water level in HydroDyn, but that point is the reference point used by the OpenFAST model of the DeepCwind semisumbersible used in the OpenFAST r-test.
If your results from AQWA match those from WAMIT without these settings, then perhaps the second-order effect is not playing a large role for the conditions you are simulating.
Regarding the "sparse" error, does the direction and frequency data in second-order solution include all combinations of direction and frequencies pairs?
Best regards,

Dear @jjonkman,
Thank you for your response. Your comments are very professional, and I now fully understand the issue with setting the reference point. As you mentioned, since the environmental loads I simulated were relatively mild, the second-order effects did not play a significant role.
To address this, I made adjustments by using the full system mass, center of mass, and inertia in AQWA, and ensured that the hydrodynamic output reference point matched the first-order solution's reference point. I then "correctly" calculated the second-order hydrodynamic coefficients in HydroDyn. Subsequently, I compared the platform displacement responses obtained using AQWA and WAMIT results in OpenFAST under a set of extreme loads (turbulent wind  U = 22.1 m/s, irregular waves Hs = 10.9 m, Tp = 16 s) to amplify the second-order effects. From the results (see the figure below), it is difficult to conclude that the two results align well, as there is a significant discrepancy in the pitch response. This seems to suggest that the second-order hydrodynamic coefficients from AQWA are still incorrect, but I cannot pinpoint the cause of the error. Do you have any other suggestions?
Regarding the "sparse data" error, the second-order hydrodynamic coefficient file (.12d, .12s) that generated the error includes all directions from -180° to 180° at 10° intervals (37 directions in total) and all frequencies from 0.03333 Hz to 0.57716 Hz at 0.01133 Hz intervals (47 frequencies in total). The total number of rows in the file is 533,022, which covers all wave direction and frequency data. However, when I include only a single wave direction in the .12d, .12s file, the total number of rows becomes 533,022/37 = 14,406, and the calculation proceeds without any errors.
**platform displacement responses obtained using AQWA and WAMIT results in OpenFAST:

Best regards,

Dear @axxyyyyyyyy378,
Regarding the second-order solution calculated by AQWA, have you plotted the QTFs against the equivalent results from WAMIT at 0 degrees wave direction (like you did with the added mass and damping matrices)?
Regarding the "sparse" error, presumably you mean 49 unique frequencies (rather than 47.  Regardless, it seems like you are missing a dimension in your QTF.  I would expect there to be 6nd^2nf^2 rows in the QTF, where nd = number of wave directions and nf = number of frequencies.  With nd = 37 and nf = 49, this would be 19,721,814 rows; you are missing the combinations of wave direction pairs.
Best regards,

Dear @jjonkman ,
Thank you for your response, but I’m not sure how to post-process the second-order hydrodynamic data or what kind of plots to create for comparison and validation. Do you have any suggestions?
Best regards,

Dear @axxyyyyyyyy378,
For the second-order data at a given wave direction (zero degrees), I would plot the QTF as a contour / surface plot as a function of the two frequencies.  The QTF is complex valued; so, you could plot the magnitude and phase or the real and imaginary components.  You could scale the data to physical units or keep the data nondimensional.
Best regards,

Dear @jjonkman,
Thank you for your prompt response. I compared the QTF magnitudes for three degrees of freedom (surge, heave, and pitch). However, the results show a significant discrepancy between the reference values from WAMIT and the values I obtained using AQWA. Considering that the first-order hydrodynamic coefficients matched very well previously, what do you think could be the reason for this difference?

Best regards,

repo: OpenFAST/openfast


text:
v2.5.0 libdiscon.so not found/recognized

Hi,
I just installed openfast 2.5.0 on Ubuntu 20.04.1 LTS and tried running the IEA-15-240-RWT monopile case. I made a few changes only in the InflowWind input file since some new variables were included in v2.5 as opposed to 2.4 and were missing in the input file. Everything else being untouched, I am getting this error linked to ServoDyn:
FAST_InitializeAll:SrvD_Init:BladedInterface_Init:The dynamic library ././ServoData/libdiscon.so
could not be loaded. Check that the file exists in the specified location and that it is compiled
for 64-bit applications.
FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR
The file libdiscon.so is present at that location. Is there a compatibility issue somewhere between the test case and the new OpenFAST version? If I disable the ServoDyn input, the simulation works fine.

How did you do your installation?  Where are your running the regression test?
If you are using git, you will need to do git submodule update to get all the updated input files from the r-test repository.
If you are using cmake and make to build the test case, you will need do make install to build and install the controller.  If you are doing it manually, you will need to manually build the controller.

How did you do your installation?  Where are your running the regression test?
If you are using git, you will need to do git submodule update to get all the updated input files from the r-test repository.
If you are using cmake and make to build the test case, you will need do make install to build and install the controller.  If you are doing it manually, you will need to manually build the controller.

Thanks for your response.
I ran the regression tests in the OpenFAST build directory, is that incorrect? I saw that for the 5MW turbine the three external controllers had to be compiled and installed manually. I had done that.
The test case I am looking at now has the *dll and *so files already in the ServoData folder. What am I supposed to compile here?

Thanks for your response.
I ran the regression tests in the OpenFAST build directory, is that incorrect? I saw that for the 5MW turbine the three external controllers had to be compiled and installed manually. I had done that.
The test case I am looking at now has the *dll and *so files already in the ServoData folder. What am I supposed to compile here?

For the cmake build system, the build directory is the correct place to run the regression tests with ctest.  If you setup the build directory with cmake -DBUILD_TESTING=On .. then you can just run make install and it will build the controller for you and install it into the regression tests in the build directory (it is slightly simpler than manually building the controller). These would be installed in the build directory at reg_tests/glue-codes/openfast/5MW_Baseline/ServoData/.
The path in your error above indicates that you may have copied the regression test over rather than using the cmake + ctest system.  So you will need to update that path in the NRELOffshrBsline5MW_OC3Monopile_ServoDyn.dat to point to where your compiled controller is located.

For the cmake build system, the build directory is the correct place to run the regression tests with ctest.  If you setup the build directory with cmake -DBUILD_TESTING=On .. then you can just run make install and it will build the controller for you and install it into the regression tests in the build directory (it is slightly simpler than manually building the controller). These would be installed in the build directory at reg_tests/glue-codes/openfast/5MW_Baseline/ServoData/.
The path in your error above indicates that you may have copied the regression test over rather than using the cmake + ctest system.  So you will need to update that path in the NRELOffshrBsline5MW_OC3Monopile_ServoDyn.dat to point to where your compiled controller is located.

No I did use the cmake and ctest commands to run the tests and that was fine (results below)- the tests that failed here, I think they failed because I am using Ubuntu 20.04 (I think there is another thread on this topic...).
    Start 17: 5MW_Land_DLL_WTurb
17/51 Test #17: 5MW_Land_DLL_WTurb ...........................   Passed   60.92 sec
      Start 18: 5MW_OC3Mnpl_DLL_WTurb_WavesIrr
18/51 Test #18: 5MW_OC3Mnpl_DLL_WTurb_WavesIrr ...............   Passed  210.14 sec
      Start 19: 5MW_OC3Trpd_DLL_WSt_WavesReg
19/51 Test #19: 5MW_OC3Trpd_DLL_WSt_WavesReg .................***Failed  634.56 sec
      Start 20: 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth
20/51 Test #20: 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth .......***Failed  1491.24 sec
      Start 21: 5MW_ITIBarge_DLL_WTurb_WavesIrr
21/51 Test #21: 5MW_ITIBarge_DLL_WTurb_WavesIrr ..............***Failed   22.26 sec
      Start 22: 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti
22/51 Test #22: 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti ........***Failed   43.74 sec
      Start 23: 5MW_OC3Spar_DLL_WTurb_WavesIrr
23/51 Test #23: 5MW_OC3Spar_DLL_WTurb_WavesIrr ...............***Failed   40.72 sec
      Start 24: 5MW_OC4Semi_WSt_WavesWN
24/51 Test #24: 5MW_OC4Semi_WSt_WavesWN ......................   Passed  110.96 sec
      Start 25: 5MW_Land_BD_DLL_WTurb
25/51 Test #25: 5MW_Land_BD_DLL_WTurb ........................   Passed  145.93 sec
      Start 26: 5MW_OC4Jckt_ExtPtfm
26/51 Test #26: 5MW_OC4Jckt_ExtPtfm ..........................   Passed   12.56 sec

But I am now running the following test case: https://github.com/IEAWindTask37/IEA-15-240-RWT which is supposed to have the ServoData files already but I don't understand why it is not recognizing the *.so file. Don't see this issue with OpenFAST v2.4

No I did use the cmake and ctest commands to run the tests and that was fine (results below)- the tests that failed here, I think they failed because I am using Ubuntu 20.04 (I think there is another thread on this topic...).
    Start 17: 5MW_Land_DLL_WTurb
17/51 Test #17: 5MW_Land_DLL_WTurb ...........................   Passed   60.92 sec
      Start 18: 5MW_OC3Mnpl_DLL_WTurb_WavesIrr
18/51 Test #18: 5MW_OC3Mnpl_DLL_WTurb_WavesIrr ...............   Passed  210.14 sec
      Start 19: 5MW_OC3Trpd_DLL_WSt_WavesReg
19/51 Test #19: 5MW_OC3Trpd_DLL_WSt_WavesReg .................***Failed  634.56 sec
      Start 20: 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth
20/51 Test #20: 5MW_OC4Jckt_DLL_WTurb_WavesIrr_MGrowth .......***Failed  1491.24 sec
      Start 21: 5MW_ITIBarge_DLL_WTurb_WavesIrr
21/51 Test #21: 5MW_ITIBarge_DLL_WTurb_WavesIrr ..............***Failed   22.26 sec
      Start 22: 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti
22/51 Test #22: 5MW_TLP_DLL_WTurb_WavesIrr_WavesMulti ........***Failed   43.74 sec
      Start 23: 5MW_OC3Spar_DLL_WTurb_WavesIrr
23/51 Test #23: 5MW_OC3Spar_DLL_WTurb_WavesIrr ...............***Failed   40.72 sec
      Start 24: 5MW_OC4Semi_WSt_WavesWN
24/51 Test #24: 5MW_OC4Semi_WSt_WavesWN ......................   Passed  110.96 sec
      Start 25: 5MW_Land_BD_DLL_WTurb
25/51 Test #25: 5MW_Land_BD_DLL_WTurb ........................   Passed  145.93 sec
      Start 26: 5MW_OC4Jckt_ExtPtfm
26/51 Test #26: 5MW_OC4Jckt_ExtPtfm ..........................   Passed   12.56 sec

But I am now running the following test case: https://github.com/IEAWindTask37/IEA-15-240-RWT which is supposed to have the ServoData files already but I don't understand why it is not recognizing the *.so file. Don't see this issue with OpenFAST v2.4

My apologies.  I had misunderstood your initial question.
The IEA test case (https://github.com/IEAWindTask37/IEA-15-240-RWT ) is managed by a different at NREL.  I suggest posting a question on their repository.  Given the dates I see there, I don't think they have updated to v2.4.0.  I am also uncertain of how their controller was built.

My apologies.  I had misunderstood your initial question.
The IEA test case (https://github.com/IEAWindTask37/IEA-15-240-RWT ) is managed by a different at NREL.  I suggest posting a question on their repository.  Given the dates I see there, I don't think they have updated to v2.4.0.  I am also uncertain of how their controller was built.

Okay, I'll try there. Thanks!

Okay, I'll try there. Thanks!

One other thought, the message from ServoDyn could also be triggered if the library can't be loaded due to missing dependencies of the library on your system, or if the architecture is incorrect.  In linux, you can use the ldd and objdump commands to find out if there are issues with that specific .so on your system (I don't remember the syntax for those commands, so you'll need to figure that out).  It is very possible that it has dependencies on older versions of gcc that are not present on your system.

One other thought, the message from ServoDyn could also be triggered if the library can't be loaded due to missing dependencies of the library on your system, or if the architecture is incorrect.  In linux, you can use the ldd and objdump commands to find out if there are issues with that specific .so on your system (I don't remember the syntax for those commands, so you'll need to figure that out).  It is very possible that it has dependencies on older versions of gcc that are not present on your system.

Ohhh. Yes, you are right. The gfortran library was missing because gcc++ 9 wasn't properly installed. I changed to gcc 7. It's fixed! Thanks a lot.

Ohhh. Yes, you are right. The gfortran library was missing because gcc++ 9 wasn't properly installed. I changed to gcc 7. It's fixed! Thanks a lot.

Excellent!
I notified the  IEA-15-240-RWT team about their input files not working with v2.5.0. They say they'll update those, but weren't sure how soon.

Excellent!
I notified the  IEA-15-240-RWT team about their input files not working with v2.5.0. They say they'll update those, but weren't sure how soon.


text:
Fixed : preprocessing with no args bug

Relocated image files into logos fixes the issue.
Closes #118

Looks great 😍
Hope you are enjoying your journey 🚆  with OpenGenus

repo: OpenGenus/memes


text:
Missing link to OHM forum

When you are on https://www.openhistoricalmap.org/help, there is no link to the OHM forum. Also the "*Welcome to OHM" card is duplicated. Maybe you wanted one of them to be for the forum?
Edit: the duplicates appear only when logged in for whatever reason.

Duplicate of #593

repo: OpenHistoricalMap/issues


text:
Adopt something close to @flha27's styling suggestions

Style change requested
A forum thread on rail layer design has generated much discussion, including this post by Ludwig @flha27 that has been up for about a month with 4 :heart:s, 1 comment from @Luke04 and no major disagreements. As such, I'd say let's adopt it with whatever adjustments @vknoppkewetzel deems appropriate.
Relevant style files
@vknoppkewetzel - please coordinate with Ludwig on the forum to resolve. I've cross-posted this ticket there.

Hi @vknoppkewetzel - any updates here?

Hey @jeffreyameyer, I have had a few different project deadlines coinciding with the end of this week, and I'll be able to dive back into OHM at the end of this week and next week. Thank you for checking in!

Hi,
For this to work well we need a few tags to be put into the layers :
electrified=* (1)
covered=* (2)
indoor=* (2)
(1) To not complicate things too much, we can have an electrified=1 when the tag exists and =0 vice versa.
(2) These two can have tunnel=1 which would avoid adding additional tags.
Having a layer= tag would also be useful.

authors: flha127 jeffreyameyer vknoppkewetzel


text:
RTSP client connection causes segmentation fault on XM530

Required information

Camera board id: 30678
OpenIPC version: 2.4.03.21-lite
Commit: 5e19ba2
Branch: master
Tag:
installation method: uboot upload
modified majestic.yaml: yes

root@openipc-xm530:~# cat /dev/kmsg
6,0,0,-;Booting Linux on physical CPU 0x0
5,1,0,-;Linux version 3.10.103+ (runner@fv-az1501-513) (buildroot-gcc-12.3.0) #2 SMP Thu Mar 21 21:07:46 UTC 2024
3,2,0,-;CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c53c7d
3,3,0,-;CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
3,4,0,-;Machine: xm530
3,5,0,-;Memory policy: ECC disabled, Data cache writealloc
7,6,0,-;On node 0 totalpages: 8960
7,7,0,-;free_area_init_node: node 0, pgdat c0348640, node_mem_map c035c000
7,8,0,-;  Normal zone: 70 pages used for memmap
7,9,0,-;  Normal zone: 0 pages reserved
7,10,0,-;  Normal zone: 8960 pages, LIFO batch:1
6,11,0,-;PERCPU: Embedded 7 pages/cpu @c03a7000 s6272 r8192 d14208 u32768
7,12,0,-;pcpu-alloc: s6272 r8192 d14208 u32768 alloc=8*4096
7,13,0,-;pcpu-alloc: [0] 0 [0] 1
3,14,0,-;Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 8890
5,15,0,-;Kernel command line: mem=35M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=xm_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)
6,16,0,-;PID hash table entries: 256 (order: -2, 1024 bytes)
6,17,0,-;Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
6,18,0,-;Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
6,19,0,-;Memory: 35MB = 35MB total
5,20,0,-;Memory: 31984k/31984k available, 3856k reserved, 0K highmem
5,21,0,-;Virtual kernel memory layout:\x0a    vector  : 0xffff0000 - 0xffff1000   (   4 kB)\x0a    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)\x0a    vmalloc : 0xc2800000 - 0xff000000   ( 968 MB)\x0a    lowmem  : 0xc0000000 - 0xc2300000   (  35 MB)\x0a    modules : 0xbf000000 - 0xc0000000   (  16 MB)\x0a      .text : 0xc0008000 - 0xc0301e64   (3048 kB)\x0a      .init : 0xc0302000 - 0xc0327880   ( 151 kB)\x0a      .data : 0xc0328000 - 0xc0348ee0   ( 132 kB)\x0a       .bss : 0xc0348ee0 - 0xc035bf64   (  77 kB)
6,22,0,-;SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
6,23,0,-;Hierarchical RCU implementation.
6,24,0,-;NR_IRQS:96
6,25,0,-;sched_clock: 32 bits at 12MHz, resolution 83ns, wraps every 357913ms
6,26,115,-;Calibrating delay loop... 298.59 BogoMIPS (lpj=1492992)
6,27,70136,-;pid_max: default: 32768 minimum: 301
6,28,70532,-;Mount-cache hash table entries: 512
6,29,72135,-;CPU: Testing write buffer coherency: ok
6,30,72898,-;Setting up static identity map for 0xc02a3b78 - 0xc02a3bd0
6,31,72952,-;L310 cache controller enabled
6,32,72973,-;l2x0: 8 ways, CACHE_ID 0x410000c9, AUX_CTRL 0x32420000, Cache size: 131072 B
3,33,74398,-;CPU1: Booted secondary processor
6,34,142988,-;Brought up 2 CPUs
6,35,143008,-;SMP: Total of 2 processors activated (598.42 BogoMIPS).
6,36,143014,-;CPU: All CPU(s) started in SVC mode.
6,37,144066,-;devtmpfs: initialized
6,38,148249,-;NET: Registered protocol family 16
6,39,148817,-;DMA: preallocated 256 KiB pool for atomic coherent allocations
6,40,150956,-;Serial: AMBA PL011 UART driver
6,41,151086,-;uart:0: ttyAMA0 at MMIO 0x10030000 (irq = 32) is a PL011 rev1
6,42,353219,-;console [ttyAMA0] enabled
6,43,356175,-;uart:1: ttyAMA1 at MMIO 0x10040000 (irq = 33) is a PL011 rev1
6,44,383913,-;bio: create slab <bio-0> at 0
6,45,389375,-;usbcore: registered new interface driver usbfs
6,46,393921,-;usbcore: registered new interface driver hub
6,47,398323,-;usbcore: registered new device driver usb
6,48,404753,-;Switching to clocksource timer0
6,49,412438,-;NET: Registered protocol family 2
6,50,417329,-;TCP established hash table entries: 512 (order: 0, 4096 bytes)
6,51,423012,-;TCP bind hash table entries: 512 (order: 0, 4096 bytes)
6,52,428055,-;TCP: Hash tables configured (established 512 bind 512)
6,53,433005,-;TCP: reno registered
6,54,434949,-;UDP hash table entries: 256 (order: 1, 8192 bytes)
6,55,439598,-;UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
6,56,445060,-;NET: Registered protocol family 1
6,57,448673,-;RPC: Registered named UNIX socket transport module.
6,58,453300,-;RPC: Registered udp transport module.
6,59,456699,-;RPC: Registered tcp transport module.
6,60,460145,-;RPC: Registered tcp NFSv4.1 backchannel transport module.
6,61,485394,-;squashfs: version 4.0 (2009/01/31) Phillip Lougher
6,62,492086,-;jffs2: version 2.2. (NAND) \xc2\xa9 2001-2006 Red Hat, Inc.
6,63,498066,-;fuse init (API version 7.22)
6,64,502072,-;msgmni has been set to 62
6,65,506905,-;Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
6,66,513072,-;io scheduler noop registered
6,67,515695,-;io scheduler deadline registered (default)
6,68,519622,-;io scheduler cfq registered
6,69,528479,-;dma-pl330 dma-pl330: Loaded driver for PL330 DMAC-267056
 SUBSYSTEM=amba
 DEVICE=+amba:dma-pl330
6,70,533550,-;dma-pl330 dma-pl330: \x09DBUFF-32x8bytes Num_Chans-4 Num_Peri-24 Num_Events-4
 SUBSYSTEM=amba
 DEVICE=+amba:dma-pl330
6,71,541031,-;uart-pl011 uart:0: no DMA platform data
 SUBSYSTEM=amba
 DEVICE=+amba:uart:0
6,72,544621,-;uart-pl011 uart:1: no DMA platform data
 SUBSYSTEM=amba
 DEVICE=+amba:uart:1
6,73,566200,-;brd: module loaded
6,74,577659,-;loop: module loaded
7,75,581159,-;XM Spi Flash Controller Device Driver Version 1.0
6,76,581771,-;XMSFCV2: flash name:W25Q64CV size:0x800000
5,77,586014,-;5 cmdlinepart partitions found on MTD device xm_sfc
5,78,590693,-;5 cmdlinepart partitions found on MTD device xm_sfc
5,79,595316,-;Creating 5 MTD partitions on "xm_sfc":
5,80,598869,-;0x000000000000-0x000000040000 : "boot"
5,81,604760,-;0x000000040000-0x000000050000 : "env"
5,82,610542,-;0x000000050000-0x000000250000 : "kernel"
5,83,616468,-;0x000000250000-0x000000750000 : "rootfs"
5,84,622502,-;0x000000750000-0x000000800000 : "rootfs_data"
6,85,629069,-;tun: Universal TUN/TAP device driver, 1.6
6,86,632824,-;tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
6,87,639458,-;XMMMAC driver:\x0a\x09platform registration...
6,88,643124,-;\x09done!
6,89,645449,-;\x09eth0 - (dev. name: xmmaceth - id: -1, IRQ #35\x0a\x09IO base addr: 0xfe010000)
6,90,654364,-;libphy: XMMMAC MII Bus: probed
6,91,657170,-;eth0: PHY ID 00010000 at 1 IRQ 0 (0:01) active
6,92,662384,-;TCP: cubic registered
6,93,664409,-;NET: Registered protocol family 17
5,94,667764,-;Key type dns_resolver registered
6,95,670860,-;VFP support v0.3: implementor 41 architecture 2 part 30 variant 5 rev 1
6,96,678734,-;registered taskstats version 1
6,97,684264,-;VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
6,98,694714,-;devtmpfs: mounted
6,99,697022,-;Freeing unused kernel memory: 148K (c0302000 - c0327000)
5,100,1361769,-;jffs2: notice: (351) jffs2_build_xattr_subsystem: complete building xattr subsystem, 6 of xdatum (0 unchecked, 6 orphan) and 6 of xref (0 dead, 6 orphan) found.
3,101,1438829,-;devpts: called with bogus options
6,102,4027850,-;libphy: 0:01 - Link is Up - 100/Full
6,103,9018402,-;xm_i2c init is ok!
6,104,9052599,-;mmz: init ok start=0x82300000, size=0x1d00000
6,105,9063895,-;VI: init ok!
0,106,9105796,-;IspKo: ispDev_init start!
0,107,9107008,-;IspKo: ispDev_init OK!
6,108,9126601,-;hx280enc: module init - base_port=0x20070000 irq=77
6,109,9127557,-;hx280enc: HW at base <0x20070000> with ID <0x82900760>
6,110,9127652,-;hx280enc: module inserted. Major <0>
6,111,9137945,-;xm_rtc init is ok!
6,112,9148444,-;xm_wdt init is ok!
6,113,9245348,-;acodec init is ok!
3,114,9259018,-;MVE: Failed to create 'mve' dir.
3,115,9259037,-;MVE: Failed to create 'dmesg' dir.
3,116,9259090,-;MVE: Failed to create 'ram0' dir.
3,117,9259100,-;MVE: Failed to create 'ram0/msg.
3,118,9259107,-;MVE: Failed to create 'generic' dir.
3,119,9259113,-;MVE: Failed to create 'scheduler' dir.
3,120,9259120,-;MVE: Failed to create 'firmware_interface' dir.
3,121,9259126,-;MVE: Failed to create 'session' dir.
0,122,9260275,-;MVE resource driver loaded successfully (nlsid=4, cores=1, version=0x56550002)
0,123,9311398,-;MVE base driver loaded successfully
3,124,10833599,-;i2c_write timeout 0x2
3,125,10875623,-;i2c_write timeout 0x2
3,126,10917662,-;i2c_write timeout 0x2
3,127,10959817,-;i2c_write timeout 0x2
3,128,11001860,-;i2c_write timeout 0x2
3,129,11046119,-;i2c_write timeout 0x2
3,130,11088274,-;i2c_write timeout 0x2
0,131,11602956,-;IspKo: [IspDrv]: Memery Init Buffer!Num[2]
3,132,23003309,-;i2c_write timeout 0x2
3,133,23045737,-;i2c_write timeout 0x2
3,134,23088567,-;i2c_write timeout 0x2
3,135,23154022,-;i2c_write timeout 0x2
3,136,23196408,-;i2c_write timeout 0x2
3,137,23239083,-;i2c_write timeout 0x2
3,138,149221039,-;i2c_write timeout 0x2
3,139,149263065,-;i2c_write timeout 0x2
3,140,149305101,-;i2c_write timeout 0x2
3,141,149347225,-;i2c_write timeout 0x2
3,142,149389282,-;i2c_write timeout 0x2
3,143,149433527,-;i2c_write timeout 0x2
3,144,149475605,-;i2c_write timeout 0x2
3,145,219155636,-;i2c_write timeout 0x2
3,146,219197671,-;i2c_write timeout 0x2
3,147,219239786,-;i2c_write timeout 0x2
3,148,219281893,-;i2c_write timeout 0x2
3,149,219323927,-;i2c_write timeout 0x2
3,150,219368166,-;i2c_write timeout 0x2
3,151,219410269,-;i2c_write timeout 0x2
3,152,275583373,-;i2c_write timeout 0x2
3,153,275625419,-;i2c_write timeout 0x2
3,154,275667518,-;i2c_write timeout 0x2
3,155,275709614,-;i2c_write timeout 0x2
3,156,275751668,-;i2c_write timeout 0x2
3,157,275795907,-;i2c_write timeout 0x2
3,158,275837984,-;i2c_write timeout 0x2
3,159,370417035,-;i2c_write timeout 0x2
3,160,370459075,-;i2c_write timeout 0x2
3,161,370501197,-;i2c_write timeout 0x2
3,162,370543303,-;i2c_write timeout 0x2
3,163,370585337,-;i2c_write timeout 0x2
3,164,370629582,-;i2c_write timeout 0x2
3,165,370671670,-;i2c_write timeout 0x2
3,166,471707969,-;i2c_write timeout 0x2
3,167,471749996,-;i2c_write timeout 0x2
3,168,471792240,-;i2c_write timeout 0x2
3,169,471834364,-;i2c_write timeout 0x2
3,170,471876407,-;i2c_write timeout 0x2
3,171,471920650,-;i2c_write timeout 0x2
3,172,471962752,-;i2c_write timeout 0x2

login as: root
root@10.10.10.114's password:

    /######                                    /######  /#######    /######
   /##__  ##                                  |_  ##_/ | ##__  ##  /##__  ##
  | ##  \ ##   /######    /######   /#######    | ##   | ##  \ ## | ##  \__/
  | ##  | ##  /##__  ##  /##__  ## | ##__  ##   | ##   | #######/ | ##
  | ##  | ## | ##  \ ## | ######## | ##  \ ##   | ##   | ##____/  | ##
  | ##  | ## | ##  | ## | ##_____/ | ##  | ##   | ##   | ##       | ##    ##
  |  ######/ | #######/ |  ####### | ##  | ##  /###### | ##       |  ######/
   \______/  | ##____/   \_______/ |__/  |__/ |______/ |__/        \______/
             | ##
             | ##                              build
             |__/                              master+5e19ba2, 2024-03-21

 Please help the OpenIPC Project to cover the cost of development and
 long-term maintenance of what we believe is going to become a stable,
 flexible Open IP Network Camera Framework for users worldwide.

 Your contributions could help us to advance the development and keep
 you updated on improvements and new features more regularly.

 Please visit https://openipc.org/sponsor/ to learn more. Thank you.

root@openipc-xm530:~# killall majestic
root@openipc-xm530:~# ulimit -c unlimited
root@openipc-xm530:~# echo /tmp/%e.%p.%s.%t.core > /proc/sys/kernel/core_pattern
root@openipc-xm530:~# majestic
LIBH264: Complied at Apr 30 2019 16:55:22
11:15:57  <       majestic> [    main] main@240                      Majestic Lite for Xiongmai, version master+18c71e2, built on 2024-03-21
11:15:57  <       majestic> [watchdog] watchdog_start@111            Watchdog timeout set to 300 seconds
11:15:57  <       majestic> [   httpd] start_web_server@381          Set server path: /var/www
11:15:57  <       majestic> [   httpd] new_http_server@369           HTTP server started on 0.0.0.0:80
11:15:57  <       majestic> [    main] init_sdk@66                   Loading main configuration: /etc/majestic.yaml
DEBUG: [ISP_SDK]BUILD TIME:Sep 21 2021 11:58:04
DEBUG: OSC:12M
11:15:57  <       majestic> [     log] printf@292                    SYS/VI set in      [ Sofia ]
11:15:57  <       majestic> [     log] printf@292                    Vstd_init  [ PAL ]
11:15:57  <       majestic> [     log] printf@292                    Rslt       [ 0 ]
11:15:57  <       majestic> [     log] printf@292                    IPC_Venc:  [ H.264 ]
11:15:57  <       majestic> [     log] printf@292                    Sns_IF:    [ By src ]

DEBUG: sensor_get_chip:
11:15:58  <       majestic> [     log] printf@292                    0x1a
 11:15:58  <       majestic> [     log] printf@292                    0x2
 11:15:58  <       majestic> [     log] printf@292                    0x1
 11:15:58  <       majestic> [     log] printf@292                    0x34
11:15:58  <       majestic> [    puts]
ERR: open /mnt/mtd/Config/SensorType.bat failed
DEBUG: Venc(264):495
DEBUG: DspChip:XM530
DEBUG: SnsIF:MIPI
DEBUG: Vstd:PAL[25fps]
DEBUG: ------------- IMX307 2M 30fps  init ok! (@201812111)----------------
DEBUG: sensor_init Ok!
DEBUG: cmos_fps_set IMX307 2M 25fps
DEBUG: cmos_fps_set IMX307 2M 25fps
DEBUG: Init over ~~~~~~~~
DEBUG: ProductType: 0x0
DEBUG: libfvideo: IMX307!
DEBUG: isp_sample end!
DEBUG: imageStyle XM!
11:15:58  <       majestic> [     sdk] ViChnConfig@164               ViChn = 0, enSize = 14
11:15:58  <       majestic> [     sdk] ViChnConfigEx@188             ViChn = 1, enSize = 0
11:15:58  <       majestic> [     sdk] COMM_VENC_Start@249           VencChn = 0, enType = 96, enSize = 14 (1920x1080), enRcMode = 1
11:15:58  <move_detect_pro> [    puts]                               XM_MPI_ISP_MemInit OK...
11:15:58  <       majestic> [     sdk] COMM_VENC_Start@249           VencChn = 1, enType = 96, enSize = 0 (704x576), enRcMode = 1
11:15:58  <       majestic> [     sdk] COMM_VENC_Start@249           VencChn = 2, enType = 26, enSize = 0 (704x576), enRcMode = 1
11:15:58  <       majestic> [    rtsp] rtsp_init@28                  RTSP server started on port 554
DEBUG: black and white
DEBUG: EShutter 1/1
DEBUG: gu8OemStyle: 0
DEBUG: color
11:16:02  <       majestic> [     sdk] sdk_take_jpeg@866             take jpeg venc_chn(2)   0x0  q:50
11:16:02  <       majestic> [  on_jpg] send_regular_jpeg@55          JPEG was sent to client
DEBUG: Delay Over !!!
11:17:05  <       majestic> [     sdk] sdk_take_jpeg@866             take jpeg venc_chn(2)   0x0  q:50
11:17:05  <       majestic> [  on_jpg] send_regular_jpeg@55          JPEG was sent to client
11:17:23  <       majestic> [  client] RtspClient_before@402         RTSP OPTIONS rtsp://10.10.10.114:554/stream=0 CSeq=1 from 10.10.10.130:36808
11:17:23  <       majestic> [  client] RtspClient_before@402         RTSP OPTIONS rtsp://10.10.10.114:554/stream=0 CSeq=2 from 10.10.10.130:36808
11:17:23  <       majestic> [  client] RtspClient_before@402         RTSP DESCRIBE rtsp://10.10.10.114:554/stream=0 CSeq=3 from 10.10.10.130:36808
11:17:23  <       majestic> [     nal] NalCodec_describe@117         RTSP chn 0 sps_len 0
11:17:23  <       majestic> [     nal] NalCodec_describe@120         RTSP chn 0 pps_len 0
11:17:23  <       majestic> [     nal] NalCodec_describe@128         RTSP chn 0 profile_level_id 000000
11:17:23  <       majestic> [  client] RtspClient_before@402         RTSP SETUP rtsp://10.10.10.114:554/stream=0/video CSeq=4 from 10.10.10.130:36808
11:17:23  <       majestic> [  client] RtspClient_setup@313          TCP RTSP SETUP done, stream_id=0 from 10.10.10.130:36808
11:17:23  <       majestic> [  client] RtspClient_before@402         RTSP PLAY rtsp://10.10.10.114:554/stream=0 CSeq=5 from 10.10.10.130:36808
11:17:23  <       majestic> [  levent] libevent_log_cb@24            Epoll ADD(4) on fd 34 failed. Old events were 0; read change was 0 (none); write change was 1 (add); close change was 0 (none): Bad file descriptor
Segmentation fault
root@openipc-xm530:~#

No files was created in the /tmp/ folder for core dump
Issue description
Any RTSP client causes segmentation fault crash of majestic. Tried this old build of OpenIPC to see if the new buildroot causes the problem but it seems it is not the case. The latest OpenIPC build acts exactly the same.
Expectations
Expect it not to segfault! :-P
Steps to reproduce

firstboot
enable video1
connect rtsp client

Information to attach
majestic.yaml.txt

I have the same problem only other sensor.
https://github.com/OpenIPC/firmware/issues/1425
"i2c_write timeout 0x2"
will there be a fix?
no one has responded to the error :(

will there be a fix?
no one has responded to the error :(

The fix is to throw XM chips in the trash xD
Openipc is not a miracle and it cant make it work any better.

Good afternoon
For quick answers, we have chats, where there is an intensive exchange of information.
https://openipc.org/our-channels
You can install firmware from the Dev channel in Telegram released before January 1, 2024 and it should work.
The problem is related to Buildroot toolchain updates.

I tried lots 2023 version. Not working :(

I tried lots 2023 version. Not working :(

The problem is with majestic. I have XM SDK and I can operate the camera with openipc. I can create jpg from command line. Without majestic source code I cannot do further tests.
Possible bug that majestic is detecting the resolution of the senzor wrong. My sensor is 1270x720 (OV9732) but majestic tries to encode in 1920x1080. If I change the resolution from the command line the image appears in RTSP but I get a segmentation error.
It would be nice to be able to override the encoding resolution in the majestic config file but unfortunately I can't.
Translated with DeepL.com (free version)

Good afternoon For quick answers, we have chats, where there is an intensive exchange of information. https://openipc.org/our-channels
You can install firmware from the Dev channel in Telegram released before January 1, 2024 and it should work. The problem is related to Buildroot toolchain updates.

The problem is with majestic. I have XM SDK and I can operate the camera with openipc. I can create jpg from command line. Without majestic source code I cannot do further tests.
Possible bug that majestic is detecting the resolution of the senzor wrong. My sensor is 1270x720 (OV9732) but majestic tries to encode in 1920x1080. If I change the resolution from the command line the image appears in RTSP but I get a segmentation error.
It would be nice to be able to override the encoding resolution in the majestic config file but unfortunately I can't.

Possible bug that majestic is detecting the resolution of the senzor wrong

No, it's not the case. My sensor is detected correctly. The issue is with rtsp implementation (you can watch the video with HLS streamer, for example). And yes, I've tried several 2023 versions as well and they act exactly the same.

Possible bug that majestic is detecting the resolution of the senzor wrong

No, it's not the case. My sensor is detected correctly. The issue is with rtsp implementation (you can watch the video with HLS streamer, for example). And yes, I've tried several 2023 versions as well and they act exactly the same.

In your case the error may be a bit different than mine but they are still related. i have a double error :(

I can confirm this issue on the current master. XM530 + sc3335 sensor.
TCP rtsp results in a segfault. UDP works.
There's also something with image white balance: the image looks waay too pink, despite ircut is enabled.

repo: OpenIPC/majestic


text:
IC/TS option "trust_file_extensions"

The default is 0, old behavior. If you set to nonzero, you are
promising the ImageCache that it will always be able to identify a
texture file's format based on the filename extension (e.g. ".exr"
always means it's an openexr file, ".tif" or "tx" for TIFF files, and
you will NEVER call a file ".tx" if it's really openexr, or if you do,
you are ok with it being unable to open it). When you enable it with
that promise, it can eliminate a few redundant file opens and header
reads, by not needing to verify file format types at certain stages of
processing.
I'm not sure I would recommend enabling this in general. But if you
are operating in a closed environment where you are sure that file
extensions will match their types (such as a studio with rigid naming
conventions, where all possible textures have been converted with
maketx), this can eliminate some unnecessary network traffic and file
server workload.

LGTM!

authors: fpsunflower lgritz

repo: OpenImageIO/oiio


text:
🛑 LinkOS Docker Registry Mirror is down

In c72408c, LinkOS Docker Registry Mirror (https://docker.linkos.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: LinkOS Docker Registry Mirror is back up in d4b5118 after 16 minutes.

repo: OpenLinkOS/uptime


text:
Improve command line parser

Add table argument type
Support space-separated list of values
Accept argument for boolean options

Codecov Report

Merging #235 into master will increase coverage by 0.48%.
The diff coverage is 57.74%.

@@            Coverage Diff             @@
##           master     #235      +/-   ##
==========================================
+ Coverage   65.32%   65.81%   +0.48%
==========================================
  Files          65       65
  Lines        5154     5192      +38
==========================================
+ Hits         3367     3417      +50
+ Misses       1787     1775      -12

Impacted Files
Coverage Δ

onmt/Factory.lua
28.77% <0%> (+3.41%)
:arrow_up:

onmt/train/Saver.lua
23.23% <0%> (-1.24%)
:arrow_down:

onmt/SeqTagger.lua
51.08% <100%> (ø)
:arrow_up:

onmt/LanguageModel.lua
44.76% <100%> (ø)
:arrow_up:

onmt/Seq2Seq.lua
60.4% <100%> (+4.02%)
:arrow_up:

onmt/data/Preprocessor.lua
71.2% <33.33%> (-3.04%)
:arrow_down:

onmt/utils/Cuda.lua
34.48% <33.33%> (-2.48%)
:arrow_down:

onmt/utils/ExtendedCmdLine.lua
55.72% <65.51%> (+13.5%)
:arrow_up:

onmt/data/Vocabulary.lua
96.87% <80%> (-0.07%)
:arrow_down:

onmt/modules/Decoder.lua
85% <0%> (+0.9%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 37a3ed3...1a4c288. Read the comment docs.

authors: codecov-io guillaumekln

repo: OpenNMT/OpenNMT


text:
Consistent state naming for VMs

Bug Report
Version of OpenNebula

[ ] 5.2.2
[ ] 5.4.0
[ ] 5.4.1
[ ] 5.4.2
[ ] 5.4.3
[ ] 5.4.4
[ ] 5.4.5
[ ] 5.4.6
[ ] 5.4.7
[ ] 5.4.8
[ ] 5.4.9
[ ] 5.4.10
[ ] 5.4.11
[X] Development build

Component

[ ] Authorization (LDAP, x509 certs...)
[X] Command Line Interface (CLI)
[ ] Contextualization
[ ] Documentation
[ ] Federation and HA
[ ] Host, Clusters and Monitorization
[ ] KVM
[ ] Networking
[ ] Orchestration (OpenNebula Flow)
[ ] Packages
[ ] Scheduler
[ ] Storage & Images
[X] Sunstone
[ ] Upgrades
[ ] User, Groups, VDCs and ACL
[] vCenter

Description
All the interfaces should comply with the same state semantics as the OpenNebula core:
TOTAL -- total number of VMs that NOT in the DONE state
ACTIVE -- VMs that are NOT in a final state (s, if left alone, will revert to RUNNING if there are not changes)
RUNNING -- VMs that are in RUNNING state
Expected Behavior
Interfaces to be consistent with this
Actual Behavior

There is no TOTAL in Dashboard
Host template has RUNNING_VMS which should be TOTAL_VMS
onehost list outputs RVM and should output TVM (Total VMs) (or just, VM)

How to reproduce
Have a VM pool with mixed VM states and look at the above issues
Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

Also, RUNNING VM quotas should be TOTAL VM quotas

Juan: onehost list outputs RVM and should output TVM (Total VMs) (or just, VM)

authors: OpenNebulaSupport rsmontero

repo: OpenNebula/one


text:
vm state documentation

Description
In the VM file source of GOCA, I found three LCM_STATE not documented:
// DiskResize lcm state
DiskResize LCMState = 62

// DiskResizePoweroff lcm state
DiskResizePoweroff LCMState = 63

// DiskResizeUndeployed lcm state
DiskResizeUndeployed LCMState = 64

Are they deprecated ?
They are just not documented here: vm states ONe 5.6
By the way, the link given to document the STATE and LCM_STATE values in the XSD file is dead.
The link is in this file: vm.xsd
FYI, it's this link:  http://docs.opennebula.org/stable/user/references/vm_states.html

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

Fixed here: https://github.com/OpenNebula/docs/pull/488, https://github.com/OpenNebula/one/pull/2894


text:
Amazon EC2 driver bare betal support

I'd like to be able to deploy bare metal through opennebula in AWS London region, but the docs state only i3.metal is supported:
http://docs.opennebula.org/5.8/advanced_components/ddc/reference/provision/driver/ec2.html
i3.metal isn't available in London, only c/m/r.metal hosts are.
Is the documentation correct, are these not supported?  They seem to be in the ec2_driver.conf file?

Hello @laurencegill
DDC should work with any metal instances, but we only test it with i3.metal, because they were the only available instances when we worked on it.
I have made some tests with r5.metal, here you have the steps I followed and the results:
Provision template
---
name: london-provision
playbook: default

defaults:
  provision:
    driver: ec2
    ami: ami-7c141006
    cloud_init: true
    instancetype: r5.metal
    securitygroupsids: ****
    subnetid: ****
    ec2_access: ****
    ec2_secret: ****
    region_name: us-east-1
  connection:
    remote_user: centos
  configuration:
    opennebula_node_kvm_param_nested: true

cluster:
  name: london-cluster

hosts:
  - reserved_cpu: 100
    im_mad: kvm
    vm_mad: kvm
    provision:
      hostname: "<%= @name %>-host1"

Note: I deploy it in us, but the instance type is also available in London, also take in account that the ami you use must have ena enabled.
Steps

Command to deploy: oneprovision create simple.yaml -D --ping_retries 20 --ping_timeout 30 I added those ping options because aws metal instances take too long to have the OS up and running. You will have to wait until Ansible finishes to configure everything.
After that, you need to wait until OpenNebula monitors the host, so you will see it on ON state.
Then you have to change the default emulator, so edit the file /etc/one/vmm_exec/vmm_exec_kvm.conf and uncomment EMULATOR = /usr/libexec/qemu-kvm line.
Restart OpenNebula, so changes take effect.
Finally you are ready to deploy VMs on that hosts, it's a fully operational KVM host.

Hi @al3xhh,
Thank you very much for confirming, and even testing, that :smile:
Cheers

You are welcome @laurencegill just tell me if anything is wrong or can be improved! Thanks for trying DDC!

PR to merge in documentation repository in 5.10 and master:

https://github.com/OpenNebula/docs/pull/985


text:
Remove pointless casts

These variables were already in the target type anyway, or implicitly converted to void *.

@michaelrsweet addressed!

repo: OpenPrinting/cups


text:
Fix documentation for clustering

The documentation about clustering shows a screenshot of the clustering dialog where all the values in a given cluster look identical, which should not normally happen. This screenshot was taken before #4004 was fixed, which probably explains that. This screenshot should be replaced by a screenshot which shows different values being clustered together.
Current image:

Additionally it could be useful to rework the text to make the clustering feature clearer because it looks like the current documentation does not convey the intended usage very well.
This was noticed in #3422 by @fgiroud.

With @fgiroud we plan to use the same dataset for documentation and for UX testing.

With @fgiroud we plan to use the same dataset for documentation and for UX testing.
@wetneb I'll like to do this. However,  would it be possible to work on the documentation given that I don't have the require dataset?

However, would it be possible to work on the documentation given that I don't have the required dataset?

For the dataset, @Babi-B, it is suggested in the discussion to use a file from the UI Tests. Can you find one with appropriate text data, and create a new screencapture to replace the flawed one?
(They are called « Functional Tests » in the doc… https://docs.openrefine.org/technical-reference/functional-tests)
Regards, Antoine

Hello @antoine2711. I think I can. Could you assign me to this issue?

authors: Babi-B antoine2711 wetneb

repo: OpenRefine/OpenRefine


text:
Differences in performance in c4ev3

Describe the bug
There are large differences in performance between driving blocks. So if I want to set the power of both engines in a loop as often as possible, and if I use a single drive block for both engines, a loop will have about 44,000 runs. But if I use two single blocks (for each engine separate block) only 220 runs per second are done in the loop (Under Screenshots).
Expected behavior
You get the same or similar performance in both cases
Screenshots
Case Where you set two engines at the same time

Case Where You set Each Motor Separately

Device information
Windows-PC
Chrome/Firefox

As I anticipated in the Gitter channel, I added to c4ev3 an explicit delay to prevent the program to write too frequently to the pwm device (which controls the motor). Without the delay I observed an inconsistent behavior when setting the speed of the motor inside a loop.
Reading the code I found out that I added the delay only if the motor is controlled singularly. This explains the difference on performance.
@munka21 Currently I don't have an EV3 to try, but did you find some inconsistencies using the first program (which controls the motors with only one block)? Also using high speeds (like >80%)?

Hey @simonedegiacomi how far are you with this?

The problem should now be solved, but I didn't try it myself (I asked @peehrlich2 that was very kind to test some programs). On Sunday I should be able to try some programs on a EV3

Nice, I can test today.

I just tested those two programs:
In the Lab I get: 45617 and 220
On your branch I get: 1 and 189503
Single motors are definitely faster now but something changed with the drive block.

Now the bug should be fixed (without using caches or waits)

Values now: 56857 and 20035 so both are fast now, so I guess this is resolved.
How come there is a magnitude difference from the previous fix for the second value?

How come there is a magnitude difference from the previous fix for the second value?

Because in the previous "fix", the function to control the motor was caching the previous set speed. If the speed was the same, it didn't call the function that actually wrote to the motor device. With the new fix there is no such cache, it always writes to the motor device. This includes I/O operations, so it slower.
Anyway I think that it's better to have it like this because it's less bug-prone and the speed should be enough for almost any problem (including PID and similar). What do yo think? does this make sense?

That sounds reasonable and definitely more stable.

authors: boonto munka21 simonedegiacomi

repo: OpenRoberta/openroberta-lab


text:
openmp in opensycl

can anyone please explain how the openmp code is identified and executed by runtime in opensycl?
is the openmp code is converted into sycl code in opensycl?

Closing as a duplicate of the discussion here: https://github.com/OpenSYCL/OpenSYCL/discussions/1024

authors: garadeaniket illuhad

repo: OpenSYCL/OpenSYCL


text:
Calculate votes cast automatically

The value of field "votes cast" should be calculated automatically after filling  the counted votes results ('Yes, No, Abstention, Invalid' resp. 'Yes, Invalid') for application and election votes.
Maybe a button "calculate votes cast" could be a solution.
Or calculate after every onChange event.

@FinnStutzenstein   Is this something for the new client? If not (or already solved) pleas close

repo: OpenSlides/OpenSlides


text:
Fixes creation of amendments

Fixes #195
Fixes #215
Fixes openslides-backend#696
Waiting for #190

Waiting for #187

Why? This seems unrelated.

Waiting for #187

Why? This seems unrelated.

I meant #190: active-meeting-id.service.ts#L35 has an error, which prevents the creation of an amendment. #190 has a fix for that.

@tsiegleauq Please re-test and let me know, if everything is okay or anything is missing.

authors: GabrielInTheWorld tsiegleauq

repo: OpenSlides/openslides-client


text:
Improved  basic stylings and made it mobile responsive

Laptop View:

Mobile View

Laptop view:

Mobile view:

Improved version!

Can you reduce the header in mobile responsive?

@Harish-2003

Can u also attach screenshots of laptop view

@Harish-2003

Can u also attach screenshots of laptop view

Sure!

@Harish-2003 Could u please add gssoc-extd label to this?

@sanjay-kv @Harish-2003 @KiranBaliga @Bruhbytes Could you please add gssoc-extd label here please!

repo: OpenTekHub/blockchain


text:
RequestGetParticipants Does Not Work

I Used RequestGetParticipants To get Participants Of Group But No Success
my code is :
                        TChannel t = (TChannel)item;                         RequestGetParticipants rgp = new RequestGetParticipants();                         TInputChannel tic = new TInputChannel();                         tic.AccessHash = t.AccessHash;                         tic.ChannelId=t.Id;                         rgp.Channel = tic;                         rgp.Limit = 5;                         rgp.Offset = 0;                         var participants = (TChannelParticipants)clientApi.CustomRequestsService.SendRequestAsync(rgp).GetAwaiter().GetResult();
but last Line Throw Exception DotNetty
Please Help Me
thx

I Solve My Problem . This Library Is Great .
The Filter Argument NOT OPTIONAL ;

I Solve My Problem . This Library Is Great .
The Filter Argument NOT OPTIONAL ;

Could you share a sample with us?


text:
GUI build error

I am trying to build this for rpi4-gui.  My host is ubuntu server 22.04
I cant get past this error
-- Performing Test HAVE_DATE_TIME - Success
fatal: HEAD does not point to a branch
CMake Deprecation Warning at /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/share/ECM/modules/ECMQMLModules.cmake:7 (message):
  ECMQMLModules.cmake is deprecated since 5.88.0, please use
  ECMFindQmlModule.cmake instead
Call Stack (most recent call first):
  CMakeLists.txt:40 (include)

CMake Error at /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/cmake/Qca-qt5/Qca-qt5Targets.cmake:73 (message):
  The imported target "qca-qt5" references the file

     "usr/lib/libqca-qt5.so.2.3.4"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/cmake/Qca-qt5/Qca-qt5Targets.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/cmake/Qca-qt5/Qca-qt5Config.cmake:38 (include)
  CMakeLists.txt:62 (find_package)

-- Configuring incomplete, errors occurred!
See also "/home/jbrodie/software/ovos-buildroot/buildroot/output/build/kf5-kdeconnect-v22.04.1/buildroot-build/CMakeFiles/CMakeOutput.log".
make[2]: *** [package/pkg-generic.mk:283: /home/jbrodie/software/ovos-buildroot/buildroot/output/build/kf5-kdeconnect-v22.04.1/.stamp_configured] Error 1
make[1]: *** [Makefile:84: _all] Error 2
make[1]: Leaving directory '/home/jbrodie/software/ovos-buildroot/buildroot'
rsync -ah --progress buildroot/output/images/sdcard.img release/OpenVoiceOS_rpi4_64-gui.img
sending incremental file list
rsync: [sender] link_stat "/home/jbrodie/software/ovos-buildroot/buildroot/output/images/sdcard.img" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]
make: *** [Makefile:26: rpi4_64-gui] Error 23

but I have that file I think
ls -l /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqca-qt5.so*
lrwxrwxrwx 1 jbrodie jbrodie      15 Dec 15 18:47 /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqca-qt5.so -> libqca-qt5.so.2
lrwxrwxrwx 1 jbrodie jbrodie      19 Dec 15 18:47 /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqca-qt5.so.2 -> libqca-qt5.so.2.3.4
-rwxr-xr-x 1 jbrodie jbrodie 1528240 Dec 15 18:47 /home/jbrodie/software/ovos-buildroot/buildroot/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libqca-qt5.so.2.3.4

I would love to get this to build once, so I can make my own changes.  Any help would be greatly appreciated

I found a workaround here and that got me past that.  Used the same for a couple more things. And then used the methods here on a few packages and not have a completed image.  It is WITHOUT kdeconnect though.  Any help getting that to work would be awesome as I like the feature.

Fixed / no longer needed.

repo: OpenVoiceOS/ovos-buildroot


text:
🛑 Text-to-Speech - Piper - Smart'Gic is down

In b75771f, Text-to-Speech - Piper - Smart'Gic (https://tts.smartgic.io/piper/status) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Text-to-Speech - Piper - Smart'Gic is back up in cfd99c3.

repo: OpenVoiceOS/status


text:
@openzeppelin/upgrades package dependency vulnerabilities

Hi, when adding the @openzeppelin/upgrades package to my project I receive warnings on package vulnerabilities (running npm audit provides detail). They all seem to arise from the web3 version you use here. Updating the web3 package used here should solve the issue.

Hi @ben-kaufman!
We have been able to reproduce this issue by following these steps:
$ mkdir issue1514 && cd issue1514
$ npm init -y
$ npm i @openzeppelin/upgrades@rc
$ npm audit

                       === npm audit security report ===

┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Low           │ Insecure Credential Storage                                  │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ web3                                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @openzeppelin/upgrades                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ @openzeppelin/upgrades > web3                                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/877                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary File Write                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ decompress                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ @openzeppelin/upgrades                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ @openzeppelin/upgrades > web3 > web3-bzz > swarm-js >        │
│               │ decompress                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1217                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 2 vulnerabilities (1 low, 1 high) in 36898 scanned packages
  2 vulnerabilities require manual review. See the full report for details.

Thanks so much for reporting it! The project owner will review and triage this issue during the next week.

The vulnerabilities are in web3 or it's dependencies and are not fixed in the latest version of web3 (You can check by installing web3@1.2.6).
https://github.com/OpenZeppelin/openzeppelin-sdk/issues/700#issuecomment-594127396
The Arbitrary File Write vulnerability should be fixed in a future version of web3
https://github.com/ethereum/web3.js/issues/3399

authors: abcoathup ben-kaufman

repo: OpenZeppelin/openzeppelin-sdk


text:
CLI: Support Foundry contract naming conventions

Contract names for the CLI currently need to be the actual contract name (e.g. MyContract), or the fully qualified name (e.g. src/myPath/MyContract.sol:MyContract).
To be more useful from Foundry, also support the following formats, according to the getCode cheatcode:

MyContract.sol if the filename and contract name are the same
MyContract.sol:Foo

Note: This does not include support for passing in Foundry artifact paths, as that is Foundry specific and not part of solc input.

Cancelling since Foundry naming conventions are not standard, so should be handled by the caller on the Foundry side before calling the Upgrades CLI.

repo: OpenZeppelin/openzeppelin-upgrades


text:
add site url in GitHub interface

Add site url https://thefaylab.github.io/lab-manual/ by clicking the gear icon in this image 'cause it's hard to find the live Faylab manual site without it

I don't see the gear icon anymore - Gavin prob has to make this change

repo: Openscapes/lab-manual


text:
PAPIv3: get and set pipette's trash container

Overview
As a PAPIv3 author, I would like to get and set my pipette's default trash container so that I can trash tips and liquid in locations other than the default fixed trash.
Acceptance criteria
A PAPIv3 author may:

[ ] get a pipette's trash labware via PipetteContext.trash_container

[ ] by default, should be the fixed trash labware

[ ] set the pipette's trash labware via the same property
[ ] drop_tip without location drops in trash container

Implementation notes

Related to #9456 for ProtocolContext.fixed_trash support
This feature should stay contained to PAPI; it does not need to leak into the engine

This might need to trickle down to the engine for drop tip on cancel purposes.

authors: mcous sanni-t

repo: Opentrons/opentrons


text:
Working data collection from TBA with auto image grabbing

image grabbing doesnt always grab a good photo though, roadmap for this feature is to upload a known good robot image to the backend in the assets folder and define it in the _robot file.  then create a robot gallery and pull all images from TBA to populate said gallery

merge TBA tests to gain access to current year info stored in 2023 robot files


text:
Create a /search endpoint

The front end will need a way to search for anything in the data using one endpoint. This endpoint should use Algolia (https://github.com/algolia/algoliasearch-client-python) to be able to perform fuzzy searching on our data and return relevant results.

This is fixed by #150

Closed by #172


text:
Token Action Hud - white text on white background difficult to read

https://foundryvtt.com/packages/token-action-hud

Fixed in v0.1.0

authors: LamahHerder OpticalShadows

repo: OpticalShadows/ACleanModernUI