Android native crashes - SIGSEGV

Description
We are experiencing a massive amount of crashes in our production application and we finally determined that it's happening due to the inclusion of the NewRelic RN agent library. The crash is showing up in a few different forms, but all look to be tied back to the same issue.
These crashes happen primarily on Motorola devices (almost 90%) though not exclusively.
We temporarily removed NR from our latest production release and the crashes completely went away.
Steps to Reproduce
We've been able to reproduce this on a few Motorola devices by a combination of backgrounding our app and opening another high-memory app like the camera. It doesn't happen every time you background the app (like this issue) but we can have it happen pretty consistently.
I'm working on getting a reproducible example I can share.
Expected Behavior
The app should not crash with NewRelic turned on.

Additional context
We've been working with the Hermes team for a while on this issue as well to no avail before finding that removing NR resolved the issue.
We also attempted to turn off instrumentation of some packages using excludePackageInstrumentation(...) but that only fixed the issue if we excluded the com.newrelic.agent.android package which obviously didn't allow us to continue using NR.

We upgraded the NR agent to the latest version when we upgraded RN to 0.74.5 in our React Native app a couple of days ago. Since then, we have experienced numerous crashes. Fortunately, this was only in the internal beta.
This is not the first time we’ve had issues with this SDK. Considering how common these use cases are, I can’t believe how the team releases the SDK. They probably don’t test it properly. If they did, they wouldn’t miss these bugs. To be honest, I have lost confidence in this SDK and have decided to disable it for now. I’m sorry to say that the quality of this SDK is very low, and I didn’t expect such a poor-quality product from New Relic. Either the team needs to step up their game or hand it over to a more capable team within the company. We are paying top dollar to New Relic.
         Fatal Exception: java.lang.NoSuchMethodError: No virtual method stop()Z in class Lcom/newrelic/agent/android/ndk/AgentNDK; or its super classes (declaration of 'com.newrelic.agent.android.ndk.AgentNDK' appears in /data/app/~~UXfp2ZvKcxmNz4l0MYNIOg==/com.originmobileapp-et4-xbWwrBKQebcKoc_EfQ==/base.apk!classes5.dex)        at com.newrelic.agent.android.ndk.NativeReporting.stop(NativeReporting.java:108)        at com.newrelic.agent.android.ndk.NativeReporting.shutdown(NativeReporting.java:53)        at com.newrelic.agent.android.AndroidAgentImpl.stop(AndroidAgentImpl.java:589)        at com.newrelic.agent.android.AndroidAgentImpl.stop(AndroidAgentImpl.java:521)        at com.newrelic.agent.android.AndroidAgentImpl.applicationBackgrounded(AndroidAgentImpl.java:681)        at com.newrelic.agent.android.background.ApplicationStateMonitor.notifyApplicationInBackground(ApplicationStateMonitor.java:102)        at com.newrelic.agent.android.background.ApplicationStateMonitor.lambda$uiHidden$0$com-newrelic-agent-android-background-ApplicationStateMonitor(ApplicationStateMonitor.java:63)        at com.newrelic.agent.android.background.ApplicationStateMonitor$$ExternalSyntheticLambda0.run(:2)        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)        at java.lang.Thread.run(Thread.java:1012)

@ladp333 - yep, that's a different issue we've seen as well. The discussion for that crash is happening here: https://github.com/newrelic/newrelic-react-native-agent/issues/183

@MFazio23 Yeh I know.  Apols, I was so frustrated with this sdk so I didn'i care about putting my comment in the right thread . I just dumped my frustration -:)

when trasition my application the foreground to background very fast many times the crash happens
https://github.com/user-attachments/assets/4f3e9d75-5c79-4c0d-b829-9e6050603fd5

@ladp333 @MFazio23 @YuriLima23 the issue is fixed in 1.4.4.
Regarding the Recent Application Crash Issue
We sincerely apologize for the inconvenience caused by the recent application crashes when transitioning to the background. We understand your frustration, and we'd like to provide a detailed explanation of what occurred and the steps we're taking to prevent similar issues in the future.
Root Cause
The issue arose due to a complex interaction between our Android and NDK agent releases:

We use a "+" convention for version numbering of both Android and NDK agents, which automatically pulls the latest versions during builds.
The Android and NDK agents were released in quick succession.
Our testing did not catch the scenario where a newer NDK agent was paired with an older Android agent.

This led to a method not found error, initially misdiagnosed as an NDK-side issue. Our attempt to resolve it by reverting NDK changes in an NDK agent release did not address the core problem: a version mismatch between the Android and NDK agents.
Our Response and Future Prevention
To prevent similar issues in the future, we are implementing the following measures:

More comprehensive testing scenarios on version compatibility between components.
Modifying our release process to ensure thorough validation of all agent combinations.
Reconsidering our use of the "+" convention for version numbers to have more predictable builds.

Moving Forward
We value your trust and are committed to delivering a stable and reliable React Native agent. We will conduct more thorough testing for future releases to prevent such issues from recurring.
If you need any additional information or clarification regarding this issue, please don't hesitate to reach out. We're here to address any concerns you may have.
Thank you for your patience and understanding as we work to improve our product and processes.

@ndesai-newrelic will this require us to to anything than bumping the version to 1.4.4?

@ndesai-newrelic - appreciate the update here and the improved process on your end.
The updated NR agent version fixed https://github.com/newrelic/newrelic-react-native-agent/issues/183 but does not resolve the current issue. I ran another build yesterday with the new library version and I'm seeing the same issue as before. To be clear, this issue is a SIGSEGV that occurs occasionally (primarily on Motorola devices), not a consistent crash every time the app is backgrounded.
What other info can I get for you to help troubleshoot what's going on here? Also, could you please re-open this issue as it is not resolved?

@MFazio23 can you disable nativecrashreporting for android?

@MFazio23 is your issue fixed?

@MFazio23 is your issue fixed?

I'm thinking so, but I'm waiting on a production release to completely confirm. Will update after that's done.

Issue is still occurring for us even with latest version 1.4.5

can you disable nativeCrashReportingEnabled for android?

We gonna lose crash reporting in android this way?

@vlimag nope, it will disable functionality of newrelic NDK agent which records C++ crash.

fyi setting nativeCrashReportingEnabled as false fixed for us @ndesai-newrelic

@vlimag  sounds good.

@MFazio23 is your issue fixed?

I can finally confirm that setting nativeCrashReportingEnabled did indeed fix the issue here. Thank you again!


Clarify that Conduit overrides pod's dnsPolicy and dnsConfig

For background on Kubernetes dnsPolicy and dnsConfig, see https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods-dns-policy
For any pod managed by Conduit, the DNS configuration is completely bypassed. Assuming we want to continue to do this, we should:

