Pressure sensor fault and no lightning data

Had a small storm pass overnight and this morning found two things.  First is that weatherflow2MQTT restarted a couple of times, both apparently due to a pressure sensor fault.  This was followed by an error that "Pressure value was reported as NoneType" (see log screenshot below for details)

Second is that weatherflow2MQTT did not record any lighting data, while both smartweather (REST api) and the app recorded several events.  Could be that I have an issue on the Tempest device.  I do get many "Lightning Disturber" events through the UDP interface.  I know that WeatherFlow does do some processing and perhaps what I am seeing is info collected from other devices, but I thought the the REST api included the raw lightning data.  Anyway, would appreciate information regarding the Lightning Disturber events, and perhaps confirmation that others are not having issues.
Thanks

What firmware do you have on the Tempest head? I did read on the Weatherflow forums that early firmware wasn't reporting lightning over UDP - It was the case for me when I was on v134.
I put in a request to get my firmware updated due to spikes in luminescence/solar radiation, and I'm on v156 now... and waiting for a storm to see if I get lightning events on UDP.
Cheers
Simon

I am on V156 also, and just had lightning yesterday, which recorded as expected. The way I count it is that I add one to a variable every time the Lightning Strike Event [type = evt_strike] occurs, and that should be the most accurate way of doing this.
For the pressure error, I will put in some checks to ensure that we have the needed values before the calculations are done. This is just a timing issue, so you might see None or Unknown until we have all the data collected.

Just released 2.0.5, which should fix the Pressure Trend crashing the system.

That station is on v150.  I saw that in the forum, but assumed I was far enough past that version that it should be ok; who knows, didn't run across release notes.
Anyway, thanks for the fix and confirmation.  I will contact support.

Just had a chat with support.  They say that the strikes are being recorded on the local station.  I asked again to confirm that it wasn't their crowd-sourced AI stuff.  So the mystery deepens a bit.  Unfortunately I didn't have any debugging turned on and was not logging any of the traffic.  Worst is that the further we get into summer here, the less likely I get any lightning to test with.  Any thoughts?

BTW, I am requesting a push of v156 so we can rule that out.

I will go through the code tomorrow, to see if there can be a situation where I will not pick-up the strikes, but as said, it works for me.

I do have a lot of "Lightning Disturber" faults reported, could that be related?  They only happen when there is actual lightning activity, I have not seen any at other times that might indicate some EMI.

Now that you mention it: When I had Lightning occur here, two days ago, I noticed that I did not get any strike events for a little while, but instead got the above in my log also. But then it stopped reporting the error, and instead started to count strikes. So there might be a correlation. I believe it is a HW thing, and not with this program.

I think you are correct on that.  My guess, from reading through the community posts on the subject (and there are a lot of them) is that lightning must be very dependent on local conditions.  So some of the "screws" on the sensitivity settings are a bit too tight, and some too loose.  The AI must not yet be able to automatically do the calibration, or they just don't trust it enough to let it do so.  And/or there just may not be enough data points yet.  Unlike pressure or temperature, they just aren't frequent enough.
Of course, it could just be a bad unit/sensor.
They are very responsive, so hopefully they can get my fixed up.  There may be more to learn about how best to interpret the data that they do send, so will certainly let you know how it goes.  Very innovative approach, they are still learning as well.

I had the exact opposite problem, as you may have read in the forum.  I was getting several thousand strikes recorded a day but there was no lightning in reality for a thousand miles.

They just updated my station to v156.  They said it would fix my issue, so perhaps there is/was a known issue with the UDP lightning event.  Just need a little thunderstorm to test now.

Just need a little thunderstorm to test now.

Be carefull what you wish for, you might get it 😀
Sounds good. I will close this now, and if any of you find new issues with lightning, just create a new issue.


Improve Globus transfer concurrency

With --non-blocking option, zstash submits a Globus transfer and immediately creates a subsequent tarball. Zstash does not wait until the transfer completes to start creating a subsequent tarball. On machines where zstash tarballs are created faster than they are transferred to a remote endpoint, zstash will create multiple Globus transfers that are put in a queue by the Globus service. Zstash should submit transfers to transfer as many zstash tarballs as have been created at the moment. On machines where it takes more time to create a tarball than transfer it, each Globus transfer will have one file. On machines where it takes less time to create a tarball than transfer it, the first transfer will have one file, but the number of tarballs in subsequent transfers will grow finding dynamically the most optimal number of tarballs per transfer.

Resolved by #214.


Rewrite product filters

I want to merge this change because it fixes product filters.
Resolves #123
Pull Request Checklist

[x] All visible strings are translated with proper context.
[x] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] The changes are tested.
[ ] The code is documented (docstrings, project documentation).

Some issues I found:

[ ] price range doesn't seem to work properly: URL is changing but there is no API call
[ ] new results aren't always returned after changing a search term on a search page
[ ] user is not able to change price filter inputs after it has been applied
[ ] there are some errors in console on search and products list pages


Loading Mistral model.

I attempted to load the Mistral Open Orca model, but I couldn't, so I changed the code a little, but now I receive an answer if I ask the same query again, so the first time it gives no answer, and the second time it responds, maybe from the cache. This is all new to me.
Please let me know if there is a method to import the "mistral-7b-openorca.Q4_K_M.gguf" model without editing.
My edit:
def build_llm(model):
    # Call the function to get the number of threads to use
    num_threads = determine_threads_to_use()
    print(f"Number of Threads avaialble : {num_threads}")

    llm = LlamaCpp(
        model_path=cfg.MODEL_BIN_DIR + "/" + model,
        n_gpu_layers=num_threads,
        # f16_kv=True,
        n_batch=8192 / 4,
        n_ctx=8192,
        max_tokens=cfg.MAX_NEW_TOKENS,
        n_threads=num_threads,
        temperature=cfg.TEMPERATURE,
        streaming=True,
        repeat_penalty= 1.3,
        callbacks=[StreamingStdOutCallbackHandler()],
    )

    # Local CTransformers model
    # llm = CTransformers(
    #     model=cfg.MODEL_BIN_DIR + "/" + model,
    #     model_type="llama",
    #     config={
    #         "max_new_tokens": cfg.MAX_NEW_TOKENS,
    #         "temperature": cfg.TEMPERATURE,
    #         "threads": num_threads,
    #         "stream": True,
    #         "repetition_penalty": 1.3,
    #     },
    #     callbacks=[StreamingStdOutCallbackHandler()],
    # )

    return llm

If I use the default code, the error is:
RuntimeError: Failed to create LLM 'llama' from 'models/mistral-7b-openorca.Q4_K_M.gguf'.
No matter what model type I change.

Apologies, Just saw your issue.
Tested: mistral-7b-openorca.Q4_K_M.gguf
Just had to update one package.
ctransformers Now Support GGUF format support for Llama and Falcon models.

Try with latest code :)


Screen tearing on Mac with vsync

Environment

LWJGL version: 3.2.4-SNAPSHOT
LWJGL build #: 20190903.201424-1
Java version: 12.0.2
Platform: macOS 10.14.6
Module: not sure

