text:
Fix sphinx warnings and show inheritance in API docs

Fixes #1565
Fixes #1574
This PR removes a significant number of Sphinx warnings and errors than were coming from autodoc.
It also adds inheritance information automagically.
There is 2 errors left and 13 warnings left.
docs/source/commands/rez-config.rst:28: ERROR: Unknown target name: "rez".
docs/source/package_commands.rst:593: WARNING: duplicate object description of optionvars, other instance in configuring_rez, use :no-index: for one of them
docs/source/package_definition.rst:924: WARNING: duplicate object description of version, other instance in package_commands, use :no-index: for one of them
src/rez/vendor/version/version.py:docstring of rez.vendor.version.version.AlphanumericVersionToken:12: ERROR: Unexpected indentation.
src/rez/vendor/version/version.py:docstring of rez.vendor.version.version.VersionRange:28: WARNING: Definition list ends without a blank line; unexpected unindent.
src/rez/build_process.py:docstring of rez.build_process.BuildProcess.__init__:1: WARNING: py:class reference target not found: DEPRECATED
src/rez/build_process.py:docstring of rez.build_process.BuildProcess.__init__:1: WARNING: py:class reference target not found: DEPRECATED
src/rez/build_process.py:docstring of rez.build_process.BuildProcess.__init__:1: WARNING: py:class reference target not found: DEPRECATED
src/rez/build_process.py:docstring of rez.build_process.BuildProcess.__init__:1: WARNING: py:class reference target not found: DEPRECATED
src/rez/rex.py:docstring of rez.rex.EnvironmentDict.keys:1: WARNING: py:class reference target not found: a set-like object providing a view on D's keys
src/rez/utils/pip.py:docstring of rez.utils.pip.pip_to_rez_version:1: WARNING: py:exc reference target not found: InvalidVersion
src/rez/utils/pip.py:docstring of rez.utils.pip.convert_distlib_to_setuptools:1: WARNING: py:class reference target not found: installed_dist
src/rez/vendor/version/test.py:docstring of rez.vendor.version.test.TestVersionSchema:1: WARNING: py:class reference target not found: unittest.case.TestCase
src/rez/vendor/version/version.py:docstring of rez.vendor.version.version.VersionRange.iter_intersect_test:1: WARNING: py:class reference target not found: callable
src/rez/vendor/version/version.py:docstring of rez.vendor.version.version.VersionRange.visit_versions:1: WARNING: py:class reference target not found: callable

Thanks for the new type hinting additions and cleanup! Much appreciated 💯 LGTM

Great. There could have been way more type hints, but I gave up pretty quickly. It's a boring task and I have to say that my time right now is better spent in other areas.

authors: JeanChristopheMorinPerso brycegbrazen

repo: AcademySoftwareFoundation/rez


text:
Prefect flow based on GitHub file for OT2

The prefect flow can be linked to a specific file within a repository, which allows for a sort of "over the air" (OTA) update to the device code.

@yunhzou

@yunhzou what are your thoughts/plans for tomorrow for the OT-2 color matching demo? #26

Sounds like you've been having trouble with installing Prefect on the Raspberry Pi (a 3 I think) embedded in the Opentrons, which it sounds like is running Linux.
Do you mind including the steps/commands you ran and the full command line output for the pip install?
Related:

https://linen.prefect.io/t/47786/hey-everyone-does-anyone-know-what-are-the-resource-requirem
https://github.com/PrefectHQ/prefect/issues/1722 (docker arm images are a thing for prefect)
https://linen.prefect.io/t/2467983/hi-everyone-i-d-like-to-share-with-you-a-nice-project-orches (seems to be possible), also https://unix.stackexchange.com/questions/777264/raspbery-ubuntu-install-running-server-ui-server-how-to-access

When you share the full command output I should be able to help debug. We can jump on a screen share / remote access if needed since it's more urgent.

Works now.
Video:
https://youtu.be/4Eu4eYGAP9w
Code:
https://github.com/yunhzou/OT2Demo/issues/1

source: gharchive/issue

authors: sgbaird yunhzou

repo: AccelerationConsortium/ac-training-lab

license: MIT

license_type: permissive

license_source: github-api


text:
after install with docker enkins not running

Hi
i follow the steps described in
https://accenture.github.io/adop-docker-compose/docs/provisioning/adop_cli/
after pulling and creating all machines  jenkins doesn't start
Jenkins unavailable, sleeping for: 9s

Hi @aermike Could you post the command you used and the logs from the containers to see what the error is. You might need to add the  --with-stdou flag to your ./adop init command.

Hi
Thank you for answer
it work with ./adop init
where i can put IP for machine?