Document this in the documentation.
In conduit inject, warn when a pod contains dnsConfig or a non-default dnsPolicy. (Note that the default dnsPolicy is not "Default"; the default is "ClusterFirst."

We might also consider whether we want to actually honor the pod's DNS policy and/or the DNS config. This would probably require us to implement DNS in the proxy.

See also http://blog.kubernetes.io/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes.html for some interesting details on this issue. We should consider allowing the controller Destination service to be configured with a ConfigMap like that.

Based on the solution to #366, we should change course. Instead of documenting that Conduit would potentially break pods using incompatible DNS configuration, we should instead by default avoid injecting the proxy into such pods. We should provide a documented way to get the proxy working with such pods. For example, we could document that one has to remove the incompatible DNS settings. And/or we could implement & document an explicit pod annotation that would override our default decision to assume that such DNS configurations are incompatible.

Based on the investigation in #392 and the current direction of things as described in the conversation at the end of #360 I think it's best to avoid doing anything for this for 0.3. Basically, if we spend the effort to, we should be able to transparently support any DNS policy, automatically. It'd be unfortunate that 0.3 wouldn't do that, but this isn't the most significant DNS transparency issue in 0.3, and we might fix the overall issue in 0.4.

We should hold off on this until #421 is done

I think we should be able to inject to pods with alternate dns policies... but this should be hashed out in terms of the larger transparency project.

@briansmith Do we still need to prevent injection for pods dnsConfig once #155 is resolved? My understanding is that, once the proxy is able to fallback to local dns lookup, dnsConfig won't be a problem (as long as the proxy honors proper dns client semantics wrt /etc/nsswitch.conf etc). Is that correct?

@briansmith Do we still need to prevent injection for pods dnsConfig once #155 is resolved?

My understanding is that, once the proxy is able to fallback to local dns lookup, dnsConfig won't be a problem (as long as the proxy honors proper dns client semantics wrt /etc/nsswitch.conf etc). Is that correct?

That's correct My goal is that the fix for #155 will at least mostly fix this. We might need some follow-up work to be completely resolve it. For example, we might fix #155 assuming that the DNS search path starts with ".$current-namespace.svc.cluster.local. .svc.cluster.local. .cluster.local." and then follow that up in this issue by completely honoring the actual configured DNS search path to handle cases where those items aren't the first items in the list or where they aren't in the list at all. And, also, we'd need to add tests for this in this issue too.

I changed the title to "Support custom dnsPolicy and dnsConfig" to better capture the plan.

@hawkw and I tried to verify that the proxy works with alternate dnsPolicy settings.  We've both observed the following behavior:
Using a spec like:
    spec:
      dnsPolicy: "Default"
      containers:
      - ...

We are able to resolve names like emoji.voto:
root@voter-68dd555fb6-spss2:/# dig +showsearch emoji.voto

; <<>> DiG 9.9.5-9+deb8u15-Debian <<>> +showsearch emoji.voto
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31472
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;emoji.voto.			IN	A

;; ANSWER SECTION:
emoji.voto.		1125	IN	A	<IP_ADDRESS>

;; Query time: 10 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Thu Apr 26 21:50:16 UTC 2018
;; MSG SIZE  rcvd: 44

but requests fail:
root@voter-68dd555fb6-spss2:/# curl -vs http://emoji.voto
* Rebuilt URL to: http://emoji.voto/
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to emoji.voto (<IP_ADDRESS>) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: emoji.voto
> Accept: */*
>

and then 10 seconds pass before the request fails with a 500.
In the proxy's log we see the following:
ERR! conduit_proxy turning operation timed out after 10s into 500
ERR! conduit_proxy::control "controller-client", controller error: Error attempting to establish underlying session layer: operation timed out after 3s
WARN trust_dns_proto::dns_handle error notifying wait, possible future leak: Err(ResolveError(Proto(Timeout), (None, stack backtrace:
   0:     0x55e78dd04e0c - backtrace::backtrace::trace::hef23eb1bdedb9de4
   1:     0x55e78dd040a2 - backtrace::capture::Backtrace::new::h570f24a892cd6a34
   2:     0x55e78dcce917 - <trust_dns_proto::error::ProtoError as core::convert::From<trust_dns_proto::error::ProtoErrorKind>>::from::h043748def247281b
   3:     0x55e78dcc2ec2 - _ZN110_$LT$trust_dns_proto..dns_handle..DnsFuture$LT$S$C$$u20$E$C$$u20$MF$GT$$u20$as$u20$futures..future..Future$GT$4poll17h37890051da49b999E.llvm.17885337389023634268
   4:     0x55e78dc92bd0 - <futures::future::chain::Chain<A, B, C>>::poll::h046c15f0cba805b8
   5:     0x55e78dcba667 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::hbeb65d90d09deaf4
   6:     0x55e78dd58fbf - futures::task_impl::std::set::h0eda14c4de187820
   7:     0x55e78dd5644f - <scoped_tls::ScopedKey<T>>::set::h0efdea05668e906c
   8:     0x55e78dd4cb7f - tokio_core::reactor::Core::poll::hfaacf20236fbcc81
   9:     0x55e78db31643 - tokio_core::reactor::Core::run::hdb7e20c27c731447
  10:     0x55e78db71da8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h808bc1a152c1d7fa
  11:     0x55e78daa5455 - _ZN3std9panicking3try7do_call17h968da37b516bd463E.llvm.6120476831782816583
  12:     0x55e78ddbb82e - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:102
  13:     0x55e78daa87fa - <F as alloc::boxed::FnBox<A>>::call_box::hb783e783e73f8fc2
  14:     0x55e78ddb376b - <alloc::boxed::Box<alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h598f9713c9cb9093
                        at /checkout/src/liballoc/boxed.rs:798
                         - std::sys_common::thread::start_thread::h65eb43a1201d41e6
                        at libstd/sys_common/thread.rs:24
                         - std::sys::unix::thread::Thread::new::thread_start::h711c51a13a158afa
                        at libstd/sys/unix/thread.rs:90
  15:     0x7f5a7ebf9063 - start_thread
  16:     0x7f5a7e71862c - clone
  17:                0x0 - <unknown>)))

It would be useful to see the contents of /etc/resolv.conf and /etc/hosts in the configuration that fails.

running in docker-for-mac:
:; kubectl -n bot exec -c vote-bot voter-68dd555fb6-spss2 -i -t bash
root@voter-68dd555fb6-spss2:/# cat /etc/resolv.conf
nameserver <IP_ADDRESS>
root@voter-68dd555fb6-spss2:/# cat /etc/hosts
# Kubernetes-managed hosts file.
<IP_ADDRESS>	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
fe00::0	ip6-mcastprefix
fe00::1	ip6-allnodes
fe00::2	ip6-allrouters
<IP_ADDRESS>	voter-68dd555fb6-spss2
root@voter-68dd555fb6-spss2:/# dig +showsearch emoji.voto

; <<>> DiG 9.9.5-9+deb8u15-Debian <<>> +showsearch emoji.voto
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37274
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;emoji.voto.			 					IN	A
;; ANSWER SECTION:
cassandra01.		3600	IN	A	<IP_ADDRESS>
;; Query time: 0 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Fri May 18 20:53:18 UTC 2018
;; MSG SIZE  rcvd: 56

For completeness, the errors that @jakerobb reported on Slack were:
ERR! conduit_proxy::control "controller-client", controller error: Error attempting to establish underlying session layer: operation timed out after 3s
WARN trust_dns_proto::dns_handle error notifying wait, possible future leak: Err(ResolveError(Proto(Timeout), (None, stack backtrace:
   0:     0x562b82671e0c - backtrace::backtrace::trace::hef23eb1bdedb9de4
   1:     0x562b826710a2 - backtrace::capture::Backtrace::new::h570f24a892cd6a34
   2:     0x562b8263b917 - <trust_dns_proto::error::ProtoError as core::convert::From<trust_dns_proto::error::ProtoErrorKind>>::from::h043748def247281b
   3:     0x562b8262fec2 - _ZN110_$LT$trust_dns_proto..dns_handle..DnsFuture$LT$S$C$$u20$E$C$$u20$MF$GT$$u20$as$u20$futures..future..Future$GT$4poll17h37890051da49b999E.llvm.17885337389023634268
   4:     0x562b825ffbd0 - <futures::future::chain::Chain<A, B, C>>::poll::h046c15f0cba805b8
   5:     0x562b82627667 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::hbeb65d90d09deaf4
   6:     0x562b826c5fbf - futures::task_impl::std::set::h0eda14c4de187820
   7:     0x562b826c344f - <scoped_tls::ScopedKey<T>>::set::h0efdea05668e906c
   8:     0x562b826b9b7f - tokio_core::reactor::Core::poll::hfaacf20236fbcc81
   9:     0x562b8249e643 - tokio_core::reactor::Core::run::hdb7e20c27c731447
  10:     0x562b824deda8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h808bc1a152c1d7fa
  11:     0x562b82412455 - _ZN3std9panicking3try7do_call17h968da37b516bd463E.llvm.6120476831782816583
  12:     0x562b8272882e - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:102
  13:     0x562b824157fa - <F as alloc::boxed::FnBox<A>>::call_box::hb783e783e73f8fc2
  14:     0x562b8272076b - <alloc::boxed::Box<alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h598f9713c9cb9093
                        at /checkout/src/liballoc/boxed.rs:798
                         - std::sys_common::thread::start_thread::h65eb43a1201d41e6
                        at libstd/sys_common/thread.rs:24
                         - std::sys::unix::thread::Thread::new::thread_start::h711c51a13a158afa
                        at libstd/sys/unix/thread.rs:90
  15:     0x7f0749c81063 - start_thread
  16:     0x7f07497a062c - clone
  17:                0x0 - <unknown>)))
ERR! conduit_proxy::control "controller-client", controller error: Error attempting to establish underlying session layer: operation timed out after 3s
WARN trust_dns_proto::dns_handle error notifying wait, possible future leak: Err(ResolveError(Proto(Timeout), (None, stack backtrace:
   0:     0x562b82671e0c - backtrace::backtrace::trace::hef23eb1bdedb9de4
   1:     0x562b826710a2 - backtrace::capture::Backtrace::new::h570f24a892cd6a34
   2:     0x562b8263b917 - <trust_dns_proto::error::ProtoError as core::convert::From<trust_dns_proto::error::ProtoErrorKind>>::from::h043748def247281b
   3:     0x562b8262fec2 - _ZN110_$LT$trust_dns_proto..dns_handle..DnsFuture$LT$S$C$$u20$E$C$$u20$MF$GT$$u20$as$u20$futures..future..Future$GT$4poll17h37890051da49b999E.llvm.17885337389023634268
   4:     0x562b825ffbd0 - <futures::future::chain::Chain<A, B, C>>::poll::h046c15f0cba805b8
   5:     0x562b82627667 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::hbeb65d90d09deaf4
   6:     0x562b826c5fbf - futures::task_impl::std::set::h0eda14c4de187820
   7:     0x562b826c344f - <scoped_tls::ScopedKey<T>>::set::h0efdea05668e906c
   8:     0x562b826b9b7f - tokio_core::reactor::Core::poll::hfaacf20236fbcc81
   9:     0x562b8249e643 - tokio_core::reactor::Core::run::hdb7e20c27c731447
  10:     0x562b824deda8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h808bc1a152c1d7fa
  11:     0x562b82412455 - _ZN3std9panicking3try7do_call17h968da37b516bd463E.llvm.6120476831782816583
  12:     0x562b8272882e - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:102
  13:     0x562b824157fa - <F as alloc::boxed::FnBox<A>>::call_box::hb783e783e73f8fc2
  14:     0x562b8272076b - <alloc::boxed::Box<alloc::boxed::FnBox<A, Output$u3d$R$GT$$u20$$u2b$$u20$$u27$a$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h598f9713c9cb9093
                        at /checkout/src/liballoc/boxed.rs:798
                         - std::sys_common::thread::start_thread::h65eb43a1201d41e6
                        at libstd/sys_common/thread.rs:24
                         - std::sys::unix::thread::Thread::new::thread_start::h711c51a13a158afa
                        at libstd/sys/unix/thread.rs:90
  15:     0x7f0749c81063 - start_thread
  16:     0x7f07497a062c - clone
  17:                0x0 - <unknown>)))
ERR! conduit_proxy turning Error caused by underlying HTTP/2 error: protocol error: unexpected internal error encountered into 500

We just updated our trust-dns dependency at the end of last week, so we'll retest this and work with upstream to address the issue if it still exists.

Maybe the rest of you already realize this, but I've found a workaround for this issue that works as long as the hosts you need to resolve have static IP addresses. In the pod template YAML, under the "spec" element, you can create a 'hostAliases' element and define entries which will land in the container's /etc/hosts file, essentially circumventing DNS entirely. Here's mine:
spec:
  hostAliases:
  - ip: "<IP_ADDRESS>"
    hostnames:
    - "cassandra01"
  - ip: "<IP_ADDRESS>"
    hostnames:
    - "cassandra02"
  - ip: "<IP_ADDRESS>"
    hostnames:
    - "cassandra03"

Hope this helps someone!

Great to know. Thanks @jakerobb

cassandra01.		3600	IN	A	<IP_ADDRESS>

The most likely reason it failed: Maybe Trust-DNS won't fall back to resolving the single-label unqualified name X as "X." after it tries everything else in the search path? I suggest we add this to Trust-DNS's unit tests and see what happens.

Maybe @bluejekyll knows?

@bluejekyll this error was observed using 0.8.2 (I checked Cargo.lock and it looks like we were pulling in bluejekyll/trust-dns@ce6952c9ba5a41fb0b7c5f90cf1870a5e8029e2d).
I'm planning on doing some testing and seeing if this also occurs with trust-dns-resolver 0.9+.

Interesting, after updating to trust-dns-resolver I now see
ERR! admin={bg=resolver} conduit_proxy::control controller error: Error attempting to establish underlying session layer: operation timed out after 3s
WARN trust_dns_proto::xfer error notifying wait, possible future leak: Err(ResolveError { inner: ProtoError { inner:  request timed out })
ERR! admin={bg=resolver} conduit_proxy::control controller error: Error attempting to establish underlying session layer: operation timed out after 3s
WARN trust_dns_proto::xfer error notifying wait, possible future leak: Err(ResolveError { inner: ProtoError { inner: request timed out })

in the logs from a pod with
    spec:
      dnsPolicy: "Default"
      containers:
      - ...

curling an external name fails with HTTP 500, but it appears after upgrading trust-dns-resolver, the proxy can no longer resolve cluster-local names with dnsPolicy: Default either.
dnsPolicy: ClusterFirst still works fine with the latest trust-dns-resolver.

We need to put #1032 into the next release and then retest this. I think #1032 will make our DNS stuff much more reasonable to think about, which is why it was prioritized.

@briansmith the results above are from a build of Conduit with #1032.
I'm planning on doing some additional digging into this issue.

Nevermind, just re-ran the tests with the master build of conduit, looks like cluster-local names were always broken, prior to the trust-dns-resolver update. I must have failed to document that when I was doing the earlier testing.

cluster-local names were always broken

To clarify, they weren't working yet for custom configurations that aren't using ClusterFirst policy, so this issue isn't resolved yet. They've been working fine for in the default DNS configuration.

@briansmith Yes, that's correct. Updated my original comment to make that clearer.

@bluejekyll
Thanks for following up & looking into the K8s docs!

Are these settings being passed directly into trust-dns-resolver config? meaning, is there some ordering required in the NameServers in the Resolver instance?

This is in fact, what I was going to start looking into next.

@bluejekyll I did the test again using a custom build of trust-dns-resolver the sort_unstable commented out, and I'm still seeing this error. Will keep digging.

In the configuration above in https://github.com/runconduit/conduit/issues/62#issuecomment-390331145 there's only one nameserver.

Is this issue still relevant?

@wmorgan I'm not aware of anything that's happened recently that would fix it, but would have to test to confirm...

We're not bypassing DNS any longer and statefulsets work properly now.


[WIP] Fix dataset import in CVAT format

Motivation and context

How has this been tested?

Checklist

[ ] I submit my changes into the develop branch
[ ] I have added a description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (read github docs)
[ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

I will close this PR as there is a problem here that needs more time, I need to invest first. I opened an issue.


DOJO: Create modules page

Closes https://github.com/garageScript/c0d3-app/issues/1848
This PR creates the modules page and creates the Lessons' page folder. By merging this PR, it'll be possible to create and update the modules.

You might notice the design is different from the one in Figma. This will be fixed in a different PR.
This page is called modules, but it's the new lessons page. It'll be renamed and refactored once more panels are added. It only contains the modules' panel for now.

To test it, access https://c0d3-app-git-fork-flacial-1848-dojo-create-the-cd28db-c0d3-prod.vercel.app/admin/lessons/1/modules

bug: Lesson ID is wrong when admin switch lessons. We should use the slug property instead of ID.


How to add tailwind style to a button?

Describe the bug
Add the tailwind style to button , no effect on that button
rx.button("Click me", class_name="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded")

in Chrome we can see the button style is:
<button type="button" class="chakra-button bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded css-wqpdoh">Click me</button>
if we remove the css-wqpdoh from the class,
the button is tailwind styled:

what's the problem with the button component?
where does the css-wqpdoh and chakra-button class comes from? any idea to block it,
It's easy to get pure tailwind class from designer, otherwise it would be headache to convert tailwind css to other style ,huge repeat work!
Specifics (please complete the following information):

Python Version: 3.10
Reflex Version: reflex==0.3.7
OS: Mac OS
Browser (Optional): Chrome

Hello, there is an issue with Chakra and Tailwind components, they don't play well together. Reflex is switching Chakra components to Radix components.
My advice if you want to style with Tailwind is to use native HTML tags. In your case, it would be rx.el.button().
Best regards.

rx.el.button()

you are the Man !

If you feel comfortable it is the html tags. You can do from reflex import el  and this, it is not necessary to put rx. in front of. So it would be el.button(), el.div(), el.input() 😀

Hi @zfusx has anyone started working on the issue?

Hi @zfusx has anyone started working on the issue?

I don't know we just put into testing, normally designer will give figma with css in tailwind, if we can do all in python, that will be really great, nobody like js and its framework 's Spaghetti code

Yes I would also advise using the components soon our core components will be able to support tailwind but probably won't be ready for a couple weeks


Provide swift-frontend path when running integration tests

Fixes the issues I was running into: https://forums.swift.org/t/lots-of-errors-running-swift-driver-integration-tests/47986
Still 90 failing tests, which is more than the 50 from March 27: https://github.com/apple/swift-driver/pull/365/commits/dadb0a3707f979dedd72d984bbd6b21dea33829d
A lot of Dependencies tests failing with similar looking errors, but first step is actually being able to run the tests :)
This is an example error snippet if anyone is curious:
            8: Failed to read dependency file
check:12'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            9: Traceback (most recent call last):
check:12'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           10:  File "SOURCE_DIR/test/Driver/Dependencies/Inputs/update-dependencies.py", line 53, in <module>
check:12'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           11:  shutil.copyfile(primaryFile, depsFile)
check:12'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           12:  File<EMAIL_ADDRESS>line 264, in copyfile
check:12'0

@swift-ci please test

Running a cross repo test run before merging, just to double check that I don't break anything.
Also figured out what was causing all those Driver/Dependencies failures. It was that I was running the tests in parallel. I'm down to 46 Failures total now, so that's good :)
Any ideas what might be causing the hiccups when running Driver/Dependencies tests in parallel with the other tests? Never had any issues in the past. Maybe some new shared dependencies file location? Is this expected? or a regression that needs to be investigated?


[Task] Migrate to k3s version 1.25

IONOS recently announced that version 1.24 is deprecated on their platform, so we must migrate to version 1.25.


Lint/NestedMethodDefinition should not be triggered in {class|instance|module}_exec

This code doesn't result in a violation:
Module.new.class_eval do
  def foo
  end
end

While this does:
Module.new.class_exec do
  def foo
  end
end

Since class_eval and class_exec are semantically equivalent, with the only difference of being able to pass context through class_exec, the cop behaviour should be the same in both cases.
RuboCop version
$ rubocop -V
0.43.0 (using Parser <IP_ADDRESS>, running on ruby 2.3.1 x86_64-darwin15)

I had to wrap the examples given in methods to duplicate the problem. For instance:
def make_module
  Module.new.class_eval do
    def foo
    end
  end
end

@mikegee I could reproduce on wrapping class_exec inside a method and not class_eval.

This was fixed in #4212. Ping @jonas054. @bbatsov. 🙂


Very much looking forward to the author's open source code

Would like to know the details of the authors' training using pre-trained embedding

Thank you for your interest. I have uploaded the implementation for our diffusion model. I will be updating the repo with the code for the classification experiment and the autoregressive baseline after the holiday season. If you have any additional questions, then please open another issue.


Fixes #815 #814 #812 #811 #762 updates

Additional updates  for Spring Boot mission, runtime details.
@metacosm  can you review runtime details in file  docs/spring-boot-runtime/master.adoc for issue 762.
@cmoulliard can you review  both files for  runtime details and mission changes for  issues 815, 814, 812, 811

LGTM, what do you think @cmoulliard?

@cmoulliard  thanks for  the review per slack. LGTM can you approve  PR.

LGTM too. Go ahead and merge it @lavernw1

Merging...

merged 05d9aedd9


[feat]: Dont convert Selects to use JSON for AxonOps CQL Console

Discussed in https://github.com/axonops/axonops-workbench-cassandra/discussions/277

Originally posted by millerjp June 30, 2024
We currently convert users query to SELECT JSON so it can be displayed in the UI. We need to not do this automatically and convert the results to JSON in the app rather than as part of the query as this can skew the query and the trace information.

We need to think carefully about this @mhmdkrmabd. I think we change our cqlsh python to return JSON instead of plain text and parse the JSON.


feat: Support custom fields on issue create

This PR adds initial support for custom fields on the issue creation. Relates to https://github.com/ankitpokhrel/jira-cli/discussions/222. Fixes #340.
Jira supports a wide variety of datatypes when creating a custom field. Out of all formats mentioned in the Jira doc, the implementation right now doesn't support Cascading select custom field, Single-user picker custom field and  Multi-user picker custom field. Support for these missing types will be added based on the request and the usecase.
Implementation Details
Since we are already using the createmeta endpoint to save metadata during jira init process, this step is modified to save custom field details. The initialization process will now add a new section issue.fields.custom to save required details about configured custom fields.

Next, a new flag --custom is added on create command that accepts a key-value pair.  The key is derived from the name you see in the configuration. This is the same name that you see in the UI making it easy to guess. Dash/hyphen (-) separated lowercase name is used as a key.  The value depends on the datatype of the field. For some datatypes like string, datetime, date, option, the value is a plain string (eg: --custom note="An example note"). For array types, its a comma separated value (eg: --custom platform=iOS,Android).
Example
Given some custom fields as below:

Custom Field
Field Type
Comment

Due Date
Datetime
ISO 8601 ('YYYY-MM-DDThh:mm:ss.sTZD') format

Note
Paragraph
A single or multiline text input

Platform
Checkbox
Array of strings

Quarter
Radio button
Single value string data

Tags
Labels
Array of strings

You can use --custom flag to pass data for custom fields
$ jira issue create -tStory --custom story-points=3 --custom due-date="2022-03-10T14:39:00.000+1100" \
 --custom note="A custom note" --custom platform=Windows,Linux --custom quarter=Q3 --custom tags=p1,q3,y2022

# Or, alternatively

$ jira issue create -tStory --custom=story-points=3 --custom=due-date="2022-03-10T14:39:00.000+1100" \
 --custom=note="A custom note" --custom=platform=Windows,Linux --custom=quarter=Q3 --custom=tags=p1,q3,y2022

The example command above creates a story with defined custom fields of different types as seen in the screenshot below.

Caveats
The Jira API returns invalid types for some locked custom fields. For instance, for the sprint field the returned datatype is an array of strings or JSON depending on the Jira version used. However, that is not true since the create API expects a single numeric value for a sprint field.
In such cases, the config needs to be modified manually to make the field work.
# Details returned by the Jira API for sprint field
- name: Sprint
  key: customfield_10020
  schema:
     datatype: array
     items: json

# Manual change needed to make it work
- name: Sprint
  key: customfield_10020
  schema:
     datatype: number

Testing
To try out this change, you can either build the app locally or install it using the following command.
go install github.com/ankitpokhrel/jira-cli/cmd/jira@request-222

Note that you will have to regenerate the config with jira init.

@ankitpokhrel how does one supplement an extant configuration with custom fields; i.e., how do I do this without re-invoking jira init?

@realtime-neil You can generate config in a new location using XDG_CONFIG_HOME env. For example the command below will generate a new config in current working directory.
 XDG_CONFIG_HOME=. jira init

You can then keep using the same env for subsequent commands or you can use -c/--config option to pass new config location.
$ XDG_CONFIG_HOME=. jira issue create

// or

$ jira issue create -c </path/to/new/.jira/.config.yml>

If you don't want to run jira init, then the config file needs to be prepared manually. issue.fields.custom is the new section added to the config.
issue:
  fields:
    custom:
    - name: Epic Link
      key: customfield_10014
      schema:
        datatype: any
    - name: Sprint
      key: customfield_10020
      schema:
        datatype: number

@ankitpokhrel you're suggesting that, in addition to a given existing configuration, I use jira init to create a completely new configuration in a different location? And then manually resolve the diff between the pair?

you're suggesting that, in addition to a given existing configuration, I use jira init to create a completely new configuration in a different location?

Yes, if you want try out this change without tampering your current config. And if this works, you can simply run jira init and override actual config.

init worked with the custom fields we use (two option fields, and two string fields). I would love to see this expanded to edit too, but fantastic work so far. Thank you!

@m4dc4p Thank you for testing! Yes, it will be expanded to edit once this is merged and stable.

@ankitpokhrel is there any facility for querying available custom fields?

Hi @zsolt-p, the config looks ok to me. I think the problem is with case-sensitive comparison I am doing in one place.
The key is derived from the name you see in the configuration and dash/hyphen (-) separated lowercase name is used as a key. So, for example if your custom field is called DeploymentNote, you should pass --custom deploymentnote="value" (all lowercase) and if your custom field is called Due Date, you should pass --custom due-date="2022-01-01" (lowercase separated with hyphen).
Could you please check and confirm if that works for you? I will make this comparison flexible if you can confirm.

@ankitpokhrel confirming it works
You're right, our custom field has an uppercase char, lowercasing it in the command makes it work, thank you

@vballestra-latch Thank you for the feedback!
Regarding your suggestions, there is a plan to work on a config command (similar to git config) to manage the configurations required for the CLI. However, this may not happen anytime soon because of other priorities.
I haven't given much thought on the command to inspect meta, but that can be included if needed. Let's first see how the users will use this feature and the issues they will run into. We can then decide on the required features.


user.dir vs user.home

Hello,
I am experiencing strange behaviour using system properties in configuration file.
While this example with user.home works
spring.cloud.config.server.git.uri=file://${user.home}/configs
the other does not work:
spring.cloud.config.server.git.uri=file://${user.dir}/configs
I am running on Linux Mint 19.3.

I don't think this has anything to do with config server. Those values come from either system properties or environment variables. So one of them isn't set with a combination of your os and jdk.


Cleanup examples

Have you checked that all these trixi_include commands give you the simulations you want? It's easy to miss something and end up with an incorrect simulation setup.

yes I have just scrolled through again. As far as I know everything should be fine. At least all of the values that are defined are used.


Fix config rollback behavior.

Currently, if you add another version of an existing config (same name
and type), then delete that config, when deploying, bosh won't find
the prior config and will remove it from the deployment entirely. This
is surprising behavior because bosh configs correctly lists the prior
version. This commit fixes that behavior so that bosh will use the
prior version configuration in this scenario.
[#179020742]

Signed-off-by: Rajan Agaskar<EMAIL_ADDRESS>What is this change about?
Describe the change and why it's needed.
Please provide contextual information.
Include any links to other PRs, stories, slack discussions, etc... that will help establish context.
What tests have you run against this PR?
Include a comprehensive list of all tests run successfully.
How should this change be described in bosh release notes?
Something brief that conveys the change and is written with the Operator audience in mind.
See previous release notes for examples.
Does this PR introduce a breaking change?
Does this introduce changes that would require operators to take care in order to upgrade without a failure?
Tag your pair, your PM, and/or team!
It's helpful to tag a few other folks on your team or your team alias in case we need to follow up later.

Thanks! @camilalonart


Firefox: Empty space displayed in popup menu when extension is pinned to Overflow Menu

Description
Empty space is displayed on the right side of content inside the popup menu when extension is pinned to overflow menu.
Steps to Reproduce

Install extension
Right-click on the extension icon on taskbar, select "Pin to Overflow Menu"
Open overflow menu by clicking on the hamburger icon
Click on the extension icon to display the popup menu

Expected behavior:
Popup menu is sized accordingly, no empty space is displayed.
Actual behavior:
Popup menu is too wide, empty space is displayed.

Versions

Extension: 2019.12.12
Browser: 72.0.2
OS: macOS 10.15.3

I found the same problem. I thought I would have to remove the extension to allow one sight through, because I didn’t realise I could whitelist it this way. Thanks for reporting the issue.

Few months later and it now looks even worse with that "hole" in search bar.


Add BSD 2-Clause License

Add BSD 2-Clause License, which the original nuget package was licensed under.
(https://www.nuget.org/packages/plist.net/)
I wasn't quite sure who you wanted as the copyright holders, or who is the actual 'Author' of this, so I've simply put it down as "PList-Net Contributors". Feel free to change that to something more appropriate when merging.
fixes #14

Lgtm


[test] Update Amber test to new syntax and add support for Eiger and Pilatus

I am adding support for Eiger and Pilatus, where the number of cores per node is so high that one cannot run the simulations with the same amount of nodes. Therefore, the small tests run with 4 nodes instead of 6 and the large ones with 8 nodes instead of 16. We could alternatively, on Eiger just test the small one with 6 nodes. Let me know what you think.
I have also extended the number of tests from 1 to 4 and I have appended the name of the input files to the test name.
The former Amber test was based on the system Cellulose_production_NVE.
Furthermore, I have simplified the logic of the tags. Before we were having one dimension to describe two different sets of tests (maint and prod), which were exactly the same. Now we just have one dimension (small and large). And both have the maintenance and production tags. As before, the health tag is only added to the single node GPU tests.
Additionally, I have made the tests more reusable outside CSCS.
I have created the GitHub repo Amber Benchmark Suite, which holds the input files for the Amber tests.
Now the tests download directly the required input files.
I could alternatively, have downloaded the original benchmark suite, but the file is 84.1 MB and expands to a bit more than 500 MB because it is comprised of the full suite. In this case, we would have all files for a bunch of systems that we do not test in every test, which IMHO is a waste.
I have only added the NVE part of the benchmark suite, the reason being the fact that this is the only one that we can reliably test the sanity. The NPT simulations depend on the pseudo-random numbers and I would need to change the original input files in order to make their energy output more reproducible. I can change the input files but for now, I would like to experiment with these NVE systems first.
Please take a look and let me know what you think.

Hello @victorusu, Thank you for submitting the Pull Request!

In the file cscs-checks/apps/amber/amber_check.py:

Line 13:16: E203 whitespace before ':'
Line 14:35: E203 whitespace before ':'
Line 15:34: E203 whitespace before ':'
Line 16:33: E203 whitespace before ':'
Line 17:29: E203 whitespace before ':'
Line 19:14: E203 whitespace before ':'
Line 20:35: E203 whitespace before ':'
Line 21:34: E203 whitespace before ':'
Line 22:33: E203 whitespace before ':'
Line 23:29: E203 whitespace before ':'
Line 25:8: E203 whitespace before ':'
Line 26:35: E203 whitespace before ':'
Line 27:34: E203 whitespace before ':'
Line 28:33: E203 whitespace before ':'
Line 29:29: E203 whitespace before ':'
Line 34:15: E203 whitespace before ':'
Line 35:35: E203 whitespace before ':'
Line 36:34: E203 whitespace before ':'
Line 37:33: E203 whitespace before ':'
Line 38:29: E203 whitespace before ':'
Line 40:13: E203 whitespace before ':'
Line 41:35: E203 whitespace before ':'
Line 42:34: E203 whitespace before ':'
Line 43:33: E203 whitespace before ':'
Line 44:29: E203 whitespace before ':'
Line 46:15: E203 whitespace before ':'
Line 47:35: E203 whitespace before ':'
Line 48:34: E203 whitespace before ':'
Line 49:33: E203 whitespace before ':'
Line 50:29: E203 whitespace before ':'
Line 52:17: E203 whitespace before ':'
Line 53:35: E203 whitespace before ':'
Line 54:34: E203 whitespace before ':'
Line 55:33: E203 whitespace before ':'
Line 56:29: E203 whitespace before ':'
Line 58:8: E203 whitespace before ':'
Line 59:35: E203 whitespace before ':'
Line 60:34: E203 whitespace before ':'
Line 61:33: E203 whitespace before ':'
Line 62:29: E203 whitespace before ':'
Line 67:15: E203 whitespace before ':'
Line 68:35: E203 whitespace before ':'
Line 69:34: E203 whitespace before ':'
Line 70:33: E203 whitespace before ':'
Line 71:29: E203 whitespace before ':'
Line 73:15: E203 whitespace before ':'
Line 74:35: E203 whitespace before ':'
Line 75:34: E203 whitespace before ':'
Line 76:33: E203 whitespace before ':'
Line 77:29: E203 whitespace before ':'
Line 79:8: E203 whitespace before ':'
Line 80:35: E203 whitespace before ':'
Line 81:34: E203 whitespace before ':'
Line 82:33: E203 whitespace before ':'
Line 83:29: E203 whitespace before ':'
Line 110:80: E501 line too long (139 > 79 characters)
Line 118:39: E203 whitespace before ':'
Line 119:38: E203 whitespace before ':'
Line 120:37: E203 whitespace before ':'
Line 121:33: E203 whitespace before ':'
Line 138:17: E128 continuation line under-indented for visual indent
Line 148:38: E128 continuation line under-indented for visual indent
Line 205:12: E111 indentation is not a multiple of four
Line 206:12: E111 indentation is not a multiple of four
Line 207:16: E111 indentation is not a multiple of four
Line 208:12: E111 indentation is not a multiple of four
Line 209:16: E111 indentation is not a multiple of four
Line 210:12: E111 indentation is not a multiple of four
Line 223:1: W391 blank line at end of file

Do see the ReFrame Coding Style Guide

Codecov Report

Merging #2018 (862971e) into master (bc59cb9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2018   +/-   ##
=======================================
  Coverage   87.48%   87.48%
=======================================
  Files          50       50
  Lines        8848     8848
=======================================
  Hits         7741     7741
  Misses       1107     1107

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 bc59cb9...862971e. Read the comment docs.

The failed CI is unrelated to test

@jjotero, I have updated the test based on our off-line conversation...

@victorusu What about all those PEP complaints?

@jjotero, I hadn't seen them! I will fix them!

The fix is done... The CI error is spurious... Can we merge this?

The CI error is spurious... I can remove pilatus from the available systems and the CI would pass. Should I do that?

@victorusu I'd say you go ahead and click that merge button! 😉

@jjotero, thanks! Done!


Update NGINX default.conf.template - adding MIME types support

Hey, I just made a Pull Request!
Without MIME types enabled Nginx services files as text/plain. This is not supported eg. in the Firefox - it does not load CSS files with wrong Content-Type header. This caused stopped to work GraphQL plugin.
:heavy_check_mark: Checklist

[x ] All your commits have a Signed-off-by line in the message. (more info)

@Vity01 thanks for this! :pray:


Saving conformed input in FastSurferCNN to use in recon-surf

Description
This PR adds saving of the conformed image used as input to the FastSurferCNN network, so that it can later be used in recon-surf.sh.
Previously, mri_convert  -c was used in recon-surf.sh to create orig.mgz from the input image. If the input image was not conformed to 256 beforehand, this caused a mismatch between the image and output segmentation (leading to issues as in  https://github.com/Deep-MI/FastSurfer/issues/45).
The modification ensures that the mismatch does not occur by always passing in the saved conformed input image to recon-surf.sh (through run_fastsurfer.sh by default).
The conform.py script is used to check whether both input image and segmentation are conformed in recon_surf.sh (for the latter, the UCHAR criterion is disregarded). If either is not, recon_surf.sh will fail. This check is necessary to validate inputs that are not produced by FastSurferCNN, for example.
The script has been slightly modified to enable this behaviour.
Changes
Here's a brief summary of the changes:

is_conform also checks whether dtype of input is UCHAR (uint8)
is_conform can display specifically which conformance criteria were violated (controlled by verbosity flag: off by default in the script, but on by default in recon_surf.sh); see example output below
is_conform has a check_dtype flag, which is off when the input image is a segmentation
conform.py has check_only (only check if the input image is conformed) and seg_input (consider the input image a segmentation, and set check_dtype to True) flags, and returns appropriate error codes
eval.py writes out the conformed input image
run_fastsurfer.sh specifies conformed_input, the path of the to-be conformed input image (default: /mri/conformed_orig.mgz)
run_fastsurfer.sh passes in conformed_input to the t1 argument of recon-surf.sh by default
recon_surf.sh uses conform.py to check for conformance of t1 and seg

is_conform verbose output example
An example of a non-conformed input image being used as input to conform.py, with flags check_only and verbose:
Reading input: ./001.mgz ...
The input image is not conformed.
A conformed image must satisfy the following criteria:
 - Dimensions 256x256x256:        False
 - Voxel size 1x1x1:              False
 - Orientation LIA:               False
 - Dtype uint8:                   False
check_only flag provided. Exiting without conforming input image.

about conform.py I do not think the script itself should have a default filename in it anywhere! It should always be passed as a parameter.

recon_surf   check_only should not convert images (as it is a check routine and should not change things). We can keep using mri_convert for that for now. Or we can write our own convert.py to cover some of the mri_convert functionality, e.g. converting between image formats. For now it is sufficient to keep using mri_convert (without the -c flag of course, only converting nil to mgz for example).

And finally run_fastsurfer : is this a wrapper around everything (including segmentation)? Then why does the input need to be a conformed images? It should conform it by default. Only recon_surf will require conform images together with conform segmentation to work. Most people will not call recon_surf directly. The supported use cases are:

call everything (including segmentation and surface processing)
call only segmentation (here in the future we need to add a simple way of producing volume statistics similar to aseg.stats directly for users who do not care about surfaces, but would like to use the stats from the segmentation).

I updated the list. The --t1 and --seg conform requirement should of course be for recon-surf.sh, not run_fastsurfer.sh (added to the wrong subsection). Personally, I think it is more convenient to directly return the .mgz image in check_conform when a specific run_fastsurfer flag or sth is set. But we can also keep mri_convert. Potentially, we can also just use the save_img routine to do this (as it is just a matter of changing the file-type).
One note, with run_fastsurfer.sh you can also just run the surface pipeline. This is useful, if e.g. you have a GPU server and CPU server. So you first generate the segmentations only on the GPU and then run the recon-surf part on  a CPU server. We have to make sure that in this case, the same command will run through both times (automatically finding the conformed image).

Thanks for the feedback @LeHenschel.
I'll update the PR accordingly. Regarding testing, I usually only push changes after having extensively tested on different case variations; I'll make sure to cover all instances I can think of.
To clarify a few points:

I was going to include converting to mgz in conform.py, but I recalled @m-reuter mentioning at some point that he did not want conform.py to perform any conversions
conformed_input (name subject to improvement) was not exposed as an argument in run_fastsurfer.sh, because I thought we would want the filename to be standardized/fixed (e.g. always mri/orig.mgz). But I’ll make that parameterizable too.

Update
The following changes have been made:

removing default output filename in conform.py
in conform.py, if --check_only and an output filename is given, an error is raised
renaming conformed_input to conformed_name (following discussions)
exposing run_fastsurfer.sh argument conformed_name
the default value of conformed_name: ${sd}/${subject}/mri/orig.mgz
saving of original image in ${sd}/${subject}/mri/orig/001.mgz (in eval.py); the method used here will be changed once the PR containing the save_image functionality is merged (note that this is currently always saved in mgz format)
updating documentation: descriptions of arguments in respective scripts
updating READMEs with mentions of conformed_name argument, and requirements of conformed image and segmentation inputs to recon_surf (including note on possibility of utilizing conform.py for non-conformed images).

Still Open
These should address the items in the list above, with the exception of the following:

Items 6 and 7 under eval.py will be addressed once https://github.com/Deep-MI/FastSurfer/pull/86 is merged; save_image contains the functionality needed to save the image in one of the supported formats.
In item 2 under recon-surf.sh, a mention of the "downside of resampling segmentation" is still missing. I am not clear on this yet.

Testing
For more explicit details on testing, I'm also including the different test cases (combinations of inputs and command variations) that I used to validate the modifications to i) using the conformed image within the pipeline, ii) conform.py (with the new flags, etc.) below.
For conform.py, the terminal output is also included in each case.

 Pipeline tests
These test cases include the following variations:

Whether the input was conformed or not
Which parts of the pipeline were run (full, seg+surf with main script, seg+surf with separate scripts)
Whether the input was a mgz, nii, or nii.gz file (last two in cases 7 and 8, respectively)

1. Running full pipeline with run_fastsurfer.sh on conformed input image
Command:
/run_fastsurfer.sh --t1 /data_dir/mri/T1.mgz --sd /output_dir/test_case_1 --sid 00001 --batch 8 --parallel --fs_license /fs60/.license

Result: Succeeds, as expected.
2. Running segmentation and surface generation separately with run_fastsurfer.sh on conformed input image
Commands:
./run_fastsurfer.sh --t1 /data_dir/mri/T1.mgz --sd /output_dir/test_case_2 --sid 00001 --batch 8 --seg_only

./run_fastsurfer.sh --t1 /output_dir/test_case_2/00001/mri/orig.mgz --sd /output_dir/test_case_2 --sid 00001 --parallel --fs_license /fs60/.license --surf_only

Result: Succeeds, as expected.
3. Running segmentation and surface generation separately with eval.py and recon-surf.sh on conformed input image
Commands:
python3.6 ./FastSurferCNN/eval.py --in_name /data_dir/mri/T1.mgz --out_name /output_dir/test_case_3/00001/mri/aparc.DKTatlas+aseg.deep.mgz --conformed_name /output_dir/test_case_3/00001/mri/orig.mgz --batch_size 8 --simple_run

./recon_surf/recon-surf.sh --t1 /output_dir/test_case_3/00001/mri/orig.mgz --sd /output_dir/test_case_3 --sid 00001 --parallel --fs_license /fs60/.license

Result: Succeeds, as expected.
4. Running full pipeline with run_fastsurfer.sh on non-conformed input image
Command:
./run_fastsurfer.sh --t1 /data_dir/mri/orig/001.mgz --sd /output_dir/test_case_4 --sid 00001 --batch 8 --parallel --fs_license /fs60/.license

Result: Succeeds, as expected.
5. Surface generation with recon_surf.sh on non-conformed input image, conformed input segmentation
(NOTE: eval.py is just used to generate the segmentation)
Commands:
python3.6 ./FastSurferCNN/eval.py --in_name /data_dir/mri/orig/001.mgz --out_name /output_dir/test_case_5/00001/mri/aparc.DKTatlas+aseg.deep.mgz --conformed_name /output_dir/test_case_5/00001/mri/orig.mgz --batch_size 8 --simple_run

./recon_surf/recon-surf.sh --t1 /data_dir/mri/orig/001.mgz --sd /output_dir/test_case_5 --sid 00001 --parallel --fs_license /fs60/.license

Result: recon_surf.sh fails due to the non-conformed image, as expected, with the following error:
python3.6 /fastsurfer/recon_surf/../FastSurferCNN/data_loader/conform.py -i /data_dir/mri/orig/001.mgz --check_only --verbose
Reading input: /data_dir/mri/orig/001.mgz ...
The input image is not conformed.
A conformed image must satisfy the following criteria:
 - Dimensions 256x256x256:        False
 - Voxel size 1x1x1:              False
 - Orientation LIA:               False
 - Dtype uint8:                   False
check_only flag provided. Exiting without conforming input image.

Command exited with non-zero status 1

6. Surface generation with recon_surf.sh on conformed input image, non-conformed input segmentation
(NOTE: eval.py is used to generate a "faulty" segmentation. This segmentation is manipulated to violate one of the conformance criteria by adding an extra dimension in the middle channel using pred_prob = np.hstack((pred_prob, np.zeros((pred_prob.shape[0], 1, pred_prob.shape[2])))). The seg argument is then used to pass in this segmentation as input to recon_surf.sh)
Commands:
python3.6 ./FastSurferCNN/eval.py --in_name /data_dir/mri/T1.mgz --out_name /output_dir/test_case_6/00001/mri/aparc.DKTatlas+aseg.deep.faulty.mgz --conformed_name /output_dir/test_case_6/00001/mri/orig.mgz --batch_size 8 --simple_run

./recon_surf/recon-surf.sh --t1 /output_dir/test_case_6/00001/mri/orig.mgz --sd /output_dir/test_case_6 --sid 00001 –seg /output_dir/test_case_6/00001/mri/aparc.DKTatlas+aseg.deep.faulty.mgz --parallel --fs_license /fs60/.license

Result: recon_surf.sh fails due to the non-conformed segmentation, as expected, with the following error:
python3.6 /fastsurfer/recon_surf/../FastSurferCNN/data_loader/conform.py -i /output_dir/test_case_6/00001/mri/aparc.DKTatlas+aseg.deep.faulty.mgz --check_only --seg_input --verbose
Reading input: /output_dir/test_case_6/00001/mri/aparc.DKTatlas+aseg.deep.faulty.mgz ...
The input image is not conformed.
A conformed image must satisfy the following criteria:
 - Dimensions 256x256x256:        False
 - Voxel size 1x1x1:              False
 - Orientation LIA:               True
check_only flag provided. Exiting without conforming input image.

Command exited with non-zero status 1

7. Running full pipeline with run_fastsurfer.sh on non-conformed input image in nii format
(NOTE: the input was generated using mri_convert 001.mgz 001.nii)
Command:
./run_fastsurfer.sh --t1 /fastsurfer/001.nii --sd /output_dir/test_case_7 --sid 00001 --batch 8 --parallel --fs_license /fs60/.license

Result: Succeeds, as expected.
8. Running full pipeline with run_fastsurfer.sh on non-conformed input image in nii.gz format
(NOTE: the input was generated using mri_convert 001.mgz 001.nii.gz)
Command:
./run_fastsurfer.sh --t1 /fastsurfer/001.nii.gz --sd /output_dir/test_case_8 --sid 00001 --batch 8 --parallel --fs_license /fs60/.license

Result: Succeeds, as expected.

 conform.py tests
These test cases include the following variations:

Whether the input was conformed or not
Whether the input was an image or a segmentation result
Different combinations of flags (-check_only, --seg_input, --verbose, -o)

1. Only checking an already conformed image
Arguments: -i, --check_only
Input: a conformed image
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/T1.mgz --check_only

Output:
Reading input: /data_dir/T1.mgz ...
Input /data_dir/T1.mgz is already conformed! Exiting.

2. Only checking a non-conformed image
Arguments: -i, --check_only
Input: a non-conformed image
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/001.mgz --check_only

Output:
Reading input: /data_dir/001.mgz ...
The input image is not conformed.
check_only flag provided. Exiting without conforming input image.

3. Only checking a non-conformed image, with verbose output
Arguments: -i, --check_only, --verbose
Input: a non-conformed image
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/001.mgz --check_only --verbose

Output:
Reading input: /data_dir/001.mgz ...
The input image is not conformed.
A conformed image must satisfy the following criteria:
 - Dimensions 256x256x256:        False
 - Voxel size 1x1x1:              False
 - Orientation LIA:               False
 - Dtype uint8:                   False
check_only flag provided. Exiting without conforming input image.

4. Conforming a non-conformed image
Arguments: -i, -o
Input: a non-conformed image
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/001.mgz -o /data_dir/001_conformed.mgz

Output:
Reading input: /data_dir/001.mgz ...
The input image is not conformed.
Input:    min: 0.0  max: 2221.3564453125
rescale:  min: 0.0  max: 1090.6860146484375  scale: 0.23379780851246593
Output:   min: 0.0  max: 255.0
Writing conformed image: /data_dir/001_conformed.mgz

5. Conforming a non-conformed image, including check_only flag
Arguments: -i, -o , --check_only
Input: a non-conformed image
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/001.mgz -o /data_dir/001_conformed.mgz –check_only

Output:
ERROR: You passed in check_only. Please do not also specify output image

NOTE: As desired, passing in an output filename along with check_only causes an error to be raised.
6. Only checking a conformed segmentation
Arguments: -i, --check_only
Input: a conformed segmentation
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/aparc.DKTatlas+aseg.deep.mgz --check_only

Output:
The input image is not conformed.
check_only flag provided. Exiting without conforming input image.

NOTE: This conformed segmentation input was incorrectly classified as not conformed, because the --seg_input flag was not used to clarify that the input is a segmentation. Because of this, the dtype criteria (which is not necessary for segmentations) is not ignored, and thus is checked and leads to flagging this as not conformed.
7. Only checking a conformed segmentation, including seg_input flag
Arguments: -i, --check_only, --seg_input
Input: a conformed segmentation
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/aparc.DKTatlas+aseg.deep.mgz --check_only --seg_input

Output:
Input /data_dir/aparc.DKTatlas+aseg.deep.mgz is already conformed! Exiting.

NOTE: The previous mistake is avoided by specifying --seg_input.
8. Only checking a non-conformed segmentation, including seg_input flag
Arguments: -i, --check_only, --seg_input
Input: a non-conformed segmentation
Command:
python3 FastSurferCNN/data_loader/conform.py -i /data_dir/aparc.DKTatlas+aseg.deep.faulty.mgz --check_only --seg_input

Output:
The input image is not conformed.
check_only flag provided. Exiting without conforming input image.

NOTE: The previous mistake is avoided by specifying --seg_input.

I added an argument conformed_img_filename to the fastsurfercnn function.
This is needed particularly when processing multiple subjects, where the path to each conformed image to be saved will differ.

Updated with latest from master and integrated save_image from #86.
Tested on mgz, nii, and nii.gz input images.
Among the earlier comments, item 6 under eval.py mentions saving the conformed image in a format matching the output segmentation, but we also currently infer the format from the conformed_name argument (for e.g. orig.mgz).
Which criteria should decide the output format?
@LeHenschel

I reviewed the changes and added some suggestions. For the question regarding the saving format of the original image: if the user specifies the conformed_name, this should be the criteria to decide the output format on. We might want to a.) include a warning, that the format of the segmentation and conformed input are not identical + how to change conformed input output type (--conformed_name flag) b.) save by default a version of the input image, which matches the segmentation (in addition to the conformed_name).
I tend toward option a.). What are your opinions @m-reuter, @AhmedFaisal95?

I also think option a may be better.


subject or causer is null

I am trying to understand this package, i did a test log, trying to access the causer or the subject of the log returns null. description is ok.
$item=Item::first();
$user=User::first();
activity()->peformedOn($item)->by($user)->log('This is a test log');
$lastActivity=Activity::all()->last();
$subject=$last->subject;
$causer=$last->causer;
both the subject variable as well as the causer variables are null, is there something that i am doing in correctly or why is it returning null. Activity logs the model name and id correctly to the database but returns null on subject or cause.
Laravel 5.5
Activitylog: 2.3

there is a typo in the provided code
$lastActivity=Activity::all()->last();
$subject=$lastActivity->subject;
$causer=$lastActivity->causer;

// dry dumping it
dd($subject, $causer);

Make sure you have stored $item and $user in db, if related model were not found it will return null

I tried dry dumping, still they are null. as can be seen in the code above, i passed the models of item and user to the activity(), and saved a test log. the related model is present in the database. is there something i am missing ?

Hi!
Taken from the readme:
activity()
   ->performedOn($anEloquentModel)
   ->causedBy($user)
   ->log('something')

The method name is called causedBy, not by. Not sure why the subject is null as well but this might solve both of the issues.

Sorry for the typos in the example code above. i ran the code without typos, still its returning null.
As explained in the documentation, the alias for causedBy is "by" and the alias for performedOn() us On. so technically this should work. any other help apart from typos ?


Training a general version?

First of all, one of the most impressive research projects I've ever come across. Thank you for being so cool!
Second, I'm very curious if it's possible to train a general version of G.pt, so maybe take all the models on huggingface and dump them in + as many other datasets as possible.
Would G.pt as it is now be useful for optimizing, say, a language model or some domain it wasn't trained on?

Hi @youssefabdelm, thanks for the generous comment. We think multi-task/architecture G.pt models are definitely a cool direction to explore. There would probably need to be a handful of changes to the current model to support multi-architecture training (mainly replacing the per-token encoder/decoders). It'll be cool to see what generalization properties could emerge in a model trained with a sufficiently large and diverse dataset of checkpoints!


support ScrollView while using closeOnDragDown

hi,
Doesn't work for label "FlatList" :(

@sekizlipenguen , check now

I know it's been a few weeks, but just wondering if you can merge this request if it's working? My UI looks good on portrait mode, but gets really janky on landscape, plus I don't want to try to fit my UI for different devices. Scrollview is really needed along with the drag to close option (makes it feel like a real mobile app instead of just a website)

I found a solution to this problem that may have some performance or unknown interactions, but that works for me at least (A dragToClose raw-bottom-sheet where the top of it is drag to close, but the bottom 90% of it is a ScrollView)
Wrap your components in a TouchableWithoutFeedback:
<RBSheet ref={ref=>this.RBSheet = ref} closeOnDragDown {...otherProps}>
   <ScrollView>
       <TouchableWithoutFeedback>
           <View>
               {children}
           </View>
       </TouchableWithoutFeedback>
   </ScrollView>
</RBSheet>

// Note* TouchableWithoutFeedback can only have a single child, hence the View component.

Hello @rhrahul @KjellConnelly, as you can see everything is working fine in my example. I'm not able to use your snippet code to test, so could you please create a new simple snippet to prove it doesn't work?

Hi @nysamnang, ScrollView as a child with closeOnDragDown is not working in current code, you can check it, and let me know :)

@rhrahul  This code is in the example folder and it works normally!

@rhrahul This code is in the example folder and it works normally!

Strange !!
It wasn't working for me that's why I've to made these changes in code.

only works when the all modal content is wrapped with any touchable component


Create synergy with DCP library?

Hello sirs,
as @jayvdb mentioned in https://github.com/browniebroke/django-codemod/issues/23, Django-Compat-Patcher has some code snippets which might interest you.
The two projects have similar goals, but with different tactics.
If I understand correctly, django-codemod works by statically rewritting the code of django projects/libs to conform to newer Django API ; whereas DCP works at runtime, by forcing the Django framework itself to acknowledge olders ways of doing.
So django-codemod "solves" the technical debt of a specific library, while DCP keeps it, but ensures that third-party django libs included in the project will work fine too, without forking them first.
I haven't thought much about it, but maybe there is some code/trick sharing to do between both projects?

Hey, yes from what I gathered, the approach are quite different.
If I understood correctly, DCP uses compat-patcher-core to implement the patcher, right?
Django-Codemod uses libCST, to work with concrete syntax tree (this an exhaustive version of the AST), and implements codemodders for it. This library is really tied to `libCST`` in terms of how we modify the code.
Maybe @jayvdb has some ideas, I haven't thought about it much either.

Ideas documented at https://github.com/pakal/django-compat-patcher/issues/12
Mostly about building a common dataset of Django deprecations/removals, ideally in a format that both libraries can separately implement fixers for.  The renames are the obvious candidate for this- fairly simple.
libCST may be a useful tool for automatically generating metadata for diffs between Django versions, but renames of interest occur at the module level and typically only need an AST.  I couldnt find any mature existing solution, but I suspect that one might be found by using a tool like https://github.com/timothycrosley/pdocs on each version of Django, keep its internal representation before it emits docs, and doing a diff between the internal representations for each version of Django.
It seems quite sensible for docs tools to have this feature, showing a real change log of the effective public interface, not limited to what humans remembered to put into manual docs or git messages, etc.

Another idea is to use django-codemod to detect which fixes are needed (and create a patch to send upstream), and use that information to configure DCP to only apply the needed fixes.
The reason I prefer using DCP in production is so that it is using known official PyPI versions, and doesnt become an assortment of patched dependencies.
If django-codemod and DCP have a similar naming convention for their fixes, it becomes trivial to use them in that two-pronged approach of using the released version while pushing to get a new fixed released version.
To facilitate that, it would help if django-codemod had support for detection of problems that a fixer hasnt yet been built for.  Then it is easier to port all of the DCP fixers to codemod detectors, and then writing the codemod fixers can come later (and some will be quite difficult).

Two other projects I ran into

https://github.com/aalekseev/healthy-projects
https://github.com/spapas/django-modernize


sqlc not generating GoLang code

Version
1.18.0
What happened?
PS C:\Users\HP\Desktop\go> sqlc generate
package postgres
schema.sql:1:1: the PostgreSQL engine does not support Windows
Relevant log output
PS C:\Users\HP\scratch> sqlc version
v1.18.0
PS C:\Users\HP\scratch> psql --version
psql (PostgreSQL) 15.3
PS C:\Users\HP\scratch> sqlc generate
# package database
sql\schema\001_users.sql:1:1: the PostgreSQL engine does not support Windows.
PS C:\Users\HP\scratch>

Database schema
-- +goose Up

CREATE TABLE users (
    id UUID PRIMARY KEY,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL,
    name TEXT NOT NULL
);

-- +goose Down
DROP TABLE users;

SQL queries
-- name: CreateUser :one
INSERT INTO users (id, created_at, updated_at, name)
VALUES($1,$2,$3,$4)
RETURNING *;

Configuration
version: "2"
sql:
  - schema: "sql/schema"
    queries: "sql/queries"
    engine: "postgresql"
    gen:
      go:
        out: "internal/database"

Playground URL
No response
What operating system are you using?
Windows
What database engines are you using?
PostgreSQL
What type of code are you generating?
Go

Any update on this? funny enough i have the exact same error with the exact same same schema, query, and config. I'm assuming you're following the freeCodeCamp tutorial. The only difference however is that i am running this on M1 Macbook Pro

Any update on this? funny enough i have the exact same error with the exact same same schema, query, and config. I'm assuming you're following the freeCodeCamp tutorial. The only difference however is that i am running this on M1 Macbook Pro
hey @itsdula,
Use SQLC docker image.
It will work fine then

As the error message states, the PostgreSQL engine is supported on Windows. You'll need to either use Docker or WSL2


Double click name in chat to message

http://forums.faforever.com/forums/viewtopic.php?f=42&t=10717&p=108997#p108997

7a1f48fcbfaace443aba72969762017bab557ee3 added

Not yet in master, pushing back

now single click

#103


feat: add gradio demo notebook

Closes #16.

There are three things to comment:

Since we are going to inject which model to use from 🤗 Model Hub, we need to reference a model hosted in 🤗 Model Hub. I have prepared a test repository just now: https://huggingface.co/chansung/test-unet/tree/main.

It seems like we can leverate from_pretrained_keras API from huggingface_hug package.

In order to generalize a bit, I think it could be better to make labels.txt file while removing def sidewalk_palette() from the code.

It would be nice to include a couple of default images to run inference

WDYT?

In order to generalize a bit, I think it could be better to make labels.txt file while removing def sidewalk_palette() from the code.

Sure we can do that when writing code for the Hugging Face space. For a notebook that benefits from interactive usage, I think it would introduce unnecessary back and forth.
I will address rest of the comments tomorrow.

@deep-diver up for another review.

LGTM! Thanks for the great work :)


Models on README

@datahygienics Use this PR as your example. Will send you a video & more details on Slack. Gracias amigo. 🥊


on windows, c:/ is alos absolute path, as c:\

http://stackoverflow.com/a/37543704/4771854

Thanks, @huaoguo! Looks like we already account for this in the 5.0 alpha, but we'll get this fix into the 4.x line as part of the upcoming 4.14 release.

@dougwilson cool!

This package correctly covers that case, maybe we should pull it in? It seems like it was originally based on code from this very repo :)
https://www.npmjs.com/package/is-absolute

Hi @LinusU, the issue with that package (and others like it that extract from the newer Node.js API) is that they export platform-specific functionality, which differs from what is in Express.js 4.x.  We have already moved to the official pollyfill in the Express.js 5.x alphas.

@dougwilson Awesome 🙌 sorry for missing that...


Add offline support

Specs

As a developer it is easy for me to write a web app, a React Native app, or a NativeScript app, that stores analytic events when offline and have those events automatically sync when back online.

Proposal
How Will ReduxGTM Determine Whether an App Is Online/Offline?
ReduxGTM will determine the connectivity of the application through a boolean in the redux state, ReduxGTM will accept a state selector that takes in the state and returns an isConnected boolean. ReduxGTM will take the absence of this selector to mean that it should not be storing analytics events when offline.

Initially I looked into solutions for having ReduxGTM itself determine whether an app has a connection or not. There's the offline/online events that you can listen for on modern browsers, there's offlinejs, there's NetInfo for React Native, and there's the connectivity module for NativeScript. There are a few things that put me off from the idea of having ReduxGTM determine whether the app is offline or online:

How will ReduxGTM know if it's running on a web app, React Native app, or NativeScript app? The user would have to pass in something to let ReduxGTM know what it's being used on, and for mobile apps there would have to be a way to pass in the Netinfo or connectivity objects. This would create a pretty leaky abstraction.

Separation of concerns. ReduxGTM facilitates the tracking of redux actions as analytics events. I don't think it's a good idea to turn it into a library for determining online/offline connectivity cross-platform as well.

Chances are if someone's building an app with Redux or ngrx with a solid offline experience, they'll be storing a connectivity boolean somewhere in their state anyway.

I think it's a good idea to have offline event selection off by default. Having it on by default could slow down an app significantly, especially when communicating synchronously with an offline data store.

I also thought of having ReduxGTM expect a specific key like isConnected at the root level of the state object, and then having an option for the user to specify a different key if they're storing the connectivity boolean elsewhere in the state object. But, a lot of people like to store their state as an immutable object, what then? I figured it'd be a lot more elegant to allow the user to specify a selector function for extracting the connectivity boolean.

Where Will ReduxGTM Store Analytics Events When Offline?
ReduxGTM will accept an OfflineStorageSync object or an OfflineStorageAsync object. These objects will have a consistent API that ReduxGTM can use to store and retrieve data from a storage system. The user will most likely never need to create their own offline storage objects, as ReduxGTM will provide some standard ones for the web (IndexDB, and maybe localStorage too), as well as for native (AsyncStorage, applicationSettings). The user will of course have the option to create their own objects if they ever need to. ReduxGTM will provide these standard offline storage objects under some namespace (maybe OfflineStores?) in the API.
What Will the API Look Like?
A user will need to do two things:

Create a selector function for the isConnected boolean and provide it when creating middleware, or a meta reducer.
Pick out one of the OfflineStorage abstractions that ReduxGTM provides, and provide it when creating middleware, or a meta reducer.

The expected parameters for createMiddleware and createMetaReducer will change. Instead of accepting a dataLayer object as their second parameter they will now accept an options object. ReduxGTM will look at the following keys in the options object:
dataLayer
A custom data layer object (same as before). Maybe rename this to customDataLayer? Since it's always referred to in that way.
connectivitySelector
The selector that returns a boolean that is true if the app is online, and false if the app is offline. The presence of this selector will determine whether or not ReduxGTM will store events offline. There's probably a better name for this key.
offlineStorageAsync
An asynchronous offline storage abstraction. (e.g. IndexDB and AsyncStorage/ReactNative). ReduxGTM will store events here when offline, and retrieve stored events when back online. This abstraction will take precedence if a synchronous abstraction is provided as well.
offlineStorageSync
A synchronous offline storage abstraction. (e.g. localStorage and applicationSettings/NativeScript)
ReduxGTM will store events here when offline, and retrieve stored events when back online. This abstraction won't be used if an asynchronous offline storage abstraction is provided.
Notes

The connectivitySelector, offlineStorageAsync, and offlineStorageSync options all need better names.
Maybe there only needs to be one option for offline storage that will be asynchronous by default. If the storage solution is synchronous then you could just do a Promise.resolve within the abstraction.
These offline storage abstractions will be constructor functions. The standard React Native abstraction will probably take in the AsyncStorage object, and the standard NativeScript abstraction will take in the applicationSettings object.

Love this so far @ttmarek. One thing I'd like to add is that the last time I've attempted adding support for offline events, I've found Measurement Protocol's Queue Time Parameter indispensable.
I don't know a clean way of generalizing this through GTM itself but I think it's worth considering. In some cases, attribution modules and certain KPIs like time-to-conversion/purchase (from an initial session or something) rely on decently accurate timestamps. Events that are time-shifted by days (or even hours) can cause issues. Of course, it also wreaks havoc with per min/hour/day reporting.

Looks good.  As per our chat, consider cordova.


apps/engine: add EC to list of capabilities

openssl engine -c wasn't showing if an engine implemented EC
cla: trivial

Hi @t8m, is there anything else I can do to get this PR merged? I believe the CI failure is unrelated to my PR.

Hi @t8m, is there anything else I can do to get this PR merged? I believe the CI failure is unrelated to my PR.

Nope, the ball is on our side now. It needs a second approval from @openssl/committers

This pull request is ready to merge

Merged to the master branch. Thank you for the contribution.


Add appropriate CORS headers to all responses and errors under the legacy JSON API.

Fixes #2825

Thanks!
On Sat, Mar 24, 2018, 9:55 PM Donald Stufft<EMAIL_ADDRESS>wrote:

Merged #3409 https://github.com/pypa/warehouse/pull/3409.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/warehouse/pull/3409#event-1539470638, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAPUczs6ROJtR5_2Fk1uZCAt12njgAPwks5thyM4gaJpZM4S6AVL
.


exposing the internal writer of AutoFlushingWriter

Pull Request Test Coverage Report for Build 892521579

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.467%

Totals

Change from base Build 892373660:
0.0%

Covered Lines:
484

Relevant Lines:
535

💛  - Coveralls

Pull Request Test Coverage Report for Build 892521579
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.467%

Totals

Change from base Build 892373660:
0.0%

Covered Lines:
484

Relevant Lines:
535

💛  - Coveralls

Pull Request Test Coverage Report for Build 892521579
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.467%

Totals

Change from base Build 892373660:
0.0%

Covered Lines:
484

Relevant Lines:
535

💛  - Coveralls


iOS Auth Dialog Crashes

On hitting the login function for any Provider, the pop-up opens and crashes giving the below error:
[AXRuntimeCommon] AX Lookup problem - errorCode:1100 error:Permission denied portName:'com.apple.iphone.axserver' PID:452
The login function however works completely fine when run on the simulator.
Code:
final res = await Web3AuthFlutter.login(                       provider: Provider.values[index],                       mfaLevel: MFALevel.MANDATORY);

The Pop Up is crashing for iOS v12.1, updating it to v13.0 fixed it


GPU starting  problem.

Dear All,
I was successfully installing  and using cellpose before update on 7th of  November.   GPU have not been  opened and worked with my computer even though I follow each steps of installation.  I use  MacOS Big Sur, and visual studio code.
Here are installation steps that I follow in my terminal of visual studio code
1- conda create --name cellpose python=3.8
2- conda activate cellpose
3-python -m pip install cellpose[all]  or python -m pip install 'cellpose[all]'
4- python -m pip install cellpose --upgrade
5-  python -m cellpose,
GPU does not appear in my screen.
Could you please help me about this situation ?
best regards,
Sertan

What GPU do you have? I think only Nvidia GPUs are supported through pytorch, and no modern Nividia GPUs will work in macOS (no driver support). It is possible that a much older Nvidia card will work because the drivers exist, but I doubt that is your situation. Most likely you will only be able to use CPU on macOS, at least until pytorch supports AMD and/or Apple Silicon GPUs.

Hello Dear Kevin,
My problem was solved ! cellpose works
thank you so much for your comments,
best,
Sertan


Reading Micro QR Code

Hello,
is it possible to read micro QR Code with Android Vision? (http://www.qrcode.com/en/codes/microqr.html)
I didn't have any luck so far...
Thanks in advance and best regards

No, the Barcode API unfortunately does not support Micro QR codes.

Hi,
You knows any app able to read Micro QR Code?
regards,
Gigot

Not part of Android Vision but I've written a Micro QR Code reader that runs on Android. https://boofcv.org/index.php?title=Example_Detect_Micro_QR_Code


problem with nomacs

Perhaps switch to using Fosshub, as suggested in disqus comment:
https://chocolatey.org/packages/nomacs#comment-2997181741

I already did create it but at the end I found that versions are problematic:

Foshub keep fixed file name for installer and versioned for portable
SourceForge doesn't have newer versions.
Their history lists only portables
Github doesn't have binaries

Switch to portable package ? Keep only latest version ?

It looks that I can get the repository and run silent from there. This makes Github page most appropriate I think.

Except that gihtub code is not the same as provided repository zip on above page.

So their 3.x installer is generic, it is proxy that always downloads latest version.
Portable version is completelly offline but only x64 bit.
So versionless installer should be used I guess for this package and portable variant may be done as alternative.

Current package doesn't work correctly with proxy. Asked about unattended setup here:
https://www.nomacs.org/redmine/issues/765


API docs are broken

@oliver---- after your latest commits
Uncaught Error: Illegal value type for property sourceLine: expected number, was object

Fixed.


AND I KNOW FILES, I CODE PY ASWELL.

Bro its not malware lol pyinstaller use hook methods to make python runtime run the code without install python xD


CI Fixes

This fixes two Issues we've been having recently withe the CI:

MacOS images are sometimes missing gcc-9, (seems to be transitioned out) so this checks for it and installs it if required.
Ubuntu 18.04 is deprecated, but as we run in a container we can safely update the Ubuntu version we are using so I bumped it to 20.04

Since I think we'll need a similar fix elsewhere though (OpenCL-CLHPP, OpenCL-ICD-Loader, probably OpenCL-SDK), at some point we should investigate whether we can move from macos-11 to macos-latest now that we're explicitly installing gcc9.

Indeed. I most probably will do one for the ICD loader in the process of validating https://github.com/KhronosGroup/OpenCL-ICD-Loader/pull/210


Upgrade minimatch due to Regular Expression Denial of Service in yarn audit

Hey there,
Yarn audit reports a possible exploit due to the version of minimatch tape package is using in commafy.
Patched in minimatch >=3.0.2
https://www.npmjs.com/advisories/118
<EMAIL_ADDRESS>(current latest) uses<EMAIL_ADDRESS>Can you roll it up?
Thanks for the super useful package!

Closed by https://github.com/miguelmota/commafy/commit/ed15b0c761815a2e0296c031ff288b11cde14cdb

@josh-renton should be fixed now. Thanks for the report!


Initial stats for bws

Coverage remained the same at 94.27% when pulling c1989b67f9afe3b9a88afdd3abec62f352b8fdc6 on matiaspando:feat/stats into 28969564bc2ac6556f5a918acff78a2bec6f0fd0 on bitpay:master.


Sign Up says fill up email but...where?

When I try to Sign Up it says

enter your email below to create your account...

Then I don't see any field to enter my email
If Github is the only expected way to Sign Up then that sentence is misleading.
Also if Github is the only way to Sign Up, you're closing the door to every non-techie user (usually most for this kind of thing).

I've removed the text, and I've planned to add a Google login also. I'll add it whenever I get some time.

You do as you feel able to, there's no rush for FOSS projects.
But I wouldn't limit it to either forcing people to have Github or Google.
Specially since your homepage is advertising this as "hassle-free"

I think you're correct. I'll keep you updated about it.

I've added Google auth for now, and I'll think about the email auth later maybe.
Thanks for raising the issue. I'll keep you updated here.


Incorporated SCP changes from closed PRs

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Creating new PR with an additional commit


"CAMEL-16784:Disable some ftp tests"

CAMEL-16784:Disable some ftp tests

And please fix the codestyle.

changes done


Change pie charts to follow standard practice

Largest slice should start at 12 o'clock position and then order clockwise descending in size.

Done. See charts branch commit: 796146df7845227b8538c77d69e9ecd1b0f9f3a5


Screenshots are wrong on changed aspect ratio

Hi, I found your code very usefull, thanks.
I did some adjustments on screenshot width and height calculus on aspect ratios that are different from the project config one. I hope you could consider to add it to your codebase too.
I added this on Transitions.gd _common_pre_fade method:
        var default_aspect_ratio: float = game_width / game_height
	var new_aspect_ratio: float = screenshot_width / screenshot_height
	var fixed_game_width: float
	var fixed_game_height: float

	if(new_aspect_ratio > default_aspect_ratio): # it is wider
		fixed_game_width = game_width * new_aspect_ratio / default_aspect_ratio
		fixed_game_height = game_height
	elif((new_aspect_ratio < default_aspect_ratio)): # it is higher
		fixed_game_width = game_width
		fixed_game_height = game_height * (screenshot_height/screenshot_width) / (game_height / game_width)
	else: # aspect ratio didn't change
		fixed_game_width = game_width
		fixed_game_height = game_height

	var sprite_scale = Vector2(fixed_game_width / screenshot_width, fixed_game_height / screenshot_height)

Hi @JPCard, thanks for using the library - glad someone is getting use out of it. Could you please describe the scenario where this code applies? I usually test with 960x540 or 1280x720 games, and didn't see any issues with this.
Also, could you open a PR instead? That would be much easier to merge (and you'll show up in GitHub as a contributor to the project).

I happened to me while testing responsive screens for my game. My project settings were 16:9 but when I tested the transitions on 16:10 screens it wouldn't covered the entire screen so I changed the code for changes on the aspect ratio.
These were my stretch settings:

Sure, I will open a PR on that matter.

I added a few questions/comments to your PR. By any chance, did you fork from the latest version? It looks like some of your changes are either behind, or undo some of the latest changes I made recently (e.g. target_scene being typed to Node).

Fixed at PR #6


Tagging releases on github

Hi,
For distro package maintainers it's nice to be able to quickly find the version of the source that we package from hackage. It's useful for applying bugfixes and security patches if needed. Doing a git blame on the version string doesn't tell us if the next commit is also part of the release without manually checking the changes.
Thank you,
David

Hi David, I do tag releases (there are 5 tags here), but unfortunately I think a few versions might have slipped through the net. Sorry!


Make 'drag' and 'actor' words consistent with FVTT translation

A minor wording change to make this translation consistent with the terminology used in the base game translation. I was initially accidentally comparing this translation with an older version of my translation for the base game.

I was in the process of revising all the language files, so just merged your changes on my copies.. Thanks again @DemianWright!


fix: cosmetic issue with register button in Spanish

Before:

After:

@AndresQuijano Thank you for the changes. Now the English version has a small issue on the "rif / year" text. We could fix it either by removing the space around / or by setting the min-width of that column to 200px. I'd probably prefer removing the empty space, but both work for me.


Singularity and new rule

Add methods to handle singularities.
Add genus-fusion rule:
   | |         ∪
g1 | | g2  =>  g1
   | |         ∩

we need to rewrite part of this for the 3D case anyway, so I'll just merge it.


documentation commands include an extra '$' character

Provide a link to the page with an issue:
most of the docs containing commands. for example:
https://docs.pachyderm.com/latest/getting_started/local_installation/
Describe what is wrong:
When clicking the copy to clipboard button, the extra '$' character gets copied as well and causes the command to be invalid.
for example:
"$ curl -o /tmp/pachctl.deb -L https://github.com/pachyderm/pachyderm/releases/download/v1.9.9/pachctl_1.9.9_amd64.deb && sudo dpkg -i /tmp/pachctl.deb" gets copied.
This forces the user to manually delete the extra character which breaks the flow of using the docs for the user.
Describe the suggested changes:
either remove the extra '$' character or make it so that copying it does not copy that character into memory.
Anything else we need to know?
nope.

This totally makes sense and shouldn't a hard fix. Thanks for filing!

I think having the $ is a good thing because it distinguishes commands from their output. Not copying it when the copy button is clicked makes a lot of sense though, and similarly not copying the output of the command.

Agreed, but we're using a built-in plug-in for the copy functionality and that's meaningfully harder to edit to just not copy the $. @svekars can comment further.

Many known and respected documentation websites omit it. Examples: AWS, Kubernetes docs. I agree that in some cases omitting the $ sign might be confusing. For these cases, we should ensure that we describe how to run these commands in more detail. But as @jdoliner and I have discussed, the multi-line commands that we have in the docs at the moment are not copypastable either with the $ in them.  These commands in their turn might be used in scripts, where the $ sign is not relevant. We can add a $ as a background image in code blocks in the future.
Here are my suggestions:

Not to use the $ sign in commands.
Separate input and output so that one-line commands are copypastable (will update the PR).
In situations with setting up env variables where we want to copy multiple lines, add \ where needed.

There is probably another way of achieving this by modifying clipboard.js to avoid copying the first symbol in a code block if it's a dollar sign. I vaguely imagine how this would work and most likely need engineering help to implement this.
Thoughts?

@jdoliner I agree with @svekars on this one. Changing the clipboard.js plugin seems like a bigger project than we want this to be and will need eng help that doesn't seem worth it.
Svetlana's suggestion of breaking up input & output into separate code blocks when output is important seems totally reasonable. There's plenty of places where we have it and it's not really needed.
If we decide breaking input/output into different code blocks worsens the docs meaningfully, then still removing the $ from all single-line commands (and making more of them single-line cmds where reasonable) still has some value gained there. Right now, nothing is copy/paste. If we only remove for single-line commands with no output, then at least those work and the multi-line/output ones still wont, so we're not really any worse off.