Description
OpenGL windows on my Mac have screen tearing near the bottom of the screen, even with vsync on. It looks like this is a regression starting with 3.2.2. When I use version 3.2.1, the problem isn't there. Also, the problem isn't there on Windows with the latest LWJGL version.
Example that shows the problem based on the SimpleDrawElements demo from lwjgl3-demos.
When I run this example on 3.2.2 or newer, the screen tearing starts after a few seconds (before this, the animation is slow but doesn't tear). The screen tearing is only there when the window is near the bottom of the screen.
Using 3.2.1, the animation is always fast and smooth (no screen tearing).

Hey @marshallsa,
GLFW 3.3 has switched to CVDisplayLink synchronization because vsync was broken in macOS 10.14. It is a known issue that this causes screen tearing. The glfw build in LWJGL will be updated immediately when a fix is available.

I do agree that this is an issue in GLFW but something is weird here.
I'm experiencing screen tearing with LWJGL version 3.2.3 and 3.2.4-SNAPSHOT as well. There is none with 3.2.1. However, I'm on macOS 10.15 Catalina.
So far, the explanation that this is GLFW 3.3 related totally makes sense.
However, when I build GLFW 3.3 from source using the command line tools that come with Xcode 10.3, I don't see any tearing when I run the tearing example of GLFW tearing.c. Everything is super smooth when setting the swap interval to 1 by using the cursor up key when running their example.
Then I just did a quick port of the tearing.c example to LWJGL Tearing.java and it does show tearing when I run it with LWJGL 3.2.2+ and with swap interval set to 1. There is no tearing in this example in Java when using LWJGL 3.2.1.
So now I'm a bit puzzled 😕
What's the difference between GLFW 3.3 build from source by myself and the one included in LWJGL 3.2.3? 😳

What's the difference between GLFW 3.3 build from source by myself and the one included in LWJGL 3.2.3?

See LWJGL-CI/glfw. The LWJGL build uses -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9, but I'm not sure how that would explain the difference (CVDisplayLink is supported on 10.4+).

I quickly build GLFW the way LWJGL-CL does it (I had to leave out -DGLFW_BUILD_TESTS=OFF so that it builds the tearing test though):
rm -rf *
cmake -DBUILD_SHARED_LIBS=ON -DGLFW_BUILD_EXAMPLES=OFF \
-DGLFW_BUILD_DOCS=OFF -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.9 ../glfw
cmake --build .
strip -u -r src/libglfw.dylib

open tests/tearing.app/

but didn't see any difference. Still no tearing. Still weird. I tried the GLFW 3.3 and master branch.
The only other difference I see is the osx_image: xcode11.1 which is different from my 10.3.
I'll try it with Xcode 11.1 next ... when the download finishes someday :wink:

I have successesfully build GLFW with Xcode 11.1 and still cannot reproduce any screen tearing with the original GLFW tearing.c test (macOS 10.15 Catalina on a 13 Inch 2016 Macbook Pro). I even tried slowing the tearing test down by rendering the white bar a couple hundred times but nothing. No tearing at all.
At least for my current macOS + hardware configuration I cannot confirm screen tearing using GLFW 3.3.
However, I still get the screen tearing when using the current LWJGL version using my Tearing.java which I've updated to be even closer to the original tearing.c. Additionally, I even built LWJGL from source and used the libglfw.dylib that I've build locally. Still, the tearing remains.
I'm still puzzled about that. There seems to be some weird interaction between Java, LWJGL and the CVDisplayLink synchronization going on that I'm not able to pinpoint.

Stop!
On Thu, 31 Oct 2019 at 8:41 AM void256<EMAIL_ADDRESS>wrote:

I have successesfully build GLFW with Xcode 11.1 and still cannot
reproduce any screen tearing with the original GLFW tearing.c test (macOS
10.15 Catalina on a 13 Inch 2016 Macbook Pro). I even tried slowing the
tearing test down by rendering the white bar a couple hundred times but
nothing. No tearing at all.
At least for my current macOS + hardware configuration I cannot confirm
screen tearing using GLFW 3.3.
However, I still get the screen tearing when using the current LWJGL
version using my Tearing.java
https://gist.github.com/void256/dde7ab8b3019e65d2dfae3a4e11bc51e which
I've updated to be even closer to the original tearing.c. Additionally, I
even built LWJGL from source and used the libglfw.dylib that I've build
locally. Still, the tearing remains.
I'm still puzzled about that. There seems to be some weird interaction
between Java, LWJGL and the CVDisplayLink synchronization going on that I'm
not able to pinpoint.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LWJGL/lwjgl3/issues/503?email_source=notifications&email_token=ALTHS6ICW4WYZPD7PCEKSQ3QRJVXTA5CNFSM4IW4ZQQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWT4RA#issuecomment-548224580,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALTHS6MER3FA6TT2FPWCYN3QRJVXTANCNFSM4IW4ZQQA
.

Reproduced. Not only is there tearing in the Java port, the frame rate is roughly half of the native version. Even if I remove everything from the render loop except glfwSwapBuffers. Do you see this too?

Quick test: Change the native GLFW executable's name to java.exe and see whether it exhibits the same behaviour as the Java port. Wouldn't be the first time that a driver alters behaviour based on the executable's name...

@Spasi Yes, same here! The original tearing.c runs with about 1900 FPS while tearing.java runs with about 700 FPS and is way more unstable too (I see a lot of big changes in FPS while tearing.c is pretty steady). This is running with swap interval 0.
Additionally if I attach a secondary display things get even more strange: with the original tearing.c everything stays the same as expected: no tearing, the same FPS and if I drag the window to the external display I get twice the amount of FPS (approx. 3000). So far so good.
Doing the same with tearing.java has some unexpected results:

The FPS are now locked to about 60 FPS even with swap interval set to zero and setting swap interval to 1 is not changing anything.
I don't have tearing now! 😳
If I move the window around between screens and resize it then sometimes I see the tearing again but only for a short moment. Somehow it catches up and the tearing is gone again after a while.

Weird! 🎃
@httpdigest Renaming "tearing" to "java" did not change anything.

Since this is still annoying me - a lot actual :wink: I did more research.
I've used instruments time profiler to profile both, the tearing.c and the tearing.java and there are indeed a couple of differences:

While tearing.c utilizing constantly about 70% CPU in the Main Thread, tearing.java is using way less. If I check the Main Thread in detail it seems to do nothing for a couple of ms o_O while in tearing.c it is constantly busy.
When I take a closer look at stacktrace then in tearing.c NSCGLSurfaceFlush is called somewhere. This is not the case for tearing.java! It is calling gIdPresentFramebufferData but not NSCGLSurfaceFlush. I did confirm the latter using lldb with a breakpoint on NSCGLSurfaceFlush (tearing.c is stopping there, tearing.java is not)
I have a screenshot explaining this a little bit graphical:

I checked the pixel formats of both, tearing.c and tearing.java using OpenGL Profiler and they are identical. However, for tearing.c I see two OpenGLContexts listed under pixel formats in OpenGL Profiler - one without a pixel format and one with a pixel format. For tearing.java I only see one. That's a bit odd as well.
Maybe this is all a coincidence but somewhere ther has to be a difference that in the end makes Apple's graphic driver to change path somewhere.
What is visible in the stacktrace is, that the java version is using a CFRunLoop (not in the screenshot unfortunately) while tearing.c is using just the plain main method that is calling into GL.
Any macOS runtime or OpenGL Gurus listening that have any idea explaining the difference?

Ok, after spending quite some time with lldb I've finally figured this out 😎
It is actually a macOS + OpenJDK java executable issue:
This is not an issue with LWJGL and it is not an issue with GLFW. It is an issue with macOS (Catalina 10.15, probably already with Mojave 10.14) and the macOS version that the java executable is being build on (I only checked OpenJDK Java 12 which is build using High Sierra, 10.13 but suspect other Java versions are using the same version).
Reason:
Somewhere deep inside AppKit a NSView is being connected with a NSCGLSurface. This happens somewhere inside [NSOpenGLContext setView:]. According to some logic in there it's either NSOpenGLContextAttachOffScreenViewSurface or NSOpenGLContextAttachOnScreenViewSurface. Only the NSOpenGLContextAttachOffScreenViewSurface path leads to NSCGLSurfaceFlush being called later in glSwap_Exec (that is the good case as in tearing.c).
The method that seems to decide which way to go is something called _NSViewAllowsRootLayerBackingDefaultValueFunction and it looks like this (disassembled using hopper):
int _NSViewAllowsRootLayerBackingDefaultValueFunction(int arg0, int arg1) {
    rsi = arg1;
    rdi = arg0;
    if (*_NSViewLinkedOnLiberty.onceToken != 0xffffffffffffffff) {
            rdi = _NSViewLinkedOnLiberty.onceToken;
            rsi = ^ {/* block implemented at ___NSViewLinkedOnLiberty_block_invoke */ } };
            rax = dispatch_once(rdi, rsi);
    }
    if (*(int8_t *)_NSViewLinkedOnLiberty.isLinkedOnLiberty != 0x0) {
            rax = 0x1;
            rbp = stack[-8];
            rsp = rsp + 0x8;
    }
    else {
            if (_NSRequiresAquaSystemAppearance(rdi, rsi) != 0x0) {
                    rdi = @"com.autodesk.Maya.2016";
                    xmm0 = intrinsic_movsd(xmm0, *double_value_minus_1);
                    if (_CFAppVersionLessThan() == 0x0) {
                            rdi = @"com.autodesk.Maya.2016";
                            rdi = @"com.autodesk.Maya.2017";
                            xmm0 = intrinsic_movsd(xmm0, *double_value_minus_1);
                            if (_CFAppVersionLessThan() == 0x0) {
                                    rdi = @"com.autodesk.Maya.2017";
                                    rdi = @"com.autodesk.Maya.2018";
                                    xmm0 = intrinsic_movsd(xmm0, *double_value_minus_1);
                                    if (_CFAppVersionLessThan() == 0x0) {
                                            rdi = @"com.autodesk.Maya.2018";
                                            rdi = @"com.autodesk.Maya.2019";
                                            xmm0 = intrinsic_movsd(xmm0, *double_value_minus_1);
                                            rax = _CFAppVersionLessThan();
                                            rcx = 0x0;
                                            rax = rax != 0x0 ? 0x1 : 0x0;
                                            rbp = stack[-8];
                                            rsp = rsp + 0x8;
                                    }
                                    else {
                                            rax = 0x1;
                                            rbp = stack[-8];
                                            rsp = rsp + 0x8;
                                    }
                            }
                            else {
                                    rax = 0x1;
                                    rbp = stack[-8];
                                    rsp = rsp + 0x8;
                            }
                    }
                    else {
                            rax = 0x1;
                            rbp = stack[-8];
                            rsp = rsp + 0x8;
                    }
            }
            else {
                    rax = 0x1;
                    rbp = stack[-8];
                    rsp = rsp + 0x8;
            }
    }
    return rax;
}

Please note a couple of interesting things in here:

It first checks if the executable (!) isLinkedOnLiberty. According to Wikipedia this means "macOS Mojave 10.14 – Liberty".
The OpenJDK java 12 executable which I checked is linked with 10.13 since: otool -v -l /Library/Java/JavaVirtualMachines/jdk-12.0.2.jdk/Contents/Home/bin/java | grep sdk returns "sdk 10.13".
So when running with the java executable isLinkedOnLiberty returns 0 which makes the method continue.
Some NSRequiresAquaSystemAppearance default setting is checked and if this is not "No" (= 0x00) it checks for "com.autodesk.Maya." - kinda interesting that Maya is getting a work around ...
The end result is that in the java executable case we'll never return with 0x01 from this method and later end up with NSOpenGLContextAttachOnScreenViewSurface which will create slow performance and the tearing problems.

Workaround (maybe):
I've asked google about the NSRequiresAquaSystemAppearance and couldn't really find out what it means. However, it seems to have something to do with the Light and Dark MenuBar in macOS Mojave and how to use this setting as a workaround, f.i. this link: How to Use Light Theme with Dark Menu Bar and Dock in MacOS Mojave.
So what if we just force this to 0x00 using:
defaults write -g NSRequiresAquaSystemAppearance -bool No

and then run our tearing.java?
Yep, we'll get equal performance in FPS in the java port of tearing.c as in the original and the tearing is gone as well!
Tadda! 🎉 🎈 🍰
What I've tested:

defaults write -g NSRequiresAquaSystemAppearance -bool Yes -> tearing
defaults write -g NSRequiresAquaSystemAppearance -bool No -> no tearing
defaults delete -g NSRequiresAquaSystemAppearance -> tearing (this is probably the default value).

Real solution
Realistically speaking I'm not sure if that workaround really counts since I don't know what NSRequiresAquaSystemAppearance really does and if one really wants to set it to No. I'm not sure about side effects and so on.
So the actual real solution would be:

building the OpenJDK java executable with MacOS Mojave, 10.14 or higher or
if we find a way to embed the java executable into some 10.14+ build executable wrapper or
macOS is changing this again.

But this is not an LWJGL issue at all and I don't think it can be fixed or workaround in GLFW.

Just. Wow.
Can confirm that, by just recompiling the packr executable on 10.15 Catalina, screen tearing is gone on my MacBook Pro.

Great work @void256!
Have you tried with NSGL: Remove problematic swap interval workaround?

I did now and have build their "ci" branch. With this branch we're back at LWJGL 3.2.1 behaviour:
tearing.java:

glfwSwapInterval = 0: lots of tearing and half the fps of tearing.c (about 400 fps)
glfwSwapInterval = 1: no tearing and 60 fps
glfwSwapInterval = 2: no tearing and 60 fps

for comparision:
tearing.c:

glfwSwapInterval = 0: no tearing and about 800 fps
glfwSwapInterval = 1: no tearing and 60 fps
glfwSwapInterval = 2: no tearing and 60 fps (this really should be 30 and was with the CVDisplayLink patch applied as it is currently still the case in the master branch of GLFW)