On Thu, 11/8/18, Alicia Steen notifications@github.com wrote:
Subject: Re: [Accenture/adop-docker-compose] after install with docker enkins not running (#296)
To: "Accenture/adop-docker-compose" adop-docker-compose@noreply.github.com
Cc: "aermike" mike_dana_iasi@yahoo.com, "Mention" mention@noreply.github.com
Date: Thursday, November 8, 2018, 6:45 PM
Hi @aermike Could you
post the command you used and the logs from the containers
to see what the error is. You might need to add the
--with-stdou flag to your ./adop
init command.
—
You are receiving this because you were mentioned.
Reply to this email directly, view
it on GitHub, or mute
the thread.

Hi @aermike
You can specify the IP using the -i <ip> flag: https://accenture.github.io/adop-docker-compose/docs/provisioning/adop_cli/ where you replace <proxy_ip> with your IP address.

Thanks @aliciasteen. Closing issue as no further actions.
@aermike please raise another issue if you are experiencing any further issues.

authors: RobertNorthard aermike aliciasteen

repo: Accenture/adop-docker-compose

license_source: bigquery


text:
refactor!: New approach to lazy initialization

This fixes #295 while still keeping the advantages of #179 for clean integrations on Windows and macOS.
The placeholder tree, if necessary, is now the responsibility of the platform adapter; that makes the adapter somewhat more complicated, but it's better to have that kind of complexity in AccessKit than in the caller. The AT-SPI implementation doesn't need a placeholder tree, and neither will Newton (the new Wayland-native accessibility stack I'm prototyping). I don't like how accesskit_atspi_common has to expose some of its implementation details to enable robust state transitions with minimal overhead in accesskit_unix, but I don't know a better way, and accesskit_atspi_common is basically an internal crate anyway.
The update to egui is in this branch. The changes are mostly in egui-winit and eframe.
@DataTriny Please repeat the same testing you did when you implemented lazy initialization for AT-SPI.
I don't yet know how to get all the benefits of #179, particularly synchronous tree initialization without requiring the application/toolkit state to be wrapped in a reference-counted mutex, in the Unix adapter. The problem is that on Windows and macOS, tree initialization is always done in response to a platform event which, in a clean integration, is initially handled by the toolkit, so it can pass us a short-lived mutable reference to the activation handler. But in the Unix adapter, we listen to accessibility status changes on our own thread. Maybe accesskit_unix could have an alternate API where the application listens to that property itself and calls a function when it changes, passing us a short-lived reference to the activation handler.

The behavior of lazy initialization on Unix seem to still work as expected. Reviewing the code now.

source: gharchive/pull-request

authors: DataTriny mwcampbell

repo: AccessKit/accesskit


text:
部分wxml解不出来

wxfb65081e88b0f684
APP.zip
大部分wxml还是可以解的
看app-wxss.js里面代码是在的 函数好像混淆了

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

实际结果确实是少了个比较关键的wxml，但是只处理到app-wxss.js这步的话里面能看到代码 只不过顺序有点乱

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

只解到app-wxss.js时候可以看到里面有一系列
gz$gwx_数字 的函数
但是解到wxml就没有对应的东西

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

只解到app-wxss.js时候可以看到里面有一系列 gz$gwx_数字 的函数 但是解到wxml就没有对应的东西

gz$gwx 之类的函数还原后就是wxml文件，并不是js代码

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

只解到app-wxss.js时候可以看到里面有一系列 gz$gwx_数字 的函数 但是解到wxml就没有对应的东西

gz$gwx 之类的函数还原后就是wxml文件，并不是js代码

我的意思就是app-wxss.js存在这些代码的 但是还原到wxml缺失了 说明有一部分代码还原失败了
比如这个小程序里面看app-wxss.js搜“度数”，能看到一些代码，很明显就是html，但是如果选择还原到wxml，生成的里面没有任何一个文件包含“度数”，那个页面的wxml并没有成功还原出来

 wxfb65081e88b0f684 APP.zip
大部分wxml还是可以解的 看app-wxss.js里面代码是在的 函数好像混淆了

图片中错误属正常，不影响解析结果

只解到app-wxss.js时候可以看到里面有一系列 gz$gwx_数字 的函数 但是解到wxml就没有对应的东西

gz$gwx 之类的函数还原后就是wxml文件，并不是js代码

我的意思就是app-wxss.js存在这些代码的 但是还原到wxml缺失了 说明有一部分代码还原失败了 比如这个小程序里面看app-wxss.js搜“度数”，能看到一些代码，很明显就是html，但是如果选择还原到wxml，生成的里面没有任何一个文件包含“度数”，那个页面的wxml并没有成功还原出来

没有问题，这个包里面没有发现和代码相关的wxml文件名，所以没有还原

authors: Ackites WolfCanglong

repo: Ackites/KillWxapkg


text:
get_rev_children() ?

In recipe-579138.py, there is a get_rev_children method in the depth-first search. This method does not work on any of my editors/REPLs and there is no documentation on it anywhere. Is this a typo? Or is something missing?

Works in python 2.7 and python 3.5
The method is from the Node class and simply returns the childrens of a node.
Using the following code in the main method :
root = make_test_tree()
print(root.get_rev_children())

produces the following output :
[Node: [b2], Node: [b1], Node: [b0]]

which is correct, according to how the test tree is built.

@CrumbleZ Would it be possible to see your entire script? When I run those two lines of code, I still get the same error message.

What is the error message you are getting ?
What editor are you using ?
How are you running your code ? (From within your editor, or manually from a terminal ?)

authors: CrumbleZ castrodd

repo: ActiveState/code

license: mit


text:
update org.activiti.cloud.dependencies:activiti-cloud-dependencies to 7.1.151

UpdateBot pushed maven dependency: org.activiti.cloud.dependencies:activiti-cloud-dependencies to: 7.1.151

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.dependencies:activiti-cloud-dependencies 7.1.151 --merge false

repo: Activiti/activiti-cloud-audit


text:
fix(versions): update Activiti/activiti-cloud-dependencies versions

UpdateBot pushed maven dependency: org.activiti.cloud.connector:activiti-cloud-connectors-dependencies to: 7.0.50

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.connector:activiti-cloud-connectors-dependencies 7.0.50

/test this
/approve

repo: Activiti/activiti-cloud-dependencies


text:
fix(versions): update Activiti/activiti-cloud-full-chart-security versions

UpdateBot pushed helm dependency: activiti-cloud-full-example to: 7.1.290

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-full-example 7.1.290


text:
update org.activiti.cloud.dependencies:activiti-cloud-dependencies to 7.1.156

UpdateBot pushed maven dependency: org.activiti.cloud.dependencies:activiti-cloud-dependencies to: 7.1.156

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.dependencies:activiti-cloud-dependencies 7.1.156 --merge false

repo: Activiti/example-cloud-connector


text:
update org.activiti.cloud.dependencies:activiti-cloud-dependencies to 7.0.179

UpdateBot pushed maven dependency: org.activiti.cloud.dependencies:activiti-cloud-dependencies to: 7.0.179

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.dependencies:activiti-cloud-dependencies 7.0.179 --merge false

/test this
/approve

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.dependencies:activiti-cloud-dependencies 7.0.180 --merge false

/test this
/approve

/test this
/approve

UpdateBot commands:
updatebot push-version --kind maven org.activiti.cloud.dependencies:activiti-cloud-dependencies 7.0.181 --merge false

repo: Activiti/ttc-acceptance-tests


text:
fix(versions): update Activiti/ttc-charts versions

UpdateBot pushed regex: \s+tag: (.*) to: 7.1.157

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.157 --exclude --previous-line \s+repository: activiti/ttc-connectors-reward **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.164 --exclude --previous-line \s+repository: activiti/ttc-campaigns-service **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.158 --exclude --previous-line \s+repository: activiti/ttc-connectors-dummytwitter **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.153 --exclude --previous-line \s+repository: activiti/ttc-connectors-ranking **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.156 --exclude --previous-line \s+repository: activiti/ttc-rb-english-campaign **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.152 --exclude --previous-line \s+repository: activiti/ttc-connectors-processing **/values.yaml

UpdateBot commands:
updatebot push-version --regex \s+tag: (.*) --value 7.1.155 --exclude --previous-line \s+repository: activiti/ttc-query-campaign **/values.yaml

repo: Activiti/ttc-charts


text:
Performance chapter on the site

On an AWS EC2 instance of size c5.2xlarge, Baker can read zstandard records from S3, uncompress them and apply a basic filtering logic, compressing them back on local files using ~90% of capacity of each vCPU (8 in total) and ~3.5GB of RAM.
It reads and writes a total of 94 million records in less than 9 minutes, that’s 178k records per second.
On a c5.2xlarge instance (48 vCPUs) the same test takes 2 minutes, so that’s a speed of 775k records per second.

This excerpt is from https://getbaker.io/docs/performance/, the readme correctly states the last one is a c5.12xlarge instance.

yup, it's a typo @arl

Thanks. I'll take care of it
On Fri, Jul 2, 2021, 10:10 Tommaso Visconti @.***>
wrote:

Assigned #182 https://github.com/AdRoll/baker/issues/182 to @arl
https://github.com/arl.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/AdRoll/baker/issues/182#event-4970037774, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADUL2XR7QD2O3LW6JYDSY3TVVX6XANCNFSM47WFITYA
.

authors: arl naufraghi tommyblue

repo: AdRoll/baker


text:
Consider Switching From PCLs to .NET Standard

Summary
Microsoft has officially deprecated Portable Class Libraries, which is what Duality is based on with regard to portability. Projects still compile just fine and will for the foreseeable future, but it will get progressively harder and less intuitive to keep things working and expanding on it. Consider switching all PCL projects to .NET Standard for v3.0.
Analysis

Duality PCLs use Profile111, which is equivalent to .NET Standard 1.1. Use this standard version for maximum compatibility.

Check which VS version is minimum required to create and build .NET Standard 1.1 libraries using the new reduced csproj format. Don't use the .json format, seems pretty much deprecated by now.
Be careful how NuGet packages are referenced. The csproj PackageReference item is not supported for all project types yet, see here. Might be better to stick to packages.config for now.
Consider doing a full switch to VS 2017 and the new project system as part of this change.

.NET Standard packages require at least NuGet 2.12 or 3.4, so the Duality package manager will need to be updated to this first. The new csproj package reference format requires at least NuGet 4.0.

It may also need to handle platform-dependent dependency scenarios.
Make sure that Duality packages continue to be able to reference regular NuGet packages.

Figure out how the NuGet package specs for Duality packages need to be changed in order in order to properly identify as netstandard packages.
Get proficient with how .NET Standard works combined with regular .NET Framework applications and libraries when it comes to dependencies and runtime behavior.

Make sure the editor doesn't get spammed with .NET Framework specific forward-only assemblies.
Make sure the deployed launcher still works on platforms it worked before, like Linux and MacOS via Mono.
What's the role of reference assemblies in this?

Some links for further research:

https://stackoverflow.com/questions/42254288/referencing-a-net-standard-library-from-a-windows-class-library
https://stackoverflow.com/questions/44617898/how-do-you-reference-a-net-standard-library-from-a-net-framework-4-5-console-a
https://github.com/dotnet/standard/issues/410
https://github.com/dotnet/standard/issues/481
https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx
https://github.com/dotnet/standard/issues/146#issuecomment-271105398
https://docs.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2017
https://docs.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2015

Projects to switch:

FarseerDuality
NVorbis
Duality / Core
Primitives
Compatibility
Tilemaps (core and sample)
All sample projects
The game plugin template

Note that it might also be required to change the AppVeyor CI settings to run in a new environment. Check the current settings to see which VS version is used.

Its good to switch to standard since PCL's are deprecated now and in the future that could mean it will be harder and harder to use other libraries.
However there are quite some things that have to be researched/changed beforehand as you already pointed out.

Related note on Twitter about .NET Standard libraries has a nice and short way to put it:

.NET Standard libraries are "unrunnable" because they are agnostic to any specific runtime frameworks.
On library build time, they specify an API surface area and nothing more.
On application build time, the specific target framework is known and .NET Standard libraries can be referenced accordingly, choosing different specific dependencies in different scenarios.

This reflects the fact that .NET Standard is, unlike PCL, not a "build once, run anywhere" deal, but a "build once, then use it for building for any platform" deal. Unfortunately, this clashes with the current portability model of Duality, which is "build once, run anywhere [just switch launcher and backend]". We can deal with this for all the official packages, but there will be cases where people publish Duality packages that depend on .NET Standard libraries with different dependency situations across platforms, which will be lost when used in Duality because the editor is a .NET Framework runtime.
For the most part, this won't really matter - we'll still get Mono compatibility and a bit more on top of that, and we haven't really had a lot of cross-platform experience beyond that so far anyway. It may turn out that, for true, robust platform support, we will need a proper build pipeline and different sets of dependencies built into the editor anyway, and if anything .NET Standard might help with that by unifying this requirement across all platforms and pushing the issue.

Side note about NuGet packing support for NetStandard packages: http://blog.tdwright.co.uk/2017/11/20/the-perils-of-publishing-a-net-standard-library-to-nuget/

Hey @ilexp a few days ago I converted Duality to .Net Standard. I have not put up a pull request yet because I had run into some problems when trying to use .Net Standard 1.1. Because of those problems, I ended up using .Net Standard 2.0 instead. However, when using 2.0 almost no code changes were needed, and I have been able to run Duality with no problems so far. In fact only two code changes were needed for Duality and all of it's plugins (or at least the plugins in this repo) combined! And the changes were just removing code that had become obsolete because of .Net Standard. Needless to say I don't think using 2.0 instead of 1.1 will cause compatibility problems. But never the less, I wanted to make sure you are okay with using 2.0 instead of 1.1, also I wanted to know which branch I should put a pull request on (if any). On a side note, I have only been using Duality for a few weeks now, but I really like it, and hope to be able to help make it even better.

Hey @Caylis1397, and welcome! Glad you're up for a PR on this 🙂
The base branch for working on this should be develop-3.0, but because of the magnitude of this change, I might create a new feature/3.0/netstandard branch for you to PR into when we're ready.
I think that we should try to target .Net Standard 1.1 first though, since the API surface we require should be as small as possible with multi platform support in mind. Can you be more specific which problems you encountered by targeting 1.1?
I'll be off for a week, but I'll get back to you after that.
(cc @AdamsLair/duality-contributors, in case they want to join the discussion in the meantime)

Well as far as 1.1 goes, there is a lot of missing api. For instance, here are some of the calls to missing api in Duality.Backend.DefaultPluginLoader:
System.IO.File
System.IO.Directory
System.IO.Path.GetFullPath
System.IO.BufferedStream
System.StringComparison.InvariantCultureIgnoreCase
System.AppDomain
System.ResolveEventArgs
System.AssemblyLoadEventArgs
System.Reflection.Assembly.GetEntryAssembly
System.Reflection.Assembly.Location
System.Security.Cryptography
All of those are not available in .Net Standard 1.1. Some of those have workarounds, but I can't figure out how to get past most of the missing api. In NVorbis.ParameterChangeEventArgs, the serializable attribute is also missing.
So if 1.1 is a hard requirement, then this will take a lot of work and planing to figure out. I do have a lot of free time, but I also have other projects, and some of them are semi time sensitive. So I can definitely give it a shot, it just might take a while. The real concern I have though, is that I might not have the knowledge / skill to find away around all these missing api calls.
If 1.1 is not a hard requirement, and you don't want to use 2.0. Then I am sure there is a workable middle ground.
I would still like to help out on this. So whatever way you think we should go about this, I will definitely try to help in any way I can.

I don't think we want to have to implement all those :P
Is there a version before 2.0 and after 1.1 that does cover most of the used API? Also Is .NET core 2.0 really that much harder to use cross platform? Wasnt that the whole point of core?

Do you really care about Windows 8.1, Windows Phone 8.1, and Windows Phone Silverlight 8.0? There's no launcher for these anyway. I say just make the jump to .NET Standard 2.0 now. All modern .NET supports it:

.NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
Xamarin.Android 8.0
Xamarin.iOS 10.14
Xamarin.Mac 3.8

See this table for more details.

But if you do care...
.NET Standard 1.3 adds most of the filesystem and crypto APIs.
The assembly load stuff can be handled by cross-targeting (e.g. use the current code on .NET Framework/Mono and use AssemblyLoadContext on .NET Core)

Looking at that table I say we go for 2.0. Windows phone is completely dead (I can know it I used to own one) and windows 8.1 is close to being dead. Not worth it imho.

I do agree that .Net Standard 2.0 is the way to go. After all, when converting Duality to 2.0 the only problems I found were caused by Visual Studio's new project format. And I still have not run into any bugs when using Duality running on 2.0. Or at least none that were caused switching to 2.0. But, 2.0 does have one down / up side; the number of available APIs in 2.0 is 32000 compared to 1.6's available APIs of 13000. The upside to this is that there are a lot more available tools to use, but the downside is that having so much functionality also means having less portability. I don't think this will be a problem, but it should be considered when making a decision.

I would consider the following: if we go with .Net Standard 1.1, would we end up switching to 2.0 in the future anyways? If so, it seems we might as well 'bite the bullet' and go with 2.0 now.

It seems like the discussion is currently leaning towards adopting .NET Standard 2.0, but I do think that there is value in restraint when it comes to API usage. The less we use, the easier platform adoption is - and this includes potential future platforms as well, which may work with a reduced API subset.
My point is not that we should bend over backwards to get compatibility with 1.1, but that I think we're so close to 1.1 that it makes sense to try to stick to it, rather than abandoning it on the first sight of trouble. If we can't make it work, 2.0 makes sense, but I think we should put a bit more energy into trying 1.1 first.

.NET Standard 1.3 adds most of the filesystem and crypto APIs.

That's an option too, though I don't think we need them for the most part.
Let's investigate where the problem originates from and see if we can fix remaining compiler errors on a case-by-case basis. For example, all file system access has been removed from the core lib in v2.0, and now lives in the system backend plugin, which is unaffected by the PCL-to-.NET Standard switch.

Well as far as 1.1 goes, there is a lot of missing api. For instance, here are some of the calls to missing api in Duality.Backend.DefaultPluginLoader:

DefaultPluginLoader is not part of any core library. It is a shared source file that is included by the launcher (.NET Framework 4.x), the editor (.NET Framework 4.x as well) and testing environments - if there are compiler errors for this class, then that probably means something got mixed up.
With .NET Standard 1.1, is the new .csproj project system already enabled? As far as I recall, it includes all *.cs files by default, and it is possible that the shared source file is located within the Duality folder, which would accidentally include it in the core library build.
If that's the case, how does the .NET Standard 1.1 compile hold up, error-wise?

Hey @ilexp, Thanks for pointing out that the Default Plugin Loader was not part of Duality's main core, I had missed that completely. And when I moved it to somewhere else, Visual Studio stopped complaining about most of the errors, even ones that were unrelated. All that was left were 4 errors in Duality.Drawing.PixelData do to Parallel.ForEach not being part of .Net Standard 1.1 by default. However, that was easily fixed by adding a direct reference to System.Threading.Tasks.Parallel in Duality's project. It now compiles and runs without an errors!
TL;DR:
I got Duality running on .Net Standard 1.1.
@ilexp all that needs to be done now is to change to a newer version of NuGet, correct? I have never published anything on NuGet so I don't know what changes will be required, but your the one who publishes Duality on NuGet anyways right? If so, then I'm sure you can do that part.

TL;DR:
I got Duality running on .Net Standard 1.1.

That's great news 🙂

@ilexp all that needs to be done now is to change to a newer version of NuGet, correct? I have never published anything on NuGet so I don't know what changes will be required, but your the one who publishes Duality on NuGet anyways right? If so, then I'm sure you can do that part.

I'm no longer sure if this is really a hard requirement (discussion in #574), and also not yet sure if this is all that needs to be done. Either way, I'd say we should proceed with this step by step and see how that works out. To make sure we'll have a safe way back, I have created a new feature/3.0/netstandard branch for you to file a PR. We can do in-detail discussion in the PR thread and proceed with a more high-level view here.

Nice job on the progress @ilexp @Caylis1397. Looking forward to switching to core.

With .NET Standard 1.1, is the new .csproj project system already enabled? As far as I recall, it includes all *.cs files by default, and it is possible that the shared source file is located within the Duality folder, which would accidentally include it in the core library build.

As far as I know all core projects use the new .csproj format. It includes *.cs files by default (which for the most part is good since it dramatically reduces the size of the csproj file). No need to move the file though as you still can exclude them.

Moving this to the Future milestone, as it increasingly seems like this is going to be a bigger feature to complete than anticipated. As I'm currently moving toward slowly wrapping up v3.0, I think this will have to remain in a branch for now, to be considered for binary release at some later point. This will also give us more time to gather experience with this in practice.
tl;dr: Let's carry on pursuing this, but don't expect it in v3.0.

Progress

Initial work on this was done by @Caylis1397 and is now present in branch feature/3.0/netstandard.
Updated appveyor.yml to use a VS 2017 build environment.

ToDo:

Find out how the NVorbis package spec would need to look like to be supporting both the existing PCL profile, as well as netstandard 1.1
In a feature branch, update AdamsLair.NVorbis to do a dual build for both PCL Profile 111 and netstandard 1.1, and include both in the package with the proper target frameworks.
Check what the Duality v2.x package manager will do when confronted with the resulting package.
If it can't deal with it, fix it and binary-release a patch for v2.x. Make sure to verify it works properly in a local mock setup, potentially add unit tests too.
Merge back the AdamsLair.NVorbis feature branch, release the package and verify that Duality v2.x installations still work properly.
Update the netstandard feature branch to use the new NVorbis package dependency.
Re-introduce "aggregate binaries" build steps in each project that were accidentally removed from the csproj files during netstandard conversion.
Make sure the PR feature branch compiles fine manually.
Make sure the AppVeyor CI build compiles fine.
Verify and review this PRs changes to be ready for merge to the main repo feature branch.
Merge this PR, so the main repo has an up-to-date feature branch for netstandard.
Close this PR after merge, independently decide when to actually switch to netstandard later on.

In the process of porting the pathfindax plugin to netstandard/netcore I noticed that nunit doesnt seem to like this. They seem to have some major bugs regarding the new roslyn based test discovery that came in VS15.6. In my case half my tests where not discovered and I had some 'ghost' tests that didnt actually exists so basically it rendered nunit unusable.
I currently have no idea if this is getting fixed any time soon. Since duality is using nunit this might become a issue for duality as well.
I fixed the problem by replacing nunit with xunit which does not have these bugs.

Necromancing the thread

I currently have no idea if this is getting fixed any time soon. Since duality is using nunit this might become a issue for duality as well.

It won't be fixed - XUnit is NUnit - the authors decided to start with new solution because of NUnit incompatibility - they also wanted to move away from MSTest

Some MS docs on multi-targeting platforms with .NET Standard: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting
One point to note is that they explicitly recommend not targeting any 1.x standard version unless there is a specific older platform that would otherwise be unsupported. Might be worth it to reconsider the 1.x target after verifying exactly which platforms and potential future platforms would be affected.

Already had a feeling .net standard/core 2.x is the way to go for projects going forward. All the nice stuff is there (SIMD, span, tiered compilation, less dependency hell etc).
Though you cannot reference a .net standard 2.x library in a .net 4.5 library I believe. Need .net 4.6.2 for that I think.

Though you cannot reference a .net standard 2.x library in a .net 4.5 library I believe. Need .net 4.6.2 for that I think.

.NET Framework 4.6.1+ allowed; 4.7.2 recommended.

.NET Framework 4.6.1+ required; 4.7.2+ recommended.

Related background info:
https://stuartlang.uk/dotnet-framework-support-for-dotnetnet-standard-2-0/

VS2019 no longer supports PCL's out of the box:
https://github.com/AdamsLair/duality/pull/726
It is possible however to install a targeting pack for it.

I created a new branch here which is based upon the netstandard branch we had. Some changes:

Uses netstandard 2.0 instead of 1.1
Uses netframework 4.7.2 instead of 4.5
Remove the portable compatibility package since its no longer needed now
I managed to fix nvorbis as a packagereference not getting copied to the buildoutput. So its no longer included in the source but its a normal nuget package again.
Noticed there was a startaction for the test project that no longer works with unit 3.x so I cleaned those up since we have a testrunner in visual studio nowadays anyway.

Tests are green and iam able to start duality and do some simple stuff. Haven't gone much farther than running a scene with a rigidbody that is falling.

So let's pick this up again 🙂

I created a new branch here which is based upon the netstandard branch we had. Some changes:

Looking at the branch comparison, it seems like something's wrong there. All those "merge master into release" commits shouldn't be part of the branch. Can you create a new branch off the current master and cherry-pick the commits we need?

Some changes:

Nice work 👍

Also noticed that starting the game from visual studio breaks debugging.

This could be a critical issue, so we should investigate a fix or workaround for this first to get a clear picture of our options in proceeding.

Progress

Lots of updates by @Barsonax, see above
Got the internal package manager ready for .NET Standard, multi-framework packages and multi-framework dependencies in issues #703, #710 and #715.

ToDo:

Fix the feature branch including a lot of commits that shouldn't be there, probably by creating a new one and cherry picking a bit. @Barsonax
Find a fix or workaround for the broken debugging when running a Duality game from its plugin solution via VS debug button, see here: dotnet/project-system#3690
Test what happens when confronting the Duality package manager with a package that targets only .NET Standard, and nothing else. If that doesn't work, fix it.
Fix the broken Canvas rendering unit test that was mentioned in the chat after recent updates to the netstandard feature branch.
Update AdamsLair.NVorbis dependency to target netstandard 2.0, and update the package as needed.

Verify this is fine with both Visual Studio in the Duality project, and with the package manager in a Duality editor instance.
Verify existing Duality installations can deal with this with a mock repository.
Release it as an updated dependency. All other dependencies aren't PCLs anyway.
Update the netstandard feature branch to use the new NVorbis package dependency.

Re-introduce "aggregate binaries" build steps in each project that were accidentally removed from the csproj files during netstandard conversion.
Make sure the feature branch compiles fine manually using VS2019.
Make sure the AppVeyor CI build compiles fine via VS2019 image.
Retarget all Duality packages to target netstandard 2.0

Do a full test build of all Duality packages and check if a new installation using a mock repository works fine.

Did I miss any ToDos?

ugh it doesnt happen often but I made a error with git :(. Now to fix it...

Extended the status message / ToDo list:

Progress

Lots of updates by @Barsonax, see above
Got the internal package manager ready for .NET Standard, multi-framework packages and multi-framework dependencies in issues #703, #710 and #715.

ToDo:

Fix the feature branch including a lot of commits that shouldn't be there, probably by creating a new one and cherry picking a bit. @Barsonax
Find a fix or workaround for the broken debugging when running a Duality game from its plugin solution via VS debug button, see here: dotnet/project-system#3690
Test what happens when confronting the Duality package manager with a package that targets only .NET Standard, and nothing else. If that doesn't work, fix it.
Fix the broken Canvas rendering unit test that was mentioned in the chat after recent updates to the netstandard feature branch.
Update external AdamsLair.NVorbis dependency to target netstandard 2.0, and update the package as needed.

Verify this is fine with both Visual Studio in the Duality project, and with the package manager in a Duality editor instance.
Verify existing Duality installations can deal with this with a mock repository.
Release it as an updated dependency. All other dependencies aren't PCLs anyway.
Update the netstandard feature branch to use the new NVorbis package dependency.

Re-introduce "aggregate binaries" build steps in each project that were accidentally removed from the csproj files during netstandard conversion.

Use the fix that Barsonax mentioned here.

Update the project template for the game plugin to use netstandard 2.0.
Make sure the feature branch compiles fine manually using VS2019.
Make sure the AppVeyor CI build compiles fine via VS2019 image.
Retarget all Duality packages to target netstandard 2.0

Do a full test build of all Duality packages and check if a new installation using a mock repository works fine.

Yes for the projects that stay on the netframework we need to target 4.7.2. I already did this in my netstandard branch but idk if that needs to be done elsewhere as well.

Not sure whether it really makes sense to update all those dependencies. No harm done to move to the same level as the Duality editor and Desktop backends, but is there any gain from it doing it in a bulk edit? Sounds to me like we might as well leave them be and update when they require any newer framework on their own. They can be used just fine from 4.7.2, whichever framework they're targeting themselves, correct? Let me know if I'm missing something here.
Affected projects would be:

AdamsLair.OpenTK
AdamsLair.OpenTK.GLControl
AdamsLair.DockPanelSuite
AdamsLair.TreeViewAdv
AdamsLair.WinForms
AdamsLair.WinForms.PopupControl

Fix the broken Canvas rendering unit test that was mentioned in the chat after recent updates to the netstandard feature branch.

This was broken while attempting to migrate to the new csproj format to clean up the nuget packages and make that more consistent. I decided to do it since all the plugin projects are already migrated now. Its not strictly neccessary. Since it turned out to be more complex than anticipated it might be better to do this later (and create a separate issue about it).

I reverted the csproj format change, tests are working again.

Re-introduce "aggregate binaries" build steps in each project that were accidentally removed from the csproj files during netstandard conversion.
Use the fix that Barsonax mentioned here.

I have been thinking about this, why not simply set the output path like so: https://github.com/Barsonax/Singularity/blob/master/src/Singularity/Singularity.csproj#L24
For the netstandard projects you also need to disable appending the targetframework like so:
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>

Update on the current progress
Progress

Lots of updates by me, see above
Got the internal package manager ready for .NET Standard, multi-framework packages and multi-framework dependencies in issues #703, #710 and #715.
Fixed the feature branch including a lot of commits that shouldn't be there.
Fixed the broken Canvas rendering unit test by reverting some changes. For some reason this test doesnt like the new csproj format so I only migrated this project to packagereference.
Updated the project template for the game plugin to use netstandard 2.0.

ToDo:

Find a fix or workaround for the broken debugging when running a Duality game from its plugin solution via VS debug button, see here: dotnet/project-system#3690

Update external AdamsLair.NVorbis dependency to target netstandard 2.0, and update the package as needed.

Verify this is fine with both Visual Studio in the Duality project, and with the package manager in a Duality editor instance.
Verify existing Duality installations can deal with this with a mock repository.
Release it as an updated dependency. All other dependencies aren't PCLs anyway.
Update the netstandard feature branch to use the new NVorbis package dependency.

Re-introduce "aggregate binaries" build steps in each project that were accidentally removed from the csproj files during netstandard conversion.

Use the fix that Barsonax mentioned here.

Make sure the feature branch compiles fine manually using VS2019.

Make sure the AppVeyor CI build compiles fine via VS2019 image.

Retarget all Duality packages to target netstandard 2.0

Do a full test build of all Duality packages and check if a new installation using a mock repository works fine.

Bugs

Test what happens when confronting the Duality package manager with a package that targets only .NET Standard, and nothing else. If that doesn't work, fix it.

I installed Singularity.Duality.core which is not a netstandard2.0 only package and for some reason it does not see it also has to install Singularity as well causing a runtime exception:

EditorError:   FileNotFoundException: Could not load file or assembly 'Singularity, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
CallStack:
   at Singularity.Duality.Scopes.GameScope..ctor(ILogger logger, ISceneScopeFactory sceneScopeFactory, ISceneEventsProvider sceneEventsProvider, IEnumerable`1 moduleResources)
   at Singularity.Duality.SingularityPlugin.OnGameStarting()
   at Duality.CorePluginManager.InvokeGameStarting() in C:\Git\duality\Source\Core\Duality\CorePluginManager.cs:line 136
   at Duality.DualityApp.SwitchExecutionContext(ExecutionContext targetContext) in C:\Git\duality\Source\Core\Duality\DualityApp.cs:line 511
   at Duality.Editor.Sandbox.Play() in C:\Git\duality\Source\Editor\DualityEditor\Sandbox.cs:line 104
   at Duality.Editor.Forms.MainForm.actionRunSandbox_Click(Object sender, EventArgs e) in C:\Git\duality\Source\Editor\DualityEditor\Forms\MainForm.cs:line 577
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Not sure how to fix the bug I just found. Seems to be a bug in nuget but since its 2.14 I doubt it will ever get fixed.

Didn't find time yet for a full response, but regarding the singularity NuGet thing, the runtime exception does look related to the package installation problem, could be missing or misplaced dependencies / libs. Did you try what happens when you manually package it with an explicit .nuspec where you specify files and dependencies as needed?

The package is correct its nuget that is not correct here

We're no longer softblocked by #668, as we found a workaround. Proceed with #668 after #574 is solved, then continue with this issue.

Fix the broken Canvas rendering unit test that was mentioned in the chat after recent updates to the netstandard feature branch.

This was broken while attempting to migrate to the new csproj format to clean up the nuget packages and make that more consistent. I decided to do it since all the plugin projects are already migrated now. Its not strictly neccessary. Since it turned out to be more complex than anticipated it might be better to do this later (and create a separate issue about it).

Made a issue for this: https://github.com/AdamsLair/duality/issues/737
We should tackle that issue after we complete this one.

authors: Barsonax Caylis1397 DaceKonn bricelam deanljohnson ilexp

repo: AdamsLair/duality


text:
Bump coverlet.collector from 6.0.1 to 6.0.2

Bumps coverlet.collector from 6.0.1 to 6.0.2.

Release notes
Commits

updated-dependencies:

dependency-name: coverlet.collector dependency-type: direct:production update-type: version-update:semver-patch ...

To delete


text:
Add HTTP error page resource

Application may extract it from its resources and set it via some method call to ProxySession.

Merged, core/pull-requests/102, 106

authors: sfionov sxgunchenko

repo: AdguardTeam/CoreLibs


text:
Slow SQL Statements

SQL statements going over the internet are inherently slow. Currently, all of the SQL statements are being executed in the thread they are called in, which is hogging the run time of the thread. If there was a runnable that was invoked in a new thread, then SQL statements would not clog up the runtime while they are waiting for a response. Additionally, look into executing statements in bulk rather than one by one when initializing the user interface.

So this is why an app should hit an API that makes the calls rather than direct DB connection also have you tested upload/download speeds from the server? Might be a ISP issue

Version 2.0 will begin using Hibernate ORM. There are definitely speed issues with the server, and I am looking into getting a host from the school.

You should be able to utilize the free tier of AWS for something like this and never be charged a dime. If you need help getting that set up just let me know.

Moved MySQL server onto RDS (AWS)

Optimized Hibernate config to no longer check for schema updates because it was a lengthy process with little benefit. This cut down on initial loading time dramatically.

Changed POJO fetch type to eager. I decided that a marginally longer load time was better than constant transactions. Will need to ensure persistence, however.

authors: AdmirilRed richeyh

repo: AdmirilRed/RedLibrary


text:
Change Libraries to OneToMany Relationship

Since users are now children of the Organization entity, there is no further reason to keep Libraries as ManyToMany. Should remove foreign key clutter.

Implemented with commit 0f620c9.


text:
[REVIEW] Feature/httpcache extensions

Picking this one up again. Simplified it by removing the ehcache module and sticking to caffeine.
Will add unit tests this week.
@davidjgonzalez , please review my work and let me know.

Coverage decreased (-0.04%) to 41.118% when pulling b02ec6f6a51e7c27555a231a4c113b83b89fc09e on Sc0rpic0m:feature/httpcache-extensions into f3ba4f3dbeb23f8f8c92301ab3b2bb053c9fa275 on Adobe-Consulting-Services:master.

This may be a bad idea, but I'd suggest breaking this into smaller PRs so that it is easier to manage. I'm not sure I totally grok all the changes, but these seem like the high-level buckets:

API changes to AbstractGuavaCacheMBean. I agree (I think) with some of @davidjgonzalez's comments that this seems unnecessary, but looking at just this change in isolation will help manage it. I will say that I don't think that just because a class is in (for example) com.adobe.acs.commons.util.impl that automatically means it should be in com.adobe.acs.commons.util when made API.
API changes for the HTTP Cache component specifically (I assume these are needed to allow for new providers).
Introduction of an EHCache provider
Introduction of a Caffeine provider

Terracotta doesn't expose everything thats what I need to copy em over. Let's remove ehcache for now and just stick with caffeine then? I guess your right, we shouldn't touch too many files. Let me do this now.

authors: Sc0rpic0m coveralls justinedelson


text:
Update JAVA_VERSION to JDK_VERSION in build.xml files

JAVA_VERSION is no longer being passed to build.xml files. So, in the build.xml files where JAVA_VERSION parameter is being used, we should change them to JDK_VERSION

The update has already been made. Cancelling this issue

repo: AdoptOpenJDK/openjdk-tests


text:
Cache the results of requests to iRacing.

Given iRacing is rate limited and not super quick to call, it might be handy to provide a cache inside of IDataClient that keys on url.
In my use case I have a few people calling the service so calls like accessing member profiles and overall results, or things that might be called "often" by many people, like current championship standings could do with caching.

Great idea.
There are some results that should be cached even longer term as well (tracks, lookups, etc).

For what it's worth it looks like iRacing caches calls on AWS, using a similar strategy (guid representing a call, I think) as I'm seeing calls to https://scorpio-assets.s3.amazonaws.com/production/data-server/cache/data-services/results/get/?AWSAccessKeyId= in my debug log.  Sensible defensive programming but it can't hurt to a cache closer to home.

Yup. Almost every method you call on my client makes 2 HTTP requests. First to call the Data API endpoint, second to convert the link that is returned into JSON that can be processed.
That's what the DataResponse<TData>.DataExpires property is all about. That would be the basis for expiring the cache items.

Didn't mean to close it - this is only partially implemented.

authors: AdrianJSClark robgray

repo: AdrianJSClark/aydsko-iracingdata


text:
Thread leak causing server to crash

Describe the bug
After running our server for a while with AdvancedSeasons on it, we start getting resource limit errors and the entire server crashes even before we hit our allocated memory limit. When profiling the server, I see that there are a ton of parked threads belonging to AdvancedSeasons that all have the same stack trace:
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base@21.0.3/Native Method)
	- parking to wait for  <0x0...> (a java.util.concurrent.CompletableFuture$Signaller)
	at java.util.concurrent.locks.LockSupport.park(java.base@21.0.3/LockSupport.java:221)
	at java.util.concurrent.CompletableFuture$Signaller.block(java.base@21.0.3/CompletableFuture.java:1864)
	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base@21.0.3/ForkJoinPool.java:3780)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base@21.0.3/ForkJoinPool.java:3725)
	at java.util.concurrent.CompletableFuture.waitingGet(java.base@21.0.3/CompletableFuture.java:1898)
	at java.util.concurrent.CompletableFuture.join(java.base@21.0.3/CompletableFuture.java:2117)
	at net.minecraft.server.level.ChunkProviderServer.a()
	at net.minecraft.world.level.World.a()
	at net.minecraft.world.level.World.a_()
	at org.bukkit.craftbukkit.v1_20_R3.block.CraftBlock.getType()
	at net.advancedplugins.seasons.visuals.type.FallingLeafVisual.createFallingLeaves(FallingLeafVisual.java:68)
	at net.advancedplugins.seasons.visuals.type.FallingLeafVisual.tick(FallingLeafVisual.java:20)
	at net.advancedplugins.seasons.visuals.VisualsHandler$$Lambda/0x00007fbfd75c4678.accept(Unknown Source)
	at java.util.HashMap$KeySet.forEach(java.base@21.0.3/HashMap.java:1016)
	at net.advancedplugins.seasons.visuals.VisualsHandler.lambda$new$0(VisualsHandler.java:28)
	at net.advancedplugins.seasons.visuals.VisualsHandler$$Lambda/0x00007fbfd663d000.run(Unknown Source)
	at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftTask.run()
	at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftAsyncTask.run()
	at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run()
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@21.0.3/ThreadPoolExecutor.java:1144)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@21.0.3/ThreadPoolExecutor.java:642)
	at java.lang.Thread.runWith(java.base@21.0.3/Thread.java:1596)
	at java.lang.Thread.run(java.base@21.0.3/Thread.java:1583)

The number of threads continue to grow until the server crashes:
---- Minecraft Crash Report ----
// I feel sad now :(

Time: 2024-06-18 15:37:04
Description: Exception in server tick loop

java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
	at java.base/java.lang.Thread.start0(Native Method)
	at java.base/java.lang.Thread.start(Thread.java:1553)
	at java.base/java.lang.System$2.start(System.java:2577)
	at java.base/jdk.internal.vm.SharedThreadContainer.start(SharedThreadContainer.java:152)
	at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:953)
	at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
	at java.base/java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:754)
	at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftAsyncScheduler.mainThreadHeartbeat()
	at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftScheduler.mainThreadHeartbeat()
	at net.minecraft.server.MinecraftServer.b(MinecraftServer.java)
	at net.minecraft.server.dedicated.DedicatedServer.b(DedicatedServer.java)
	at net.minecraft.server.MinecraftServer.a(MinecraftServer.java)
	at net.minecraft.server.MinecraftServer.w(MinecraftServer.java)
	at net.minecraft.server.MinecraftServer.lambda$spin$0(MinecraftServer.java)
	at java.base/java.lang.Thread.run(Thread.java:1583)

How to reproduce
Unfortunately I was not able to reproduce this issue on a testing server by myself, so I don't know how to reproduce this. I have attached our server info+config, as well as a Spark and a jstack showing the massive amount of threads.
Server: Pufferfish+ version git-PufferfishPlus-45 (MC: 1.20.4) (Implementing API version 1.20.4-R0.1-SNAPSHOT) (Git: eb69634 on HEAD)
Configuration: archive-2024-06-19T152807+0100.tar.gz
Screenshots / Videos
Spark: https://spark.lucko.me/zvVbNIRlzI
jstack: stack.txt
Server Log
Too big to upload - mostly useless

Did you try using PaperMC?

Hi! Your problem should be solved in version 1.3.8.

repo: AdvancedPlugins/Seasons


text:
New component

Описание PR

Добавлен новый компонент "NoGhostFollowComponent".
Причины изменения
Данный компонент предотвращает возможность призраков (гостов) следовать за определёнными сущностями, чтобы избежать нежелательных конфликтов....
Техническая информация
Компонент можно назначить на любую сущность. После его активации призраки не смогут телепортироваться к этой сущности, благодаря обновлению логику в функции return в коде компонента, мы будем выходить из OnGhostWarpToTargetRequest и не телепортироваться.
Критические изменения
Внесено одно условие в GhostSystem.cs в функции OnGhostWarpToTargetRequest, что блокирует телепортацию призраков к объектам с добавленным компонентом.

Требования

[x] Я прочитал(а) и следую Руководство по созданию пулл реквестов. Я понимаю, что в противном случае мой ПР может быть закрыт по усмотрению мейнтейнера.
[x] Я добавил скриншоты/видео к этому пулл реквесту, демонстрирующие его изменения в игре, или этот пулл реквест не требует демонстрации в игре

Чейнджлог
NO CL. NO FUN

Саня...
У тебя всё очень не очень с названиями компонентов

Саня... У тебя всё очень не очень с названиями компонентов

ОЙ ДА ТЫ
Я ДА
ЩАААААС
ЭТО БЫЛО СДЕЛАНО ЗА ПАРУ МИНУТ

@FaDeOkno
PreventGhostFollowingComponent
сойдёт?

Так это же я тебе в дискорде это название предложил, дудка)

Так это же я тебе в дискорде это название предложил, дудка) я очень люблю Шрёдьку ^_^

НУ Ни знаю даже


text:
Store incoming notifications in new DB entity with no extra logic

Summary
When notifications are received ideally no extra logic is done other than storing them in the database after the authentication methods have been verified. With this PR we're saving the incoming notifications AS IS in a new database entity. On cron job run they are converted and stored as a regular notification to be processed.
Tested scenarios
After the authentication is valid incoming notifications are received successfully regardless of content, and stored in a new table s_plugin_adyen_text_notification.
On cron job run the text notifications stored are fetched, converted into regular notifications in s_plugin_adyen_order_notification and processed.
Fixed issue: #81

@acampos1916
To be verified with pull request: https://github.com/Adyen/adyen-shopware5/pull/115

@acampos1916
To be verified with pull request: https://github.com/Adyen/adyen-shopware5/pull/115

@bortefi I see you used NotificationReceiver from the library but this was included in version 7. The plugin uses ^6.1 so I'm replacing the call with the function logic until this is outsourced.

@bortefi I see you used NotificationReceiver from the library but this was included in version 7. The plugin uses ^6.1 so I'm replacing the call with the function logic until this is outsourced.


text:
010 Not allowed on Adyen CC?

I'm getting the 010 Not allowed error when trying to test the Adyen CC in Magento. Any suggestions?

Hi Floris, thats an error due to missing permissions on your webservice user account. Could you send your merchantAccount and webservice user name to plugin@adyen.com so that we can take a look for you?

@guangmian done

@guangmian, hi! I have the same problem in test account. in magento logs i only see
<refusalReason xmlns="http://payment.services.adyen.com">010 Not allowed</refusalReason>

in SOAP response. But i have no ideas how to fix this...

Hi @nolka
You do not have the permission. Maybe you are using raw card data what is not allowed unless you are PCI compliant or you are using our CSE but did not provide us a SAQ A form. Please contact our support at support@adyen.com to help you further please provide your merchantAccount and your pspreference of the transaction that failed.
Regards,
Rik
Adyen

Hello. Really, we does not provided SAQ A Form to you. But our boss
promised to send this form soon.
We cannot use raw card data only for testing?
2018-02-14 18:58 GMT+07:00 Rik ter Beek notifications@github.com:

Hi @nolka https://github.com/nolka
You do not have the permission. Maybe you are using raw card data what is
not allowed unless you are PCI compliant or you are using our CSE but did
not provide us a SAQ A form. Please contact our support at
support@adyen.com to help you further please provide your merchantAccount
and your pspreference of the transaction that failed.
Regards,
Rik
Adyen
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Adyen/adyen-magento/issues/365#issuecomment-365584945,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATmU7iNFsh3elmslsnIXMBKHTjLXXr4ks5tUsp9gaJpZM4FYE1I
.

--
С Уважением, Виктор.
Контакты:
icq: 444 121 808
skype: xternalx

@rikterbeek @guangmian  I have the same issue on local machine. So, in this case, do I need to contact to support?
One more question: how can I test the Magento Adyen payment on my local machine?

authors: florisgoumans guangmian mrkhoa99 nolka rikterbeek

repo: Adyen/magento


text:
Add headers to the copied Primitives.{fst,v} files

We need to add a header "THIS FILE WAS AUTOMATICALLY GENERATED BY AENEAS" to the copied files

Notes: this is where we copy the files; this is where we generate headers.

authors: Nadrieril sonmarcho

repo: AeneasVerif/aeneas


text:
"UNION DISTINCT" not supported

parser := clickhouse.NewParser("select replica_name from system.ha_replicas UNION DISTINCT select replica_name from system.ha_unique_replicas format JSON")
statements, err := parser.ParseStatements()

this code will return a error,  such as
line 0:50 expected keyword: ALL, but got <keyword>
select replica_name from system.ha_replicas UNION DISTINCT select replica_name from system.ha_unique_replicas format JSON
                                                  ^^^^^^^^

"UNION DISTINCT" is supported by clickhouse engine，please see: https://clickhouse.com/docs/en/sql-reference/statements/select/union

@lvjinyu Thanks for your feedback, will support it soon.

authors: git-hulk lvjinyu

repo: AfterShip/clickhouse-sql-parser


text:
🚀 [REQUEST] - Create error page

Describe
create a page to show when 404 error occurs
Reasons
To create a more friendly page for users
How to Implement Features
No response
Additional Explanation
No response
Connection

[X] Have no effect on other functions
[ ] Other functions need to be changed

Duplicate of #66

authors: bentshrimp hummingbbird


text:
Osra393 extract date not beyond the first of next month validator

https://osraav.atlassian.net/browse/OSRA-393
Extracted custom validator:  :date_not_beyond_first_of_next_month
to app/models/validators/date_not_beyond_first_of_next_month_validator.rb

Looks good!

Does this need a rebase to get rid of the first 4-5 commits? They look like they've been merged already.

done!

authors: NikitaAvvakumov razorcd

repo: AgileVentures/osra


text:
语音无法发送

对Bot戳一戳后无法发送语音，输出该消息：[CQ:record,file=file:///C:\Users\Administrator\Desktop\meigumi\Daiwa_Scarlet\Daiwa_Scarlet_poke\acc\1.mp3,magic=,cache=,proxy=,timeout=]                                                                                ffmpeg插件我已经装了，我的路径是配置对了，音频有用mp3,wav,我看了代码是可以wav的，请问是有什么问题吗？恳请大佬指教

现在没问题了，是我的ffmpeg换了位置没有改环境变量


text:
setLocalUserAttributes, addOrUpdateLocalUserAttributes always throw failed errorCode:3

I'm setting my local user attributes just like below
await _rtmClient.addOrUpdateLocalUserAttributes([{
      "muted": "true",
      "handRaised": "false"
    }]);

or this one
await _rtmClient.setLocalUserAttributes([{
      "muted": "true",
      "handRaised": "false"
    }]);

But I always get failed errorCode:3
E/flutter (11523): [ERROR:flutter/lib/ui/ui_dart_state.cc(213)] Unhandled Exception: addOrUpdateLocalUserAttributes failed errorCode:3
E/flutter (11523): #0      AgoraRtmClient.addOrUpdateLocalUserAttributes (package:agora_rtm/src/agora_rtm_client.dart:294:7)

Am I doing something wrong? Please enlighten me. Thanks

Fixed it by using code below
Map<String, String> muted = {
        "key": "muted",
        "value": "true",
      };
      Map<String, String> handRaised = {
        "key": "handRaised",
        "value": "false",
      };
      await _rtmClient.addOrUpdateLocalUserAttributes([muted, handRaised]);

repo: AgoraIO/Agora-Flutter-RTM-SDK


text:
Bug: throw an unexcepted TypeError: "x" is not a function

in console, it will return legacy.js:4 Uncaught TypeError: t is not a function

my fault

文档是不是没更新 type （
https://nashi.js.org/type.html
我怎么愣是看不到each（

文档是不是没更新 type （
nashi.js.org/type.html
我怎么愣是看不到each，我还以为是我错了，但是发觉 ts 没报错不应该啊

因为是手写 type。。疏忽了

authors: AkaraChen wibus-wee

repo: AkaraChen/nashi


text:
Allow Shuffling Of Quiz Questions and MCQ Options

Allow Shuffling Of Quiz Questions and MCQ Options of each question while maintaining the same quiz functionalities

Working on it


text:
Fix typo

Have you read the Contributing Guidelines?

[x] YES
[ ] NO

Project URL

What is the current behavior?

Issue Number: #...

Category

[x] 𝑴𝒊𝒔𝒄𝒆𝒍𝒍𝒂𝒏𝒆𝒐𝒖𝒔 𝑺𝒕𝒖𝒇𝒇.
[ ] 𝑫𝑺𝑨 + CP
[ ] 𝑻𝒆𝒄𝒉𝒏𝒊𝒄𝒂𝒍 𝑺𝒖𝒃𝒋𝒆𝒄𝒕
[ ] 𝑳𝒐𝒘 𝑳𝒆𝒗𝒆𝒍 𝑫𝒆𝒔𝒊𝒈𝒏
[ ] 𝑷𝒓𝒐𝒋𝒆𝒄𝒕𝒔
[ ] 𝑰𝒎𝒑𝒐𝒓𝒕𝒂𝒏𝒕 𝑩𝒐𝒐𝒌𝒔 𝒂𝒏𝒅 𝑹𝒆𝒔𝒐𝒖𝒓𝒄𝒆𝒔
[ ] 𝑩𝒆𝒉𝒂𝒗𝒊𝒐𝒖𝒓𝒂𝒍 𝑰𝒏𝒕𝒆𝒓𝒗𝒊𝒆𝒘 𝑸𝒖𝒆𝒔𝒕𝒊𝒐𝒏𝒔

Changes

Description of changes

Fix a typo
Screenshots

(Add Runnig Work Demo Image)

Checklist ✅

[x] I've read the instructions on the README file before submitting my application.
[x] I've read the Contributing Guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've follow Tree of Index.
[x] I've add work in proper folder
[x] I've not delete/modify previous codes.

Also, you can review Jupyter Notebooks changes by installing GitNotebooks in this repository. Here's what it looks like:

@smith-kyle
Only change Classifer to Classifier
But you remove many lines of code
Thanks for raising this issue
I fix this issue
If you get something wrong like this then you can raise an issue or send a pull request but don't remove the default code.


text:
feat(Server): Add express middlewares inside config

It allow developers to add somme middleware to express (inside app.use())
For exemple, I wanted to have cookie inside my req, so I wanted to add cookie-parser
Use in vue.config.js
const cookieParser = require('cookie-parser');

module.exports = {
  pluginOptions: {
    ssr: {
      middlewares: [cookieParser()]
    },
  },
};

Nice one !

@Akryum it seems as though this merge was undone at some point. Is there any update as to why?

authors: Tactless7 nathanaelphilip zickat

repo: Akryum/vue-cli-plugin-ssr


text:
What is the purpose of the 1234S syntax?

I'm not sure why we need the recently added 1234S syntax. Why not just do 1234 as float?
We still need the L thing to specify longs: 123456789123456789 as long wouldn't work, because 123456789123456789 by itself would be an int and the value does not fit into an int.
Similarly, I think we don't really need the 12.34f syntax. You can always do 12.34 as float.

I like the idea, and it's pretty close to what Zig does, for example. But there's at least this situation where it would not work:
foo = 0
foo = some_function_returning_int()

The first line foo = 0 sets it to be as small as possible to fit a zero, so probably 8-bit signed (currently unnamed) or short. But then the second line fails, because it's trying to assign int into a short.

The first line foo = 0 sets it to be as small as possible to fit a zero, so probably 8-bit signed (currently unnamed) or short. But then the second line fails, because it's trying to assign int into a short.
I mean, we should type promotion short to int not int to short

It will be a int, because the number doesn't fit into short(16bit), so if we don't want overflow, we have to set the type to int(32bit).
Maybe short use less memory(lol)...
It looks like python's variable (type can be change)

It looks like python's variable (type can be change)

This is something I want to avoid. When there is foo = bar in the code, and a variable foo doesn't exist yet, I want to use only that line to determine the type of the newly created foo variable. I don't want to look at other lines below to find the type of a variable. I also don't want the type of a variable to change in the middle.
Again, this is my design goal of keeping Jou simple and minimal. In the past I have made other languages where the type of a variable is determined from all places where it's used (I think my oomph language does this, for example).

I mean we can change the exist variable type, not create a new one.

Another thought: Changing the type of a variable in the middle becomes complicated when the same code executes many times.
foo = 0  # foo is int
while True:
    # foo is int
    printf("%d\n", foo)
    ...
    foo = 123456789123456789L
    # foo is long

If the loop runs more than once, we somehow have to convert 123456789123456789L to int because the type of the variable was changed. The simplest solution is to never change the type of an existing variable.

For example, just like 123456798123456798 doesn't fit into an int, so the compiler should set the type to long automaticly.
After thinking about this a bit more I think it is a good idea, if the type always becomes int or long. You can still use as when needed.

And after some more time, I think automagically choosing int or long is a bad idea :)
I'm pretty happy with how the L suffix for long works. Today I wrote result = 0L in one of my advent of code solutions, and it felt good.

authors: Akuli littlewhitecloud

repo: Akuli/jou


text:
aursync: couldn't read spotify/.git/packed-refs: Not a directory

I did a aursync -u when the following happened:
  -> Using [custom] repository
==> Resolving dependencies...
  -> spotify 1.0.72.117-1 -> 1.0.77.336-1
==> Retrieving build files...
POST git-upload-pack (972 bytes)
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From https://aur.archlinux.org/spotify
   b18e792..dda96cb  master     -> origin/master
fatal: couldn't read spotify/.git/packed-refs: Not a directory

Simply trying again, I got this:
  -> Using [custom] repository
==> Resolving dependencies...
  -> spotify 1.0.72.117-1 -> 1.0.77.336-1
==> Retrieving build files...
From https://aur.archlinux.org/spotify
 = [up to date]      master     -> origin/master
fatal: couldn't read spotify/.git/packed-refs: Not a directory

Cleaning the cache for spotify will probably fix the issue, but I would like to know if you have any idea why this happens.

This indeed looks like an upstream bug. Bisect seems to point to git/git@f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0
From my testing seems like we can work around this by specifying absolute paths for GIT_DIR and GIT_WORK_TREE.

Thanks for the investigation. Happy to merge such a workaround.

Merged in #342

The issue is fixed upstream git/git@fb9c2d27039a23457cb9710d86e00c51dfb910dc (> v2.18.0) thus 03a17476ab046961077bde3dad547560e7654f21 can, optionally, be reverted.
Not advocating for a revert, but documenting it here in case we stumble on this in the future.

authors: AladW jendrikw rafasc

repo: AladW/aurutils

license: isc


text:
Update min js example system

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: # (issue, if applicable)
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.

Update minified js example system to work on docsite
Update dependencies

Type of change:
Please delete options that are not relevant.

[ ] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

:tada: This PR is included in version 3.1.11 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: AlaskaAirlines/auro-accordion


text:
auro-banner:  boolean attributes need to be reflected and have default value

Describe the bug
The following properties are used as styling hooks and need to be reflected so the styles when the property is set instead of an attribute (e.g. Svelte):

hero
iconic
marquee
roundedBorder

Giving them a default value will also allow Svelte apps to use the boolean attribute shorthand, e.g. <auro-banner hero>.
Expected behavior
Properties used for styling are reflected to attributes and have default values.

:tada: This issue has been resolved in version 1.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: blackfalcon geoffrich

repo: AlaskaAirlines/auro-card


text:
 doesn't shrink to allow the display of a 26-character first name (or even 16-character text) on one line

Please verify the version of auro-header you have installed
"@aurodesignsystem/auro-header": "^2.0.0"
Please describe the bug
Bug affects all environments, browsers. Repro steps are for prod in a Chrome incognito window.

Use VPN, an on-prem connection, or a non-Alaska-issued device.
Turn off any SwitchHost proxying.
Open an incognito window in Chrome.
Go to as.com and sign-in with a prod test account that has not made a 100K Benefit Choice.

Navigate to https://www.alaskaair.com/account/mpchoice

Observe the "Congratulations..." header, which uses the <auro-header> component.
Shrink the width of the page to 320px with dev tools.

Observe that the word "Congratulations," breaks across lines.

Notes:

Mileage Plan account first names may be up to 26 characters long. <auro-header> can't even accommodate the 16 characters in "Congratulations," on one line.
The issue is reproducible on the Auro doc site:

Reproducing the error on the docsite
This issue is reproducible on the Auro docsite
Expected behavior
The <auro-header> should shrink to fit the width of the screen to a screen width of 320px and a first name of 26 characters.
What browsers are you seeing the problem on?
Chrome
Additional context
No response
Exit criteria
Stakeholder:
As a Mileage Plan member using my tiny phone
Scenario
I want to login to my benefits site, and see my 26-character first name on one line.

Introducing dynamically changing font sizes as a built in default functionality of the component is outside of the scope of capabilities we want to include.

authors: Patrick-Daly-AA Sara-Jade

repo: AlaskaAirlines/auro-header


text:
Develop

Hi AleSpero, I got your library via my mentor from Udacity. You really have done a great job in this library. I have just added some elevation and cornerRadius to the expandable-cardview.xml which makes the cards look better. Do review my commits once and merge if you find it nice.

Hello Gaurav! Thank you for your interest in this library, i really appreciate that.
The corner radius and elevation seems nice, would you like to add a setter to the ExpandableCardView in which you can set dynamically the corner radius? that would be great!
Alessandro

Also, watch out that in your first commit you also pushed some Android Studio files that are not needed (ex: .idea/codeStyles/Project.xml). Everything in the .idea folder needs to stay local. i'm gonna edit the .gitignore file so that files will be ignored by git. :)

Yeah sure Alessandro, i'll take care of these from next time.

repo: AleSpero/ExpandableCardView


text:
better support for icmp

when configuring a flow i can select protocol icmp but none of the codes.
ICMP doesn't really uses port numbers but rather type/codes.

I need to find a way to integrate that cleanly, as it would be 2 fields used only by ICMP. Would the code/subtype be necessary or only the type?

Personally I have never seen a subtype being used in firewall rules, on the other other simple types are everywhere.

also attention should be placed for icmpv4 and icmpv6 as they do differ

Still thinking about how best to implement that, I have not found a satisfying way in the Forms to have a special case for two protocols (ICMP / ICMPv6) that would change how the rest of the form is displayed/interpreted.
For the moment, I'd recommend using the destination port field to store the type.

repo: Alef-Burzmali/netbox-data-flows


text:
sudo apt update issue: File has unexpected size (1125 != 1132). Mirror sync in progress?

System Details

OS: Linux Mint 21.1
Thorium Version 112

Problem
Installed Thorium 112 like this some weeks ago. I ran great
wget https://dl.thorium.rocks/debian/dists/stable/thorium.list
sudo mv thorium.list /etc/apt/sources.list.d/
sudo apt update
sudo apt install thorium-browser

When running sudo npm update, this happens for Thorium since the v113 came out
E: Failed to fetch https://dl.thorium.rocks/debian/dists/stable/main/binary-amd64/Packages.gz  File has unexpected size (1125 != 1132). Mirror sync in progress? [IP: 94.130.183.73 443]
   Hashes of expected file:
    - Filesize:1132 [weak]
    - SHA256:e06ad9a89dca2cc7dab3eb2122280712688d266f6825a0abfcc6b163d3eda75a
    - SHA1:695bbbabf48086bea01e70587667df557dc5ba74 [weak]
    - MD5Sum:99aff104362d64fa6889f75a74d8e3be [weak]
   Release file created at: Fri, 02 Jun 2023 08:34:23 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

Screenshots
See code above
Additional Notes
Removing and reinstalling Thorium results in the same issue

Hi and thanks for filing @jstdk
I forgot to update those file sizes in the Release file...should work now. Please try again.

Thanks @midzer!

authors: jstdk midzer


text:
Crashing when adding a new profile

System Details

OS: Ubuntu 23.10
Thorium Version: 121.0.6167.204

Problem
When I try to add a new google account using the add button on the profile menu located in the top right corner, thorium immediately crashes.
Screenshots
here is a little recording:-
Screencast from 2024-02-25 08-08-23.webm
Additional Notes
The issue also happens if I click the gear icon beside Other profiles

This is a known bug and this issue is a duplicate

@gz83 @RIRafi Fixed in latest M122 version.


text:
Не работает анализатор спектра на ленте <40 светодиодов

Версия 2.6.2 WAVGAT

Вы решили проблему?
У меня на последнем режиме все светодиоды горят одновременно.

Скорее всего не проблема, а логика - последний режим имеет очень много полос и ему тупо не хватает диодов. Причём полосы, как я понимаю, захватывают не менее 3 диодов. Таким образом, нужно как минимум по 6 на каждую (симметрично влево и вправо по 3). Даже для 5 полос это уже 30, а там этих полос штук 15.

А почему тогда цвет на каждый диод?

authors: Butylkus CharlzVard SAn4Es-TV

repo: AlexGyver/ColorMusic


text:
Milestone: Hooks

For this milestone I:

Deleted class properties at Calculator.js ✂
Built a new arrow function 🏹
Added hooks 🏴☠

Thank you @Lameck1


text:
Aktualisierung von Nachrichten

Wenn ich eine neue Mail an die TestMail schreibe, wird das MagicMirror falsch aktualisiert. Die neue Mail wird drei mal angezeigt.

Der Bug ist durch den letzten Commit von Tobias entstanden. Ich habe das Projekt auf den alten Stand gebracht und jetzt aktualisieren sich die Nachrichten auch ohne weitere Probleme.

repo: AlexRekowski/Magic-Mirror-Projekt


text:
Update the NPM Package to fix Fullscreen gap at the top of the page

When in windowed mode, the titlebar works properly

Except when I press F11 to put the window into fullscreen (not maximized) mode, the titlebar disappears.

it's actually really hard to see it here, but theres a 30px tall white bar at the top of the screen

It seems like the code fixes this in titlebar.ts
if (fullscreen) {
  hide(this.titlebar);
  this.container.style.top = '0px';
} else {
  show(this.titlebar);
  this.container.style.top = `${this.titlebar.getBoundingClientRect().bottom}px`;
}

...BUT in the latest npm build I find this compiled typescript instead, it's missing the style.top changes:
if (!platform_1.isMacintosh) {
    if (fullscreen) {
        dom_1.hide(this.titlebar);
    }
    else {
        dom_1.show(this.titlebar);
    }
}

Solution to this: Update the npm package to a 3.1.0 or 3.0.1 or something.

@imdaveead Check if this error is kept in the latest version, it has already been tested and everything works correctly.
If the error is maintained, please indicate in this same issue.

authors: AlexTorresSk imdaveead

repo: AlexTorresSk/custom-electron-titlebar


text:
Segmentation fault when reloading waybar with pkill -SIGUSR2 waybar

Doesn't happen every time, has a chance to properly reload. But fails most of the time.

Seems to be related to #1749

can confirm I also experience the same.

Some clarification: seems to happen only with tray module

Seems to be fixed? Running latest commit, no issues here

Can't reproduce original crash, although a similar crash happens on latest commit:
GLib-GIO:ERROR:../glib/gio/gapplicationimpl-dbus.c:837:g_application_impl_command_line: assertion failed: (object_id != 0)
Bail out! GLib-GIO:ERROR:../glib/gio/gapplicationimpl-dbus.c:837:g_application_impl_command_line: assertion failed: (object_id != 0)
zsh: IOT instruction (core dumped)  waybar -c .config/waybar/hyprland.jsonc

I think it happens much more frequently if you're running multiple bars, not sure

Happens only when I run a second bar.

authors: Fxzzi Lassebq huiser

repo: Alexays/Waybar


text:
"webrtc/offer: unknown error" when using "mode: webrtc"

Running a PC with HA supervised install. With Chromium on the GUI on that PC I can't use webRTC streams. It displays "webrtc/offer: unknown error".  All other devices on the network can use RTC.

Anyone else having this issue?

Seems that this and the previous issue (defaulting to MSE) was solved by update to Debian Bookworm or kernel v6. I'm thinking the previous kernel 5.10.0.23 did not properly support Ryzen 5000 chips and therefore did not have hardware acceleration.

repo: AlexxIT/WebRTC


text:
HA Cant stream Picam

Hi,
I use Webrtc to stream my picam V2 to homeassistant.
I have installed the latest version, but get this error, any idea ? :
Logger: homeassistant.helpers.integration_platform
Source: loader.py:850
First occurred: 11:28:14 (6 occurrences)
Last logged: 17:40:36

    Unexpected error importing webrtc/recorder.py
    Unexpected error importing webrtc/logbook.py
    Unexpected error importing webrtc/system_health.py
    Unexpected error importing webrtc/media_source.py
    Unexpected error importing webrtc/hardware.py

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/integration_platform.py", line 50, in _async_process_single_integration_platform_component
    platform = integration.get_platform(platform_name)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/loader.py", line 833, in get_platform
    cache[full_name] = self._import_platform(platform_name)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/loader.py", line 850, in _import_platform
    return importlib.import_module(f"{self.pkg_path}.{platform_name}")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'custom_components.WebRTC.diagnostics'

This files not from this integration:
    Unexpected error importing webrtc/recorder.py
    Unexpected error importing webrtc/logbook.py
    Unexpected error importing webrtc/system_health.py
    Unexpected error importing webrtc/media_source.py
    Unexpected error importing webrtc/hardware.py

authors: AlexxIT bibitocarlos


text:
Configure i/o timeout duration

We're attempting to forward an RTSP stream from an IP camera to go2rtc using FFmpeg. However, intermittent packet loss from the camera results in go2rtc disconnecting FFmpeg due to an I/O timeout. We are looking for a way to configure this timeout duration or request the addition of a configuration option.
Details:
We are using the following FFmpeg command to forward the RTSP stream:
ffmpeg -f rtsp -rtsp_transport tcp -i rtsp://CAMERA_RTSP_URL:PORT/PATH -c copy -f rtsp -rtsp_transport tcp rtsp://GO2RTC_URL:8554/PATH

(We're using the incoming sources feature of go2rtc.)
Issue:
Occasionally, packets from the camera fail to arrive, causing no packets to be forwarded to go2rtc. When this occurs, go2rtc disconnects FFmpeg with the following error message:
handle error="read tcp 172.27.0.2:8554->10.xxx.xxx.xxx:60991: i/o timeout"

Based on empirical measurements, this timeout duration is approximately 15 seconds.
Request:

Is there a way to configure the timeout duration in go2rtc?
If not, would you be open to adding a configuration option to adjust this timeout?

I think this is your 15 seconds
https://github.com/AlexxIT/go2rtc/blob/f432e72dd0f1f3be1dc8ae437b99d146180284ec/pkg/rtsp/conn.go#L125-L127
I'll think about settings this value. Maybe via query param.
PS. 15 sec is a quite large value. The client defaults to 5 sec.

I suffer the same issue with go2rtc/Frigate under Proxmox. Have a camera with not so solid wifi connection and can't modify the network to mitigate the issue. Every one or two days have to reboot frigate to regain visibility.

This issue only about incoming RTSP.
But RTSP source has timeout setting via #timeout param.
In any case, it is no good if the camera has not sent a single packet within 5 seconds (default).

https://github.com/AlexxIT/go2rtc/releases/tag/v1.9.3

authors: AlexxIT Claudio1L siddhantwahal


text:
InterType-based AST for Decapodes

This requires https://github.com/AlgebraicJulia/ACSets.jl/pull/75.

For documentation purposes, note that there used to be a feature that allowed one to tag the type of a quantity inline in an equation. This feature was eventually dropped due to this feature increasing line noise, and also it being a better style to separate tagging from defining.
When this support was dropped, the “Judgement” struct was not also deleted from the definition of “Term”, although it could never be called. This PR, among other changes, amends this artifact.

Code for this PR was just merged in PR #156 .


text:
[NEW ALGORITHM]: Want to add Find Missing Number in Array problem in bit manipulation folder

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:  Find Missing Number in Array problem
[NEW ALGORITHM]
About:
The Find Missing Number in Array problem is a classic bit manipulation and arithmetic problem. Here’s a quick explanation of the problem and solution approach:
Problem:
Given an array of integers containing numbers from 1 to N, where N is the length of the array plus one, find the missing number. There’s exactly one missing number, and all other numbers are unique and present exactly once.
Input:
int nums[] = {1, 2, 4, 5};  // Array with one missing number
int n = 5;  // The range is from 1 to 5

output
Missing number is: 3

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[X] Contributor in GSSoC-ext
[X] Want to work on it

@pankaj-bind assign this issue to me

assigned

authors: Jivanjamadar pankaj-bind

repo: AlgoGenesis/C


text:
可否按月建索引

你好，我使用filebeat模式，想按月创建索引，需要怎么修改？

目前还不支持，后续我们增加下支持

同问

authors: caipengtao chenquanzhao ibc789

repo: AliyunContainerService/log-pilot


text:
[Bug]:  LocalBox has been removed from 0.9.0

Is there an existing issue for the same bug?

[X] I have checked the troubleshooting document at https://docs.all-hands.dev/modules/usage/troubleshooting
[X] I have checked the existing issues.

Describe the bug
Hey team,
We built our setup based on local sandbox in Openshift with restricted permission. We did it after this discusion https://github.com/All-Hands-AI/OpenHands/discussions/2675
But we found there is no local sandbox in v. 0.9.0+ and it brakes our setup :(
Is there a replacement for it or would it be possible to revert this changes?
Many thanks!
Current OpenHands version
0.9.0+

Installation and Configuration
We 've written own Dockerfile based on yours:

FROM ghcr.io/opendevin/opendevin:0.7
RUN chmod 777 -R /app
ENTRYPOINT []
USER root

# install basic packages
RUN apt-get update && apt-get install -y \
    curl \
    wget \
    git \
    vim \
    nano \
    unzip \
    zip \
    python3 \
    python3-pip \
    python3-venv \
    python3-dev \
    build-essential \
    openssh-server \
    sudo \
    gcc \
    jq \
    g++ \
    make \
    iproute2 \
    && rm -rf /var/lib/apt/lists/*

RUN mkdir -p -m0755 /var/run/sshd

# symlink python3 to python
RUN ln -s /usr/bin/python3 /usr/bin/python

# ==== OpenDevin Runtime Client ====
RUN mkdir -p /opendevin && mkdir -p /opendevin/logs && chmod 777 /opendevin/logs
RUN wget "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-$(uname)-$(uname -m).sh"
RUN bash Miniforge3-$(uname)-$(uname -m).sh -b -p /opendevin/miniforge3
RUN chmod -R g+w /opendevin/miniforge3
RUN bash -c ". /opendevin/miniforge3/etc/profile.d/conda.sh && conda config --set changeps1 False && conda config --append channels conda-forge"
RUN echo "" > /opendevin/bash.bashrc

# - agentskills dependencies
RUN /opendevin/miniforge3/bin/pip install --upgrade pip
RUN /opendevin/miniforge3/bin/pip install jupyterlab notebook jupyter_kernel_gateway flake8
RUN /opendevin/miniforge3/bin/pip install python-docx PyPDF2 python-pptx pylatexenc openai
RUN chmod 777 -R /opendevin
RUN mkdir -p /opt/workspace_base && chmod -R 777 /opt/workspace_base
RUN sed "s/config.sandbox_type/\'local\'/g" -i /app/opendevin/runtime/runtime.py && sed '24,27{/.*/d}' -i /app/opendevin/runtime/plugins/mixin.py && mkdir /opendevin/plugins/ && cp -av /app/opendevin/runtime/plugins/jupyter /opendevin/plugins/ && cp -av /app/opendevin/runtime/plugins/agent_skills /opendevin/plugins/
RUN export PATH=/opendevin/miniforge3/bin:/app/.venv/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUN echo $PATH
RUN cd /app && playwright install
CMD ["uvicorn", "opendevin.server.listen:app", "--host", "0.0.0.0", "--port", "3000"]

We combined opendevin and sandbox into the same container, changed paths and permission.
This image works without root/docker etc so we were able to start it under restrictedv2 Openshift SCC

### Model and Agent

_No response_

### Operating System

_No response_

### Reproduction Steps

_No response_

### Logs, Errors, Screenshots, and Additional Context

_No response_

Tagging @enyst since he was involved in he initial discussion to see if he is able to help.

Local box has been removed a while ago when we have completely rewrote our images, there is no more "SSH box" either, and we have switched to a runtime to which we connect via a REST API. I'm not sure how that can play with your restrictions. 🤔 @xingyaoww what do you think?

Well if the sandbox is remote it is ok too, for example if we start it manually somehow and pass some args like the API URL or something like that. Our restriction basically is we cannot run things as root for security reasons, so the backend shouldn't build or run a container.
Is this option easier to implement ?

Circling back a few months later -- With the help of OpenHands, hopefully we will get this implemented :) https://github.com/All-Hands-AI/OpenHands/pull/5284

authors: aelbarkani enyst mamoodi xingyaoww yaroslavkasatikov

repo: All-Hands-AI/OpenHands


text:
Improve LLM Documentation

What problem or use case are you trying to solve?
We should review and improve the LLM documentation:

Make sure that the recommended setup is clear (Claude 3.5 Sonnet, or clarify which models work well)
Make sure that the we also explain the setup of other models

Fixed by #4151


text:
Feat changed "is_confirmed" to "confirmation_state"

This parameter is not a boolean, so we should not name it as though it were.

[ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Simple find & replace: is_confirmed -> confirmation_state

The pull request focuses on renaming the parameter is_confirmed to confirmation_state across multiple files to better reflect its non-boolean nature. This change is consistent and improves code readability by using a more descriptive name.
Overall Feedback:
The changes are straightforward and well-executed, ensuring that the new parameter name is consistently applied across the codebase. This improves the clarity of the code by using a name that accurately describes the parameter's purpose and possible values.
Score: 95/100
Code Suggestions:

File: frontend/src/services/actions.ts

Language: TypeScript
Suggestion: Consider using a switch statement instead of multiple if conditions for checking confirmation_state values. This can improve readability and maintainability if more states are added in the future.
Relevant Line: +      !message.args.confirmation_state ||

File: openhands/runtime/runtime.py

Language: Python
Suggestion: When checking for confirmation_state, consider using an enumeration for ActionConfirmationStatus to improve code readability and reduce the risk of typos in string comparisons.
Relevant Line: +            and action.confirmation_state == ActionConfirmationStatus.AWAITING_CONFIRMATION

File: openhands/security/invariant/analyzer.py

Language: Python
Suggestion: Ensure that all instances where confirmation_state is used are updated to handle any potential new states that might be introduced in the future.
Relevant Line: +            and event.confirmation_state == 'awaiting_confirmation'

The renaming of is_confirmed to confirmation_state is a positive change that enhances code clarity. Here are some suggestions:

In frontend/src/services/actions.ts, consider using a switch statement for confirmation_state checks to improve readability.
In openhands/runtime/runtime.py, use an enumeration for ActionConfirmationStatus to avoid string comparison errors.
In openhands/security/invariant/analyzer.py, ensure future-proofing by handling potential new states for confirmation_state.

authors: ngduyanhece tofarr


text:
Improve caching in workflow file

Is it possible to speed up multiple runs of the workflow by adding caching

Good point, I think we can probably cache the install of packages at least.

I've attached one possible solution for caching the package installation
Another cache could be dedicated to the docker image itself. However, Github only allows for 10GB of cache in a single repository, so this may be unideal for some users

The new caching is great, the resolver starts much faster!
I think any remaining caching-related things can be tracked in issue #49, so let's close this one as finished.

authors: d-walsh malhotra5 neubig

repo: All-Hands-AI/openhands-resolver


text:
Incorrect missing file error

output:
Command error:
  [capsule-7106853] cloning git repo...
  Cloning into 'capsule-repo'...
  [capsule-7106853] running capsule...
  + python -u run_capsule.py
  NWB backend: zarr
  Traceback (most recent call last):
    File "/tmp/nxf.KiTisPSf3L/capsule/code/run_capsule.py", line 155, in <module>
      sync_times = np.load(stream_folder / "synchronized_timestamps.npy")
    File "/opt/conda/lib/python3.9/site-packages/numpy/lib/npyio.py", line 427, in load
      fid = stack.enter_context(open(os_fspath(file), "rb"))
  FileNotFoundError: [Errno 2] No such file or directory: '../data/ecephys_session/ecephys_clipped/Record Node 104/experiment1/recording1/continuous/Neuropix-PXI-100.ProbeD-AP/synchronized_timestamps.npy'

This originates from here:
https://github.com/AllenNeuralDynamics/NWB_Packaging_Units/blob/main/code/run_capsule.py#L150-L156

the code makes the false assumption that this is OpenEphys < 0.6, because it can't find (stream_folder / "sample_numbers.npy")
the actual problem is that stream_folder doesn't exist:

experiment1/recording1 doesn't exist
experiment1/recording2 exists and should be used

A similar bit of code in SpikeInterface is also causing issues with aind-data-transfer uploads (Carter P might have been in contact about that):
https://github.com/SpikeInterface/spikeinterface/blob/main/src/spikeinterface/extractors/neoextractors/openephys.py#L247

This is the same issue as https://github.com/SpikeInterface/spikeinterface/pull/2655

Fixed by 58e0673b498a467a26aea12e60cd332db3a9ad33

Fixed here https://github.com/AllenNeuralDynamics/NWB_Packaging_Units/commit/74469e70b87ed4d604f5ff9432078fff902d2a3d
and in aind-data-transfer: https://github.com/AllenNeuralDynamics/aind-data-transfer/pull/329