MIssing libcef on Linux

Hello!
I am trying to run my app on linux and I am getting strange error:

2020-05-01 15:30:12.256 [ERROR] Oops! Something went wrong.     Unable to load shared library 'libcef' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibcef: cannot open shared object file: No such file or directory          at Xilium.CefGlue.Interop.libcef.enable_highdpi_support()
at Xilium.CefGlue.CefRuntime.EnableHighDpiSupport()
at Chromely.CefGlue.BrowserWindow.HostBase.RunInternal(String[] args)
at Chromely.CefGlue.BrowserWindow.HostBase.Run(String[] args)

I added runtime identifire  and also chromium downloaded correctly. libcef.so is present at bin folder.
I am running PopOs 20.04

@mikart143 seem like PopOs is a derivative of Ubuntu.
Please see list of what we have tested and supported so far -
https://github.com/chromelyapps/Chromely#platforms
Also check to see if related to:
https://github.com/chromelyapps/Chromely/issues/187
https://github.com/chromelyapps/Chromely/pull/188

So I tried to run tests from #188  but It failed on CreateWindow() method:

2020-05-01 17:44:25.661 [ERROR] Oops! Something went wrong.     Exception has been thrown by the target of an invocation.          at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture)
at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
at System.Activator.CreateInstance(Type type, Object[] args)
at Caliburn.Light.SimpleContainer.ActivateInstance(Type type, Object[] args) in /home/mikart/Downloads/Chromely-master/src/Chromely.Core/Infrastructure/SimpleContainer.cs:line 496
at Caliburn.Light.SimpleContainer.BuildInstance(Type type) in /home/mikart/Downloads/Chromely-master/src/Chromely.Core/Infrastructure/SimpleContainer.cs:line 485
at Caliburn.Light.SimpleContainer.<>c__DisplayClass9_0.b__0(SimpleContainer c) in /home/mikart/Downloads/Chromely-master/src/Chromely.Core/Infrastructure/SimpleContainer.cs:line 147
at Caliburn.Light.SimpleContainer.GetInstance(Type service, String key) in /home/mikart/Downloads/Chromely-master/src/Chromely.Core/Infrastructure/SimpleContainer.cs:line 374
at Chromely.ChromelyBasicApp.CreateWindow() in /home/mikart/Downloads/Chromely-master/src/Chromely/ChromelyBasicApp.cs:line 38
at Chromely.Core.AppBuilder.Run(String[] args) in /home/mikart/Downloads/Chromely-master/src/Chromely.Core/AppBuilder.cs:line 124

Everything is updated, dotnet command is present. I did not changed my Gnome to anything else because most of my users will use Gnome. libcef.so is present and it is 904 MB. I tried to run test from #188 but it failed.

@mikart143  please ensure you are not mixing the assemblies - there was a change to the SimpleContainer about 2 weeks or so .. the issue you see may be related to that.
https://github.com/chromelyapps/Chromely/commit/1589d83206f05e2ede4e5b9f173a5e4d6d5f8cc8#diff-3b58baf3508d7be93b31b46b8993d4cd

Sorry but I do not understand. Where I probably mixed assemblies ? In test or in my app ?

There are 3 assemblies
Chromely.Core
Chromely.CefGlue
Chromely
If you are using source code, better to use source code for all. That is what I mean.
So what you find may be correct, but good to be sure. The changes have only been tested by a few people and not on Linux/MacOS yet.

I am seeing something similar on MacOSX.
When invoking "dotnet run" it downloads cef, extracts it and then gives an error:
2020-05-02 01:12:16.258 [INFO] Running MacOSX chromium 77.0.3865.120
2020-05-02 01:12:16.275 [ERROR] Oops! Something went wrong.	Unable to load shared library 'libcef' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(liblibcef, 1): image not found	   at Xilium.CefGlue.Interop.libcef.api_hash(Int32 entry)
   at Xilium.CefGlue.CefRuntime.CheckVersionByApiHash()
   at Xilium.CefGlue.CefRuntime.CheckVersion()
   at Xilium.CefGlue.CefRuntime.Load(String path)
   at Xilium.CefGlue.CefRuntime.Load()
   at Chromely.CefGlue.BrowserWindow.CefBinariesLoader.Load(IChromelyConfiguration config)
2020-05-02 01:12:16.291 [INFO] CefLoader: Installing CEF runtime from http://opensource.spotify.com/cefbuilds
2020-05-02 01:12:16.325 [INFO] CefLoader: Load CEF for MacOSX X64, version 3865
2020-05-02 01:12:16.327 [INFO] CefLoader: Load index page http://opensource.spotify.com/cefbuilds/index.html#macosx64_builds
2020-05-02 01:12:16.922 [INFO] CefLoader: Found download URL http://opensource.spotify.com/cefbuilds/cef_binary_77.1.18%2Bg8e8d602%2Bchromium-77.0.3865.120_macosx64_minimal.tar.bz2
2020-05-02 01:12:16.952 [INFO] CefLoader: Parallel download cef_binary_77.1.18%2Bg8e8d602%2Bchromium-77.0.3865.120_macosx64_minimal.tar.bz2, 63MB
2020-05-02 01:12:16.979 [INFO] CefLoader: Load /var/folders/dx/s24_dlw516qctm2xg55_mdjr0000gn/T/tmpk1nCCA.tmp (0..8321494)
[......]
2020-05-02 01:12:39.030 [INFO] CefLoader: Extracting cef_binary_77.1.18+g8e8d602+chromium-77.0.3865.120_macosx64_minimal/Debug/cef_sandbox.a
2020-05-02 01:12:39.041 [INFO] CefLoader: Decompressing archive took 17161ms
2020-05-02 01:12:39.042 [INFO] CefLoader: Copy files to application directory
2020-05-02 01:12:39.401 [INFO] CefLoader: Copying files took 359ms
[0502/011241.650292:ERROR:icu_util.cc(129)] icudtl.dat not found in bundle
[0502/011241.650444:ERROR:icu_util.cc(165)] Invalid file descriptor to ICU data received.

If I run "dotnet run" again it doesn't download anymore but just repeats those last 2 lines from icu_util.
The icudtl.dat is present in my bin/Debug/netcoreapp3.1 directory.

@behaug I have seen developers raise this issue a few times. I personally do not know why it happens. I always suggest a refresh/redo or to be pretty sure, CEF download was not corrupted that developers try a manual download.
Please let me know if this helps - https://github.com/chromelyapps/Chromely/issues/175#issuecomment-610350084
We may need to zoom in somehow to see why this happens.
Thanks.

I deleted my bin directory and run "dotnet build" over again, so I have my application with no cef. I then downloaded it manually as described here: https://github.com/chromelyapps/Chromely/blob/9e7b079053279df51487a5940a6c8db054574cd3/Documents/cef_binaries_download.md
But it still gives me the exact same error message.
2020-05-02 02:21:41.053 [INFO] Running MacOSX chromium 77.0.3865.120
[0502/022141.208076:ERROR:icu_util.cc(129)] icudtl.dat not found in bundle
[0502/022141.209087:ERROR:icu_util.cc(165)] Invalid file descriptor to ICU data received.

Should I try a newer version of chromium or is Chromely built to this version?

I see in this commit https://github.com/chromelyapps/Chromely/commit/b657d24505590a1c8bffab98c124aa335b4e675f that you upgraded to Chromium 79. But that is not yet available in the nuget version of Chromely (<IP_ADDRESS>) because when I manually download version 79 I get this error:
2020-05-02 02:47:44.494 [INFO] Running MacOSX chromium 77.0.3865.120
2020-05-02 02:47:44.589 [ERROR] Oops! Something went wrong.	CEF runtime version mismatch: loaded version API hash "4a77f1908fabccdb01a2d3bdbede5ca09fbaa394", but supported "1c87ca78fce1bd15cd78f33f8f4e1763d616556a" (77.1.18+g8e8d602+chromium-77.0.3865.120).	   at Xilium.CefGlue.CefRuntime.CheckVersionByApiHash()
   at Xilium.CefGlue.CefRuntime.CheckVersion()
   at Xilium.CefGlue.CefRuntime.Load(String path)
   at Xilium.CefGlue.CefRuntime.Load()
   at Chromely.CefGlue.BrowserWindow.CefBinariesLoader.Load(IChromelyConfiguration config)

@behaug CefGlue does not give us the liberty of changing versions at will - https://github.com/chromelyapps/Chromely/blob/master/src/Chromely.CefGlue/CefGlue/Interop/version.g.cs. Of course we could separate CefGlue into a separate DLL but we wanted to make things simpler so we embedded the code. CefGlue itself does not have nugets published, we had to manage that too, if we go that route.
But the issue  you are having seems more like dependencies missing or security issue. Is it possible you debug using Visual Studio Code? Maybe some .Net Core libs missing or versioning issue. It was tough to get MacOS right, but it has been smooth sailing for a while now. And on MacOS the CEF binaries load pretty fast - my experience.
Also if you can share your Mac version, we can check if there are CEF issues around that.
So using Visual Studio Code, I will start from the basics:
dotnet restore
dotnet build
dotnet run
If anything missing, restore, or build should point it out.
Thanks

I tried download manually chromium and add to project but the same issue is still present. Could this be a chromium issue ?

@mikart143 will be hard to tell. First time I am hearing about PopOs 20.04 is from you. So it may not be widely used in the CEF community. Or it is just me.
But still, it is based on Ubuntu, so should work if basic things are not changed in the distro.
Unfortunately with the bandwidth we have on Chromely project we cannot support every Linux distros out there. There are many many.
I will suggest you use Visual Studio Code to debug and that may help. I usually just flatten the source code to help me debug on Linux and MacOS using VSC.
Attached is an example of what I meant. You can try this for v77 and do same for v79 (current repo) if need be,
Thanks.
Chromelyv77.zip

@mikart143  remember to  change the runtime to Linux in the project file.


Double vertical resolution

Nice project! You could double the available vertical resolution by using ASCII "half-blocks" with fore- and background colors, like:
https://theasciicode.com.ar/extended-ascii-code/top-half-block-ascii-code-223.html
https://theasciicode.com.ar/extended-ascii-code/bottom-half-block-ascii-code-220.html

Hi, thank you for the advice, maybe before aomenting the vertical resolution I'd better improve the efficiency of the algorithms, otherwise it would be too slow.

I will add this improvement in the TODO


Create new post on 103 responds with a 500

After successfully subscribing to a 103 feed, creating a new post results in an http 500.
The item is actually created but the publish action to the sub seems to fail as I don't receive any callback.
Screenshots

The feed contains 3 items

The publication fails

A new item appears on the feed

Same for me, also for 102 Atom feed discovery

I get the same problem whenever I have successfully subscribed on every subscriber test except 204, because the verification fails (intentionally) and I haven't implemented 101, 102, or 103 so I haven't test those.
To test:

login and go to a random (fresh) blog URL that no one has subscribed to before.
Try to click 'Create New Post', and it should work, if it doesn't try another one, that blog URL likely has a subscription.
Subscribe to the blog URL you used.
Try to click 'Create New Post'. It should just spin, and you shouldn't get a response on the subscription you made.

This bug was caused by an incomplete change at 07ef450 and can be fixed with the following tiny patch (in #29):
diff --git a/lib/Rocks/Hub.php b/lib/Rocks/Hub.php
index 3de3544..969b92d 100644
--- a/lib/Rocks/Hub.php
+++ b/lib/Rocks/Hub.php
@@ -137,7 +137,7 @@ class Hub {
     );

     $route = new \App\Subscriber();
-    $feed = $route->get_feed($request, $response, ['num'=>$num, 'token'=>$token]);
+    $feed = $route->get_feed($request, ['num'=>$num, 'token'=>$token]);
     $html = $feed->getBody();

     return (string)$html;


fix(types) ignore tag order for object comparisons

Ignore tag order for object comparisons by sorting the string slices that contain them before checking object equality. This avoids issues with spurious diffs resulting in unnecessary changes when the tag order constructed by deck from dump YAML and the tag order reported by admin API JSON differ.
Because Kong object tags are logical string sets, their order does not matter: it is only a perceived difference because JSON and YAML lack set types and represent them with ordered arrays.
Fix #239 and a minor typo ("Copt" to "Copy" in one of the functions).
Implementation notes/questions:
We have Equal() and EqualWithOpts() functions for each object. The former is just return reflect.DeepEqual(thing1, thing2), is not modified by this PR, and would still report the objects not equal as such. The latter copies the objects first and then nulls out their IDs and/or created and updated timestamps based on the options provided before performing a comparison. This PR does modify EqualWithOpts() to ignore tag order, though it doesn't introduce a new option: IDs and timestamp differences do actually matter for objects, but tag order never does, so it doesn't seem like it makes sense to add an option.
I'm curious about the history behind this, since as far as I know deck never cares about timestamps (there's no CLI options to toggle that option, and dumps don't include timestamp data, but this doesn't mean that deck repeatedly updates objects because the nil timestamps in dumps do not match the not-nil timestamps) and only sort of cares about IDs (dump has an option to include them or omit them, but sync doesn't have an option to ignore them).

Do we use Equal() in practice, and if so, how/why? Do we need to modify it to also create copies and sort their tags?
Ditto for EqualWithOpts(): do we ever use that without ignoring IDs and timestamps?

Unrelated to that, types_test.go does not currently include tags on any of its test objects. We can cover that pretty easily by adding differently-ordered Tags to objects, e.g. after https://github.com/Kong/deck/blob/v1.2.3/state/types_test.go#L51 and confirming that EqualWithOpts() is still true, but I wanted to get a pass on the proposed implementation here before writing those out for every object (Golang generics, you cannot arrive soon enough).

I'm curious about the history behind this, since as far as I know deck never cares about timestamps (there's no CLI options to toggle that option, and dumps don't include timestamp data, but this doesn't mean that deck repeatedly updates objects because the nil timestamps in dumps do not match the not-nil timestamps) and only sort of cares about IDs (dump has an option to include them or omit them, but sync doesn't have an option to ignore them).

There is development history behind it. In an early PoC of decK, the code looked a lot different than it is today and there was a DAG built to solve the diffing problem. It turned out to be over-engineered. The code simplification kept major parts of the codebase, including this. There are no parts of code that care about timestamps in diffing.
ID is a little different. Around decK 0.5.0 or 0.6.0, decK again underwent a major re-write to simplify code and ensure 100% correctness without an elaborate test suite. Before this re-write, some portions of code ignored ID for comparison and some didn't. I don't recall why that was the case, git spelunking might help here.

Do we use Equal() in practice, and if so, how/why? Do we need to modify it to also create copies and sort their tags?

We don't but these functions are now diverging. Order of tags should be ignored no matter what. I'd recommend the following refactor as part of this change:
fn Equal() {
  return EqualWithOpt(with, default, arguments)
}

Ditto for EqualWithOpts(): do we ever use that without ignoring IDs and timestamps?

A quick grep says no.

Consider the PR approved once you add in tests and refactor the Equal fns.

Double-checking on the refactor, but I think we're good to go here. Grepping shows that we actually do have ID checks enabled in current calls, though presumably most users aren't using --with-id when dumping and/or aren't changing object IDs between runs, so that doesn't really matter in practical usage.
The complete signatures follow a func (c1 *Object) EqualWithOpts(c2 *Object, ignoreID bool, ignoreTS bool, ...) bool pattern, e.g. for aclGroup, and across the codebase:
$ grep -Ir EqualWithOpts | egrep -ce "\(\w*, false"
32
$ grep -Ir EqualWithOpts | egrep -ce "\(\w*, true"
0

Have made that the default in the Equal() refactor as such. Would we want to flip that for any reason?
Not sure if there's some more idiomatic way to handle the tag test without creating the test Tags slice in each test function--doesn't appear to be any way to create constant *string slices, even if you make them fixed-sized arrays, so the generator function works around that.


[internal] dig into why linting was not working

            if (pattern == null)
            {
                throw new ArgumentNullException(nameof(pattern));
            }

Originally posted by @kblok in https://github.com/microsoft/playwright-dotnet/pull/2012#discussion_r810148325

Seems like it was never activated, when I go back to 4802c3ee9a45c3c2bd042648348260777925c4a8 it was not throwing errors before running. Closing then.


TBI - ui-components, Enhancements for UIContextualMenu(used for context menues and dropdown butons)

Value
Dropdown items for buttons or context menu already supports icons, but visualisation is not adjusted:

Expected visualisation is:

Notes
Tasks

[x] Apply sizing to icons -> PR #1034
[x] Show icons on right side of menu -> PR #1034

Additional:

[ ] Add an option of horizontal divider
[ ] Add possibility for non-selectable subtitle line item

@gpeuc

Fluent has this by default already, maybe we can just tweak the styling and that's it?
https://developer.microsoft.com/en-us/fluentui#/controls/web/dropdown


Title of plot not fully readable

When I run the LeNetMnistVisualization from the examples module
https://github.com/Kotlin/kotlindl/blob/master/examples/src/main/kotlin/examples/visualization/LeNetMnistVisualization.kt
the title of the plot is not fully displayed. One can't read the predicted label:

It would be better to introduce a line break instead of the pipe symbol between the real and predicted label.

I would like to fix this issue.

This is how it would look like:

@b0n541 looks nice, a PR would be very welcome!


When quickdoc is enabled in IDE, quickdock dialog pops up continuously

I have my QuickDoc box set to popup at around 250 ms.  This works fine in most files, but with markdown plugin enabled, when editing a markdown file, the quickdoc box pops up EVERYWHERE my cursor is at the moment, making editing impossible. This happens in AndroidStudio, and Webstorm

It appen also for me, with pycharm community edition 5.0.3. Very anoying.


Awaiting an already-completed IAsyncAction does not consume stack (in C++20 mode)

Normally, when awaiting an IAsyncInfo, we register a completion handler and resume the coroutine from the handler. However, this results in stack build-up if the IAsyncInfo has already completed because the IAsyncInfo will call the completion handler synchronously. The stack is

caller -> awaiter -> await_suspend -> Completed -> Handler -> caller

We want to avoid the deep stack that leads back to the caller. This is particularly problematic when the co_await happens in a loop: Each iteration of the loop eats more stack.
One way to do this is to sniff the IAsyncInfo's Status in await_ready and return false if it is already in a terminal state. However, this adds three virtual calls to the co_await code path. (QI + Status + Release.)
Instead, we detect the situation by having the handler check whether it is being called while await_suspend is still running:

caller -> awaiter -> await_suspend -> Completed -> Handler

If the Handler realizes that it's inside await_suspend, it delegates responsibility to resume the coroutine to await_suspend and returns immediately. This unwinds the stack back to await_suspend:

caller -> awaiter -> await_suspend

The await_suspend detects that the Handler wants to resume the coroutine, so it just returns false. This unwinds the stack all the way to the caller:

caller

which can now resume with no stack usage.
This works great, except that there is a code generation bug in MSVC C++17 prerelease coroutines that occurs if await_suspend returns bool. (Improper promotion decision.) This bug is fixed in MSVC 16.11.
However, MSVC 16.11 prerelease coroutines are ABI-compatible with pre-16.11 prerelease coroutines, and it's possible that somebody is going to mix some pre-16.11 coroutine code with post-16.11 coroutine code. Changing the the behavior of await_suspend based on the compiler version would introduce ODR violations.
Therefore, if we are using MSVC prerelease coroutines, we cannot have await_suspend return bool, just in case this code ever links against code compiled with pre-16.11. await_suspend must return void. The best we can do is have it resume the coroutine inline.

caller -> awaiter -> await_suspend -> caller

This is not great, but it's the best we can do with MSVC prerelease coroutines. Hopefully, everybody will move to C++20 coroutines, either by compiling in C++20 mode or opting into C++20 style coroutines in C++17 mode via /await:strict. Or at least they will upgrade their toolchain to MSVC 16.11 or higher. Then we can finally drop support for MSVC prerelease coroutines less than 16.11.
We take this opportunity to simplify the await_suspend by consolidating the three things that the Completion handler has to manage into the single disconnect_aware_handler. (The three things are disconnection, apartment switching, and now synchronous completion.)
Note that the suspending flag must be atomic, because it's possible that the IAsyncInfo completes on another thread. The completion uses release semantics (and await_suspend uses acquire semantics) to ensure that all state is properly transferred from the completing thread to the awaiting thread. Normally, resume_apartment would establish the necessary memory barriers, but in this short-circuit, we can't use resume_apartment. (Fortunately, we don't need it because the await_suspend is already running in the correct apartment.)

This is not great, but it's the best we can do with MSVC prerelease coroutines. Hopefully, everybody will move to C++20 coroutines, either by compiling in C++20 mode or opting into C++20 style coroutines in C++17 mode via /await:strict. Or at least they will upgrade their toolchain to MSVC 16.11 or higher. Then we can finally drop support for MSVC prerelease coroutines less than 16.11.

Do we want to raise a build warning when a project is targeting C++ 17 with /await instead of /await:strict?


remove MKL_EXPERIMENTAL and update make files for MKL-DNN

Description
remove MKL_EXPERIMENTAL and update make files for MKL-DNN
Checklist
Essentials

Passed code style checking (make lint)
Changes are complete (i.e. I finished coding on this PR)

Changes

remove MKL_EXPERIMENTAL and update make files for MKL-DNN

@zheng-da @piiswrong can you please review ... these are minor changes to remove old references to MKL_EXPERIMENTAL and minor updates to other make/doc changes. thanks!

@ashokei there's a test for MKLML installation, tests/python/cpu/test_mklml.py.
Is it possible to update this for MKL-DNN?

@szha i addressed all the review comments, can you please take a look/approve if ok. thanks!

Would it be possible to fix the CMake build with MKLDNN too? It says mkldnn.hpp not found unless I first compile the repo with make and then use cmake

@rahul003 cmake should work with mkldnn. mkldnn is a submodule in 3rdparty. did you update update mkldnn with git submodule update?

@marcoabreu can you please review requested Jenkins file changes; This PR is primarily targeting at removing MKL_EXPERIMENTAL and minor changes to regular makefiles; we may do a separate PR for cmake mkldnn build as required. thanks!

which files exactly?
On Fri, Feb 23, 2018 at 1:19 AM Marco de Abreu<EMAIL_ADDRESS>wrote:

@marcoabreu commented on this pull request.
In Jenkinsfile
https://github.com/apache/incubator-mxnet/pull/9810#discussion_r170200495
:

@@ -24,6 +24,7 @@
mx_lib = 'lib/libmxnet.so, lib/libmxnet.a, dmlc-core/libdmlc.a, nnvm/lib/libnnvm.a'
// mxnet cmake libraries, in cmake builds we do not produce a libnvvm static library by default.
mx_cmake_lib = 'build/libmxnet.so, build/libmxnet.a, build/dmlc-core/libdmlc.a, build/tests/mxnet_unit_tests, build/3rdparty/openmp/runtime/src/libomp.so'
+mx_cmake_mkldnn_lib = 'build/libmxnet.so, build/libmxnet.a, build/dmlc-core/libdmlc.a, build/tests/mxnet_unit_tests, /usr/local/lib/libiomp5.so, /usr/local/lib/libmklml_gnu.so, build/3rdparty/mkldnn/install/lib/libmkldnn.so, build/3rdparty/mkldnn/install/lib/libmkldnn.so.0, /usr/local/lib/libmklml_intel.so'

I don't understand why we are generating files outside the source
directory. This could cause issues because I would not assume that a
compile process writes files to /usr/local or any other place outside of
the source directory. Since I don't have much experience with cmake, I'd
like to ask @larroy https://github.com/larroy and @cjolivier01
https://github.com/cjolivier01 for assistance here
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-mxnet/pull/9810#pullrequestreview-98850945,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKts_V4K6R7JHtxWYDj-8E-RY7BJpf5eks5tXoKLgaJpZM4SIufG
.

@marcoabreu jenkins issue is fixed, it passes the build.

@marcoabreu i made your requested changes...can you please approve/merge if ok.


Geth 1.9.x incompatibility

As of ef460128305490828e9b4f10987facbafd8aec37, we're not compatible with geth 1.9.x for a number of reasons:
NOTE geth --dev leaks memory on 1.9.0, make sure to use >=1.9.1

[ ] geth now requires a flag to be able to unlock via HTTP (used in integration tests)
[ ] there's some timing/race cond issue in the integration tests (found by @chrishunt):

1) test get the blocks from child chain after sending a transaction and start exit (OMG.Watcher.Integration.BlockGetterTest)
test/omg_watcher/integration/block_getter_test.exs:50
match (=) failed     The following variables were pinned:       deposit_blknum = 1       token_deposit_blknum = 2
token_addr = "0x10778cbaf134b9a32f505db993b3b6a6d6b5ef05"
code:  assert [%{"blknum" => ^deposit_blknum}, %{"blknum" => ^token_deposit_blknum, "currency" => ^token_addr}] = TestHelper.get_utxos(alice.addr())
right: []
stacktrace:
test/omg_watcher/integration/block_getter_test.exs:59: (test)

Not sure could be causing this, requires investigation. Hint: if one Process.sleep(5000) just before this failing assertion - the test will progress till next similar error. Something must be time-dependant where it shouldn't or?

we're using infura's geths in production so this might be very valid work!

yeah I was pondering this as a blocker, but thought infura should make it transparent for us. But you're right, I think it's better to be safe in this aspect. And not having to maintain 1.8 is all the more reason. And this should be rather easy, once someone gets to focus on it


use new error blade directive

Laravel 5.8.13 introduced a new blade directive that cleans up the error handling. It's used in the laravel/ui blade templates, so it would be nice if the tailwind-presets used it, too.

This is kind of a high priority pull request, I think, because the existing templates result in errors being thrown in Laravel 6.x. I don't remember seeing any documentation about a breaking change around the old $error->has() stuff, but the $error object appears to be missing. I solved it on my own site by manually changing to the new directive much like this pull request does.


Armstrong exercise tests confusion

The test does not inform what method should be implemented. Can someone please confirm if the tests are still correct?
def test_single_digit_numbers_are_armstrong_numbers
    skip
    assert_includes ArmstrongNumbers, 5
  end

TypeError: wrong argument type Integer (expected Module)

Traceback (most recent call first):
    Line 7:in `test_zero_is_an_armstrong_number'

It's a bit weird, but the tests are correct. You can write the code like this.
class ArmstrongNumbers
  def self.include?(number)
    #...
  end
end

I think we should add a stub. @ErikSchierboom Do you agree?

I 100% agree. In general I think that stubs should be added to all practice exercises, on the condition that it doesn't unnecessarily restrict the student to certain solutions. In this case, the interface to implement is fixed and thus there is no benefit to defining the signature from scratch. As Ruby has Learning Mode, it is there that students can practice defining function signatures.

Summary: Did we identify that this is an error and not a failed test?  We may be missing a test to inform the student that we need to write a class, it is not reporting a deficiency in a missing include? method.  The test itself does inform, but the message given was not about the method.  Perhaps we are missing a test, so it fails, instead of causing an error, in this situation.

I 100% agree. In general I think that stubs should be added to all practice exercises, on the condition that it doesn't unnecessarily restrict the student to certain solutions.

Even if the stubs are given, it does not mean that it is a "given" in that the students are not allowed to delete the stub and write it in another way.  It also does not restrict students from throwing the stubbed material out, in case they want to write it in another way, so I think stubs are fine.  This is not the only way to get this method to pass (the def self.include?(argument) while it is probably  a first reach)

I think we should add a stub

The tests itself means that the student almost has to know what "assert_includes" means, in that it alludes to calling the method include? which really is not intuitive.  They must have some knowledge of the testing framework to know this.
Do we give them that information anywhere?
Are we missing information that should be given to the student in HELP.md where we give information about what the minitest assertions are using to check underneath the hood?  How would they know given the failing message.  We can do this in a test message, so the test may be lacking communication.
I think we are not checking that the constant Armstrong exists and instead letting the tests fail to give some hint.  And then the response is that a module does not exist, which is not required, but could be a solution to what the tests need to continue, to finally get to the information that the include? method does not exist, which should bubble up as things are progressed.
So, my question is "do we let the student learn how to read the error messages when something comes up like this, or do we hold their hand for, as @ErikSchierboom suggests, all practice exercises.
Perhaps stubs are not necessarily the best answer (as it can hide a deficiency that should be known, but might end up being a hand waved away thing that they have to know later in life).  We might be missing a fundamental test here to help the student get a better test failure message here.
I write this, because the method not being written here is not the problem coming from the errored test, since the test did not fail, but instead is an error.
If we had a test that suggested that we need the constant Armstrong, which could be a class or a module, (or not), then the error would not happen, but a test failure instead.

I think this whole include? thing is a big distraction from the actual exercise. The only reason we have this is because Rubocop automatically updated the files - it's not by design: 3129539

A fairly good argument to not have a "robot" update things automatically.  If that is the only reason.  It should have been that plus another reason, really.

I think this whole include? thing is a big distraction from the actual exercise.

Should we remove the test then?
Stub would be less disruptive all around, for sure.

Added in https://github.com/exercism/ruby/pull/1556


warning when switching to different host

Is it possible to add a warning when switching to a system with a different hostname?
Today I accidentally nixos-rebuild switched my laptop to one of my servers, and this is probably the third time I've done so...
It would be really useful if the nixos-rebuild script could warn the user if they are trying to switch to a completely different nixos configuration.

This has never happened to me, maybe you should reorganize your config structure if this is happening to you often.

Hasn't happened to me either but a warning when changing things like hostname and networking.hostId would be nice to have since they have potential to break stuff (such as booting from zfs) even when changed intentionally.

This has never happened to me, maybe you should reorganize your config structure if this is happening to you often.

This is really quite a rare occurrence and only happens if I am building and inspecting other hosts, but I still think it should be implemented.


Query - Testnet Web Wallet is open source?

If the Testnet Web Wallet is open source? if yes, where is it? Many thanks
https://t1wallet.eos.io/
I built the https://github.com/EOSIO/eos-wallet-app but found that it is a static pages with no connection to Testnet.

https://github.com/Tandemly


No Wyze Cam v3 Pro Support

Support for Wyze Cam v3 Pro similar to existing cam support with optional enhancements
CAMERA_V3_PRO Device model
Current cameras.py attributes such as:
        "power_switch",
        "temperature",
        "humidity",
        "room_type",
        "comfort_standard_level",
        "supports_temperature_humidity",
        "supports_continuous_record",
        "suppprts_audio_alarm",
        "suppprts_co_alarm",
        "suppprts_motion_alarm",
        "suppprts_smoke_alarm",
        "voltage",
        "battery_charging",
        "power_saving_mode_switch"

Confirm events model supports new device type.

In addition to power On/Off support it would be neat to explore these additional use cases:
Spotlight On/Off
Siren On/Off
Smart Focus
Take Photo
Restart camera
Sync Time
Download images and videos from camera Micro-SD card

Shaun, I will share a device for testing.  Thank you for developing the wyze-sdk package.

I agree with Anthony with regards to API support for additional use cases.  I'm looking for a way to download video segments from a camera's micro-sd card for a given time range.
Thanks for providing and supporting this API.


Keeps asking to install forever when issuing: script/bootstrap

Script/install or restart works but bootstrap keeps prompting install forever but still prompts after forever is installed.  I realize this is old and my node may be too new but just thought I would see here if there is a work around.  script/server says no file guessing since the bootstrap isn't working.  Any help is welcomed, cheers!

IIRC, when I was wrestling with this on my M1 Mac mini w/ Big Sur, I ran into something like this.  I installed Forever with Homebrew and it is in a different path than what is assumed in the scripts.  I think I ended up modifying all the scripts/setting path so things would work as designed.
I struggled a bit because I don't really know what I am doing, but ultimately have it working perfectly.


Atom index of the ligand in covalent bond restraint. And explicit hydrogen

Hi Chai team,
Thanks for the update for the covalent bond restraint. I'm wondering to specify a linkage between ligand and protein, how do I find the atom name/index to put in the restraint file for the ligand atom of interest? Or is the function for now just for glycan and other modification with standard names?
My second question: I realize Chai removes all hydrogens in the output ligand, which is, I think, due to rdkit's procedure reading the smiles string. But sometimes there are some important hydrogens, like metal-hydride, that I wish to be explicitly predicted. Is there any way to do that in the current version or near future?

Regarding the linkage between ligand and protein, you can find the atom index by doing something like this, opening the resulting file in PyMOL (or something similar), clicking through, and finding the name of the atom that you wish to bind to:
def write_reference_conformer(query: str, query_type: str, output_file="ligand.pdb"):
    """Writes reference conformer of the given query to the given pdb file.

    NOTE: query_type must either be "ccd" or "smiles" and determine how we parse query.

    Meant as a research utility for quickly determining atom names and checking the
    conformer generated for a smiles string.
    """
    conformer_generator = RefConformerGenerator()

    if query_type == "ccd":
        conf_data = conformer_generator.get(query)
        assert conf_data is not None
    elif query_type == "smiles":
        conf_data = conformer_generator.generate(query)
    else:
        raise ValueError(f"Unrecognized {query_type=}")

    # log the atom names
    for i, n in enumerate(conf_data.atom_names):
        logging.info(f"Atom {i}:\t{n}")

    with open(output_file, "w") as f:
        # PDB format uses 1-based indexing for atom numbers
        for atom_index, (atom, coord) in enumerate(
            zip(conf_data.atom_names, conf_data.position), 1
        ):
            # Format each line according to PDB specifications
            line = (
                f"HETATM{atom_index:5d}  {atom:<3s} LIG A   1    "
                f"{coord[0]:8.3f}{coord[1]:8.3f}{coord[2]:8.3f}"
                f"  1.00  0.00          {atom:>2s}\n"
            )
            f.write(line)

        bonds_grouped = defaultdict(list)
        for i, j in sorted(conf_data.bonds):
            bonds_grouped[i + 1].append(j + 1)  # Converts 0 to 1 indexed
        for center_atom, connections in bonds_grouped.items():
            bonded_atoms = sorted(connections)
            while bonded_atoms:
                # Take up to 4 bonded atoms at a time
                current_bonds = bonded_atoms[:4]
                bonded_atoms = bonded_atoms[4:]

                # Format the CONECT record
                # The format requires each atom number to take exactly 5 columns
                line = f"CONECT{center_atom:5d}"
                for bonded_atom in current_bonds:
                    line += f"{bonded_atom:5d}"
                line += "\n"
                f.write(line)

        # Write the END record to properly terminate the PDB file
        f.write("END\n")

Regarding hydrogens - we remove all hydrogens during training, so while it might be possible to hack this in by changing the conformer generation logic, I wouldn't expect particularly good results when doing so. If you wish to hack it in, I would start by seeing what happens if you remove the call to remove hydrogens here: https://github.com/chaidiscovery/chai-lab/blob/3278943196725f468e0e2195b0d237b58484d02a/chai_lab/data/sources/rdkit.py#L95-L97

We've also added an example of specifying covalently bound ligands here: https://github.com/chaidiscovery/chai-lab/tree/main/examples/covalent_bonds#non-glycan-ligands

Thanks for providing the script. I ran it and here is the PDB I ended up with. In your example, you specified the sulfur atom as @S1. Does the "1" here means the first S atom in the atom order of the generated PDB? Because the index is not 1 for the desired atom in the output file.

HETATM    1  C   LIG A   1       0.867  -0.164  -1.047  1.00  0.00           C
HETATM    2  C   LIG A   1       0.155  -1.005  -1.898  1.00  0.00           C
HETATM    3  C   LIG A   1      -1.020  -0.593  -2.489  1.00  0.00           C
HETATM    4  C   LIG A   1      -1.470   0.679  -2.211  1.00  0.00           C
HETATM    5  C   LIG A   1      -0.754   1.506  -1.363  1.00  0.00           C
HETATM    6  C   LIG A   1       0.422   1.108  -0.765  1.00  0.00           C
HETATM    7  O   LIG A   1       1.081   1.989   0.071  1.00  0.00           O
HETATM    8  C   LIG A   1       2.271   1.682   0.745  1.00  0.00           C
HETATM    9  C   LIG A   1       2.181   0.616   1.751  1.00  0.00           C
HETATM   10  O   LIG A   1       3.235   0.274   2.391  1.00  0.00           O
HETATM   11  N   LIG A   1       0.962  -0.037   2.033  1.00  0.00           N
HETATM   12  C   LIG A   1       0.932  -1.083   3.030  1.00  0.00           C
HETATM   13  C   LIG A   1       1.340  -0.610   4.406  1.00  0.00           C
HETATM   14  S   LIG A   1       1.246  -2.029   5.541  1.00  0.00           S
HETATM   15  CL  LIG A   1      -2.960   1.237  -2.944  1.00  0.00          CL
HETATM   16  CL  LIG A   1      -1.907  -1.671  -3.564  1.00  0.00          CL
CONECT    1    2
CONECT    2    3
CONECT    3    4   16
CONECT    4    5   15
CONECT    5    6
CONECT    6    1    7
CONECT    7    8
CONECT    8    9
CONECT    9   10   11
CONECT   11   12
CONECT   12   13
CONECT   13   14
END

Thanks for providing the script. I ran it and here is the PDB I ended up with. In your example, you specified the sulfur atom as @s1. Does the "1" here means the first S atom in the atom order of the generated PDB? Because the index is not 1 for the desired atom in the output file.

Atom names are assigned in order of occurrence in the reference conformer, so @S1 indicates the first sulfur in the reference conformer.
In the general case, you can hover over each atom in something like PyMOL to find the atom name we assign to it, and change which atom you specify in your restraint accordingly.


[Event Request] Codeunit 90 "Purch.-Post" - OnCheckAndUpdateOnBeforeArchiveUnpostedOrder

Hi, would it be possible to modify the OnCheckAndUpdateOnBeforeArchiveUnpostedOrder event in codeunit 90 (Purch.-Post) by adding the var keyword to the PurchHeader parameter, like this:
    [IntegrationEvent(false, false)]
    local procedure OnCheckAndUpdateOnBeforeArchiveUnpostedOrder(var PurchHeader: Record "Purchase Header"; PreviewMode: Boolean; var IsHandled: Boolean)
    begin
    end;

Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Collapsable info panel

why

it takes up a lot of room, let people who don't want it hide it.

Do you think we should save the preference of whether they like it closed or open locally so that even if they refresh, it'll stay how they want?

👍


more tests for clean core tools

Codecov Report

Merging #490 into master will increase coverage by 0.73%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #490      +/-   ##
=========================================
+ Coverage   71.77%   72.5%   +0.73%
=========================================
  Files          47      47
  Lines        3713    3714       +1
=========================================
+ Hits         2665    2693      +28
+ Misses       1048    1021      -27

Impacted Files
Coverage Δ

tests/test_menu.py
100% <100%> (ø)
:arrow_up:

vent/menus/clean_core_tools.py
91.25% <0%> (+33.75%)
:arrow_up:

Continue to review full report at Codecov.

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


Add TypeScript definition

A little late now, but would have been nice for the definition file to match closer to the version in DefinitelyTyped
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/query-string/index.d.ts
Specifically InputParams vs {[key: string]: unknown} and OutputParams vs ParsedQuery
ParsedUrl is a welcome addition though

This is a necessary evil. This one time we have to break compat with DT.
The benefit is that now types will always be up to date and if a breaking change is introduced to the types, a major version will be released.
In DT, breaking changes to types may be introduced even to atch releases.


New package: Torch v0.1.0

Registering package: Torch
Repository: https://github.com/dhairyagandhi96/Torch.jl
Created by: @dhairyagandhi96
Version: v0.1.0
Commit: 6b8da59c5e5012451aa24c9eaa59c77b9230872d
Reviewed by: @dhairyagandhi96
Reference: https://github.com/dhairyagandhi96/Torch.jl/commit/6b8da59c5e5012451aa24c9eaa59c77b9230872d#commitcomment-38769532

@dhairyagandhi96 If you ping me in 3 days, I can manually merge this.

Thanks!

Pinging @DilumAluthge
Thanks!


add README in doc/ folder

Fix issue #100 : add README in doc/ folder

Just ignore appveyor issue for now, I was doing some tests on my fork of py-earth and I referenced this repo by mistake

Looks good.  Merging now:).


update pages

Fix deploy commands in contract quickstart
Removed cargo build and deploy --release, not relevant here, we should only be using cargo near. They can optionally use cargo near --no-abi or --no-release. They can reference the cargo near README for this (I will add commands there once docker commands have been added)
Fix eth wallets code snippet

@race-of-sloths

@PiVortex Thank you for your contribution! Your pull request is now a part of the Race of Sloths!
Weekly streak is on the road, smart strategy! Secure your streak with another PR!

Current status: waiting for scoring
We're waiting for maintainer to score this pull request with @race-of-sloths score [0,1,2,3,5,8,13] command. Alternatively, autoscoring [1,2] will be applied for this pull request
What is the Race of Sloths

Race of Sloths is a friendly competition where you can participate in challenges and compete with other open-source contributors within your normal workflow
For contributors:

Tag @race-of-sloths inside your pull requests
Wait for the maintainer to review and score your pull request
Check out your position in the Leaderboard
Keep weekly and monthly streaks to reach higher positions
Boast your contributions with a dynamic picture of your Profile

For maintainers:

Score pull requests that participate in the Race of Sloths
Engage contributors with fair scoring and fast responses so they keep their streaks
Promote the Race to the point where the Race starts promoting you
Grow the community of your contributors

Feel free to check our website for additional details!

Bot commands

For contributors

Include a PR: @race-of-sloths include to enter the Race with your PR

For maintainers:

Invite contributor @race-of-sloths invite to invite the contributor to participate in a race or include it, if it's already a runner.
Assign points: @race-of-sloths score [1/2/3/5/8/13] to award points based on your assessment.
Reject this PR: @race-of-sloths exclude to send this PR back to the drawing board.
Exclude repo: @race-of-sloths pause to stop bot activity in this repo until @race-of-sloths unpause command is called

🥁  Score it!
@bucanero, please score the PR with @race-of-sloths score [1/2/3/5/8/13]. The contributor deserves it.
If no scoring is provided within 24 hours, this PR will be scored as 1 🦥

⏰ Scoring closed
24 hours have already passed since the merge


New image type: Fedora IoT Raw Image

New image type
Adding a new image type fedora-iot-raw-image.  This is the same type of image as the edge-raw-image for RHEL.  It's built by pulling a commit from a remote, deploying it, and making a bootable raw image from the deployment.
Configuration changes are made to this image to match the official images, based on the official kickstart [0] and by inspecting the existing raw images [1,2].
OSBuild changes
The PR also includes changes to osbuild stages that were introduced during the development of this image type.
One general change to the obsuild package and bindings is the addition of the ostree.deployment mount.  This was added ages ago [3] but was never used in composer until now.  It makes it possible to add an ostree.deployment mount to any osbuild stage to make changes to an ostree deployment transparently.
Differences from official image
The image isn't identical to the official one.

GPT instead of DOS partitioning: The official raw images are DOS partitions.  We might have to change ours to match to support some older devices (possible for the Raspberry Pi 3).  I need to confirm this.
Small difference in ostree remote configuration: Our remote config is written to the global /ostree/repo/config instead of /etc/ostree/remotes.d/fedora-iot.conf as in the official image.  This is functionally equivalent.
No FONT set in /etc/vconsole.conf: Not supported by osbuild (yet) and it's a minor issue.

TODO
This PR isn't ready yet:

[x] The image boots but fails to start a few important services.  I'm still investigating the cause of this.  I've used the same commit found in existing, working IoT images in the build and inspected both images for differences and haven't found what might be causing it.

https://bugzilla.redhat.com/show_bug.cgi?id=2121197

[x] ARM (aarch64) image not finalised or tested yet.
[x] Remove the hardcoded URL for the remote repository.  Currently the ostree remote configuration is hard coded for the raw image, including the metadata and content URLs.  We might want this to be an external configuration option, but we should think a bit more about how to set this.

Keep for now.  Future plan is to see if we can get it through a package, the same way rpm sources are installed for traditional images.

Update 2022-09-05
Two failures

[x] image-info failing on lvm on F37.
[x] User accounts "baked in" to the commit can't login when deployed.

The image-info issue is related to our own tooling so it's not a big issue.  We just need to figure out a general solution to reading lvm disks that agrees with both old and new versions of lvm/kernel.
The second issue is a bit worrying and I don't know the exact cause of the problem.

[0] https://pagure.io/fedora-kickstarts/blob/main/f/fedora-iot.ks
[1] https://getfedora.org/en/iot/download/
[2] https://kojipkgs.fedoraproject.org/compose/iot/
[3] https://github.com/osbuild/osbuild/pull/847

Update on the service failures: The services start normally when the image is used with our own commit and specifically when the rpm stage is run with the ostree_booted flag.  Still investigating why building with the commit from the compose causes failures.

Seems we're probably hitting this bug: https://bugzilla.redhat.com/show_bug.cgi?id=2121197

Marking as ready.  The IoT commits in the composes are causing issues.  I think we can review this as is and handle any differences or fixes required for the official image in a followup.
@teg wdyt?

Agreed. Are you talking with the right people to figure out a path forward for the fedora compose?

Agreed. Are you talking with the right people to figure out a path forward for the fedora compose?

Yup.  We still have a bit of time, but not much.

You need this before the CI wakes up: https://github.com/osbuild/gitlab-ci-terraform/pull/71

Updated terraform commit and rebased on main.

I think we have a broken repo: f37 aarch64 should include the following file, depsolved in the manifests, but as far as I can tell, it's not in the rpmrepo.
https://rpmrepo.osbuild.org/v2/mirror/public/f37/f37-aarch64-fedora-development-20220817/Packages/g/google-noto-serif-vf-fonts-20201206^1.git0c78c8329-2.fc37.noarch.rpm

Depends on https://github.com/osbuild/osbuild/pull/1100

Pinned osbuild to the version in the (currently still open) PR https://github.com/osbuild/osbuild/pull/1101 which enables building F37 RPMs.
The RPMs are already built from that commit and I'd like to move this PR along while the osbuild PR is still working through testing.

@thozza could you take a look at the change in image-info and tell me what you think?

@lavocatt FYI, you'll have to pick the changes to image-info to manifest-db once this is merged...

@lavocatt FYI, you'll have to pick the changes to image-info to manifest-db once this is merged...

@achilleas-k  can you after this is merged open a PR against https://github.com/osbuild/manifest-db  to send the updated image-info please ?

@lavocatt FYI, you'll have to pick the changes to image-info to manifest-db once this is merged...

@achilleas-k can you after this is merged open a PR against https://github.com/osbuild/manifest-db to send the updated image-info please ?

Ok, but I'll have to figure out the general solution first (or hack something up that works for all versions).

@thozza THANKS for the image-info idea.  It worked!
Locally at least.  Let's see what CI thinks.

Two failures to go:
fatal: [<IP_ADDRESS>]: FAILED! => {
    "assertion": "result_var_mount_point.stdout == \"/dev/vda4[/ostree/deploy/redhat/var]\"",
    "changed": false,
    "evaluated_to": false,
    "msg": "/var does not mount on /dev/vda4[/ostree/deploy/redhat/var]"
}
fatal: [<IP_ADDRESS>]: FAILED! => {
    "assertion": "result_usr_mount_point.stdout == \"/dev/vda4[/ostree/deploy/redhat/deploy/491eab6e36b868d8c8bc264a621f4025b7e6fa88c4c9f1f2c4f762e351436c6a.0/usr]\"",
    "changed": false,
    "evaluated_to": false,
    "msg": "/usr does not mount on /dev/vda4[/ostree/deploy/redhat/deploy/491eab6e36b868d8c8bc264a621f4025b7e6fa88c4c9f1f2c4f762e351436c6a.0/usr]"
}

s/redhat/fedora/ or something like that? (didn't confirm that)
https://gitlab.com/redhat/services/products/image-builder/ci/osbuild-composer/-/jobs/3001184571

I think that we need to add --import to the second virt-install command. This looks like a change in v4.1.0, a quick bisect found this commit to be changing the behaviour: https://github.com/virt-manager/virt-manager/commit/5e48307e9d9d3c811ccbdb6463b6ccb79a029c4d#diff-13be38129d95d0bbd3ebda0a70ff63e792490b8572b592bcf1d1be03fb97bb6a

I pushed a commit to fix one more virt-install issue. Let's hope it works also on EL8.

Force-pushed a fix to "test/ostree-raw: separate osname variable in playbook", we need to differentiate redhat and fedora-iot also in those two other ansible-playbook runs.

Regarding the failing CS9 raw image test:
I built the same image (using the manifests from the job artifacts) locally and it boots fine in UEFI with qemu.  The issue is probably related to the way we boot the image with virt-manager.


⚠ Bofrost.be has degraded performance

In 167db08, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2281 ms

Resolved: Bofrost.be performance has improved in a504a9d.


Request: T-watch-s3 optimization adds more features

This watch is very interesting and portable. It would be great if more functions could be added and improved. It also has IR infrared remote control function and BlueSpy added. Thank you

This user seems to be a lily-go employee posting on a lot of these projects... if only they could also do a pull request to add support ;)


Make OSD Bootstrap more sturdy in CI

Description
As the Bootstrap command in CI is inconsistent, this has been causing a lot of delays in getting CI feedback in PRs. This PR seeks to address this with a few safeguards:

Advice from the OSD Developer Guide was applied to update the network timeout. In their own CI they use this network setting and also have a backup call in case it fails. They also use a clean which may address some inconsistency, though it should be a no-op in a CI setting.
fail-fast is disabled in the CI, so even if the measures from (1) are unsuccessful, we will at least receive some feedback from the other two runs without needing a full re-run.
The results are cached to both reduce the effects of the issue and speed up CI overall.

Issues Resolved
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@Swiddis Love this!
Do you have any way to test this in local dev?  (docker instructions somewhere?)
If so, can you post a terminal log of the test.  I just want to get a feel for what this actually does at CI runtime?

Do you have any way to test this in local dev? (docker instructions somewhere?)

Not at the moment, I'm mostly just relying on an actual run to hang. It looks like this one is pretty close to expected behavior, since it hung for multiple minutes while waiting on network calls. I'm still experimenting a bit with caching.

Results are in

OS
No Cache
Cache

Ubuntu
4:28
0:20

Windows
11:51
2:04

Mac
8:54
2:12

Should be good to merge now


Merge from develop into CGD2D with additional work for graphics re-integration (after UX refactor work)

This change is

The failed tests on build pass locally.
Investigating.

Looks like a file copy over issue

Stale old files don't help you find path changes :(

Files with explicit conflicts:
Conflicts:
	.gitattributes
	Frameworks/CoreGraphics/CGContext.mm
	Frameworks/CoreGraphics/CGGraphicBufferImage.mm
	Frameworks/QuartzCore/CALayer.mm
	Frameworks/UIKit/StarboardXaml/CompositorInterface.mm
	Frameworks/UIKit/UIImage.mm
	Frameworks/UIKit/UILabel.mm
	Frameworks/UIKit/UIPasteboard.mm
	Frameworks/include/CACompositor.h
	Frameworks/include/CGContextInternal.h
	Frameworks/include/CGGraphicBufferImage.h
	Frameworks/include/CGImageInternal.h
	build/Tests/UnitTests/CoreGraphics/CoreGraphics.UnitTests.vcxproj

@jaredhms What app validations would you recommend for niche compositor features we may miss in a CG-centric pass?

@jaredhms  @DHowett
To add onto to previous comments.
The current testing is CGCatalog   + unit tests.
Trying some of the WOC catalog features (but we did break some of the in CGD2D at one point)
E.g pasteboard.

Also:
Frameworks/QuartzCore/CALayer.mm
Frameworks/UIKit/StarboardXaml/CompositorInterface.mm
Core of the re-integration work took place, pretty much the cross over point.

:shipit:

:shipit:

@msft-Jeyaram Thank you


ci: always run commitlint on latest commit

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.451%

Totals

Change from base Build<PHONE_NUMBER>4:
0.0%

Covered Lines:
12422

Relevant Lines:
16505

💛  - Coveralls


paddlex==2.1.0 下piconet添加负样本运行报错

Process Process-17:
Traceback (most recent call last):
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 355, in _worker_loop
six.reraise(*sys.exc_info())
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/six.py", line 719, in reraise
raise value
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 345, in _worker_loop
for b in batch
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 345, in
for b in batch
RuntimeError: (Unavailable) Memory map failed when create shared memory.
[Hint: Expected ptr != ((void *) -1), but received ptr:0xffffffffffffffff == ((void *) -1):0xffffffffffffffff.] (at /paddle/paddle/fluid/memory/allocation/mmap_allocator.cc:81)
Process Process-18:
Traceback (most recent call last):
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 355, in _worker_loop
six.reraise(*sys.exc_info())
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/six.py", line 719, in reraise
raise value
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 345, in _worker_loop
for b in batch
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/worker.py", line 345, in
for b in batch
RuntimeError: (Unavailable) Memory map failed when create shared memory.
[Hint: Expected ptr != ((void *) -1), but received ptr:0xffffffffffffffff == ((void *) -1):0xffffffffffffffff.] (at /paddle/paddle/fluid/memory/allocation/mmap_allocator.cc:81)
Exception in thread Thread-24:
Traceback (most recent call last):
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/dataloader_iter.py", line 583, in _get_data
data = self._data_queue.get(timeout=self._timeout)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/multiprocessing/queues.py", line 105, in get
raise Empty
_queue.Empty
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/threading.py", line 926, in _bootstrap_inner
self.run()
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/dataloader_iter.py", line 505, in _thread_loop
batch = self._get_data()
File "/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/dataloader_iter.py", line 599, in _get_data
"pids: {}".format(len(failed_workers), pids))
RuntimeError: DataLoader 2 workers exit unexpectedly, pids: 1133, 1134
---------------------------------------------------------------------------SystemError                               Traceback (most recent call last)/tmp/ipykernel_101/1640193468.py in
59     use_ema=True,
60     save_dir='output/picodet_esnet_l',
---> 61     use_vdl=True)
/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddlex/cv/models/detector.py in train(self, num_epochs, train_dataset, train_batch_size, eval_dataset, optimizer, save_interval_epochs, log_interval_steps, save_dir, pretrain_weights, learning_rate, warmup_steps, warmup_start_lr, lr_decay_epochs, lr_decay_gamma, metric, use_ema, early_stop, early_stop_patience, use_vdl, resume_checkpoint)
908             early_stop_patience=early_stop_patience,
909             use_vdl=use_vdl,
--> 910             resume_checkpoint=resume_checkpoint)
911
912
/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddlex/cv/models/detector.py in train(self, num_epochs, train_dataset, train_batch_size, eval_dataset, optimizer, save_interval_epochs, log_interval_steps, save_dir, pretrain_weights, learning_rate, warmup_steps, warmup_start_lr, lr_decay_epochs, lr_decay_gamma, metric, use_ema, early_stop, early_stop_patience, use_vdl, resume_checkpoint)
332             early_stop=early_stop,
333             early_stop_patience=early_stop_patience,
--> 334             use_vdl=use_vdl)
335
336     def quant_aware_train(self,
/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddlex/cv/models/base.py in train_loop(self, num_epochs, train_dataset, train_batch_size, eval_dataset, save_interval_epochs, log_interval_steps, save_dir, ema, early_stop, early_stop_patience, use_vdl)
331             step_time_tic = time.time()
332
--> 333             for step, data in enumerate(self.train_data_loader()):
334                 if nranks > 1:
335                     outputs = self.run(ddp_net, data, mode='train')
/opt/conda/envs/python35-paddle120-env/lib/python3.7/site-packages/paddle/fluid/dataloader/dataloader_iter.py in next(self)
695
696             if in_dygraph_mode():
--> 697                 data = self._reader.read_next_var_list()
698                 data = restore_batch(data, self.structure_infos.pop(0))
699             else:
SystemError: (Fatal) Blocking queue is killed because the data reader raises an exception.
[Hint: Expected killed != true, but received killed:1 == true:1.] (at /paddle/paddle/fluid/operators/reader/blocking_queue.h:166)
import paddlex as pdx
(共19行)

把num_workers设成0试试。https://github.com/PaddlePaddle/PaddleX/blob/develop/paddlex/cv/datasets/voc.py#L38

这个issue先关闭了哈，如有需要再打开～


ConnectionCallback is calling twice on startup

Why the ConnectionCallback is called twice on my fragment startup?
Is that a bug or is that with my project?
How can I make it to call only once on startup?

It's not a bug. It's normal. If you don't want multiple calls, you can use a flag variable to see if the callback has already been called once.
Example:
// Global variable
var hasConnection : Boolean = true

// ...

connectionCallback = object : ConnectionCallback {
    override fun hasActiveConnection(hasActiveConnection: Boolean) {
        if(hasActiveConnection != hasConnection) {
            hasConnection = hasActiveConnection

            // Do something here
        }
    }
}


The "get"button freezes selio when pressing it after installing the first package installed

@CC0235 How did you resolve this issue?

This bug is confirmed with members of the RootHide Discord server, who are also experiencing both issues with Sileos postinst being killed, and Sileo freezing when pressing 'Get' on tweaks.

In fact, Sileo has many small bugs on both rootless and rootide, and we have fixed many of them. If you can reproduce your problem stably and tell us how to reproduce it, then we may be able to fix it.

idk how but it got randomly fixed On 8 Jan 2024, at 7:27 AM, roothide @.***> wrote:
In fact, Sileo has many small bugs on both rootless and roothide, and we have fixed many of them. If you can reproduce your problem stably and tell us how to reproduce it, then we may be able to fix it.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Make Japanese localization improvements

This PR makes some improvements to Japanese localization.
Dear @Hima-Zinn @tkusano @dolciss @oboenikui
I would appreciate your review and feedback on these text updates.
Many thanks!

If possible, it may be a good idea to update the header information.

@Hima-Zinn @ansh
Thank you very much for checking.
I will be working on it in a few hours, after I finish today's business.

I made the changes, thank you!

@ansh Thank you!


seafile-client: 6.1.0 -> 6.1.5

Semi-automatic update. These checks were performed:

built on NixOS
found 6.1.5 with grep in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5
found 6.1.5 in filename of file in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5

cc "@calrama"

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘seafile-client-6.1.5’ in /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/applications/networking/seafile-client/default.nix:30 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5
shrinking /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5/bin/.seafile-applet-wrapped
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5/bin
patching script interpreter paths in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5
checking for references to /tmp/nix-build-seafile-client-6.1.5.drv-0 in /nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5...
postPatchMkspecs
postPatchMkspecs
/nix/store/7y211zn1irykpjfgf8n38vbhh57xgaq2-seafile-client-6.1.5

/cc @MoritzMaxeiner

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘seafile-client-6.1.5’ in /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/applications/networking/seafile-client/default.nix:32 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5
shrinking /nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5/bin/.seafile-applet-wrapped
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5/bin
patching script interpreter paths in /nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5
checking for references to /tmp/nix-build-seafile-client-6.1.5.drv-0 in /nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5...
postPatchMkspecs
postPatchMkspecs
/nix/store/q8sjx62y4q020rbkgyws5g0llv4jnnvv-seafile-client-6.1.5

Failure on aarch64-linux (full log)
Partial log (click to expand)
[1996/17378] CXX obj/sandbox/linux/seccomp_bpf/die.o
[1997/17378] CXX obj/sandbox/linux/seccomp_bpf/sandbox_bpf.o
[1998/17378] CXX obj/sandbox/linux/sandbox_services/broker_channel.o
[1999/17378] CXX obj/services/service_manager/public/interfaces/constants_shared_cpp_sources/constants.mojom-shared.o
[2000/17378] CXX obj/services/file/public/interfaces/constants/constants.mojom.o
[2001/17378] CXX obj/ppapi/thunk/thunk/ppb_audio_thunk.o
[2002/17378] CXX obj/device/serial/serial_mojo_shared_cpp_sources/serial.mojom-shared.o
building of '/nix/store/pwq8dpxp76ka2jri87bdhn2hclq3l5q7-qtwebengine-5.10.1.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/2v7b9nm7q4x66z8zqizcf7fzvb0840pc-seafile-client-6.1.5.drv': 1 dependencies couldn't be built
error: build of '/nix/store/2v7b9nm7q4x66z8zqizcf7fzvb0840pc-seafile-client-6.1.5.drv' failed

Failure on aarch64-linux (full log)
Partial log (click to expand)
[4356/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4357/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_partial_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4358/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_partial_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4359/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_partial_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4360/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_partial_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4361/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_partial_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
[4362/17378] ACTION //third_party/WebKit/Source/bindings/modules/v8:generate_bindings_modules_v8_interfaces(/build/qtwebengine-everywhere-src-5.10.1/src/toolchain:target)
building of '/nix/store/pwq8dpxp76ka2jri87bdhn2hclq3l5q7-qtwebengine-5.10.1.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/2v7b9nm7q4x66z8zqizcf7fzvb0840pc-seafile-client-6.1.5.drv': 1 dependencies couldn't be built
error: build of '/nix/store/2v7b9nm7q4x66z8zqizcf7fzvb0840pc-seafile-client-6.1.5.drv' failed

@ryantm @dotlambda Sorry, I don't use these packages (or NixOS) at the moment, I just haven't had the time to send a PR to be removed as a contact point.


WinRT support

As of commit 3f84910, any attempt to build sdl2-compat for WinRT fails
because of unsupported calls to MessageBoxA, lstrcpyA and wsprintfA, and
possibly LoadLibraryA.

Originally posted by @sezero in https://github.com/libsdl-org/sdl2-compat/issues/40#issuecomment-1422518698
This might not be super-important, but just so this isn't lost, I'm tossing this into a separate bug.

The lstrcpyA and wsprintfA dependencies are easily overcome by
a local stpcpy() and itoa() implementation, and since those two are
universal and standalone they work for everything: Patch below, OK
to apply?
diff --git a/src/sdl2_compat.c b/src/sdl2_compat.c
index f8b7d24..e3e843d 100644
--- a/src/sdl2_compat.c
+++ b/src/sdl2_compat.c
@@ -146,6 +146,41 @@ static SDL_bool WantDebugLogging = SDL_FALSE;
 static Uint32 LinkedSDL3VersionInt = 0;

+static char *
+SDL2COMPAT_stpcpy(char *dst, const char *src)
+{
+    while ((*dst++ = *src++) != '\0') {
+        /**/;
+    }
+    return --dst;
+}
+
+static void
+SDL2COMPAT_itoa(char *dst, int val)
+{
+    char *ptr, temp;
+
+    if (val < 0) {
+        *dst++ = '-';
+        val = -val;
+    }
+    ptr = dst;
+
+    do {
+        *ptr++ = '0' + (val % 10);
+        val /= 10;
+    } while (val > 0);
+    *ptr-- = '\0';
+
+    /* correct the order of digits */
+    do {
+        temp = *dst;
+        *dst++ = *ptr;
+        *ptr-- = temp;
+    } while (ptr > dst);
+}
+
+
 /* Obviously we can't use SDL_LoadObject() to load SDL3.  :)  */
 /* FIXME: Updated library names after https://github.com/libsdl-org/SDL/issues/5626 solidifies.  */
 static char loaderror[256];
@@ -156,16 +191,12 @@ static char loaderror[256];
     #define LoadSDL3Library() ((Loaded_SDL3 = LoadLibraryA(SDL3_LIBNAME)) != NULL)
     #define LookupSDL3Sym(sym) (void *)GetProcAddress(Loaded_SDL3, sym)
     #define CloseSDL3Library() { if (Loaded_SDL3) { FreeLibrary(Loaded_SDL3); Loaded_SDL3 = NULL; } }
-    #define strcpy_fn  lstrcpyA
-    #define sprintf_fn wsprintfA
 #elif defined(__APPLE__)
     #include <dlfcn.h>
     #include <pwd.h>
     #include <unistd.h>
     #define SDL3_LIBNAME "libSDL3.dylib"
     #define SDL3_FRAMEWORK "SDL3.framework/Versions/A/SDL3"
-    #define strcpy_fn  strcpy
-    #define sprintf_fn sprintf
     static void *Loaded_SDL3 = NULL;
     #define LookupSDL3Sym(sym) dlsym(Loaded_SDL3, sym)
     #define CloseSDL3Library() { if (Loaded_SDL3) { dlclose(Loaded_SDL3); Loaded_SDL3 = NULL; } }
@@ -218,8 +249,6 @@ static char loaderror[256];
     #define LoadSDL3Library() ((Loaded_SDL3 = dlopen(SDL3_LIBNAME, RTLD_LOCAL|RTLD_NOW)) != NULL)
     #define LookupSDL3Sym(sym) dlsym(Loaded_SDL3, sym)
     #define CloseSDL3Library() { if (Loaded_SDL3) { dlclose(Loaded_SDL3); Loaded_SDL3 = NULL; } }
-    #define strcpy_fn  strcpy
-    #define sprintf_fn sprintf
 #else
     #error Please define your platform.
 #endif
@@ -243,7 +272,8 @@ LoadSDL3Symbol(const char *fn, int *okay)
     if (*okay) { /* only bother trying if we haven't previously failed. */
         retval = LookupSDL3Sym(fn);
         if (retval == NULL) {
-            sprintf_fn(loaderror, "%s missing in SDL3 library.", fn);
+            char *p = SDL2COMPAT_stpcpy(loaderror, fn);
+            SDL2COMPAT_stpcpy(p, " missing in SDL3 library.");
             *okay = 0;
         }
     }
@@ -484,7 +514,7 @@ LoadSDL3(void)

         okay = LoadSDL3Library();
         if (!okay) {
-            strcpy_fn(loaderror, "Failed loading SDL3 library.");
+            SDL2COMPAT_stpcpy(loaderror, "Failed loading SDL3 library.");
         } else {
             #define SDL3_SYM(rc,fn,params,args,ret) SDL3_##fn = (SDL3_##fn##_t) LoadSDL3Symbol("SDL_" #fn, &okay);
             #include "sdl3_syms.h"
@@ -494,7 +524,19 @@ LoadSDL3(void)
                 LinkedSDL3VersionInt = SDL_VERSIONNUM(v.major, v.minor, v.patch);
                 okay = (LinkedSDL3VersionInt >= SDL3_REQUIRED_VER);
                 if (!okay) {
-                    sprintf_fn(loaderror, "SDL3 %d.%d.%d library is too old.", v.major, v.minor, v.patch);
+                    char value[12];
+                    char *p = SDL2COMPAT_stpcpy(loaderror, "SDL3 ");
+
+                    SDL2COMPAT_itoa(value, v.major);
+                    p = SDL2COMPAT_stpcpy(p, value);
+                    *p++ = '.';
+                    SDL2COMPAT_itoa(value, v.minor);
+                    p = SDL2COMPAT_stpcpy(p, value);
+                    *p++ = '.';
+                    SDL2COMPAT_itoa(value, v.patch);
+                    p = SDL2COMPAT_stpcpy(p, value);
+
+                    SDL2COMPAT_stpcpy(p, " library is too old.");
                 } else {
                     WantDebugLogging = SDL2Compat_GetHintBoolean("SDL2COMPAT_DEBUG_LOGGING", SDL_FALSE);
                     if (WantDebugLogging) {
@@ -1070,7 +1112,7 @@ SDL2Compat_InitOnStartup(void)
     return 1;

 fail:
-    strcpy_fn(loaderror, "Failed to initialize sdl2-compat library.");
+    SDL2COMPAT_stpcpy(loaderror, "Failed to initialize sdl2-compat library.");

     if (EventWatchListMutex) {
         SDL3_DestroyMutex(EventWatchListMutex);

If the above patch is applied, MessageBoxA() seems to be the only
problematic call: SDL has a winrt implementation in C++, but I have
no experience with that.

Yep, seems fine to me.

Yep, seems fine to me.

Applied. (And it applies almost without any changes to sdl1.2-compat too: Should I?)
Now MessageBoxA, and possibly LoadLibraryA, seem to be the only problematic
calls in sdl2-compat.

Applied. (And it applies almost without any changes to sdl1.2-compat too: Should I?)

Sure, seems fine.

For now, let's just change LoadLibraryA to LoadLibraryW and SDL3_LIBNAME to L"SDL3.dll" ... this should work out of the box on everything back to Windows XP anyhow.
For MessageBoxA, we can't use SDL_iconv because we only call this when SDL3 failed to load, but we completely control the error string afaict and it's all low-ASCII, so we could just do something like this:
static void error_dialog(const char *errorMsg)
{
    WCHAR werrmsg[256];
    int i;
    for (i = 0; (i < (SDL_arraysize(werrmsg) - 1)) && errorMsg[i]; i++) {
        werrmsg[i] = (WCHAR) errorMsg[i]; /* low-ASCII maps to WCHAR directly. */
     }
    werrmsg[i] = '\0';

    MessageBoxW(NULL, werrmsg, L"Error", MB_OK | MB_SETFOREGROUND | MB_ICONSTOP);
}

Again, this code will presumably work on both Win32 back to Windows XP and WinRT.
Then we need to actually test this on WinRT in any case.

Yep!

Both MessageBoxW and LoadLibraryW are documented to be "destop apps only", so I can't see how that would help.

Maybe something like this? (Disclaimer: Not even compile tested, I don't do winrt or c++ and the cmake'ry is possibly bullsh?t: @icculus and @madebr to rescue.)
test.zip

Both MessageBoxW and LoadLibraryW are documented to be "destop apps only", so I can't see how that would help.

Huh, I didn't realize that.  :/
LoadPackagedLibrary() is apparently the correct way to do this from UWP, but it has limitations (but I assume UWP developers will be shipping sdl2-compat and SDL3.dll packaged with their app anyhow, so I think it'll work out?).
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-loadpackagedlibrary?redirectedfrom=MSDN

Maybe something like this?

I think yes, but we probably need someone to take the time to compile testsprite2 for UWP and see what the state of all of this is.
Until then, I don't think it hurts to get it in revision control as-is, since we know the it's 100% broken until we do something to fix it.

Maybe something like this?

I think yes, but we probably need someone to take the time to compile testsprite2 for UWP and see what the state of all of this is.
Until then, I don't think it hurts to get it in revision control as-is, since we know the current code is 100% broken until we do something to fix it.

You mean push it to git as is for now?
P.S.: Is the winrt code not doable in C-only?

Yeah, push it to git. It's a starting point if someone comes along to finish it (or we find time to do so).
A lot of the Win32 API is available from C on WinRT, but when Microsoft decided to cut parts out, the replacements are all C++ (or whatever variant of C++ it uses..."C++/CX" or something...?). It's annoying.
My guess is that message boxes got replaced because they wanted to offer a real async API instead of MessageBoxA(), which blocks and runs the Windows event queue internally...so we're stuck with C++ for that.

OK, pushed to git main.

With these 2 patches (cmake + ci), I can get SDL2-compat compiling, but not linking.
The linking errors disappear when I remove the _DllMainCRTStartup function, but that's no good.
These are the linking errors.

With these 2 patches (cmake + ci), I can get SDL2-compat compiling, but not linking.

Those changes should be good I guess and can go in

The linking errors disappear when I remove the _DllMainCRTStartup function, but that's no good.

Without _DllMainCRTStartup I don't know how we can do the dlopen magic..

I got it linking, and running with this additional patch.
I can now start testviewport, but SDL_Init fails here.

I know you aren't supposed to do LoadLibraryA in DllMain, but this works...

Are you doing LoadLibraryA in your patch? Or am I looking at the wrong place?

Also, when the app can't find SDL3.dll, it hangs rather then showing a error dialog.

The error dialog procedure is not tested - it's just copied from SDL2 with some butchering.
@icculus or @slouken may help

I can now start testviewport, but SDL_Init fails here.

We aren't building SDL_main, that may be the reason?

I know you aren't supposed to do LoadLibraryA in DllMain, but this works...

Are you doing LoadLibraryA in your patch? Or am I looking at the wrong place?

sdl2-compat uses LoadLibraryA/LoadPackagedLibrary to load SDL3.dll.

The error dialog procedure is not tested - it's just copied from SDL2 with some butchering. @icculus or @slouken may help
We aren't building SDL_main, that may be the reason?

I copied SDL2's SDL2main, but it needs extra care to be compatible with SDL3. It fails here.

I know you aren't supposed to do LoadLibraryA in DllMain, but this works...

Are you doing LoadLibraryA in your patch? Or am I looking at the wrong place?

sdl2-compat uses LoadLibraryA/LoadPackagedLibrary to load SDL3.dll.

Ah, I misread the meaning.
Other than calling LoadPackagedLibrary from DllMain, one can use a function marked as constructor like gcc does, but I don't know how / if that is done with MSVC.

Other than calling LoadPackagedLibrary from DllMain, one can use a function marked as constructor like gcc does, but I don't know how / if that is done with MSVC.

This alternative MSVC-only way has the same behavior (currently).
It uses CRT initialization.
I don't know of a destructor equivalent.
--- a/src/sdl2_compat.c
+++ b/src/sdl2_compat.c
@@ -668,7 +668,7 @@ __declspec(selectany) int _fltused = 1;
 #define _DllMainCRTStartup LibMain
 #endif
 #if defined(__WINRT__)
-#define _DllMainCRTStartup DllMain
+#define _DllMainCRTStartup SDL2compat_DllMain
 #endif
 BOOL WINAPI _DllMainCRTStartup(HANDLE dllhandle, DWORD reason, LPVOID reserved)
 {
@@ -706,6 +706,14 @@ BOOL WINAPI _DllMainCRTStartup(HANDLE dllhandle, DWORD reason, LPVOID reserved)
     return TRUE;
 }

+#if defined(__WINRT__)
+#pragma section(".CRT$XCZ", read)
+static void __cdecl sdl2compat_entry(void) {
+    SDL2compat_DllMain(NULL, DLL_PROCESS_ATTACH, NULL);
+}
+__declspec(dllexport) __declspec(allocate(".CRT$XCZ")) void(__cdecl* sdl2compat_entry_crt)(void) = sdl2compat_entry;
+#endif
+
 #else
     #error Please define an init procedure for your platform.
 #endif

Other than calling LoadPackagedLibrary from DllMain, one can use a function marked as constructor like gcc does, but I don't know how / if that is done with MSVC.

This alternative MSVC-only way has the same behavior (currently). It uses CRT initialization. I don't know of a destructor equivalent.

Not good without a destructor equivalent as far as I can see.

Other than calling LoadPackagedLibrary from DllMain, one can use a function marked as constructor like gcc does, but I don't know how / if that is done with MSVC.

This alternative MSVC-only way has the same behavior (currently). It uses CRT initialization. I don't know of a destructor equivalent.

Not good without a destructor equivalent as far as I can see.

If LoadLibrary in DllMain turns out problematic, we might combine the CRT initialization for doing LoadLibrary and initialization with DllMain for doing the clean up.
But plugging in the CRT initialization is probably a bad idea anyways. WinRT uses c++, and the STL might not have been completely initialized.

If LoadLibrary in DllMain

That wisdom is not restricted to winrt, is it not? We've been using that
for 'normal' windows for some time. Let's leave that discussion for later
unless it truly bites us.

SDL3 killed winrt/uwp, therefore this ticket is now stale. Closing.


[ALLUXIO-3114] Better attempt to return block locations for blocks not in Alluxio workers

https://alluxio.atlassian.net/browse/ALLUXIO-3114
Applications like Impala requires block locations to be non-empty for data load to work. Currently Impala could not read from Alluxio Hadoop client when data is not preloaded:

For files in HDFS under file system, Alluxio returns HDFS block location hostnames for BlockLocation::getNames(), but Impala requires two part name:port format which is indicated in javadoc of the method.

For files in non-HDFS or remote HDFS under file system, Alluxio returns no BlockLocation, this is making Impala skip reading of the file all together.

This change updated the client to return full two-part locations for UFS locations if there is an Alluxio worker co-located. If no worker is colocated with the UFS block location, it will fallback to return all the worker hosts so that applications can just pick from one location to read from.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18704/
Test PASSed.

@gpang @calvinjia This change will fix Impala for reading blocks only in UFS locations. PTAL.

I did some manual testing with Impala. I am looking into writing some tests for the logic.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18715/Build result: FAILURE[...truncated 3005 lines...][JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.7.1-SNAPSHOT/alluxio-core-common-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.7.1-SNAPSHOT/alluxio-core-common-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.7.1-SNAPSHOT/alluxio-core-common-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-common/1.7.1-SNAPSHOT/alluxio-core-common-1.7.1-SNAPSHOT-tests.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-worker/1.7.1-SNAPSHOT/alluxio-core-server-worker-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-worker/1.7.1-SNAPSHOT/alluxio-core-server-worker-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-worker/1.7.1-SNAPSHOT/alluxio-core-server-worker-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-logserver/1.7.1-SNAPSHOT/alluxio-logserver-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-logserver/1.7.1-SNAPSHOT/alluxio-logserver-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-logserver/1.7.1-SNAPSHOT/alluxio-logserver-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-client/1.7.1-SNAPSHOT/alluxio-core-client-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-examples/1.7.1-SNAPSHOT/alluxio-examples-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-examples/1.7.1-SNAPSHOT/alluxio-examples-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-examples/1.7.1-SNAPSHOT/alluxio-examples-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core/1.7.1-SNAPSHOT/alluxio-core-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-proxy/1.7.1-SNAPSHOT/alluxio-core-server-proxy-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-proxy/1.7.1-SNAPSHOT/alluxio-core-server-proxy-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-core-server-proxy/1.7.1-SNAPSHOT/alluxio-core-server-proxy-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-shell/1.7.1-SNAPSHOT/alluxio-shell-1.7.1-SNAPSHOT.pom[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-shell/1.7.1-SNAPSHOT/alluxio-shell-1.7.1-SNAPSHOT.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-shell/1.7.1-SNAPSHOT/alluxio-shell-1.7.1-SNAPSHOT-sources.jar[JENKINS] Archiving<EMAIL_ADDRESS>to org.alluxio/alluxio-tests/1.7.1-SNAPSHOT/alluxio-tests-1.7.1-SNAPSHOT.pomchannel stoppedArchiving artifacts
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18727/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18728/
Test PASSed.

@gpang I added the logic to shuffle the block locations. PTAL.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/18753/
Test PASSed.


Attempt to improve design tools performance

The code is a mess. And there may be some unnecessary optimizations. But the result is great! 😆

@diegohaz In other words... we'll built our own Redux! With context and pubsubs! 😂

@diegohaz Thank you so much for investigating this! I'll poke around some more tomorrow!! <3


Add note to Domain-Specific Languages

Given that this specific lecture was not present in the schedule of this year, it would be nice to add a note to https://tudelft-in4303-2016.github.io/lectures/introduction/domain-specific-languages.html stating that it is not required for the exam of this year.

I'd warmly welcome a PR that fixes this. Adding {: .notice .notice-warning} below a paragraph turns it into a note.


Editing file in Atom unfolds previously folded branches

This is another suggestion. I have got huge mindmap, like 1000x elements, 7 levels of nesting. At a time I explore / edit only subset of the map, trying to keep irrelevant branches closed for easy of navigation. However, when I add new items to the map, all branches are unfolded again, and it becomes not usable again. Folding all unnecessary branch again is even more inconvenient.

I confirm this is an inconvenient behavior. Since the changes come through markdown text there is no straightforward way to map the changes to data structure changes. We would have to implement some kind of tree diffing. Hopefully I will come up with a simple enough solution, but I can't promise anything.

This is now fixed in the latest version (0.6.0).


Windows 10 Universal Windows Platform (UWP) - Feedback

At present the UWP SDK does not allow us to use the Feedback option as is the case with other platforms. What are the plans of including this, or what other options are available?
I am reading this, and it seems that this is the recommended path suggested by Microsoft. https://docs.microsoft.com/en-us/windows/uwp/monetize/launch-feedback-hub-from-your-app
Any opinions?

@mieliespoor Thanks for using HockeyApp. Our team is working on App Center which is the next generation of HockeyApp. We don't plan to wok on supporting Feedback service in HockeyApp UWP SDK.
Please let us know if you have any questions.

Great thanks. I somehow missed the announcement on AppCenter. I will be investing more in that going forward.


Fix #609, Remove CFE_PLATFORM_EVS_LOG_ON undefined option to diasble log

Describe the contribution
Fix #609 - removes the ability to disable the log by not defining CFE_PLATFORM_EVS_LOG_ON
Testing performed
Build and run unit tests, passed
Expected behavior changes
No longer able to disable log completely, for minimum memory use define CFE_PLATFORM_EVS_LOG_MAX as 1
System(s) tested on

Hardware: cFS Dev Server
OS: Ubuntu 18.04
Versions: Bundle main + this commit

Additional context
Could remove control based on LogEnabled, panic on reset area fail and limp along if sem create fails.
Needs requirements updates - #1131
Third party code
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

CCB:2021-01-27 APPROVED

Option to reduce memory footprint is to set max = 1
Keep it simple. Having cFE do this is extra complexity that might not be necessary. Let PSP work with this.

CCB:2021-01-27 APPROVED

Option to reduce memory footprint is to set max = 1
Keep it simple. Having cFE do this is extra complexity that might not be necessary. Let PSP work with this.

Need to remove control based on HK parameter before merge (will submit as an additional HOTFIX merge, or fasttrack?)

Need to remove control based on HK parameter before merge (will submit as an additional HOTFIX merge, or fasttrack?)

@skliper this is in draft form, can I change this to ready?

@astrogeco Good to go, opened #1153 to address the CCB actions.

@astrogeco Good to go, opened #1153 to address the CCB actions.

Should we address the requirements issue #1131 before merging this though?

@astrogeco Good to go, opened #1153 to address the CCB actions.

Should we address the requirements issue #1131 before merging this though?

Nvm, clicked merge too soon :P


History of Elemental Blocks is not reflected correctly on the history of a Page

When changes are saved or published within elemental blocks then these changes are not reflected on the history of a Page. Instead, it takes the most recent record and updates its “Block History” where the correct changes are shown:

The issue here is that changes made within a content block are not immediately visible to the user when the history of a page is viewed which could lead to the impression that no changes have taken place.
Users have to take an additional step by clicking on the “Block History” of a block to view the accurate set of changes.
Prior to clicking on the “Block History” the state that is shown on the history of a page shows an outdated version of the block which could lead to further miscues. Ideally, the state that is shown on the page level should at least reflect the most recent state of the block.
It would be handy if the "Block History" was integrated into the "Page History" using a single view instead of having these two entities as separate views that can lead to misleading history reviews for content editors.

CMS: 4.12.1
Framework: 4.12.4
Elemental: 4.10.2
Steps to reproduce:

In the CMS, create a page
Make changes to the Content of the page and hit Save
Go to the "History" tab and check that a new record is created for the latest changes
Go back to the main tab of the page, create a new content block and save the content block
Go to the "History" tab and see that no new record is created to reflect the creation of the content block
Make changes to the content block and hit save
Go back to the "History" tab and see that no new record is created from the changes made to the content block

Maybe the silverstripe/versioned-snapshot-admin module might be able to help here?

Is there an ETA on this bug / issue being worked on?
Our client has reported inconsistent behavior for Block history and would like to resolve it asap.


fix UI elements for login dialog

Signed-off-by: Mohit Suman<EMAIL_ADDRESS>

@mohitsuman most of those changes have been included already, or are no longer relevant. The only remaining difference is whether we still want to switch from filled inputs:

to outlined

Which actually doesn't look that good because of the misaligned header (similar to https://github.com/docker/extensions-sdk/issues/175#issue-1235625867)
@mohitsuman so, WDYT?

This is known issue #175

The alignment fix is available in @docker/docker-mui-theme 0.0.7:

@mohitsuman is this something you want us to apply now?

@fbricon yes let's get this fix in the extension. I think the change looks good and better than the grey background and overlapping text.

Fixed in https://github.com/redhat-developer/openshift-dd-ext/commit/282cb7bb2c771f5932902b26261d4a2e10272188
See


Injected Text Debt

[x] #127410
[x] #127411
[x] #127412

Closing this since all subitems have their own issue and there is a PR for each individual issue.


add ability to turn off buffer pooling

Working on a P2P messaging bug. Adding ability to turn off pooling of ByteBuffers by setting new system property: -Dgeode.byte.buffer.pool.strategy=none
I haven't fully tested the system property switch yet, so for now (11/3/2021) this PR unconditionally uses a no-op buffer pool. To make it unconditional:

[ ] figure out how to pass along system property from test invocation to DUnit VM invocations in P2PMessagingConcurrencyDUnitTest
[ ] uncomment geode.byte.buffer.pool.strategy system property handling logic
[ ] run P2PMessagingConcurrencyDUnitTest with -Dgeode.byte.buffer.pool.strategy=none and verify the no-op BufferPoolNoOp is used (and the test passes)

For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Had a failure in upgrade test: https://concourse.apachegeode-ci.info/builds/6265749
re-triggered…

this PR appears to be abandoned, can it be closed?

Closing this out due to age.