Applying defaults write -g NSRequiresAquaSystemAppearance -bool No to the java executable I'll get the same behaviour as in tearing.c, about 800 fps and no tearing with glfwSwapInterval = 0.
So far everything is as I would expected it.
However, in general it seems that with the CVDisplayLink patch applied to GLFW we get a little better performance in the tearing.c and tearing.java + workaround example (about 1400 fps instead of 800) and we get the correct behaviour for glfwSwapInterval = 2 which is 30 fps.
Speaking only for my system (MacBook Pro and macOS catalina) I'd prefer the version of GLFW with CVDisplayLink and a java executable build with macOS Mojava for best performance 😎
I think at some point the latter part is solving itself when the OpenJDK mac build is changed one day to Mojava instead of High Sierra.

I've now checked the OpenJDK 13 build and it is build with macOS Mojave (10.14) already and guess what? The problems are gone when using OpenJDK 13 😎
If you can use LWJGL 3.2.3+ with java 13 and enjoy tearing free, equal to c fps performance!
🎉 🚀 🍰

This should be fixed in the latest snapshot (LWJGL 3.2.4 build 4).


allow long type along with int type

reopen of https://github.com/nodejs/node-gyp/pull/1085 pull request (single commit pull request)
refs https://github.com/yarnpkg/yarn/issues/2286
refs https://github.com/yarnpkg/yarn/issues/2376
allow long type as result of ExpandVariables call. along with str and int.
skip long type(value) along with int.
debug (buggy long type):
[
  {"type(expanded)": "<type 'long'>", "expanded": "1483986851164", "value": "1483986851164", "phase": "0", "build_file": "binding.gyp"},
  {"type(expanded)": "<type 'long'>", "expanded": "1483986851164", "value": "1483986851164", "phase": "0", "build_file": "deps\\libexpat\\libexpat.gyp"}
]

@vany-egorov FWIW you can git push origin your-branch --force to update the Pull Request if you want to change the commits via git rebase or git commit --amend. :)

@Fishrock123 thanks! git rebase -i origin/long~1 long && git push --force origin long work like a charm (^^)

@vany-egorov Did you have any luck with a regression test?  If not, can you rebase it so I can land it?  Thanks.

@bnoordhuis I didn't do any regression tests.
I did: git remote add upstream git://github.com/nodejs/node-gyp.git && git pull --rebase upstream master && git push -f origin long

Anyone against merging this? Seems to still be good.
/cc @cclauss

long was removed in Python 3 in favor of an implementation of int that is of infinite precision.  Given that Python 2 reaches its end of life is 194 days, is there a really strong need to add support for legacy Python long at this late daate?
If so, please define long in Python 3as follows (just after the imports):
try:
    long
except NameError:
    long = int

if this is only for Python 2 then let's not and just focus on getting to Python 3, thanks @cclauss

How is this only for Python 2?  Should we delete this file in the Python 3 install process?

$ python2 -c "long"  # no problems
$ python3 -c "long"  # a NameError is raised halting execution


ctx.body=null may make some confusing things

I found some code in the test case and added a line to describe the problem I encountered.
it('should respond 204 with status=200', async () => {
      const app = new Koa();

      app.use(ctx => {
        ctx.status = 200;
        ctx.body = null;

        // When I try to set ctx.body repeatedly,
        // even if the value is not Null, it will still return 204
        ctx.body = { hello: 'world' };
      });

      const server = app.listen();

      const res = await request(server)
        .get('/')
        .expect(204)
        .expect('');

      assert.equal(res.headers.hasOwnProperty('content-type'), false);
    });

the reason is
https://github.com/koajs/koa/blob/master/lib/response.js/#L83-L92
https://github.com/koajs/koa/blob/master/lib/response.js/#L134-L145
This problem may be good to avoid, but if you don't pay attention, it will cause troublesome problems.
So I posted the problem I encountered here and it might help others save some time.

I’m on a business trip but this is a duplicate. This issue is understood but the problem is that changing this behavior is a major server version (breaking)

Thanks for the reply, if the official support is the best.

So the thing here is that once you change status, Koa doesn't overwrite it. It only sets status if missing or if you're using ctx.(throw|assert). This isn't a bug - but rather a side effect and perhaps a docs issue. Once you understand how Koa reasons about this, it shouldn't be a problem.

ok, I've got it. thanks.


401 Unauthorized: Temp URL invalid if path contains whitespaces

Obviously a quoting issue.
Suggestion : refactor url() using swiftclient's generate_temp_url().
FYI my quick and dirty workaround in my django app was as follow :
from swiftclient.utils import generate_temp_url
from six.moves.urllib import parse as urlparse

sw = SwiftStorage()
url = urlparse.urljoin(sw.base_url, urlparse.quote(sw.name_prefix + release_path))
path = urlparse.unquote(urlparse.urlsplit(url).path)
url = generate_temp_url(path=path, key=sw.temp_url_key, seconds=int(sw.temp_url_duration), method='GET')
return urlparse.urljoin(sw.base_url, url)

Got an example of an invalid url?

Please review the PR

Will let you know shortly !

Great. Not sure if the quoting matters or not. That's the only thing missing from your example.

Trying to pip install your pull request like usual and this doesn't work:
pip install git+git://github.com/blacktorn/django-storage-swift.git@043fabe1af9532f9b5d649ef450abf0d75616802

Says it's not a tree. Any idea ?

Try from the repo/branch the pull requests came from:
https://github.com/ZettaIO/django-storage-swift/tree/temp-url

To be more specific, use github's archive url: (tar.gz of branch temp-url)
https://github.com/ZettaIO/django-storage-swift/archive/temp-url.tar.gz

Using your fork works ... but I'm back to 401 !
The url seems OK but the temp_url_sig is probably wrong.
It looks like you pass the sig as third argument of generate_temp_url, it should be an url_key as in my example above.

When do you get 401?

When I go to the generated url.

Are you sure that added the SWIFT_TEMP_URL_KEY in your swift account as well?

Of course, look at my example, I'm even using it and... it works.
Again, I think you don't pass the correct arguments to generate_temp_url(). Read this : the third argument should precisely be the temp url key, not the hash of it !

ahh yes you are right. generate_temp_url is also generating the hmac.
Fixing.

Side comment : the unit tests should have spotted that it didn't work ;-)

Yep they should ideally do that. Branch is updated 😄

Doesn't work : the path must be unquoted here because it was quoted here !

fixed

Nope :

unquote() got an unexpected keyword argument 'encoding'

Must be a python 2 thing

Fixed. all good things are 5?

That was the one ! 👍

.. and I added unit test to verify the generated temp-url key.
Please close this issue if there is nothing more to add.

@blacktorn @dperetti Can any one you close this issue?


mriqc_clf T1w classifier not working in mriqc latest release on docker

Hello,
I am interesting in the T1w classifier function mriqc_clf which seems to be no longer supported in the latest release
On my system,  container image files for both the latest and second latest version (0.16.1) of MRIQC were downloaded from docker hub.
When I ran the classifier on the latest version
singularity exec -H ~/mengjia_space -B ~/mengjia_space:/output ~/mriqc-21.0.0.sif mriqc_clf --load-classifier -X group_T1w.tsv -v
I got the error
WARNING: skipping mount of /local/path/to/output: stat /local/path/to/output: no such file or directory
FATAL:   container creation failed: mount /local/path/to/output->/output error: while mounting /local/path/to/output: mount source /local/path/to/output doesn't exist
(base) [rbc@cubic-login5 mengjia_space]$ singularity exec -H ~/mengjia_space -B ~/mengjia_space:/output ~/mriqc-21.0.0.sif mriqc_clf --load-classifier -X group_T1w.tsv -v
Traceback (most recent call last):
  File "/opt/conda/bin/mriqc_clf", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.8/site-packages/mriqc/bin/mriqc_clf.py", line 190, in main
    from ..classifier.helper import CVHelper
  File "/opt/conda/lib/python3.8/site-packages/mriqc/classifier/helper.py", line 19, in <module>
    from sklearn.metrics.scorer import check_scoring
ModuleNotFoundError: No module named 'sklearn.metrics.scorer'

However, when I ran the same command with the second latest (0.16.1) version
singularity exec -H ~/mengjia_space -B ~/mengjia_space:/output ~/mriqc_0.16.1.sif mriqc_clf --load-classifier -X group_T1w.tsv -v, I was able to obtain the output file with prediction labels.
/usr/local/miniconda/lib/python3.7/site-packages/sklearn/utils/__init__.py:4: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import Sequence
/usr/local/miniconda/lib/python3.7/site-packages/sklearn/ensemble/weight_boosting.py:29: DeprecationWarning: numpy.core.umath_tests is an internal NumPy module and should not be imported. It will be removed in a future NumPy release.
  from numpy.core.umath_tests import inner1d
211112-09:45:37 mriqc.classifier:INFO Results saved as /cbica/projects/RBC/mengjia_space/mclf_run-20211112-094536*

Is it true that mriqc_clf is no longer supported? Thank you so much for your help and feedback!!

I ran into the same problem!
I tried building the latest mriqc image, but mriqc_clf still didn't work.
Here is the error I got:
Traceback (most recent call last):
File "/opt/conda/bin/mriqc_clf", line 8, in
sys.exit(main())
File "/opt/conda/lib/python3.8/site-packages/mriqc/bin/mriqc_clf.py", line 303, in main
cv_helper = CVHelper(
File "/opt/conda/lib/python3.8/site-packages/mriqc/classifier/helper.py", line 200, in init
self.load(load_clf)
File "/opt/conda/lib/python3.8/site-packages/mriqc/classifier/helper.py", line 716, in load
from sklearn.externals.joblib import load as loadpkl
ModuleNotFoundError: No module named 'sklearn.externals.joblib'
If I use version 0.16.0 instead, I can get a similar output file as Mengjia. However, here raises a question: since my IQMs were computed by version 21.0.0rc2, can I trust the prediction I got from version 0.16.0?


Audit logging not logging user, permission.. etc deletion?

Can the opendistro audit logging log if a user is deleted or created?

Yes audit log can log when user is deleted/created.
There are two types of audit logging provided.

API Request auditing - audit REST and Transport requests that hit the security plugin
Compliance auditing - audit index for any read/write/update action. Here, the action of doc being read, written or updated is audit logged and not the request itself.

Internal security index can be audited using compliance auditing as all internal users are stored in the .opendistro_security index.
To enable, provide configuration in audit.yml (recommended) or if using the deprecated elasticsearch.yml setting opendistro_security.compliance.history.internal_config_enabled: true" .
You can control logging the document content using settings like write_metadata_only: false write_log_diffs: true in audit.yml or equivalent deprecated elasticsearch.yml settings.
Audit log event COMPLIANCE_INTERNAL_CONFIG_WRITE should be generated for create/update/delete actions.

Worked like a charm! Thanks for your response. Have a nice day!

Questions got answered. Closing the issue.


Dead link

[Under section Enable Service Map
Enable the Service Map solution from the Azure Marketplace

The deeplink under "Azure Marketplace"
does not work]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e2fa4879-da5a-e026-5cc6-fd0dcde1b69b
Version Independent ID: b7d90e6e-4578-512b-d595-14ef46a78609
Content: Using Service Map solution in Azure - Azure Monitor
Content Source: articles/azure-monitor/insights/service-map.md
Service: azure-monitor
Sub-service: ****
GitHub Login: @bwren
Microsoft Alias: bwren

@Frank-Henkes -
Thanks for brining this to our attention. We will investigate it further and update you shortly.

@Frank-Henkes - Thanks for reaching out to us. The links are working as expected.  At this moment, Since there is no doc update required, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


[OTHER] Update Awesome GitHub profiles link

What would you like to share?
The message/link to the Awesome GitHub profiles repository should be updated to contain a proper message. https://github.com/EddieHubCommunity/gh-actions-html-table-generator/pull/26#discussion_r886845191
https://github.com/EddieHubCommunity/gh-actions-html-table-generator/blob/d422d55a1e16f2e5be4b0ef6324af1b6f1b66a71/README.md#L98
Steps to contribute
If you've already forked the repository, skip to step 3

Fork the repository here.
Make a new branch named update_message.
Open the README.md file.
Replace line 98 content with the following content:

From this repository usage: [Awesome GitHub profiles](https://github.com/EddieJaoudeCommunity/awesome-github-profiles).

Commit and push your changes.
Create a pull request.
You're done now! 🎉 You just have to wait until the maintainers check your PR.

Additional information
This is a good first issue. Please leave it open to first-time contributors and beginners.
If you need any help with this issue, let us know! 🙂

@eddiejaoude, would be great if this could be opened again. Thank you.


Initialize hasZ in the constructor of GML3

See https://github.com/openlayers/openlayers/pull/6677#discussion_r116012108

@fredj Can you review this?

@Jenselme it's complaining about the indent

@bartvde fixed!

thanks


Allow customizing which gates are used per feature

Currently all gates are used for all features all the time. I've found that sometimes I don't pass in an actor, so the % of actors, actor and group gates don't make sense for the feature. I'd like to be able to deactivate those gates and have that show up in the UI and DSL. In the UI, we could hide the forms for deactivated gates. In the DSL, we could raise if you attempt to enable/disable those gates.
As far as naming, enabled/disabled is pretty dominant in flipper so I don't want to and really can't use them for this. Thinking about it for a bit all I could come up with is activate/deactivate/activated?. enabled/disabled/enabled? are for determining feature enabled-ness and activate/deactivate/activated? would be for determining if the gates should be used when determining feature enabled-ness.
As far as where this should be stored, the easiest thing is to just store it in memory in the code. The stinky thing is that if we do that any place that mounts the UI or API will also need that shared code. I may start with this to see what the feature feels like overall and then look at how to persist it at the adapter level in a way that it doesn't need to be defined in code and will work wherever.
Some code scribbles so I remember:
# will need DSL methods as well, but here is what it would/could look like from feature
flipper[:search].activate(:boolean)
flipper[:search].deactivate(:boolean)
flipper[:search].gate_activated?(:boolean)

flipper[:search].gate(:boolean).activate
flipper[:search].gate(:boolean).deactivate
flipper[:search].gate(:boolean).activated?

[ ] deactivate should clear any adapter values for the gate
[ ] ui actions should not work for deactivated
[ ] api actions should not work for deactivated
[ ] dsl actions should not work for deactivated

I've got a branch going for this, but something doesn't feel right.
https://github.com/jnunemaker/flipper/compare/custom-gates
I was trying to do in memory first and avoid adapter stuff, but there really is no way. You have to at least involve the adapter when deactivating, or you end up with weird state in the UI. For example, let's say you enable an actor, then deactivate the actors gate, the feature shows up as partially enabled, but that isn't true. Because the gate is deactivated, it is actually disabled. The way to fix that is to clear all gate values when deactivating a gate. The problem with that is that there is no adapter method to clear all values for a gate. Currently it only works to clear a single value for a gate. That means we need a new method for the adapters to clear all values. The alternative is to do a get and then a disable for each value (ie: get all actors and disable each).
activate/deactivate also have to permeate the code. feature needs to know what gates are active before it does anything (enable, disable, etc.). The UI needs to know so it can hide things and deny certain actions. The API needs the same.
I think overall what is bothering me is that it is in memory and not persisted in the adapters, but persisting in the adapters means it is a little harder/annoying to build adapters. Perhaps that is fine since most people will use one of the core adapters.
Decided to leave some notes as I'm going to shelf this for a sec to think about it. If anyone has thoughts please let me know.


exhaustUpdate causes memory usage to increase rapidly

Looking at the Memory usage in Task Manager (under the Performance tab in Windows 10) I observed that the committed memory increases rapidly when playing the game.
The issue is not present if I remove the lines of code that update geometry.vertices inside player.js's  exhaustUpdate function.
I observed this on both Chrome and Edge.

Good find! I don’t have time to investigate further at the moment; do you think it’s repairable? (I’d rather fix the issue or find a more efficient means of updating the exhaust trail rather than disabling it altogether.)

I think this can be answered once the root cause is discovered. I did some experimentation by modifying exhaustUpdate to simply:
        function exhaustUpdate( side ){
            const
            arm      = player.arms[ side ],
            engine   = arm.engine,
            enginePositionNow = engine.localToWorld( new THREE.Vector3() ).sub( M.three.world.position ),
            exhaust  = arm.exhaust,
            geometry = exhaust.geometry

            geometry.vertices.splice(vectorsPerRing, geometry.vertices.length - vectorsPerRing);
            geometry.elementsNeedUpdate = true
        }

And the memory usage continues to climb. However, removing the call to elementsNeedUpdate results in stable memory usage.
Perhaps there is an underlying issue with THREE.CylinderGeometry?


Optimise sync of scraping targets

Scraping targets are synced by creating the full set, then adding/removing any which have changed.
This PR speeds up the process of creating the full set.
I added a benchmark for TargetsFromGroup; it uses configuration from a typical Kubernetes SD.
The crux of the change is to do relabeling inside labels.Builder instead of converting to labels.Labels and back again for every rule.  The change is broken into several commits for easier review.
This is a breaking change to scrape.PopulateLabels(), but relabel.Process is left as-is, with a new relabel.ProcessBuilder option.
Benchmarks, first with the slice version of labels.Labels:
                               │    sec/op    │    sec/op     vs base               │
TargetsFromGroup/1_targets-4     51.35µ ± 14%   34.24µ ± 48%  -33.31% (p=0.032 n=5)
TargetsFromGroup/10_targets-4    515.8µ ± 37%   318.0µ ± 14%  -38.35% (p=0.008 n=5)
TargetsFromGroup/100_targets-4   5.890m ± 44%   3.204m ± 11%  -45.61% (p=0.008 n=5)

                               │     B/op      │     B/op      vs base               │
TargetsFromGroup/1_targets-4     10.599Ki ± 1%   3.734Ki ± 0%  -64.77% (p=0.008 n=5)
TargetsFromGroup/10_targets-4    105.94Ki ± 0%   37.60Ki ± 1%  -64.50% (p=0.008 n=5)
TargetsFromGroup/100_targets-4   1056.1Ki ± 0%   374.5Ki ± 0%  -64.54% (p=0.008 n=5)

                               │  allocs/op   │  allocs/op   vs base               │
TargetsFromGroup/1_targets-4       65.00 ± 0%    43.00 ± 0%  -33.85% (p=0.008 n=5)
TargetsFromGroup/10_targets-4      641.0 ± 0%    430.0 ± 0%  -32.92% (p=0.008 n=5)
TargetsFromGroup/100_targets-4    6.419k ± 0%   4.310k ± 0%  -32.86% (p=0.008 n=5)

and then with -tags stringlabels:
goos: linux
goarch: amd64
pkg: github.com/prometheus/prometheus/scrape
cpu: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
                               │    sec/op    │    sec/op     vs base               │
TargetsFromGroup/1_targets-4     62.81µ ± 17%   32.47µ ± 14%  -48.31% (p=0.008 n=5)
TargetsFromGroup/10_targets-4    560.6µ ± 29%   333.0µ ± 11%  -40.59% (p=0.008 n=5)
TargetsFromGroup/100_targets-4   5.696m ± 22%   3.234m ±  7%  -43.22% (p=0.008 n=5)

                               │     B/op      │     B/op      vs base               │
TargetsFromGroup/1_targets-4     19.099Ki ± 0%   4.365Ki ± 1%  -77.14% (p=0.008 n=5)
TargetsFromGroup/10_targets-4    191.46Ki ± 0%   43.55Ki ± 1%  -77.26% (p=0.008 n=5)
TargetsFromGroup/100_targets-4   1907.5Ki ± 0%   435.2Ki ± 1%  -77.18% (p=0.008 n=5)

                               │  allocs/op  │  allocs/op   vs base               │
TargetsFromGroup/1_targets-4      61.00 ± 0%    43.00 ± 0%  -29.51% (p=0.008 n=5)
TargetsFromGroup/10_targets-4     602.0 ± 0%    430.0 ± 0%  -28.57% (p=0.008 n=5)
TargetsFromGroup/100_targets-4   6.025k ± 0%   4.309k ± 0%  -28.48% (p=0.008 n=5)

Rebased on master and added another optimisation, which is a breaking change to the interface of TargetsFromGroup.
Will update benchmarks shortly.

Thank you! I like how you used a for loop with Get in resolveConflictingExposedLabels.

Thank you! I like how you used a for loop with Get in resolveConflictingExposedLabels.

That's in #12084


Writer did not close gracefully.

Hi @mliberty1
Awesome stuff you have going here. Very impressed by the joulescope so far.
We are developing a C# library that can communicate with the server you have written in python.
I can see, that in your example client.py, you are awaiting a receiver_task in the end.
I have implemented an async connection with a receiver that takes care of the communication, and everything is working fine, except when closing the connection, then i get the following console output from the server:
ERROR:2022-11-08 08:35:52,752:server.py:380:joulescope_server.server:handle_client error
Traceback (most recent call last):
File "C:\Users\ara\AppData\Local\Programs\Python\Python38\lib\asyncio\windows_events.py", line 453, in finish_recv
return ov.getresult()
OSError: [WinError 64] The specified network name is no longer available
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
\joulescope_server\server.py", line 354, in run
msg = await framer.treceive(self._reader)
\joulescope_server\framer.py", line 105, in treceive
tag, payload = await receive(reader)
\joulescope_server\framer.py", line 89, in receive
header = await reader.readexactly(HEADER_LENGTH)
\Python38\lib\asyncio\streams.py", line 740, in readexactly
await self._wait_for_data('readexactly')
\Python38\lib\asyncio\streams.py", line 534, in _wait_for_data
await self._waiter
\Python38\lib\asyncio\proactor_events.py", line 280, in _loop_reading
data = fut.result()
\Python38\lib\asyncio\windows_events.py", line 808, in _poll
value = callback(transferred, key, ov)
\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 64] The specified network name is no longer available
WARNING:2022-11-08 08:35:52,756:server.py:386:joulescope_server.server:Writer did not close gracefully
INFO:2022-11-08 08:35:52,756:server.py:250:joulescope_server.server:_async_task done
INFO:2022-11-08 08:35:52,757:server.py:392:joulescope_server.server:ClientManager.run done
I am pretty clueless on how to solve this. The server sometimes becomes unresponsive after this has happened.
Any pointing in the right direction would be greatly appreciated.
//Anders

Hi @mliberty1
I have been cloning the repo and running it from there using the python -m joulescope_server.
I still get the same behaviour when installing it with pip and running it directly.
I suspect I need to await some event.
At the moment, I am facing different issues however. Is there a forum I should ask questions instead?

Hi @earsnot  - If you have general Joulescope questions, the best place is the Joulescope forum.  If you have questions specific to this pyjoulescope_server package, I just opened "Discussions" on the GitHub repo.  Visit the repo and click on the Discussions tab.

We still have an outstanding unexplained behavior with a C# client (see discussion).  However, the example python client now closes cleanly, so I am going to close this issue.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.15.13",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cce476954401e3421afafb25bbaa926050688b1d"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "cce476954401e3421afafb25bbaa926050688b1d",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "ALSA: hda: intel-sdw-acpi: harden detection of controller\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.13 by commit cce476954401e3421afafb25bbaa926050688b1d. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000063


fix default image repository namespace

docker pull staffbace/syseleven-exporter:1.2.0
Error response from daemon: manifest for staffbace/syseleven-exporter:1.2.0 not found: manifest unknown: manifest unknown

Good catch, thanks! :)


I am confused why I cannot see a route that I'm told is unavailable.

Using cf version 6.20.0+25b1961-2016-06-29
What Happens
So I try to push an app:
cf push example-app
And I am told I can't, because the route is taken:
Using route example-app.local.pcfdev.io
       Binding example-app.local.pcfdev.io to app_using_angular...
       FAILED
       The route example-app.local.pcfdev.io is already in use.
       TIP: Change the hostname with -n HOSTNAME or use --random-route to generate a new route and then push again.

Huh, that's weird. Just a few minutes ago I'd used cf delete example-app to clear the way.
Let me just check!
$ cf routes
Getting routes for org pivotal / space integration as admin ...

space   host   domain   port   path   type   apps   service
No routes found

Um ... what? Where's the route?
After some searching, it turns out that the route is in another organization. I can't see that route from where I am. I just keep getting told "no, you can't use it". On a scale from 1 to "Jacquesrant", this rates increasingly higher on each iteration.

Deleting route example-app.local.pcfdev.io...
OK

And now we're clear to reuse example-app.
What I Wish Had Happened:
Using route example-app.local.pcfdev.io
       Binding example-app.local.pcfdev.io to app_using_angular...
       FAILED
       The route example-app.local.pcfdev.io is not available for binding because it has been used by another organization.
       TIP: Change the hostname with -n HOSTNAME or use --random-route to generate a new route and then push again.

The change is to say that the route was taken by a different org.
While it would be convenient to know which org is holding the route, this would leave folk open to enumeration attacks intended to find who owns what routes.

@SocalNick @shalako Can you confirm that with the following API's error response, we can safely change the current CLI message of "The route  is already in use." by something like "The route  is already in use in another org."?
PUT /v2/apps/ff4f92d6-4157-456c-a62d-d5ead73d953a/routes/9304d6b0-a180-470f-a306-1aacd156950c HTTP/1.1
...

HTTP/1.1 400 Bad Request
...
{
  "code": 1002,
  "description": "Invalid relation: The requested route relation is invalid: 9304d6b0-a180-470f-a306-1aacd156950c",
  "error_code": "CF-InvalidRelation"
}

The constraint is that app and route must exist in the same space (can be in the same org or another; doesn't matter).
I don't think that the current API response is helpful. Better would be The app cannot be mapped to the route because they are not in the same space.
If the CLI passed through the API response I have suggested, it would be more meaningful than the current CLI UX. The current response ...is already in use is misleading, as it doesn't matter whether a route is in use but that it was created in another space; the route could be mapped to an app or not. A more helpful response might be: The route example.cf.com cannot be mapped to an app in space foo because it has been reserved in another space.

I'm less fussed about wording. The point is that I had no idea what the heck was going on. It was a very frustrating morning.

@jchesterpivotal would this wording have told you what was going on: https://www.pivotaltracker.com/story/show/138649897

Not really. I already know that "the route is not in this space", that's exactly what drove me to despair.
What I need to know is why.

@jchesterpivotal so would it help if the error was:
The app cannot be mapped to this route because the route is not in this space. Apps must be mapped to routes in the same space

Not really. I would still type cf routes, get an empty route table and be confused. If the route is reserved by someone else, that's what explains the outcome. Knowing or not knowing who holds it would be a secondary consideration.

@jchesterpivotal why would you type cf routes when we told you that the route is not in the current space?

Because I'm not a CLI developer. I have a fuzzy model of how CF works. I might, for example, expect to be told which space or org it belonged to.
But mostly because I am lazy, in both the negative sense and positive sense. I hate thinking, I reserve it for leisure activities.

@jchesterpivotal I don't think we are going to provide which space and org the route belongs to in an error message. As an API server, we don't want to spend extra time looking things up for 4xx client errors.
Unless you have a suggested error message, I'll use what I mentioned above.

I'm not asking to know who owns it. In fact, it's a bad idea; that information could be considered sensitive, as it can leak information.
I just want the clearest message I can about why it's unavailable.
Without knowing how the API works in depth, is there a scenario in which a route can exist without being owned?
Because if a route is owned, you don't need to look up the owner to tell me someone else took it. You can infer that from its unavailability.
My original request is not based on a hypothetical. This really happened to me. I wasted an entire morning because I am not willing or able to mentally model every single component in Cloud Foundry all the time. The message I suggested would've entirely avoided the question.

 I've captured an alternative error message in the story and will work with @zrob, the incoming CAPI PM, on the exact wording.

Thanks Nick!
Once the new wording has been finalised, we'll look at updating the CLI to use the same message.

Hey,
CAPI just pushed the work for this story. You can see the story here: https://www.pivotaltracker.com/story/show/138649897.

I just ran into the same error and the message seemed quite unclear to me, because it didn't say that the route was in use anymore. Am I right that the new wording is:
The app cannot be mapped to route <app-name>.<region>.<domain>.<tld> because the route is not in this space. Apps must be mapped to routes in the same space.
Google the error leads to this issue. Did you suggest mentioning that the route is no in this space because it is used in another org/space?

It might or might not be in use in another space. This command doesn't reveal that to make it harder to enumerate routes across the whole CF instance. Slightly annoying, but the root cause here is that malicious people kinda ruin it for everyone.

I think it's because example-app has already used by other account. You need to choose another name likecf push example-app123.

@heinels1982 yes it was. Like @jchesterpivotal said, it can‘t be revealed if it actually exists already (due to the possible security issues that could be caused revealinng that the org/space already exists).
Thanks for the answer though!

Hey, I had exacly the same problem because I called my app TestApp... hahahah giving it an unique name  was an easy fix :)


Does this mod work with both of the main Waystone Mods for Fabric?

The descriptions mentions "Waystones" by @BlayTheNinth, but the modpack on which I've based my CurseForge profile is using "Fabric Waystones" by @LordDeatHunter.
So, if it works with both, please let us know.
If not, please turn this into a feature request for it to support both.

As far as I can tell, this is a forge-only mod. 🤔

@LordDeatHunter I'm no expert at Java code or Minecraft mod authoring, so if the description or title fails to mention a required mod-loader I might make some assumptions (potentially faulty...)
Anyway, this mod was mentioned in one of @xaero's maps' issues, so I came here and saw that the author specified just @BlayTheNinth's mod, but since the "Better MC [FABRIC] 1.19.2" modpack on which my CurseForge Overwolf client's profile is based uses your Waystone mod, I thought I'd ask the question (not even wondering whether this mod works on Fabric).

This mod is Forge only and only supports interaction with the Waystones mod by BlayTheNinth.


Support roles as a list property of Dashboards

The roles input field is revealed after enabling DASHBOARD_RBAC flag.

The information was already retrieved, but now also stored in the Dashboard during json processing.

I am still working on saving a Dashboard with roles attached. This is not working yet because the save function in base.py is not yet converting the list of Role objects to json.

Hi @ecederstrand or other supersetapiclient developer, I'm done with the changes I needed to store the Roles of a Dashboard. I have applied these changes to my superset setup and they work. I would like to follow through on this PR and merge it.

Is the correct target branch set on this PR? I noticed some more changes on develop.
Are units test available which I can expand on?
I would like to expand documentation in README.md regarding the feature I'm adding, but I would like to do it in a separate PR, is that ok?

Hello @ljpeters ,
Thank you for your contribution. I was on vacations and unable to respond sooner.

The correct target branch should be develop
On master & develop, there is a skeleton for unit testing the client but it does not yet cover everything.
Yes please do it in a separate PR, I will then approve it. At some point we should also release some official documentation on a website.

Thanks again

@ljpeters If you base this PR off #38 then there's now a full test suite you can add test cases to, with lots of examples on how to write tests cases.

Is this still in progress?


Remove lambda code

Remove lambda code
Add random string suffix to sns topic name
Refactor code to pull lambda code from public geff repo
Fix directory structure to pull all lambda code into geff module and thus support relative imports and thus help scale to more modular and unit testable code

let's do one thing at a time -- this seems to update a bunch of docs as well as removing lambda code?

@sfc-gh-afedorov Let me make a separate one for the REAMDE.md changes.


RDA-AboutUs

Add my credentials to AboutUs, and all the files related.

Codecov Report

Merging #20 (4e2c560) into master (d986076) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #20   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

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 d986076...4e2c560. Read the comment docs.


Bugfix/Permission Denied when Yarn start or Yarn dev

What does this PR do?
Fixed bug where files are not executable, causing Permission denied on Linux based machines
Related PRs and Issues
The Pull Request is related to this https://github.com/Outerbridgeio/Outerbridge/issues/95

Nothing changed?

Its changed to executable, see the index:

Answer: https://stackoverflow.com/a/21694391


"Replace all" tooltip covers options

When the Replace All button is enabled (after you've run a search), command-enter does the same thing as clicking the button.

Duplicate of atom/find-and-replace#501, please subscribe there for updates.


Change the LanceDBIndex to compute its new cache rows in parallel and then do a bulk insert

Description
This greatly improves the performance of indexing. Combined with the change for bulk inserts in ChunkCodebaseIndexer, indexing is over twice as fast. However, it can be much faster if the other indexers are converted to use bulk insert as well.
In addition, this indexer is not using the computed chunks in the chunk table. It would be faster to reference the already computed chunks, however, for the purposes of this PR we are not changing that behavior.
Checklist

[x] The base branch of this PR is dev, rather than main
[x] The relevant docs, if any, have been updated or created

the tsc check appears to be failing due to an older node.js version in the check environment.

@spew - it looks like our JS target doesn't actually support  cause .
See this comment: "The constructor overload with cause is only supported with ES2022 or later."
Our config:
"target": "ES2020",
"lib": ["ES2021", ...],

The following config resolved the type errors for me. Going to push a commit to update to it.
"target": "ES2022",
"lib": ["ES2022", ...],


Add availability attributes to Sendable conformances

It is desirable to attach the same availability to the extensions declaring Sendable as to their base types.

@swift-ci please test


Can't install stplanr

@Robinlovelace I'm going to have to revert the changes you made to the routing pratical. I can't install the new version of stplanr sucesfully because of a dependance on terra >= 1.5.12 which is not compiling on windows.
library(stplanr)    # General transport data functions
Error: package or namespace load failed for ‘stplanr’ in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
 namespace ‘terra’ 1.4-22 is being loaded, but >= 1.5.12 is required

@mem48 thanks for the heads-up. We hit this problem last week and found a solution that worked for everyone who tried it. Try this:
install.packages('terra', repos='https://rspatial.r-universe.dev')

I'll try it when I get back. In the meantime the practical works without stplanr

I'll try it when I get back. In the meantime the practical works without stplanr

When do you get back?

This is not working for me, I'm keeping the practial without stplanr as I can't teach it if I can't run it.

This is not working for me, I'm keeping the practial without stplanr as I can't teach it if I can't run it.

Sorry to hear you're still having issues. What error message do you get?

Heads-up @mem48 planned solution to this: push a copy of the practical with the updated route function to give max flexibility for the students who want to. Then we can replace the old way with the new way after the practical.


Clean up dependency inconsistency

There are at least 4 conda environment specification files, and one setup.py/setuptools all listing a bunch of dependencies, of which some are inconsistent. A clean up would be nice, to

remove dependencies that are no longer needed or pulled in by other dependencies, and
use the same library versions across different environments if possible

Conda files:

https://github.com/wroscoe/donkey/tree/master/envs

Setup.py

https://github.com/wroscoe/donkey/blob/master/setup.py

There are additional dependencies on the dev branch.

some library versions were not available on different platforms at the time
this was created. You are welcome to test all these platforms and create a
pull request. But do no simply change them without testing, please.
On Thu, May 17, 2018 at 3:36 AM, Tomas Nilsson<EMAIL_ADDRESS>wrote:

There are at least 4 conda environment specification files, and one setup.py/setuptools
http://setup.py/setuptools all listing a bunch of dependencies, of
which some are inconsistent. A clean up would be nice, to

remove dependencies that are no longer needed or pulled in by other
dependencies, and
use the same library versions across different environments if
possible

Conda files:

https://github.com/wroscoe/donkey/tree/master/envs

Setup.py

https://github.com/wroscoe/donkey/blob/master/setup.py

There are additional dependencies on the dev
https://github.com/wroscoe/donkey/tree/dev branch.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/wroscoe/donkey/issues/260, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKk59d8QEsraLM6evxf0UR1irwFcPpCks5tzVKzgaJpZM4UC0c9
.

I'll start and see if I can get far enough.
Should all libraries used in donkeycar be listed in setup.py or are there some exceptions? And should the conda environment files reflect those dependencies?

I just removed keras from the env dependencies and upgraded the tensorflow versions. Donkeycar is also now installable from pypi. All the dependences should be listed in setup.py but the installation of the packages that require compilation should be completed outside of the pip workflow for the raspberry pi.

Thinking more about this, we've got to have one way to install on each system, not many. For mac/windows/ubuntu this can be via conda. For raspberry pi I think the only reliable way to get all the dependencies will be via a disk image. This is unfortunate because it's a lot of work to prepare the disk image so it doesn't get update frequently. This may change if can get a whl built for tflite

@wroscoe - I was thinking it could be nice to have a trained model for every released donkey version to pypi. I'm planning to use it for both testing training functionality and backward compatibility. Do you have some good training data I can use? Also, do you have any preference on where to store binaries used for testing?


Why are you using void * for module instance and such in modules thread extention

For example here void * is used here:
https://github.com/azure-rtos/threadx/blob/8ff9910ddc089e7af91e4089b26f225aba5d7eb7/ports_module/cortex_a35/gnu/inc/tx_port.h#L214
I know that the module struct wasn't declared yet, but it can be solved by struct forward declaration.
I think that using the void* instead of the struct pointer is misleading.

That is worth looking into... since it isn't a published API, it might be something that could be changed.


Add FileIoManager interface documentation

Hey can you look at this interface documentation and let me know if there are any big no-nos?
Also, some general guiding principles on what should be bothered to document for backend implementations.  I'm thinking documentation for private non-overriding functions (as necessary) would help ease refactoring and ensuring there are comments for business logic exceptions such as the comment for hiding the input element for iOS Safari or always returning an empty extension list for Safari/MAC JVM (I'm in favor of having those next to the code where the exceptions are being made instead of being double documented in things like member functions or class documentation for these parts of the api that are not exposed to core code).

Yeah I forgot to put in the 2mb file size limitation @nbilyk


Should not use a hook-line name of function

https://github.com/plone/volto/blob/c40e772701e4f6771a541898621457ec45500859/packages/volto-slate/src/blocks/Text/SlashMenu.jsx#L113
In react code the use prefix is reserved for hooks, afaik

Hey, can I contribute to this issue?

@sjain-hub please read and follow Contributing to Plone and First-time contributors.


Could not resolve dependency

When I try to load this as a dependency in my project it says that it could not find dev.sejtam:MineSchem:2.1.0
> Could not resolve all task dependencies for configuration ':testRuntimeClasspath'.
   > Could not resolve dev.sejtam:MineSchem-Core:2.1.0.
     Required by:
         project : > project :groot-minestom
      > Could not resolve dev.sejtam:MineSchem-Core:2.1.0.
         > Could not parse POM https://repo.repsy.io/mvn/sejtam10/minestom/dev/sejtam/MineSchem-Core/2.1.0/MineSchem-Core-2.1.0.pom
            > Could not find dev.sejtam:MineSchem:2.1.0.
              Searched in the following locations:
                - https://repo.maven.apache.org/maven2/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom
                - https://jitpack.io/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom
                - https://repo.spongepowered.org/maven/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom
                - https://repo.velocitypowered.com/snapshots/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom
                - https://libraries.minecraft.net/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom
                - https://repo.repsy.io/mvn/sejtam10/minestom/dev/sejtam/MineSchem/2.1.0/MineSchem-2.1.0.pom

In your MineSchem-Core-2.1.0.pom it says that it needs to load just MineSchem which it can not find. Any idea on how to fix this? Thanks in advance!

Hi, thanks for reporting this bug!
I uploaded an update where the bug should be fixed. I hope it will work!
https://github.com/sejtam10/MineSchem/releases/tag/v3.0.0

Yes, this fixed the issue. Thanks for fixing this so soon! Closing this.


when can I control npc cars ?

As mentioned in the title, it's very important for me to construct a specific scenario with npc cars controllable.
I noticed that this function is part of road map.
But I still want to know what time about its implementation or how it is going now ...
Thanks a lot   :)

Hello @18605973470 we dont have an exact estimation of time, but right now we are designing this together with other systems directly connected to it.

Take a look to this #145 and this #444


toil --version prints installed version (resolves #535)

Try using this technique to get the full version including the build number:
https://github.com/BD2KGenomics/cgcloud/blob/master/core/src/cgcloud/core/project.py#L40

This must work for both pip install and make develop.


Add support for global ignore directories

Right now, when we want to add a common directory to ignore, we need to go to each integration and add an item. Adding support for some common global ignores would be really useful. Some common directories to ignore are often:
vendor/
test/
testdata/
hack/

You mean to be ignored by git checkin ?

@PankhudiB no. The extractor process matches files based on a set of patterns. In this commit I went through and added testdata as an ignore for every extractor. This can be tedious. Having a way to match across extractor patterns would be much more useful rather than needing to update each and every one of them.


throw on unhandled terms

This results in a better error message for issue #100 :
Unhandled term: {"ctor":"Cse","name":"xs#J","func":{"ctor":"Loc","from":60,"upto":68,"expr":{"ctor":"Ann","done":true,"expr":{"ctor":"Var","indx":"xs#2"},"type":{"ctor":"Ref","name":"String"}}},"info":[{"ctor":"Ext","head":["xs",{"ctor":"Ann","done":true,"expr":{"ctor":"Var","indx":"xs#2"},"type":{"ctor":"Ref","name":"String"}}],"tail":{"ctor":"Ext","head":["sep",{"ctor":"Ann","done":true,"expr":{"ctor":"Var","indx":"sep#1"},"type":{"ctor":"Ref","name":"String"}}],"tail":{"ctor":"Nil","size":0},"size":1},"size":2},[null,null,null]]}

Interesting, we need to investigate more precisely why that case happens.

But can we please merge this, so that we get better diagnostics when it recurs, please?
At the moment I'm repeatedly rebasing this patch on my working copy.

I'm not sure this is the best way to solve the issue at hands, it should just give you a message when compilation fails. Do you disagree?


DAF python bug

Hi
I was using Lalaine to perform the second step of DAF usage through the network traffic and call trace retrieved by previous step.
When I run this command "python analyze_log.py -d . -n 0" this is what comes out:

and then after several lines:

Can you help me?
Thank you in advance

It looks like the error when HarParse try to parse the network traffic. You may need to save the network traffic in har format to allow HarParse to correctly read.

On Apr 13, 2023, at 8:35 AM, annapaolagiancaspro @.***> wrote:
Hi
I was using Lalaine to perform the second step of DAF usage through the network traffic and call trace retrieved by previous step.
When I run this command "python analyze_log.py -d . -n 0" this is what comes out:
https://user-images.githubusercontent.com/83175380/231759541-31d20c43-baf3-4734-bcd9-c75f3ce61e07.png
and then after several lines:
https://user-images.githubusercontent.com/83175380/231759637-9ed369bf-5b29-4c64-9861-bea6a0bbc2ef.png
Can you help me?
Thank you in advance
—
Reply to this email directly, view it on GitHub https://github.com/xiaoyue10131748/Lalaine/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJDU24QT56ZU56TJNENSNL3XA7XHNANCNFSM6AAAAAAW5AR5L4.
You are receiving this because you are subscribed to this thread.

Thanks!


POC: Add support to run tests in web workers

This is a POC to add support for running tests in webworkers. I'm using this karma plugin - https://github.com/Joris-van-der-Wel/karma-mocha-webworker, it seems to get the job done and it allows running all tests inside a webworker. @dignifiedquire @diasdavid please let me know what you think.

I'll try to get to this ASAP, hopping for today.

@dignifiedquire I've made the changes you requested, let me know if something else is missing.

@dryajov I just saw that the karma.webworker.conf file is missing, could you open a PR adding that, so I can release this?

Ah... Will do ASAP. @dignifiedquire


[WIP] Unify the source of urdf files

The idea is to unify the source of the urdf files into one package and to make ros2 control demos launch files used them in that form.
Importing all the configuration, launch and urdf files for different robots is also aim of this PR. So this PR will deal with urdf porting issue.
#27
Source of urdfs is  here.

@gavanderhoorn Here you referenced this package as the best source of urdf, launch and configuration files. Please can you check also another alternative which I got from the other parties involved.

@gavanderhoorn Here you referenced this package as the best source of urdf, launch and configuration files. Please can you check also another alternative which I got from the other parties involved.

@gavanderhoorn Here you referenced this package as the best source of urdf, launch and configuration files. Please can you check also another alternative which I got from the other parties involved.

"from the parties involved"?
You mean from @fmauch? I'm not sure why you don't mention him.

@gavanderhoorn Here you referenced this package as the best source of urdf, launch and configuration files. Please can you check also another alternative which I got from the other parties involved.

"from the parties involved"?
You mean from @fmauch? I'm not sure why you don't mention him.

In case it still matters, I also vote for using the ros-melodic-staging branch from the original repo instead of my fork. The only reason that I don't propose users to use that one is the lack of working moveit support on that branch, see https://github.com/ros-industrial/universal_robot/pull/538.

In case it still matters, I also vote for using the ros-melodic-staging branch from the original repo instead of my fork. The only reason that I don't propose users to use that one is the lack of working moveit support on that branch, see https://github.com/ros-industrial/universal_robot/pull/538.

In case it still matters, I also vote for using the ros-melodic-staging branch from the original repo instead of my fork. The only reason that I don't propose users to use that one is the lack of working moveit support on that branch, see https://github.com/ros-industrial/universal_robot/pull/538.

I used most of the stuff from ros-melodic-staging branch.
The main difference I would say is I added a parameter  to ur.xacro. Easier matching of names from .srdf files in urx_y_moveit_config was the motivation for this.

In case it still matters, I also vote for using the ros-melodic-staging branch from the original repo instead of my fork. The only reason that I don't propose users to use that one is the lack of working moveit support on that branch, see https://github.com/ros-industrial/universal_robot/pull/538.

I used most of the stuff from ros-melodic-staging branch.
The main difference I would say is I added a parameter  to ur.xacro. Easier matching of names from .srdf files in urx_y_moveit_config was the motivation for this.


[Bug]: Failed to check global snapshot in oracle mode

ODC version
ODC423
OB version
Oceanbase2277
What happened?
Failed to check global snapshot in oracle mode

What did you expect to happen?
export normally
How can we reproduce it (as minimally and precisely as possible)?
chat privately
Anything else we need to know?
No response
Cloud
No response

pass


fix aspect ratio of gifs

cc @Qix-
I was mostly guessing, but this seems to fix the aspect ratio issue I was seeing before.

before
after

As a downside, it appears performance is slightly worse now. Presumably the width/height could be halved from this and it'd be pretty nice.

Width and height are already halved; should have seen it when I was rendering at full size (it was awful).
Let me review.

Ah. Well Somehow this fixes the aspect ratio.. not sure why, then. :)

Well the width/height were halved to increase performance, but that just meant the aspect ratio was messed up. The problem is that most image formats assume that the pixel aspect ratio is square where in terminals the aspect ratio is something closer to 1:1.5, hence the skew.

Looks good :) Thanks!

@Qix- ahhh yeahhh that makes sense. :)
Then my naive attempt to scale and fix the skew would be this:
diff --git a/covfefe-art.js b/covfefe-art.js
index 5abf47f..82323f9 100644
--- a/covfefe-art.js
+++ b/covfefe-art.js
@@ -13,7 +13,7 @@ childProcess.fork(path.join(__dirname, 'music.js'));
 function updateFrame(frame, cb) {
 	var covfefe = [];
 	var skipped = false;
-	for (var y = 0; y < frame.height; y += 2) {
+	for (var y = 0; y < frame.height; y += 4) {
 		for (var x = 0; x < frame.width; x += 2) {
 			var offset = ((y * frame.width) + x) * 4;
 			if (frame.data[offset + 3] === 0) {
@@ -21,7 +21,7 @@ function updateFrame(frame, cb) {
 			} else {
 				if (skipped) {
 					skipped = false;
-					covfefe.push('\x1b[' + (y / 2 + 1) + ';' + (x / 2 + 1) + 'H');
+					covfefe.push('\x1b[' + (y / 4 + 1) + ';' + (x / 2 + 1) + 'H');
 				}

and the results are reasonable. up to a point:

pushed that change to the PR. :)
if you're happy i think this is good enough for our beloved covfefe module. :)

This is great :) Thank you!!

cheers dude.


Revision of sections

WebView2 contains hundreds of APIs that provide a vast set of capabilities, ranging from enhancing your app's native-platform capabilities, to enabling your app to modify browser experiences. Leveraging this technology for your app grants it access to various methods and properties that are provided through the WebView2 classes or interfaces.
This article provides a high-level grouping of these APIs to help you understand the different things you can do using WebView2.
Hybrid app approach
When deciding between building a web app or a native app, a Developer should consider the tradeoff between reach and power:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 75e2e1f6-9d4d-1b6e-dc60-d03c95e5e366
Version Independent ID: 75e2e1f6-9d4d-1b6e-dc60-d03c95e5e366
Content: Overview of WebView2 features and APIs - Microsoft Edge Development
Content Source: microsoft-edge/webview2/concepts/overview-features-apis.md
Product: microsoft-edge
Technology: webview
GitHub Login: @MSEdgeTeam
Microsoft Alias: msedgedevrel

@JasonAndrewWriter how is this different from #2051? Do we need 2 issues for this? Or should one of them be closed?


[Enhancement] Support show full fields syntax

Signed-off-by: Astralidea<EMAIL_ADDRESS>What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #17234
Problem Summary(Required) ：

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

run starrocks_fe_unittest


sudo nxbt demo / sudo nxbt test / sudo nxbt webapp not doing anything

Everything else works fine - I've looked through issues before, and I've tried:
sudo pip install jinja2==3.0.3 itsdangerous==2.0.1 Werkzeug==2.0.2 eventlet==0.33.0 dnspython==2.2.1 and all are installed correctly.
There is no error, nothing happens if I wait, it just immediately goes to next line.
Installed from cloned repository, but have since tried with PyPi install (because of #29) and still didn't work...
Any help appreciated, (sorry if post is not descriptive enough, I'm new to this - just lmk what other information is needed) thanks!

With more digging I'm starting to believe issues are coming from dbus, and im having all manner of problems trying to correctly install/reinstall/update it and get the nxbt.py to run standalone without giving a "No module named 'dbus'" error.

I'm having the same issue even after uninstalling and reinstalling. I execute sudo nxbt demo and all I get is "Running Demo..." on the next line without any other updates / changes


Generate Expand expression

The graph SDK has a method SelectAndExpand() - The logic in the SnippetsGenerator currently supports $select query option and not expand. The implementation here needs further investigation.
Scenarios for $expand
GET /v1.0/me/drive/root?$expand=children($select=id,name) HTTP/1.1
GET /v1.0/users?$expand=directReports HTTP/1.1

Resolved under #30


API modules aren't sorted for Kubernetes

The API modules for Kubernetes seem to be in a random order. At a glance, other providers seem to be fine (and I haven't found another example of this), so I wonder if this is just a problem with Kubernetes.

Note that while the fix is merged, as we regenerate API docs for providers with each provider version release the issue will correct itself since we would regenerate the JSON for the tree at the same time as well.


PROD SUPPORT : Advocate | Re-registration with same number

Describe the bug
Whenever one advocate registration request is rejected by Nyaymitra, that advocate should be able to do registration again by using same number

hi @Susmitabe  I am not able to reproduce this issue, I did the above mentioned steps and it is working as expected(UAT). can you please elaborate the exact steps to reproduce this. cc: @Ramu-kandimalla

@tanmaybhateja (Program team ) & Highcourt signoff on either enabling address change or letting them re-register again with same number

Hi @Susmitabe  Please confirm

working fine


Update hololens-outage.md

Added collapsible text.

Docs Build status updates of commit 2e7a6a7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/hololens-outage.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 44fec6f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/hololens-outage.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Create functional tests

Common
I do not know how to name this tests exactly correct, but tests is for user view cases actually.
I change all html files I need to test and сcombine multiply lines to singe — easy to test without \n and \t.
Tests utils

olga/functional_tests/utils.py — I write utils for tests, that help me to setup common integrations for several test classes and provide parts of html-templates, that need to be tested comfortable funtionality.

Tests
I add cases for statistics exists and no statistics on server. :

olga/functional_tests/test_graph_metrics.py — tests for graphs activity metrics.

olga/functional_tests/test_map_metrics.py — tests for graphs activity metrics.

olga/functional_tests/test_output_dates.py — tests for extraction duration and courses engagement dates.

Codecov Report

Merging #47 into master will decrease coverage by 1.83%.
The diff coverage is 97.27%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
- Coverage     100%   98.16%   -1.84%
==========================================
  Files          25       30       +5
  Lines         748      874     +126
==========================================
+ Hits          748      858     +110
- Misses          0       16      +16

Impacted Files
Coverage Δ

olga/charts/views.py
100% <ø> (ø)
:arrow_up:

olga/analytics/tests/test_utils.py
100% <100%> (ø)
:arrow_up:

olga/functional_tests/test_map_metrics.py
100% <100%> (ø)

olga/analytics/tests/test_models.py
100% <100%> (ø)
:arrow_up:

olga/analytics/tests/__init__.py
100% <100%> (ø)
:arrow_up:

olga/analytics/models.py
100% <100%> (ø)
:arrow_up:

acceptor/settings.py
100% <100%> (ø)
:arrow_up:

olga/analytics/tests/test_views.py
100% <100%> (ø)
:arrow_up:

olga/functional_tests/utils.py
100% <100%> (ø)

olga/analytics/views.py
100% <100%> (ø)
:arrow_up:

... and 13 more

Continue to review full report at Codecov.

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

Sorry for trash in commits list.


Issue/110/sidereal

Correction of major typo in "func_sshg1g2": the angular velocity W was written as 2pi*period, I corrected it to 2pi/period.
I ran some tests offline on SSO 9979

RMS sHG1G2 0.063 mag
RMS ssHG1G2 0.047 mag  <-- the version with a simple rotation phase, used in the first wide computation (24/10)
RMS ssHG1G2 0.063 mag  <-- current version of sidereal: the fact that RMS does not improve vs sHG1G2 is suspicious
RMS ssHG1G2 0.047 mag  <-- with the proposed PR

I splitted the commit to ease your review work. Second commit is to clean the code:
The name "spin_angle" was not intuitive, I rewrote it as "cos_aspect_angle", added comments.
I also added comments in other functions for traceability of computation.
And run a PEP8 formatting tool on the file.

One last point, which is crucial:

you compute light-time correction in "estimate_synodic_period" function, but the LT corrected epochs are not filled in the returned pdf
the ssHGG fitting function must be fed with these LT corrected epochs (and not the JD of observations)

I prefer to let you implement that as you have removed it from my original code. Maybe you prefer to recompute the LT correction in the ssHGG function? But then the function must make clear that input JD must not be LT corrected.

the ssHGG fitting function must be fed with these LT corrected epochs (and not the JD of observations)

Hum, good point. As func_sshg1g2 is used internally to fit for the parameters, I would not add the need for adding Dobs in the parameters. So the best is to input the time with light travel correction to estimate_sso_params. I updated the documentation of the function, and I will implement this at the level of the SSOFT (in fink-science).


Bugfix - Incorrect gradients for Ordered Logistic Distribution

Summary
Discovered by @t4c1 in #1248. The ordered logistic distribution is returning incorrect gradients for the ordered cutpoints if the input array of integers has multiple 1's
This was due to the following line:
      if (!is_constant_struct<T_cut>::value)
        ops_partials.edge2_.partials_vec_[n](0) = d;

When T_cut is an Eigen::Vector, partials_vec_[n] always refers to partials_vec_[0], so the gradient calculation was overwriting ops_partials.edge2_.partials_vec_[n](0) at each of the n iterations, rather than incrementing it.
Tests
Added a new test for the gradients when the input array of integers are all 1's
Side Effects
Checklist

[x] Math issue #1248

[x] Copyright holder: Andrew Johnson
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

@bob-carpenter forgot to ping you, this is ready to have another look at


Bugreport of data parser

https://github.com/nerfstudio-project/nerfstudio/blob/a578ac8d1520c79ff0aff7c0e7d51d25feae2afa/nerfstudio/data/dataparsers/phototourism_dataparser.py#L99

"_id" in line 99  referred to the camera_id according to the load function of line 84. In line 99, the key of "imgs" is image_id.
Is it a bug that use camera_id to query dict with key of image_id?

If I recall correctly, the keys should be the same for both, has this line caused an error for you?

Yes.

@thekaka Can you give me the command you're running and the full stack trace so I can try and replicate this?
I seemed to recall during testing that they had the same keys, I guess I remembered incorrectly then :/

Yes. It is probably correct for colmap default process. However, I changed colmap pipeline, and an error happens.
I suggest iterate images instead of cameras, using image id to link the camera. I did it, and it works out.

I can probably put up a quick PR for this, but any chance you can tell me what you've changed? Like did you change something in the colmap utilities file added for parsing the phototourism datasets?

Yes. It is probably correct for colmap default process. However, I changed colmap pipeline, and an error happens.
I suggest iterate images instead of cameras, using image id to link the camera. I did it, and it works out.

I can probably put up a quick PR for this, but any chance you can tell me what you've changed? Like did you change something in the colmap utilities file added for parsing the phototourism datasets?

Sure, here is the modification, please review~
        with CONSOLE.status(f"[bold green]Reading phototourism images and poses for {split} split...") as _:
            cams = read_cameras_binary(self.data / "dense/sparse/cameras.bin")
            imgs = read_images_binary(self.data / "dense/sparse/images.bin")

        poses = []
        fxs = []
        fys = []
        cxs = []
        cys = []
        image_filenames = []

        flip = torch.eye(3)
        flip[0, 0] = -1.0
        flip = flip.double()

        for image_id, img in imgs.items():  #change here
            if image_id not in select_imgs: #change here
                continue

            cam = cams[img.camera_id] #change here
            assert cam.model == "PINHOLE", "Only pinhole (perspective) camera model is supported at the moment"

            pose = torch.cat([torch.tensor(img.qvec2rotmat()), torch.tensor(img.tvec.reshape(3, 1))], dim=1)
            pose = torch.cat([pose, torch.tensor([[0.0, 0.0, 0.0, 1.0]])], dim=0)
            poses.append(torch.linalg.inv(pose))
            fxs.append(torch.tensor(cam.params[0]))
            fys.append(torch.tensor(cam.params[1]))
            cxs.append(torch.tensor(cam.params[2]))
            cys.append(torch.tensor(cam.params[3]))

            image_filenames.append(self.data / "dense/images" / img.name)

There is an assumption that image to camera is one-to-one relation, but actually it is many to one, so I suggested that iterating images instead of cameras.
I tried the original codes with my own dataset, and it turns out the loaded images is less than real size.

Yeah that 100% makes sense that there will possibly be more images than cameras bc there's no guarantee that sfm can get a good camera pose for each image, but doesn't that mean it's a problem if we get our _id's from a set of images, since then when we iterate over our _id's, we might very well get a key error if no camera exists for that image's _id?

cam = cams[img.camera_id]
This line means getting the camera with img's attributes of camera_id instead of using image_id directly.

Closing as this looks stale. Feel free to reopen if needed.


Self implementation - some confusion

Hey guys, I've been implementing Steam Audio and I've got a few high level questions.
Optimal Design
While the documentation does a good job explaining the components and what they're used for, it's not totally clear how they should be implemented. What I mean by that is, in terms of the graph, the order in which stuff is called.
So my impression was
( each sample [ samples > directeffects > reflection > ambisonicdecode ]  )-> [output]
But the documentation seems to imply that reflection per source is prohibitively expensive - especially at realtime. So it would be better to do this:
( each sample [ samples > directeffects-> binaural ]  ) > reflection > ambisonicdecode > [output]
But then I'm a bit confused, because reflection can only take a mono input, so does this mean that when doing listener based reflection it's always going to be mono? Or would you do it individually for each channel?
Pathing
This is for baked only, right? Or can runtime drop probes to populate/refresh in realtime?
Reverb
Reverb plays longer than the sample, and I assume you check the return of iplReflectionEffectApply to see if it's finished and then you can end that source. My assumption is that if you feed it silent buffers after the sample has finished, eventually it'll return IPL_AUDIOEFFECTSTATE_TAILCOMPLETE  to indicate that it's no longer playing any reverb.
This doesn't seem to be the case for me, sometimes it doesn't return IPL_AUDIOEFFECTSTATE_TAILCOMPLETE at all. What could I be doing wrong?
Custom Tracer
I set up a custom tracer, and it's working great for occlusion, but I'm having problems with reflection. When I try to use IPL_REFLECTIONEFFECTTYPE_PARAMETRIC , it works, but whenever I use IPL_REFLECTIONEFFECTTYPE_CONVOLUTION , in iplReflectionEffectApply, it outputs a silent buffer.
Is this a limitation of the custom scene tracer, or should it work? Is there any way to debug why it isn't working? There's nothing from the debug print callback, the rays are definitely running and they're correct. I've been changing vars and moving stuff around for like 6 hours, so I thought I'd better make sure that it's meant to work before I did anything else.

@garrynewman These are all great questions! Responses below.
Optimal Design
Applying reflections to individual sources isn't prohibitively expensive, but it does incur a non-trivial CPU cost, so per-source reflections should be used with careful consideration. That said, note that the way the DSP effects should be connected roughly mirrors the separation between direct sound propagation (sound traveling in a straight line from source to listener), and indirect sound propagation (reflections). So the way we do it in our plugins is:
             [direct effect] ------- [binaural/panning effect]
           /                                                   \
[input] --                                                      + -- [output]
           \                                                   /
             [reflections effect] -- [ambisonic decode effect]

Here, both the direct effect and reflections effects take mono input. The direct effect generates mono output, which is spatialized by either the binaural or panning effects (depending on speaker configuration). The reflections effect generates Ambisonic output, which is spatialized by the Ambisonic decode effect. Both these spatialized outputs are then mixed to produce the final output.
Pathing
Yes, pathing is baked only at the moment.
Reverb
iplReflectionEffectApply always returns IPL_AUDIOEFFECTSTATE_TAILCOMPLETE because it assumes that there might be more input, even after you pass it a silent buffer (for example, you may be playing a speech clip with a brief pause). To address your use case, we would have to add new API functionality to explicitly indicate that the input has ended, and to fetch the reverb tail.
Custom Tracer
No, the custom ray tracer should work identically regardless of which reflection effect type you're using. Can you send a minimal repro program/project that we can use to diagnose the issue? Thanks!

Thank you, this all helped a lot (not as much as having the source though!).
I fixed the custom tracer not working. The problem was that it was sending infinity for the trace length, and I was trying to convert that to inches!