[Bug] Crash after some time in the list view, with no user action

Sorry if you are hearing so much from me lately. :O
I've set up my work email account and nmail manages to fetch a handful of messages (some in the Trash, and everything else is in "Deleted items" because I have a forward/delete procedure in place), but every time I try to fetch e-mails from this latter folder, nmail crashes with the following output:
unexpected termination: 13

0   0x000000000046c98d  Util::SignalHandler(int)
1   0x00007ffaf650c850
2   0x00007ffaf6c6e7ef  __write
3   0x00007ffaf6b17775
4   0x00007ffaf6b15674  BIO_write
5   0x00007ffaf6d6bba0  ssl3_write_pending
6   0x00007ffaf6d6c510  ssl3_write_bytes
7   0x00007ffaf6ca5cdc
8   0x00007ffaf6ca4267  mailstream_low_write
9   0x00007ffaf6ca4cc8  mailstream_flush
a   0x00007ffaf6cc3286  mailimap_uid_fetch_qresync_vanished
b   0x00007ffaf6cabde1  mailimap_uid_fetch_changedsince
c   0x000000000042e1a7  Imap::GetHeaders(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > const&, bool, bool, std::map<unsigned int, Header, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, Header> > >&)
d   0x0000000000435e59  ImapManager::PerformRequest(ImapManager::Request const&, bool, bool)
e   0x0000000000437026  ImapManager::Process()
f   0x0000000000438fbe  std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (ImapManager::*)(), ImapManager*> > >::_M_run()
10  0x00007ffaf68e94a0
11  0x00007ffaf6c6510e
12  0x00007ffaf65e2fff  clone

Here is the log file: log.txt
It may be worth noting that there are several thousand messages in this folder. The white space in "Deleted items" does not seem to be the issue because nmail successfully fetched like 10 or 12 messages from this folder.
Note also that the account was initially set in French in OWA, with folder names translated to French.   The associated accents could not be displayed properly in nmail (I had some broken syntax instead), which is why I changed the region to English in case this was causing the fetching problem, but it turned out that it was not the issue.

With the latest changes for #19 it should be fine to use verbose_logging=1 (or -e flag). If the resulting log file is very large you can try zip it, I think the compression ratio should be good.

It would also be useful if you could try reproduce the problem with the latest version of nmail as it adds some improved logging.
Also, for for this latest crash, which OS did you observe it on, and what type of Internet connection was in use?
Thanks!

Before I collect some logs and send them to you, just a short update to say that I noticed the issue can happen with non-Exchange accounts too. I observed it with my Disroot accounts today too.
I observed it on Solus (with libetpan missing some feature, mentioned it to the Solus dev team) with both Ethernet and Wifi. I'm not sure if I saw it on Xubuntu from chroot on my phone, it seems to be more stable, but I'll keep an eye on it.

Thanks, this is useful information! When I get a chance I will try to reproduce it using my Solus installation with disroot.

I think I only get this issue on Solus, so it might be related to libetpan. It would be interesting to see if you can reproduce it with libetpan from repository and compare with the version you built yourself.

I built libetpan on Solus and still observe the issue. Let me know in case you fail to reproduce it with your installation and I'll try to collect some logs.

I am able to see issues (such as "Get headers failed" and other "Get ... failed") with the combination Solus Linux and Disroot. It is possible the root cause to your crash is the same as the errors I see, but it would be good to confirm, for example by sharing the log.  Do you also get "Get ... failed" errors btw?
Interestingly I don't see issues with Disroot on other OS'es (macOS or Ubuntu).
Nor do I see issues with Gmail or Hotmail under Solus Linux.

I've worked around the issue that I saw on my Solus Linux installation using disroot. Hopefully it fixes the issue for you too, if not please re-open the issue.
Dev notes: Solus Linux uses an end-of-life version of OpenSSL (1.0.2) which does not have the built-in thread-safety that OpenSSL >= 1.1.0 provides. When nmail AES decrypt operations fail (in this case due to trying to decrypt an empty file buffer) the global SSL state is affected, which may affect SSL communication with an email server. During troubleshooting an attempt was made to support OpenSSL 1.0.2 by registering necessary thread safety routines, only issue is that libetpan (which nmail uses for email server communication) overrides such registered routines without checking if already set or not. As OpenSSL 1.0.2 is EOL I decided to not to officially support this version, but still implement a workaround for 1.0.2 users which avoids a typical AES decrypt error for empty buffers.

I'll need to open a new task on the Solus issue tracker to warn then about this issue, hopefully they will fix it.
Thanks a lot for taking the time to investigate yourself in another distribution, and implementing a workaround. I just pulled from git, I'll see if I still have the random crash issues/

I still get crashes with the latest commit on Solus, including with Disroot. That was without doing any action, just nmail setting iddle in the list view.

Oh no.. Ok, could you please help share the latest log?

 I had two different nmail sessions running concurrently on two different workspaces and got confused: the one that crashed is the Exchange one. I'll wait a bit to see if the other one (Disroot) crashes too.

I finally got a crash with Disroot as well, I'm sending the logs.

Hi @Kabouik - thanks for sharing the log files!
I found one issue with nmail (it shouldn't "crash" on SIGPIPE), so I fixed that and also added some improved crash logging (in case there is still some crash..). It's added in v1.53 / f83ac26
Please let me know if you still see crashes after this fix. Thanks!

Thanks for the quick fix, I'll let you know.

Still getting some crashes with both Exchange and Disroot, but more often with Exchange. I'm sending you the -e logs.

After one day of use, I didn't get any crash with Disroot, but multiple crashes with Exchange. The crash is silent, no errors in the terminal after nmail closes (which I think was not the case before). Changing inbox= to a smaller folder in main.conf didn't solve it.

I have been using nmail for several days consistently, I can confirm crashes are still frequent (< 1 hour) with Exchange, and rare with other servers (perhaps related to network changes and sleep/wake changes when moving places with the laptop).
Not sexy, but useable to mitigate the issue, I use this alias for the Exchange account to relaunch nmail whenever it crashes:
alias nmail-disr='while true; do nmail -d ${HOME}/.nmail/nmail-disr && break; done' # disr.it

Now I'll need to enable logging and collect some data for you.

Okay that would be great. I'll reopen this issue so I don't loose track of it.
I personally have not encountered this type of stability issues, and I generally keep nmail running for weeks/months at a time. I don't generally use Exchange though, but I will try start a long Exchange session and see if I can reproduce any issue.

I'm sending you some logs. Note that this time, nmail crashed and left the config directory locked:
error: unable to acquire lock for /home/mathieu/.nmail/nmail-inrae/
       only one nmail session per account/confdir is supported.

This does not happen all the time, but I observed that on a regular basis. I haven't found any way to unlock the config directory yet, there's no nmail zombie process to kill, only logging out  seemed to work so far. But both issues are probably different, since I often observe crashes that do not cause this.

Turns out the locked state happens when nmail crashes when using $EDITOR in it because it leaves the process running:
$ lsof ~/.nmail/nmail-work/
COMMAND    PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
kak     109935 kabouik    3r   DIR  259,5     4096 8291264 /home/kabouik/.nmail/nmail-work
$ kill -9 109935

I assume this could happen too with external viewers if nmail crashes while viewing attachments or message parts externally? If so, perhaps different issue would be relevant to implement a way for nmail to kill child process when it crashes (but perhaps not relevant if the crashes are fixed anyway).

Thanks @Kabouik for sharing your extra verbose log-file via email. As mentioned in my email reply it's unfortunately still unclear what is happening, but I have some idea of additional logging I can add to nmail. I will update this issue again once I've implemented the appropriate logging.

It may be worth noting that, while I get crash ad seemingly random times when nmail is idle in the message list, message view or compose view, sending an email seems to increase the probability of a crash.
As an example, it is not unusual to send an email with nmail and this Exchange account and get a crash right after hitting Ctrl+x and y, somewhere between the "Sending" and the "Saving" status. Sometimes, sending went through and my recipient got the message. Sometimes not. Saving never goes through (crash happens before saving is over).

It may be worth noting that, while I get crash ad seemingly random times when nmail is idle in the message list, message view or compose view, sending an email seems to increase the probability of a crash.
As an example, it is not unusual to send an email with nmail and this Exchange account and get a crash right after hitting Ctrl+x and y, somewhere between the "Sending" and the "Saving" status. Sometimes, sending went through and my recipient got the message. Sometimes not. Saving never goes through (crash happens before saving is over).

Hi @Kabouik - I have created a simple script that allows you to run nmail through a debugger (gdb) and capture the backtraces of all threads when crashing. Could you help to try running nmail using it and see if you can reproduce any crash?
The script is located in the source package under ./util/debug-nmail.sh. If you use a custom nmail directory you need to adjust the beginning of the script and set ARGS accordingly, for example:
ARGS="-d ~/.nmail-gm"

Once you have encountered a crash, please review the generated log file and do a quick search either for pass or your actual plain text password, and make sure it is not there, before sharing the file. There is a possibility actual plain text password will be present, mainly if the crash happens during (IMAP or SMTP) authentication.

Hi @Kabouik - I have created a simple script that allows you to run nmail through a debugger (gdb) and capture the backtraces of all threads when crashing. Could you help to try running nmail using it and see if you can reproduce any crash?
The script is located in the source package under ./util/debug-nmail.sh. If you use a custom nmail directory you need to adjust the beginning of the script and set ARGS accordingly, for example:
ARGS="-d ~/.nmail-gm"

Once you have encountered a crash, please review the generated log file and do a quick search either for pass or your actual plain text password, and make sure it is not there, before sharing the file. There is a possibility actual plain text password will be present, mainly if the crash happens during (IMAP or SMTP) authentication.

FYI - An improvement to Linux crash logging was added in a2b3bb9 so it might not be necessary to reproduce the crash with ./util/debug-nmail.sh (although it would probably simplify debugging). The nmail log file itself should contain most relevant information going forward.

FYI - An improvement to Linux crash logging was added in a2b3bb9 so it might not be necessary to reproduce the crash with ./util/debug-nmail.sh (although it would probably simplify debugging). The nmail log file itself should contain most relevant information going forward.

Do take note though that I simplified the logging options in e51b9a5 so now there's normal logging and verbose logging. The config param verbose_logging now only supports 0 or 1.

Do take note though that I simplified the logging options in e51b9a5 so now there's normal logging and verbose logging. The config param verbose_logging now only supports 0 or 1.

I just sent you some logs using the new logging feature, only to realize now that you said using the debug script would make it easier to debug. I can do that too, let me know.
Note that nmail --help still shows -ee as an option, but it has no effect (just shows the help message again).

I just sent you some logs using the new logging feature, only to realize now that you said using the debug script would make it easier to debug. I can do that too, let me know.
Note that nmail --help still shows -ee as an option, but it has no effect (just shows the help message again).

I just sent you some logs using the new logging feature, only to realize now that you said using the debug script would make it easier to debug. Sorry. I can do that too, let me know.

Thank you! I've looked through the log and unfortunately the new logging feature does not help. Yes, if you could try the ./util/debug-nmail.sh script it would be great.

Note that nmail --help still shows -ee as an option, but it has no effect (just shows the help message again).

Thanks for catching - I've removed it from the --help in b2d9301.

I just sent you some logs using the new logging feature, only to realize now that you said using the debug script would make it easier to debug. Sorry. I can do that too, let me know.

Thank you! I've looked through the log and unfortunately the new logging feature does not help. Yes, if you could try the ./util/debug-nmail.sh script it would be great.

Note that nmail --help still shows -ee as an option, but it has no effect (just shows the help message again).

Thanks for catching - I've removed it from the --help in b2d9301.

Hi @Kabouik - thanks for sharing the logs from running ./util/debug-nmail.sh via email, I believe I've finally found and addressed the root cause. Please reopen the issue if you still encounter the crash.

Root cause analysis for those interested:
The previous attempt to fix this bug was to remove the application-specific SIGPIPE signal handler. This was a mistake, because SIGPIPE defaults to application termination(!) which caused nmail to silently "crash", leaving no hints in the logs. The debug-mail.sh log file provided made it clear that SIGPIPE still was crashing nmail. A quick man 7 signal confirmed that
SIGPIPE      P1990      Term    Broken pipe: write to pipe with no readers

(Term stands for terminating)
After finding this I did some googling and found this post https://securityboulevard.com/2018/10/tcp-ip-sockets-and-sigpipe/ which describes the SIGPIPE issue and other potential solutions to it.
For nmail the fix is to explicitly ignore SIGPIPE signals.
In the above commit we also improve general signal handling, to enable nmail to gracefully shutdown when requested by OS signalling.

Awesome.


Error logging and cron jobs

Refactor code to move the load_data.py and get_api_data.py into reusable services. These can be called from both the server (cron job) and by a user. Users can use debug mode (errors are raised) vs. non debug mode (errors are skipped and the service continues, reporting errors via email at the end).
Set up server to run the cron jobs
If an error occurs, skip the data source (loading or getting) and move on to the next one
If an error occurs and it is possible to only skip a line, skip just that line (i.e. WMATA data downloading)
If an error occurs in geocoding, put nulls instead (e.g. DCHousing data download, building permit geocoding, etc.).
Drop unique_data_id rows after cleaning the data and move it to just before loading the PSV file

@speedyturkey and @blw9u2012
FYI, I've been discussing a bit with @mkalish about our get and load data weekly jobs; There's a strong chance that we'll actually want to set these up as Lambda functions on AWS, instead of having the Flask app and server run them directly. This is mostly for the long term cost savings of keeping the API server on a t2.micro, which probably won't have enough memory / CPU for the more intensive update scripts.
I think this doesn't change any of the work you've done so far on this - it'll just change how we trigger it. @prisalex also did some investigation (before we made the flask app and before Python 3 was available on AWS lambda) into running Lambda functions; I'll dig up her notes on that.

@speedyturkey and @jkwening As I've been working through the entity resolution on our project table from the 3 data sources, I realized we'll need to do a (slightly) more complex loading process due to data downloads depending on other data downloads.
I had previously thought we'd be OK doing all of get_api_data and then all of load_data as long as we had something in the database - any missed entries would get resolved in the following week. However, we have ended up implementing all of our entity resolution in the download phase instead of the cleaning phase.
To avoid double-adding a project that appears in two data sets (i.e. DCHousing and DHCD, which will happen), and especially for the first time the database is built, we'll need to do:
load_data mar
load_data project
get_api_data dchousing
load_data dchousing
get_api_data dhcd
load_data dhcd
Then we can safely do
get_api_data everythingelse
load_data everythingelse
@speedyturkey this will probably be what we'll want to put into that services section you've added,

Since we're going to have to refactor anyways to avoid double-adding projects, I'm thinking we should implement a service mediator object - where specific actions triggers another set of actions; regularly scheduled or user triggered update will still be a core task but not the primary purpose.
Currently we have many modules importing into each other - engaged in various pairwise interactions. Instead they will now interact through a service mediator module. It will talk to all of these other objects and coordinate their activities. I think moving in this direction should also work with utilizing Lambda functions in AWS, along with also making it easier to understand the relationships between all our objects, and helping facilitate debugging.
I'm still working through the full design but for example via mediator module, monitoring S3 bucket for newly uploaded prescat data would trigger migration of the new files into data folder which once completed will trigger cleaning and loading into db, which if successful would trigger reprocessing dchousing and dhcd data since I assume we would always want to honor nlihc_id metadata instead of replacing with randomly assigned uuid if a project is added that was originally unique to dchousing or dhcd.
I'm going start implementing this concept by dealing with the double-adding projects issue since that needs to be resolved anyways. I think this would require adding a new field to manifest: "dependency" so that I can better control when certain unique_data_ids are processed and also allow them to be updated if their dependent unique_data_id is successfully cleaned and reloaded (there will be an optional flag to allow skipping of this step). Also so that there isn't a need to hard code dependencies.


Power search should support assays

Right now assay contents are not indexed for power searching and you cannot jump straight to assay pages through the search.

Added in v0.7


getsockopt: connection refused since v0.18.5

Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
Issue
What version of acs-engine?:
v0.18.5

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes 1.10
What happened:
On cluster created with acs-engine v0.18.5, network liveliness probes are flaky and often fail with an error message like :  dial tcp <IP_ADDRESS>:80: getsockopt: connection refused
This can happen for every pods we use. Clusters deployed with version v0.18.3 work fine (#3153 aside)
How to reproduce it (as minimally and precisely as possible):
Here is the definition :
  "apiVersion": "vlabs",
  "properties": {
    "orchestratorProfile": {
      "orchestratorType": "Kubernetes",
      "orchestratorRelease": "1.10"
    },
    "masterProfile": {
      "count": 3,
      "dnsPrefix": "XXX",
      "vmSize": "Standard_D2_v3"
    },
    "agentPoolProfiles": [
      {
        "name": "cpuworkers",
        "count": 2,
        "vmSize": "Standard_D16s_v3",
        "availabilityProfile": "VirtualMachineScaleSets"
      }
    ],
    "linuxProfile": {
      "adminUsername": "cluster",
      "ssh": {
        "publicKeys": [
          {
            "keyData": ""
          }
        ]
      }
    },
    "servicePrincipalProfile": {
      "clientId": "",
      "secret": ""
    }
  }
}

The following install with helm (as an example) will lead to failing pods :
helm install --name ddagent --set datadog.apiKey=<api_key> stable/datadog

@sharmasushant @tamilmani1989 Do we have any test data that suggests this change introduced add'l network flakiness?
https://github.com/Azure/acs-engine/commit/77b9e9346c256e6de76a9ed853926b8b2da00460
(That change went in between v0.18.3 and v0.18.5)

Seeing same issue on 18.5 deployment this morning. Started with Tiller, now getting it on DNS.

@SteveCurran would you be willing to try the previous version of Azure CNI to see if that addresses your situation?
curl -fsSL https://acs-mirror.azureedge.net/cni/azure-vnet-cni-linux-amd64-v1.0.4.tgz -o /tmp/azure_cni_1.0.4.tgz
sudo tar -xvzf /tmp/azure_cni_1.0.4.tgz azure-vnet -C /opt/cni/bin/
sudo tar -xvzf /tmp/azure_cni_1.0.4.tgz azure-vnet-ipam -C /opt/cni/bin/
sudo tar -xvzf /tmp/azure_cni_1.0.4.tgz 10-azure.conflist -C /etc/cni/net.d/

On every node (master + agents). And to be extra sure a vm reboot.
That's a lot of extra credit work, but it might give us data that suggests we have a regression in v1.0.6. Thanks!

@jackfrancis If that can help, the problem is gone after re-creating the exact same cluster with v0.18.3

@jackfrancis  Connection refused indicates that server is refusing the connection. CNI cannot cause server side to refuse connections. I suspect there is something else that is causing this. Also, I think @msornay did not just revert CNI, the older acs-engine version was used, which means every change in acs-engine is reverted (and not just cni).
I suspect if we revert without investigation, we may ship the change that is actually causing it.

@sharmasushant Here is the commit history of v0.18.5:
https://github.com/Azure/acs-engine/commits/patch-release-v0.18.5
And from v0.18.3:
https://github.com/Azure/acs-engine/commits/patch-release-v0.18.3
There are 6 commits there, and due to (1) the likelihood that changing the Azure CNI implementation is the cause (there are no other comparable changes to underlying network) and (2) the time sensitivity w/ respect to accommodating AKS's release schedule, we will revert as an expression of caution.
We may be wrong! In which case, with some more data, we will rev back to v1.0.6.
In the meantime, if you could look at your own real-world test data of v1.0.6 running on a Kubernetes cluster and report back if you see any comparable flakiness that would be great.
Thanks!

@msornay Do we know who is expected to be listening on port 80 and if the listener is actually up?

@sure, you can try to see if reverting cni helps. We can run tests on our side as well. Can you also share starting from what date, you started seeing flakiness in your tests?

We saw flakiness right after merging. Unfortunately, to confuse things, circleci had an outage on the day this was merged, and was a little flaky itself coming out of that, so I suspect our signalling was a little confused for a while. But as the days progressed the flakiness started to become a pattern. And this customer report nudged us in the direction that a general pattern may be present post-Azure CNI v0.1.6 merge.

@jackfrancis I also see that rpcbind and rpc-statd was started at the same time. May be something else you can take a look at.

We discussed that possibility as well, but in fact missing rpcbind and rpc-statd were a regression that the change you observed fixes. See this in v0.16.0:
https://github.com/Azure/acs-engine/blob/v0.16.0/parts/k8s/kubernetesagentcustomdata.yml#L187
We did not observe any such network flakiness in that or prior versions so we do not suspect the re-introduction of rpcbind and rpc-statd to be the cause.

I'm wondering if this could be the source of DNS resolution problems I'm having on a cluster running 1.10.4 and Azure CNI 1.0.6 :
root@ubuntu-79c745bbd8-kc566:/# curl -s http://abstraction.fr/ > /dev/null
09:31:37.554648 IP (tos 0x0, ttl 64, id 11882, offset 0, flags [DF], proto UDP (17), length 86)
    ubuntu-79c745bbd8-kc566.49203 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c4e -> 0xfb4b!] 1272+ A? abstraction.fr.default.svc.cluster.local. (58)
09:31:37.554790 IP (tos 0x0, ttl 64, id 11883, offset 0, flags [DF], proto UDP (17), length 86)
    ubuntu-79c745bbd8-kc566.49203 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c4e -> 0xe529!] 6911+ AAAA? abstraction.fr.default.svc.cluster.local. (58)
09:31:37.556385 IP (tos 0x0, ttl 62, id 24898, offset 0, flags [DF], proto UDP (17), length 179)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.49203: [udp sum ok] 6911 NXDomain q: AAAA? abstraction.fr.default.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (151)

09:31:42.559682 IP (tos 0x0, ttl 64, id 12320, offset 0, flags [DF], proto UDP (17), length 86)
    ubuntu-79c745bbd8-kc566.49203 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c4e -> 0xfb4b!] 1272+ A? abstraction.fr.default.svc.cluster.local. (58)
09:31:42.560617 IP (tos 0x0, ttl 62, id 25733, offset 0, flags [DF], proto UDP (17), length 179)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.49203: [udp sum ok] 1272 NXDomain q: A? abstraction.fr.default.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (151)
09:31:42.560713 IP (tos 0x0, ttl 64, id 12321, offset 0, flags [DF], proto UDP (17), length 86)
    ubuntu-79c745bbd8-kc566.49203 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c4e -> 0xe529!] 6911+ AAAA? abstraction.fr.default.svc.cluster.local. (58)
09:31:42.561389 IP (tos 0x0, ttl 62, id 25734, offset 0, flags [DF], proto UDP (17), length 179)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.49203: [udp sum ok] 6911 NXDomain q: AAAA? abstraction.fr.default.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (151)
09:31:42.561540 IP (tos 0x0, ttl 64, id 12322, offset 0, flags [DF], proto UDP (17), length 78)
    ubuntu-79c745bbd8-kc566.58962 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c46 -> 0x4733!] 18236+ A? abstraction.fr.svc.cluster.local. (50)
09:31:42.562690 IP (tos 0x0, ttl 62, id 25735, offset 0, flags [DF], proto UDP (17), length 171)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.58962: [udp sum ok] 18236 NXDomain q: A? abstraction.fr.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (143)
09:31:42.562743 IP (tos 0x0, ttl 64, id 12323, offset 0, flags [DF], proto UDP (17), length 78)
    ubuntu-79c745bbd8-kc566.58962 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c46 -> 0x6dcd!] 8327+ AAAA? abstraction.fr.svc.cluster.local. (50)
09:31:42.563457 IP (tos 0x0, ttl 62, id 25736, offset 0, flags [DF], proto UDP (17), length 171)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.58962: [udp sum ok] 8327 NXDomain q: AAAA? abstraction.fr.svc.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (143)
09:31:42.563531 IP (tos 0x0, ttl 64, id 12324, offset 0, flags [DF], proto UDP (17), length 74)
    ubuntu-79c745bbd8-kc566.37056 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c42 -> 0xaca3!] 3552+ A? abstraction.fr.cluster.local. (46)
09:31:42.564678 IP (tos 0x0, ttl 62, id 25737, offset 0, flags [DF], proto UDP (17), length 167)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.37056: [udp sum ok] 3552 NXDomain q: A? abstraction.fr.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (139)
09:31:42.564754 IP (tos 0x0, ttl 64, id 12325, offset 0, flags [DF], proto UDP (17), length 74)
    ubuntu-79c745bbd8-kc566.37056 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c42 -> 0x7028!] 19008+ AAAA? abstraction.fr.cluster.local. (46)
09:31:42.565555 IP (tos 0x0, ttl 62, id 25738, offset 0, flags [DF], proto UDP (17), length 167)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.37056: [udp sum ok] 19008 NXDomain q: AAAA? abstraction.fr.cluster.local. 0/1/0 ns: cluster.local. SOA ns.dns.cluster.local. hostmaster.cluster.local.<PHONE_NUMBER> 28800 7200 604800 60 (139)
09:31:42.565689 IP (tos 0x0, ttl 64, id 12326, offset 0, flags [DF], proto UDP (17), length 112)
    ubuntu-79c745bbd8-kc566.43607 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c68 -> 0x05dd!] 55424+ A? abstraction.fr.frh2mpjefqcedg0y3yjpi5zilh.ax.internal.cloudapp.net. (84)
09:31:42.567987 IP (tos 0x0, ttl 62, id 25739, offset 0, flags [DF], proto UDP (17), length 167)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.43607: [udp sum ok] 55424 NXDomain* q: A? abstraction.fr.frh2mpjefqcedg0y3yjpi5zilh.ax.internal.cloudapp.net. 0/1/0 ns: ax.internal.cloudapp.net. SOA localhost. hostmaster. 272071<PHONE_NUMBER>0 10 (139)
09:31:42.568050 IP (tos 0x0, ttl 64, id 12327, offset 0, flags [DF], proto UDP (17), length 112)
    ubuntu-79c745bbd8-kc566.43607 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c68 -> 0x5778!] 34506+ AAAA? abstraction.fr.frh2mpjefqcedg0y3yjpi5zilh.ax.internal.cloudapp.net. (84)
09:31:42.569908 IP (tos 0x0, ttl 62, id 25740, offset 0, flags [DF], proto UDP (17), length 167)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.43607: [udp sum ok] 34506 NXDomain* q: AAAA? abstraction.fr.frh2mpjefqcedg0y3yjpi5zilh.ax.internal.cloudapp.net. 0/1/0 ns: ax.internal.cloudapp.net. SOA localhost. hostmaster. 272071<PHONE_NUMBER>0 10 (139)
09:31:42.569994 IP (tos 0x0, ttl 64, id 12328, offset 0, flags [DF], proto UDP (17), length 60)
    ubuntu-79c745bbd8-kc566.51591 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c34 -> 0x796b!] 912+ A? abstraction.fr. (32)
09:31:42.571364 IP (tos 0x0, ttl 62, id 25741, offset 0, flags [DF], proto UDP (17), length 76)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.51591: [udp sum ok] 912 q: A? abstraction.fr. 1/0/0 abstraction.fr. A <IP_ADDRESS> (48)
09:31:42.571449 IP (tos 0x0, ttl 64, id 12329, offset 0, flags [DF], proto UDP (17), length 60)
    ubuntu-79c745bbd8-kc566.51591 > kube-dns.kube-system.svc.cluster.local.53: [bad udp cksum 0x1c34 -> 0x4885!] 13403+ AAAA? abstraction.fr. (32)
09:31:42.571979 IP (tos 0x0, ttl 62, id 25742, offset 0, flags [DF], proto UDP (17), length 88)
    kube-dns.kube-system.svc.cluster.local.53 > ubuntu-79c745bbd8-kc566.51591: [udp sum ok] 13403 q: AAAA? abstraction.fr. 1/0/0 abstraction.fr. AAAA 2001:bc8:4400:2000::280f (60)

As show in this tcpdump trace I've a 5 seconds delay as it seems that first DNS query never gets a response. This occurs around once every 5 or 6 calls.

@sylr We are currently testing v1.0.7 of Azure CNI:
https://github.com/Azure/acs-engine/pull/3433
If possible, it'd be great to see if you can repro the above DNS flakiness on a cluster using that version (check out the above branch, build, deploy a cluster).
Are you able to repro the above symptoms quickly/reliably using a new 1.0.6-backed cluster?

@jackfrancis I've regenerated my cluster with a branch that contains the revert to CNI 1.0.4 and I'm still experiencing the DNS issue.
The only difference I now have between two clusters generated from the same acs-engine commit is acceleratedNetwork enabled on the affected cluster.
I'm going to regenerate it again with acceleratedNetwork disabled to see if this is the culprit for my issue.

Thanks for following up. The current release (v0.20.1), which includes Azure CNI v1.0.7 by default, and accelerated networking enabled by default (for VM SKUs that support accelerated networking) is the current best-known option. Please feel free to experiment w/ accelerated networking disabled, we haven't observed any operational issues as a result of that option.


[nrf fromtree]: scripts: modules: support west group feature

West has introduced support for group tags in:
https://github.com/zephyrproject-rtos/west/pull/454
This means that manifest files might start containing groups.
Zephyr itself only requires west>=0.7.2 where groups are not supported
but other Zephyr based projects might start using the group feature.
When using a west version with group support, then only active projects
will be processed as Zephyr modules.
West versions without group support will consider all projects active.

Afaik this is not a requirement according to the described workflow, but added anyway.

Right, we only require git cherry-pick -x when reapplying OOT downstream patches or when we rewrite history since our master branch rebases. That provides a link to previous versions of sdk-zephyr patches.

Please rebase this PR if still relevant; master has been rebased.

Please rebase this PR if still relevant; master has been rebased.

done

Merging; CI is green in https://github.com/nrfconnect/sdk-nrf/pull/3782


Tech debt: add from __future__ import annotations in the Metrics feature

Why is this needed?
Reference: https://github.com/aws-powertools/powertools-lambda-python/issues/4607
Add from future import annotations to all files, including examples
Which area does this relate to?
Automation
Solution
No response
Acknowledgment

[X] This request meets Powertools for AWS Lambda (Python) Tenets
[ ] Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

Closed as complete.


⚠ Slack has degraded performance

In a878826, Slack (https://status.slack.com/api/v2.0.0/current) experienced degraded performance:

HTTP code: 200
Response time: 208 ms

Resolved: Slack performance has improved in ca7fde6.


Add font-size

Hello, here's my PR that allow changing widgets text size.
I needed it to create a smaller UI.
How to use:
<a-gui-button
    width="2.5" height="0.75"
    onclick="testButtonAction" key-code="32"
    value="test button X"
    font-family="Arial"
    textsize="25px"
    margin="0 0 0.05 0"
>

That's it.
Also I would like to know if the toggle events (check and uncheck) that I added are in the correct PR.
I can remove them if you want, to make a new PR that be focused on new events.

Merged your font-size PR  - we should start thinking about not using px but dmm for VR
see:
https://sizecalc.com/#distance=55.17inches&perceived-size=660.0000547800046dmm&physical-size-units=inches
@matEhickey - Let me know if you are up for the math :-)

Indeed I was not very satisfied with this proportion unit, that why I left the "px" in the string.
Good idea, I totaly forgot about dmm unit, I'll try to implement this when I'll get time, shouldn't be too long.


windows10重启系统出现vscode文件夹丢失

VSCode Version:
OS Version:

Steps to Reproduce:
1.打开使用vscode
2.第二天启动windows, vscode快捷方式丢失，再查找vscode安装的文件夹，也丢失。
安装了python 脚本插件

Does this issue occur when all extensions are disabled?: Yes/No

thank u very much， i reinstall vscode progam, then , it seem likes had solved this problem.


get attribute empty when using "ignore" endpoints

I create the jwt auth config
function jwtAuth(): JwtAuthentication
{
    return new JwtAuthentication([
        'secure' => false,
        'ignore' => ['/token'],
        'secret' => env('JWT_SECRET')
    ]);
}

then in my controller if i try to:
$request->getAttribute('token');
It returns NULL, but if i remove the "ignore" from the JWT configuration it returns the decoded token just fine
    return new JwtAuthentication([
        'secure' => false,
        'secret' => env('JWT_SECRET')
    ]);

Does anyone knows what is happening?

As the name implies the middleware is not executed in the ignored routes. Since the middleware was not executed it did not write the token attribute to the $request object.


Use bixby for rubocop. Part of story curationexperts/alexandria#15

Coverage remained the same at 92.857% when pulling 0cd3016a657928aa12a611e8f6893fbb3527c32c on bixby into f21f6c820087a425dcd451b884a9104099c7f458 on master.


front-end improvements

I will use this issue to document small things that are not optimal.

The title, the button at the top left and the "Cancel" button at the bottom are missing on the right-hand screen

This screen cannot be scrolled, it is not possible to see the "Share" button

On the main screen, there are 3 points at the top right for the menu
The menu is not displayed in the wallet itself.
The menu button with the three dots should be displayed at the top right of all 3 wallets. When the user clicks on the 3 dots, the settings menu always opens. The same view always appears, regardless of the wallet in which the menu button is pressed.

Not all buttons can be used with an Iphone Mini.
For example, the Share button cannot be pressed on the Receive screen and the create MultiDevice Wallet screen does not work either.

If the Iphone loses the Internet connection then no pop-up should appear.

Top


Equality check

Equals
Not Equals

Implemented in f0b8be3059e208c19c2550cd64bad978123b9e7b
The methods are now called IsEqualTo and IsNotEqualTo to avoid conflicts with the standard Equals method of System.Object and IEquatable<T>.


A pull request showing a proposed fix for the create obersvation form wh...

...ich cleans it up a bit.  If we want to go this way, then I can finalize it and make ready for other themes.

Coverage remained the same at 84.64% when pulling ed22f2adb678fc041eba55a52650b967d9e9ddc1 on raysuelzer:ror4 into a4f873b0eb3b81ec12b45ce4792607100306ec58 on MushroomObserver:ror4.

Don't know about everyone else, but this looks great to me.  My only
comment is that I think the 's are unnecessary and distract the eye and
at any rate fail to actually help group things.  But that may just be a
personal preference.
-Jason
On Sat, Apr 25, 2015 at 4:08 PM, Coveralls<EMAIL_ADDRESS>wrote:

[image: Coverage Status] https://coveralls.io/builds/2423360
Coverage remained the same at 84.64% when pulling ed22f2a
https://github.com/MushroomObserver/mushroom-observer/commit/ed22f2adb678fc041eba55a52650b967d9e9ddc1
on raysuelzer:ror4 into a4f873b
https://github.com/MushroomObserver/mushroom-observer/commit/a4f873b0eb3b81ec12b45ce4792607100306ec58
on MushroomObserver:ror4.
—
Reply to this email directly or view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96290192
.

Cool.  I can pop those out and just put in white space.
Ray Suelzer
Mobile:<PHONE_NUMBER>
On Sat, Apr 25, 2015 at 4:25 PM, Jason Hollinger<EMAIL_ADDRESS>wrote:

Don't know about everyone else, but this looks great to me. My only
comment is that I think the 's are unnecessary and distract the eye and
at any rate fail to actually help group things. But that may just be a
personal preference.
-Jason
On Sat, Apr 25, 2015 at 4:08 PM, Coveralls<EMAIL_ADDRESS>wrote:

[image: Coverage Status] https://coveralls.io/builds/2423360
Coverage remained the same at 84.64% when pulling *ed22f2a
<
https://github.com/MushroomObserver/mushroom-observer/commit/ed22f2adb678fc041eba55a52650b967d9e9ddc1
on raysuelzer:ror4* into *a4f873b
<
https://github.com/MushroomObserver/mushroom-observer/commit/a4f873b0eb3b81ec12b45ce4792607100306ec58
on MushroomObserver:ror4*.
--
Reply to this email directly or view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96290192

.

--
Reply to this email directly or view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96293829
.

Should I merge it?  Sounded like you wanted feedback first(?)
On Sat, Apr 25, 2015 at 5:46 PM, Raymond Suelzer<EMAIL_ADDRESS>wrote:

Cool. I can pop those out and just put in white space.
Ray Suelzer
Mobile:<PHONE_NUMBER>
On Sat, Apr 25, 2015 at 4:25 PM, Jason Hollinger<EMAIL_ADDRESS>
wrote:

Don't know about everyone else, but this looks great to me. My only
comment is that I think the 's are unnecessary and distract the eye
and
at any rate fail to actually help group things. But that may just be a
personal preference.
-Jason
On Sat, Apr 25, 2015 at 4:08 PM, Coveralls<EMAIL_ADDRESS>wrote:

[image: Coverage Status] https://coveralls.io/builds/2423360
Coverage remained the same at 84.64% when pulling *ed22f2a
<

https://github.com/MushroomObserver/mushroom-observer/commit/ed22f2adb678fc041eba55a52650b967d9e9ddc1

on raysuelzer:ror4* into *a4f873b
<

https://github.com/MushroomObserver/mushroom-observer/commit/a4f873b0eb3b81ec12b45ce4792607100306ec58

on MushroomObserver:ror4*.
--
Reply to this email directly or view it on GitHub
<

https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96290192

.

--
Reply to this email directly or view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96293829

.

—
Reply to this email directly or view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96299384
.

You can hold if on merging it if we can wait until tomorrow for me to
finish it up.  The tests failed on something I didn't touch, not sure what
is up with that.  They passed locally.
Ray Suelzer
Mobile:<PHONE_NUMBER>
On Sat, Apr 25, 2015 at 5:51 PM, Jason Hollinger<EMAIL_ADDRESS>wrote:

Should I merge it? Sounded like you wanted feedback first(?)
On Sat, Apr 25, 2015 at 5:46 PM, Raymond Suelzer<EMAIL_ADDRESS>
wrote:

Cool. I can pop those out and just put in white space.
Ray Suelzer
Mobile:<PHONE_NUMBER>
On Sat, Apr 25, 2015 at 4:25 PM, Jason Hollinger <
<EMAIL_ADDRESS>
wrote:

Don't know about everyone else, but this looks great to me. My only
comment is that I think the 's are unnecessary and distract the eye
and
at any rate fail to actually help group things. But that may just be a
personal preference.
-Jason
On Sat, Apr 25, 2015 at 4:08 PM, Coveralls<EMAIL_ADDRESS>wrote:

[image: Coverage Status] https://coveralls.io/builds/2423360
Coverage remained the same at 84.64% when pulling *ed22f2a
<

https://github.com/MushroomObserver/mushroom-observer/commit/ed22f2adb678fc041eba55a52650b967d9e9ddc1

on raysuelzer:ror4* into *a4f873b
<

https://github.com/MushroomObserver/mushroom-observer/commit/a4f873b0eb3b81ec12b45ce4792607100306ec58

on MushroomObserver:ror4*.
--
Reply to this email directly or view it on GitHub
<

https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96290192

.

--
Reply to this email directly or view it on GitHub
<

https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96293829

.

--
Reply to this email directly or view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96299384

.

--
Reply to this email directly or view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/161#issuecomment-96299479
.

Made the changes and tested in all the themes.  Looks pretty slick.  I've noticed the old image uploader might be having some issues, specifically it doesn't seem to be adding more than one image when I select an image.  I'll look into that a bit more.

Coverage remained the same at 84.64% when pulling a4a1016f0b52480d3414d2bf94269aa751e8823a on raysuelzer:ror4 into a4f873b0eb3b81ec12b45ce4792607100306ec58 on MushroomObserver:ror4.


optimize image size and remove unused images

Trello - Move images from public/images to assets/images
Assets in the public directory are not optimized during the build process, which causes them to have a larger size (in bytes) than necessary. I moved images from public/images to assets/images so they are part of the optimization process and updated the code accordingly.
I also deleted images that were not being used (and cleanup some code). Note that the image files are reduced in size (bytes), but the image will preserve its original size in pixels; that's something we can improve later too.
Before
528K	src/assets/images/cerc.png
744K	src/assets/images/ghss.png
 36K	src/assets/images/harvard.png

After
1056	build/static/media/cerc.b3452041.png
1488	build/static/media/ghss.be6c19ea.png
  72	build/static/media/harvard.14f5f4c4.png

CRA · Adding images, fonts, and files
CRA · Using the public folder

 Performance · Move images from public/images → src/assets/images

 Performance · Move images from public/images → src/assets/images


Avro gPRC / HTTP Handlers

In addition to Thrift, any thoughts on supporting Avro?
HTTP - https://avro.apache.org/docs/1.9.1/spec.html#HTTP+as+Transport
gRPC - https://jira.apache.org/jira/browse/AVRO-2172
https://github.com/phunt/avro-rpc-quickstart

Sure. Why not? Are you interested in working on it?

It's on my mind. Not sure how one would handle the HTTP 1 pieces. I see THttpClient in Thrift, but not sure there's a direct equivalent in Avro


chore/add concurrency support for deployments

Resolves: https://linear.app/prefect/issue/PLA-701/deployments-support-concurrency
Adds concurrency limit which is an int and concurrency options which is an object
Based on the current api docs for deployments found here

🤔 Looking into concurrency_limit more. Looks like it is deprecated in favor of concurrency_limit_id based on this code. That change was added in https://github.com/PrefectHQ/prefect/pull/15426, which has a lot more context on the change. I need to read up on that to understand how we need to implement the ability in the Terraform provider.
The relevant docs (https://docs.prefect.io/v3/deploy/index#concurrency-limiting) still instruct you to set concurrency_limit directly, and the API docs don't say it's deprecated.
I'll read up more and reach out to the backend folks if anything needs clarification.


Don't think we need sudo on the npm commands

sudo npm install -g yo gulp
sudo npm install -g generator-yeogurt

Windows doesn't have a sudo equivalent, aside from running command prompt "as administrator"
Node lets you install globally anyway, I believe

Good to know. I don't have a lot of confidence something like that is to be consistent across platforms and configurations.
We should probably have instructions ready for both cases. You will have sudo on Windows in some of the common terminal alternatives. We're going to need to decide which shell we have the students use in the lab.

I don't think npm needs sudo on mac either but I could be wrong.
Meanwhile, just ran the install on plain ol' command prompt on a Windows 10 machine and it worked great!

there is also a git bash terminal the computers may have, depending on how git was installed, that might seem more familiar, since bash commands like pwd and ls will actually work. We'll have to check.

K. We can figure this stuff out the day before. I will also be in Wednesday and open most of the day.
Great news about Windows! Thanks for doing that.


Deployment demos?

Would it be helpful to include demos or documentation on how to deploy Oxygen APIs to AWS, GCP or similar?  I had a similar project that I just deprecated and I remember that moving from a version running locally to a deployed instance was a common pain point.  If so I'd be glad to add them.

@amellnik
Absolutely, that's a great idea. In retrospect, that's a pretty big piece of documentation that's missing from the project. I appreciate the help!

Absolutely second that. As a non-architect this is what keeps me from using Oxygen for my use case. If there was something like
https://genieframework.com/docs/genie/v5/tutorials/16--Using_Genie_With_Docker.html
(esp the precompilation bit) and/or analogous to
https://fastapi.tiangolo.com/deployment/deta/
for some service that would be so valuable to me. Right now it boils down a lot of trial and error based off of myriads of bits.

There is this using Azure: https://discourse.julialang.org/t/tutorial-deploying-an-oxygen-jl-app-to-microsoft-azure/107595

We're deploying Julia docker containers to AWS ECS (aka Fargate)
These are some of the key issues when you deploy:

minimize container startup time (compile to CPU targets)
create a /health endpoint. (load balancers pings this to see if container is alive)
This may require a prioritized route feature in Oxygen.jl (TODO post issue)
run with --threads=auto,1 (important to have a dedicated interactive thread)

This is still a work in progress, we're at the dev stage now, but should be in production within a year. Here's our Dockerfile and ECS config within the CDK project:

https://github.com/open-AIMS/ReefGuideAPI.jl/blob/main/Dockerfile
https://github.com/open-AIMS/reefguide-web-api/blob/main/src/infra/components/reefGuideAPI.ts


persisting CreateCommitError

For dataset https://huggingface.co/datasets/venetis/VMMRdb_make_model_test, we get the same error after 30 retries: CreateCommitError. Another one: https://huggingface.co/datasets/celsowm/stack-exchange-paired-mini-1k
Also, two other datasets have the CreateCommitError for more than 1 month, so it does not seem to be the same issue:

https://huggingface.co/datasets/schhetri41/PoseDataset
https://huggingface.co/datasets/asuglia/coco_pope

see https://github.com/huggingface/dataset-viewer/pull/2758#issuecomment-2090313327

Same for error LockedDatasetTimeoutError: 6 entries are never retried, from more than one month. I'm not sure why they are not removed during the daily backfill.

See also https://huggingface.co/datasets/Cnam-LMSSC/vibravox/discussions/4

Reducing the prio, since it seems to only affect venetis/VMMRdb_make_model_test now, and has not been reported since. Maybe some issue with a LFS file.


[Bim Tiles] Error is thrown when removing a streamed model from the scene

Describe the bug 📝
After streaming an IFC file into the scene, if i try to remove it by calling remove(modelID) in FragmentStreamLoader, an error will be thrown by GeometryCullerRenderer, because the _geometries property has been cleared by the culler's corresponding remove(modelID), but the _foundGeometry property will still have some of the model's geometry data. The "Geometry not found!" error is thrown in this block the next time the culler is automatically updated. https://github.com/ThatOpen/engine_components/blob/9abb99ce95c7a4d8bbe3886ef78cacbdb38fb248/src/fragments/FragmentIfcStreamer/src/geometry-culler-renderer.ts#L533-L539
Reproduction ▶
No response
Steps to reproduce 🔢

Call FragmentStreamLoader.load() and stream an ifc model into the scene
Call FragmentStreamLoader.remove(modelID) and remove the previosuly added model
Check console for the GeometryCullerRendered error the next time the culler is updated

System Info 💻
System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 5.85 GB / 15.89 GB
  Binaries:
    Node: 20.12.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (123.0.2420.65)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    openbim-components: 1.4.15 => 1.4.15

Used Package Manager 📦
npm
Error Trace/Logs 📃
No response
Validations ✅

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
[X] Check that this is a concrete bug. For Q&A join our Community.
[X] The provided reproduction is a minimal reproducible example of the bug.

Thanks for the PR! Did you try this? Last time I tried this worked. If it doesn't, we'll merge your PR 🙏

No problem! I just tried using that code, but the error persists. Again, there could be a better way around this, but in my app i just cleared the .foundGeometry array after removing the model from the scene and that seemed to prevent the error from being thrown.


Change indents.

This change is

Reviewed 1 of 1 files at r2.
Review status: 1 of 7 files reviewed at latest revision, all discussions resolved, some commit checks broke.

Comments from Reviewable

Reviewed 6 of 7 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks broke.

Comments from Reviewable

rebuild


Fix cross-site scripting vulnerability relating to the logout route

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable
[x] Documentation in docs/ or install-docs/ was updated, if applicable

Fixes https://github.com/pajbot/pajbot/security/code-scanning/8?query=ref%3Arefs%2Fheads%2Fmaster

I don‘t think this is right. Have you tried this?

Have you tried this?

Yes, logging in and out works just fine. It returns to the page you were on and everything.

I don‘t think this is right.

What doesn't look right about it? I did a similar pr for pajbot2: https://github.com/pajbot/pajbot2/pull/447

Are you sure the argument to redirect() needs to be escaped? I would think it'd mess up special characters... The real vulnerability here is sending people to a URL like https://forsen.tv/logout?returnTo=http://badwebsite.com which I don't think this PR fixes, right?

To elaborate on this, go to https://pajlada.pajbot.com/user/<html> and click Log In, and then Log Out again, you'll see you'll get sent back to the same page again. Without having tried your PR, I'd think it would send me back to https://pajlada.pajbot.com/user/%253Chtml%253E (double encoding) when using the logout.

The real vulnerability here is sending people to a URL like https://forsen.tv/logout?returnTo=http://badwebsite.com which I don't think this PR fixes, right?

I'm still working on this one. I still need to figure out how to check the host domain against a variable (since redirectTo starts after the host)

To elaborate on this, go to https://pajlada.pajbot.com/user/<html> and click Log In, and then Log Out again, you'll see you'll get sent back to the same page again. Without having tried your PR, I'd think it would send me back to https://pajlada.pajbot.com/user/%253Chtml%253E (double encoding) when using the logout. Which is incorrect, and does not fix any security issue if I'm not mistaken.

I can see what you mean, https://pajlada.pajbot.com/user/%3Cscript%3Ealert('XSS');%3C/script%3E didn't seem to do anything either on the master branch - which evidently I didn't fully test and mostly relied upon CodeQL. I'll mark as invalid and continue working on the redirect one.


Workspace Numbers not the Same as Hyprland

Describe the bug
When using the Show Workspace Number option, it is not the same workspace numbers as in Hyprland.
To Reproduce
Steps to reproduce the behavior:

Activate the Option Show workspace numbers
Open a window on workspace 10.

Expected behavior
I would expect when I open a window on workspace 10 that I get the number 10 in the bar.
Screenshots

Desktop (please complete the following information):

Archlinux
Hyprland v0.44.1

Found my error had Mask Workspace Numbers on Monitor on


Images not loading in login page

Images in login page are not loading in production app. Only in Development.

Implemented a new Design for Login Page
#243


Fixes #10013: Implement first stage of NoSQL profiler

Describe your changes:
Fixes https://github.com/open-metadata/OpenMetadata/issues/10013

Implemented the NoSQLProfilerInterface as an entrypoint for the nosql profiler.
Added the NoSQLMetric as an abstract class.
Implemented the interface for the MongoDB database source.
Implemented an e2e test using testcontainers.

Type of change:

[ ] Bug fix
[x] Improvement
[ ] New feature
🤷 Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Checklist:

[x] I have read the CONTRIBUTING document.
[x] My PR title is Fixes <issue-number>: <short explanation>
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

[x] I have added tests around the new logic.
[ ] For connector/ingestion changes: I updated the documentation.

anybody know why py_format is failing for files I have not changed?
ingestion/src/metadata/great_expectations/action.py:110:4: W0237: Parameter 'expectation_suite_identifier' has been renamed to 'payload' in overriding 'OpenMetadataValidationAction._run' method (arguments-renamed)
ingestion/src/metadata/great_expectations/action.py:110:4: W0237: Parameter 'checkpoint_identifier' has been renamed to 'expectation_suite_identifier' in overriding 'OpenMetadataValidationAction._run' method (arguments-renamed)

OpenMetadataValidationAction

You should check the parent method signature (it looks like some parameters do not use the same name in the method of the children class

OpenMetadataValidationAction

You should check the parent method signature (it looks like some parameters do not use the same name in the method of the children class

@TeddyCr
The files which are being reported were not changed in this delivery (neither OpenMetadataValidationAction class). I dont mind fixing the linting issue but I it is a bit strange that it is getting reported here. I also dont see any breaking change in great-expectations

re: #15189 (comment)

It appears gx have the same issue with their linter. I will add an ignore comment like they did...
https://github.com/great-expectations/great_expectations/blame/0.18.8/great_expectations/checkpoint/actions.py#L374C16-L374C83

Awesome. Thank you

@TeddyCr thanks. Should I take any action on this discussion or are we good?


Add convenience methods for meta attributes

This allows you to access meta attributes with something like:
element.id

Instead of:
element.meta.id

Note: There is still more work to fix this.

There is a bug with this, as it still mutates meta #40
It is not DRY, as it has copy/paste code from Meta class

I will try to address these together as I refactor how we use meta.

cc @danielgtaylor

@smizell Looks good. Merge when ready.

:+1:


Generalized Procedure Learning: Anticipation issue

<(&/,<$1 --> A>,+10,(^pick,{SELF},$1),+10) =/> <$1 --> B>>.
100
<a --> A>. :|:
10
<a --> B>!
10
<a --> B>. :|:
In this case, execution happens and an anticipation is generated, but the last event should lead to confirmation of the anticipation, but for some reason does not.

Resolved by https://github.com/opennars/opennars/commit/bdbc2d497fccd8acb7cf9d16b84f812dc8aeaaa0 in v3.0.2_dev.


Compilation/restore failing (via build.cmd) - The target "Restore" does not exist in the project

I cloned the repo and run build.cmd /t:Restore (for build.cmd it's the same result).
It mostly works but fails on Microsoft.VisualStudio.RazorExtension.csproj with MSB4057 ("The target "Restore" does not exist in the project") error:
D:\Work\Repos\aspnet\Razor.my>build.cmd /t:Restore
Using KoreBuild 2.1.0-preview1-15532
WARNING: dotnet found on the system PATH is 'C:\Program Files\dotnet\dotnet.exe' but KoreBuild will use 'C:\Users\Sergei
Dorogin\.dotnet\x64\dotnet.exe'.
WARNING: Adding 'C:\Users\Sergei Dorogin\.dotnet\x64' to system PATH permanently may be required for applications like Visual
Studio or VS Code to work correctly.
Adding C:\Users\Sergei Dorogin\.dotnet\x64 to PATH
.NET Core runtime 2.0.0 is already installed. Skipping installation.
.NET Core SDK 2.1.0-preview1-007042 is already installed. Skipping installation.
>>> dotnet.exe msbuild @D:\Work\Repos\aspnet\Razor.my\artifacts\msbuild\msbuild.rsp
  Using lineup Internal.AspNetCore.Universe.Lineup 2.1.0-preview1-27331
  Using lineup Internal.AspNetCore.Partners.Lineup 2.1.0-preview1-27331
  Pinned 200 package(s) from 2 lineup(s) in 1548ms

<lots of restore skipped>

D:\Work\Repos\aspnet\Razor.my\tooling\Microsoft.VisualStudio.RazorExtension\Microsoft.VisualStudio.RazorExtension.csproj : error MSB4057: The target "Restore" does not exist in the project. [C:\Users\Sergei Dorogin\.dotnet\buildtools\korebuild\2.1.0-preview1-15532\KoreBuild.proj]
D:\Work\Repos\aspnet\Razor.my\build\VSIX.targets(29,5): error MSB3073: The command ""C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe" "D:\Work\Repos\aspnet\Razor.my/tooling\Microsoft.VisualStudio.RazorExtension\Microsoft.VisualStudio.RazorExtension.csproj" /t:Restore /v:m /p:BuildNumber=t000" exited with code 1. [C:\Users\Sergei Dorogin\.dotnet\buildtools\korebuild\2.1.0-preview1-15532\KoreBuild.proj]

What did I miss?

@evil-shrike does your local copy contain this commit from yesterday?

Also cc @natemcmaster in case you have ideas.

What version of VS is installed? You need at least 15.3.
Also, it looks like you're using the BuildTools SKU of VS. I'm not sure if VSIX development is available in this SKU.

sure, 15.3

it looks like you're using the BuildTools SKU of VS

I have several VS and BuildTools, I guess they are in conflict and it causes the error.

Ok. I assume the problem is here then:
https://github.com/aspnet/Razor/blob/b064a28dcfb1c9e1b9c694022b67e6393f2f72db/build/VSIX.targets#L14-L17
This globbing pattern picks up the first VS it finds alphabetically. BuildTools > Community > Enterprise. @jkotalik and I are currently looking into making our build tools smarter about which version of VS they pick using the vswhere.exe tool, but this work is not done yet. See https://github.com/aspnet/BuildTools/issues/428

@natemcmaster I don't want users to be blocked by this though - do you think it would work to add a /p:SuppressRazorVSIX=true or some such property until that work can be completed?

Yeah, that sounds good. We did that on the rel/2.0.1 branch and called it /p:BuildVSIX=false

Cool, I'll send a PR to that effect

@evil-shrike  - I've merged this now https://github.com/aspnet/Razor/pull/1731
Please let us know if this solves the problem:
.\build.cmd /p:BuildVSIX=false

@rynowak works great, thanks

OK cool, I'm going to close this then. Let us know if you run into any other issues.


Fix/analytics connection hang

Describe changes
I implemented a workaround that disables retries for sending analytics data, in response to issue #130. This ensures the CLI remains responsive even when the Segment analytics API is unreachable, due to network failures or blocking mechanisms like PiHole.

Updated src/mlstacks/analytics/client.py to set max_retries to 0, which can be adjusted as needed.
Wrapped the analytics_context.track call in a try/except block within the track_event function. This ensures the return False statement is reachable for error handling and logging exceptions.

Reference to Documentation
The Segment Python library documentation did not explicitly mention configurable options for max_retries, but the source code revealed a max_retries property in segment/analytics/client.py.
Testing
To simulate an unreachable analytics API domain at api.segment.io, I redirected all requests to this domain to <IP_ADDRESS> by adding the following entry in the /etc/hosts file on my Mac:
<IP_ADDRESS> api.segment.io

Following this setup, I tested the deploy, breakdown, output, and destroy CLI commands, and confirmed it exits immediately, without hanging, after attempting to reach the analytics API domain once.
Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to docs, I have updated the documentation
accordingly.
[x] I have added tests to cover my changes.
[x] I have based my new branch on develop and the open PR is targeting
develop. If your branch wasn't based on develop read
Contribution guide on rebasing branch to develop.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to
change)
[ ] Other (add details above)

Thank you for this PR! One thing you'll probably need to do is rebase on develop branch. If your branch is branched off develop already, then you can just click the 'edit' button at the right / top of the header and then update it so that it knows it'll be merged onto develop and not to main (which it's currently set to do).

Thanks!

You can also see the CI is showing a linting error, so please do run the formatting and linting scripts locally before updating with the fix.

Just fixed any issues mentioned in the CI and ran the format and lint scripts again. This was indeed branched off develop already so the edit button at the top allowed me to update it. Thanks!

@coderabbitai review

Great suggestion, @strickvl. I've committed the change. Thanks for your input. Regarding the other CodeRabbit suggestion, I'm assuming it's safe to ignore as the app uses a single instance of the analytics client?

@marwan37 yep sometimes the rabbit has good suggestions. Today, not so much :) You can ignore them.

@marwan37 sorry the line I suggested seems to have been too long. I'd break up that logger statement and then I'll rerun the CI.

@strickvl, I've adjusted the logger statement. Thanks for pointing that out.

@marwan37 I cloned your fork + checked out your branch but when running this I still get the following output when testing locally:

i.e. it doesn't seem to pick up your custom error at all. Looking at their codebase, it's not clear to me whether the on_error is doing what we think it's doing actually... @bcdurak any thoughts? This e.g. is the place where the log I'm getting is generated.

@marwan37 can you run the format / linting script on the files on your end and push any changes that get made?


fix key and value columns of map are normal column type

Proposed changes
Problem summary
PR(https://github.com/apache/doris/pull/17330) has changed the column type of kay and value from array to normal column, but orc&parquet reader still cast to array column, resulting in cast error.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

LGTM

run buildall


Using url not working

Hi all,
I tried using the url as json data but nothing to show, can anyone create a sample how to call JSon from url?
I am using this json https://jsonplaceholder.typicode.com/posts
Thanks

I think is not active?

can you send me your example code?

Hi @jiren ,
Thanks for reply, I really like your script but I got stuck to using it.
here the example script:
https://www.dropbox.com/s/zbx1eov9yi1kfwn/examples.zip?dl=0
I used the pagination.html for test it
And I also got the Uncaught TypeError: qFn is not a function error on console.
Really need your help, Thank

Do you mean the file under view directory? Or can you please mention which file exactly? I tried take a look under view directory but can't find to edit the attribute
Thanks

You need to change view template and filtering options based on your JSON data fields.

Finally found it the data displayed, but this error Uncaught TypeError: qFn is not a function still appeared, how to solved this?
Thanks,

Hi, is it possible to do something like this:
var services = "myremoteurl.com/json.json";
var FJS = FilterJS(services, '#movies', {

});

Get error: Uncaught TypeError: Cannot read property 'replace' of undefined
Any idea? Thanks!


Use material theme for material table

Use material theme for material table
Fix auto sizing issue

Pull Request Test Coverage Report for Build 2873

1 of 2 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.004%) to 36.771%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/components/material/MaterialTable.tsx
1
2
50.0%

Totals

Change from base Build 2870:
-0.004%

Covered Lines:
2585

Relevant Lines:
6294

💛  - Coveralls


[BUG]: KubeloginInstallerV0 Cannot read properties of undefined (reading 'trim')

Task name
KubeloginInstallerV0
Task version
0.226.0
Environment type (Please select at least one enviroment where you face this issue)

[x] Self-Hosted
[ ] Microsoft Hosted
[ ] VMSS Pool
[ ] Container

Azure DevOps Server type
Azure DevOps Server (Please specify exact version in the textbox below)
Azure DevOps Server Version (if applicable)
Azure DevOps Server 2023.8
Operation system
Debian 12
Task log
Starting: KubeloginInstaller
==============================================================================
Task         : Kubelogin tool installer
Description  : Helps to install kubelogin
Version      : 0.226.0
Author       : Microsoft Corporation
Help         : https://azure.github.io/kubelogin/index.html
==============================================================================
##[error]Cannot read properties of undefined (reading 'trim')
Finishing: KubeloginInstaller

Relevant log output
##[error]Cannot read properties of undefined (reading 'trim')

Aditional info
Kubelogin version: 0.0.32
After restarting failed job, this task succeeds

Same problem here!

I was also experiencing that issue ~30 mins ago on self-hosted agents.
It appears to have been fixed now - my pipelines are working again :)

Hi everyone, thanks for reporting.
Can anyone confirm if this issue still persists? if so what's the reoccurrence rate?
I was just checking the source code of this task, and I don't see any recent changes deployed (last change was 2 months back), so ig it's unlikely this issue might be from the task end.
Can anyone confirm if this issue is fixed? if not, can you enable the debug logs (debug=true) and send us the failure logs to v-mohithgc @microsoft.com.
Thanks

Hello, thanks for the response. This issue appears from time to time, like once a week for us on multiple pipelines. It existed all the time since we started using kubelogin task (for a month now).
I will try to capture output with debug logs.

I was experience the issue yesterday for about 1 hour (on self hosted agents).

Hello,
Thank you for reporting the issue.
The root cause of the issue is that the task is making an anonymous REST API call to GitHub in order to fetch the latest version of kubelogin. However, anonymous calls in GitHub are subject to a limit of 60 requests per hour. When a 403 error  occurs in the task, it is not being handled properly, leading to a failure later in the code when attempting to use the version tag. Hence, you see the error "cannot read property of undefined".
There is no way to provide credentials to the task to make an authorized rest api call with a rate limit of 5000 calls per hour.
However, there are 2 possible workarounds.
The first one is to specify the version explicitly in the task. This way we will skip the call to github to retrieve the latest version. For example,

task: KubeloginInstaller@0
inputs:
kubeloginVersion: 0.0.30
The second one is to avoid using KubeloginInstaller task and install kubelogin on the VM where you run the self-hosted agent and add to it to the PATH. The tasks that use kubelogin should pick it up there.

We will be working on a fix , but there is no ETA at the moment.
(Note. This issue is unlikly to happen on Microsoft Hosted agents because a new agent is assigned to each pipeline run )

Thank you very much for your response and your suggestions on how to resolve the issue!

Is there any update on this issue?  We are required to use kubelogin for AKS + Azure AD + Azure RBAC integration, and the task fails often enough to make this a serious challenge for teams.

The first one is to specify the version explicitly in the task. This way we will skip the call to github to retrieve the latest version. For example,

task: KubeloginInstaller@0
inputs:
kubeloginVersion: 0.0.30

Wouldn't specifying the version explicitly also hit the GitHub API rate limit?  It seems getKubeloginRelease() is called which queries the API:
let request = new webClient.WebRequest();
request.uri = 'https://api.github.com/repos/' + KUBELOGIN_REPO_OWNER + '/' + KUBELOGIN_REPO + '/releases/tags/' + version;
request.method = 'GET';
request.headers = request.headers || {};
request.headers['User-Agent'] = userAgent;

const response = await webClient.sendRequest(request);

@sivetic is right -we've specified a version, and we consistently still get rate limited. We need to find a different solution until this gets resolved as it's pretty impactful to our pipelines.

@matthawley A quick workaround we do is to replace the official task with a bash/PS script:
- bash: |
   curl -fsSLO https://github.com/Azure/kubelogin/releases/download/v0.1.1/kubelogin-linux-amd64.zip
   unzip -ojd /usr/local/bin kubelogin-linux-amd64.zip bin/linux_amd64/kubelogin
   rm -f kubelogin-linux-amd64.zip
   kubelogin --version

  displayName: 'Install Kubelogin'

@sivetic Nice - I'll give this a try!

We are currently working on the fix, will update as soon as possible.


volume_server_handlers_read.go:71] read /2,89f636320a error: already deleted after fs.meta.load

Sponsors SeaweedFS via Patreon https://www.patreon.com/seaweedfs
Describe the bug
Few files are not being opened after weed shell fs.meta.load
System Setup
Ubuntu 18.04
Weed v. version 30GB 1.31 linux amd64
Started seaweedfs filer with this command
./weed -v=0 server -filer=true -dir=storage -pulseSeconds=1 -volume.images.fix.orientation=false

Add new files to filer using REST API at port 8888.
the storage directory contains:
1.dat  2.dat  3.dat  4.dat  5.dat  6.dat  7.dat   filer  snapshot
1.idx  2.idx  3.idx  4.idx  5.idx  6.idx  7.idx  conf        log

All files are being served from port 8888 and accessible.
Now go to weed shell and run fs.meta.save, this created a new file in the root of the folder as
localhost-8888-20190425-104730.meta

Now delete the filer directory from
1.dat  2.dat  3.dat  4.dat  5.dat  6.dat  7.dat  snapshot
1.idx  2.idx  3.idx  4.idx  5.idx  6.idx  7.idx  conf        log

and stop start seaweedfs.

No operation was performed on Filer API port 8888.. to delete this file(almost 10 files are being shown as deleted.)
as filer directory contains all meta values, but on deleting that directory, few files are also missing.
After doing many start-stops to seaweedfs the log from already deleted changed to

there were total of 108 files were being added

on fs.meta.load meta values are back but few files are missing now.
Expected behavior
It should not give 404 or already delete as actual file or file data is not saved on filer store.
Additional context
This issue is to demonstrate what I described over slack.

I can not reproduce locally.
There are no deletion happening, while the file in the volume .dat and .idx files are changed. Can you check why the .dat and .idx files are changed when you fs.meta.save and fs.meta.load?

what could be the possibility of the changes in .dat or .idx?

We are not deleting anything.
Auto Vacuum forcing to delete those files??

Try it this way.
after deleting the filer store directory. and before doing fs.meta.load, keep seaweedfs filer keep running.
I think that's the moment when master filer made some changes. I am trying to replicate it again, I will post again with screenshots.

If there are some updates to existing uploaded files, e.g., upload a new version of a picture, the picture's metadata will point to a new file id, and deleting the old file id. So using the previous fs.meta.save meta files will point to the old deleted file id.

Okay, this is what I came to.
We recorded almost 15 minutes for a camera, and these are all different jpegs with time series, which cannot be re-recorded. And cannot be deleted. After recording for 15 minutes I stopped the server which was recording the jpegs (getting from the camera and send it to Seaweedfs).
Now nothing is being added and nothing is getting replaced/deleted.
I repeat the above process again. During all this seaweedfs is running. after all meta.save meta.load,
I have lost 14 images.
That's all I can tell. More than that I have no idea what I am doing wrong which is making it lose images. I am going to update seaweedfs any way now.

If possible, you can run fs.meta.save again if found files are missing and send me the 2 meta files. I can code something to find out the difference.

added a simple tool to see the content of meta file: https://github.com/chrislusf/seaweedfs/commit/6aad558972459f048835a85d721e48488e6c604e

closing. reopen if more findings.


Integration with INA219

I am trying to build a Raspberry Pi controller that switches a pin state based on the voltage, and was hoping to use the following modules to make this work together.
https://www.npmjs.com/package/ina219
https://www.npmjs.com/package/raspi-io
https://www.npmjs.com/package/johnny-five
I have successfully read the current and voltage from an INA219 connected to a Raspberry Pi, and also turned an LED on/off with raspi-io and johnny-five.
Based on feedback from @dtex (https://github.com/rwaldron/johnny-five/issues/1500#issuecomment-419728752), I was wondering if the GPIO pins had to be declared in any way to get these modules working together.  @dtex thought the modules (INA219 & raspi-io) may need shared access to the GPIO pins. Ideally the INA219 would use a 3.3V, ground, and both I2C pins, and johnny-five / raspi-io would use the rest of them.
Does raspi-io need to be declaratively set to share GPIO pins?

Pins cannot be shared, that's fundamentally the way that microcontrollers work. Pins often support more than one type of functionality (e.g. pin P1-3 supports the SDA pin of I2C, GPIO Input, and GPIO Output), but they can only be used for one of these at a time, not both.
I'm not sure this is actually your question though. Can you confirm that what you want to do is use the ina219 library linked on P1-3 and P1-5, while having an LED connected to an entirely different pin, e.g. P1-7, is this correct?
If so, yes Raspi IO and ina219 should work together just fine without modification.

Yes, the idea is to use pins PI-1, 3, 5, 9 for the INA module, and some of the other pins 7, 11, 13, etc. for controller switching.

Oh interesting, what are pins 5 and 9 being used for in the INA module? (they're not I2C pins)

I'm using the PI indexing scheme. The breakout board needs I2C as well as power and ground.
1 - 3.3V Power
3 - SDA (I2C)
5 - SCL (I2C)
9 - Ground

Oh, lol, right...that's what I get for not checking my own pinout diagrams 😅
So yes, you should be able to use that module without interference from Raspi IO, and you should not need to do any special configuration to get them to work together. Everything should just work AFAIK. (famous last words?)

I did get some of it working, but ran into memory issues. I'm trying again with the rpio module to do some switching instead of johnny-five + raspi-io.
Here's the thread with the memory issues if you are interested: https://github.com/rwaldron/johnny-five/issues/1504#issuecomment-421041814
And the rpio module: https://www.npmjs.com/package/rpio

Since it sounds like this is now focused solely on memory issues and we have a separate issue opened for it, I'm going to go ahead and close this issue.


style: add pre-commit and new checks

Adds pre-commit as a check-driver (in turn, driven by Nox), and adds some new checks - I added most of my favorites, figuring we could scale back or split up as needed.

Black (like before)
Pre-commit-hooks: some common simple checks, like for nice end-of-files, etc.
PyUpgrade, set to 3.6+: A fantastic tool that can keep syntax fresh and clean.
isort (like before)
setup-cfg-fmt: Some standardisation for setup.cfg, also keeps trove classifiers accurate
pycln: Cleans out unused imports automatically (flake8's check but mutating)
yesqa: cleans out noqa's that are no longer needed
flake8: This time, with bugbear, which looks for problematic expressions that might be correct but tend to confuse readers or cause bugs
mypy (as before)
codespell: Looks for common misspellings. Very handy!
pygrephooks: Avoid allowing blanket noqa or type ignores, type commends, and some other common mistakes.
shellcheck: looks for mistakes in shell scripts. Might not be needed, not sure if there are any shell scripts.

Removes "nox -s blacken", since some checks modify in place anyway, and everything is in git.
I'll comment on the changes a bit inline.

I'm on board with this and agree with the changes overall, there are a lot of changes in this PR but they all seem to be small linty/style type stuff which is fine!
However since it's a reasonable change to how our CI works (albeit not to the user, they simply run nox as normal which is great!) I'd like to get some other maintainers thoughts/comments before merging 🙂

Happy to merge as is or do we want to change to the pre-commit action?

No, that action is deprecated in favor of pre-commit.Ci. Someone with permissions will have to enable pre-commit.ci for the repo.

No, that action is deprecated in favor of pre-commit.Ci. Someone with permissions will have to enable pre-commit.ci for the repo.

Okay, sounds like that's best done under a new PR then

I don't have experience with pre-commit, butit seems like it will fit well with Nox!
Also, and sorry for my ignorance, but... will pre-commit do the changes for us, or it will just fail?

It will just fail. It effectively just runs all the linters specified in the config file. You can use it how we do here (by calling pre-commit run either manually or from another tool like Nox) or you can install it as a git pre-commit hook so that every time you commit it will run and abort the commit if it fails.
Some people (myself included) don't like the latter option as long running checks can interrupt your commit flow but it depends on what you have configured

I don't have experience with pre-commit, butit seems like it will fit well with Nox!

Also, and sorry for my ignorance, but... will pre-commit do the changes for us, or it will just fail?

It will just fail. It effectively just runs all the linters specified in the config file. You can use it how we do here (by calling pre-commit run either manually or from another tool like Nox) or you can install it as a git pre-commit hook so that every time you commit it will run and abort the commit if it fails.
Some people (myself included) don't like the latter option as long running checks can interrupt your commit flow but it depends on what you have configured

Does that imply that this PR leaves no easy way for a developer to run black and isort to make changes as the "blacken" session does now?

I almost always run pre-commit run -a, but pre-commit install is quite speedy, as the git hook only looks at changed files. It even handles partial stages. And git hooks can be skipped with -n in a pinch. I just like having control.
Pre-commit supports both changing checks (black, pyupgrade) as well as failing checks (flake8). The changing ones are better, since they can be fixed automatically by pre-commit.ci and pushed.

Does that imply that this PR leaves no easy way for a developer to run black and isort to make changes as the "blacken" session does now?

Well... not exactly. As far as I know, if you install pre-commit, you can run it by yourself, and it should fix your mistakes?
BTW, I would suggest to add --show-diff to the pre-commit command called by Nox, to show the Git diff where the failure is?

Does that imply that this PR leaves no easy way for a developer to run black and isort to make changes as the "blacken" session does now?

Sorry just re-read my reply and it wasn't too clear! As @henryiii said it can do both changing and non-changing fixes, my saying it will fail was confused by pre-commits commit hook functionality which would fail the commit even if it managed to change the code e.g. black, pyupgrade etc as you'd have to re-commit the changes.
Looks like with pre-commit run this isn't an issue :)

Thank you @henryiii


compute_deltas raising "CUDA error: invalid configuration argument" on large inputs

🐛 Bug
torchaudio.functional.compute_deltas is raising a CUDA error: invalid configuration argument when the batch size is too large.
To Reproduce
Steps to reproduce the behavior:

On my GTX 970, calling compute_deltas with a large enough spectrogram and batch size triggers this error, e.g. compute_deltas(torch.rand([64, 2, 1000, 1000], device="cuda")).

Googling other triggers for this error, it seems this is usually caused by exceeding the maximum CUDA block size (e.g. here). Since this varies by GPU, I'm not sure whether it will reproduce on newer cards.
Examples:
>>> compute_deltas(torch.rand([64, 2, 1000, 1000], device="cuda"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jcaw/opt/miniconda3/envs/fastaudio-dev/lib/python3.7/site-packages/torchaudio/functional.py", line 1623, in compute_deltas
    specgram = torch.nn.functional.pad(specgram, (n, n), mode=mode)
  File "/home/jcaw/opt/miniconda3/envs/fastaudio-dev/lib/python3.7/site-packages/torch/nn/functional.py", line 3561, in _pad
    return torch._C._nn.replication_pad1d(input, pad)
RuntimeError: CUDA error: invalid configuration argument

This appears to be distinct from an outright out-of-memory error. If I push the parameters further:
>>> compute_deltas(torch.rand([64, 2, 2000, 2000], device="cuda"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/jcaw/opt/miniconda3/envs/fastaudio-dev/lib/python3.7/site-packages/torchaudio/functional.py", line 1623, in compute_deltas
    specgram = torch.nn.functional.pad(specgram, (n, n), mode=mode)
  File "/home/jcaw/opt/miniconda3/envs/fastaudio-dev/lib/python3.7/site-packages/torch/nn/functional.py", line 3561, in _pad
    return torch._C._nn.replication_pad1d(input, pad)
RuntimeError: CUDA out of memory. Tried to allocate 1.91 GiB (GPU 0; 3.95 GiB total capacity; 2.15 GiB already allocated; 518.06 MiB free; 2.39 GiB reserved in total by PyTorch)

Reducing the size of the input tensor solves the issue:
>>> compute_deltas(torch.rand([32, 2, 1000, 1000], device="cuda"))
tensor(...)
>>> compute_deltas(torch.rand([64, 2, 500, 1000], device="cuda"))
tensor(...)

Expected behavior
compute_deltas should return successfully (or explicitly produce an out-of-memory error, if that's the real issue).
Environment
PyTorch version: 1.7.0
Is debug build: True
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Manjaro Linux (x86_64)
GCC version: (GCC) 10.2.0
Clang version: 11.0.0
CMake version: version 3.19.1

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce GTX 970
Nvidia driver version: 455.45.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.4
[pip3] torch==1.7.0
[pip3] torch-audiomentations==0.4.0
[pip3] torchaudio==0.7.0
[pip3] torchvision==0.8.1
[conda] blas                      1.0                         mkl    anaconda
[conda] mkl                       2020.2                      256    anaconda
[conda] mkl-service               2.3.0            py37he8ac12f_0
[conda] mkl_fft                   1.2.0            py37h23d657b_0
[conda] mkl_random                1.1.1            py37h0573a6f_0    anaconda
[conda] numpy                     1.19.4                   pypi_0    pypi
[conda] numpy-base                1.19.2           py37hfa32c7d_0
[conda] torch                     1.7.0                    pypi_0    pypi
[conda] torch-audiomentations     0.4.0                    pypi_0    pypi
[conda] torchaudio                0.7.0                    pypi_0    pypi
[conda] torchvision               0.8.1                    pypi_0    pypi

Additional context
It appears to be CUDA-specific. I can't trigger this error on CPU.

Hi @jcaw
Thanks for the report and the detailed description. Looks like the fix should be applied in PyTorch, I will move the issue to PyTorch.


Use dict instead of OrderedDict for generating skeletons

Codecov Report

Merging #2222 (8a61756) into v2 (a3d8b9f) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##               v2    #2222      +/-   ##
==========================================
- Coverage   97.60%   97.57%   -0.03%
==========================================
  Files          56       56
  Lines       10470    10470
==========================================
- Hits        10219    10216       -3
- Misses        251      254       +3

Impacted Files
Coverage Δ

botocore/utils.py
97.05% <100.00%> (-0.17%)
:arrow_down:

botocore/httpsession.py
92.48% <0.00%> (-0.58%)
:arrow_down:

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 a3d8b9f...8a61756. Read the comment docs.


Possibility to prevent certain sections of code being formatted by VSCode

I was considering to use another extension to structure my import statements into columns such as the following:
import {    Commandlet   } from "@cli/Framework/Commandlet" ;
import {    Manifest     } from "@cli/Framework/Manifest"   ;
import {    PackageJson  } from "@cli/Framework/PackageJson";
import {    VerbsData    } from "@cli/Framework/VerbsData"  ;
import {    IPackage     } from "@cli/Schemas/IPackage"     ;
import {    IPackageJson } from "@cli/Schemas/IPackageJson" ;
import * as fs             from "fs"                        ;
import * as path           from "path"                      ;

Unfortunately though, running the VSCode formatter (either manually or automatically when saving) sanitizes the number of spaces and yields the following more usual output:
import { Commandlet } from "@cli/Framework/Commandlet";
import { Manifest } from "@cli/Framework/Manifest";
import { PackageJson } from "@cli/Framework/PackageJson";
import { VerbsData } from "@cli/Framework/VerbsData";
import { IPackage } from "@cli/Schemas/IPackage";
import { IPackageJson } from "@cli/Schemas/IPackageJson";
import * as fs from "fs";
import * as path from "path";

I'd like to know whether there is any option available or feature planned to configure the fomatter s.t. it does not format my customized imports or other configurable sections.

This is tracked by https://github.com/Microsoft/TypeScript/issues/18261
There are no imminent plans to change the built-in JS/TS formatter, but another formatting extension may be able to preserve the formatting or reformat the code the way you are after

@mjbvz I stumbled upon beautifier myself but the author mentions in HookyQR/VSCodeBeautify#122 that he is not going to add real Typescript support to the extension and says in multiple comments that one should rely on the VSCode formatter.
Do you have any further information on Microsoft/TypeScript#18261? Has any work been done on this or is it just untouched?

It's not high priority work for the TypeScript team but I'm sure someone would be happy to help you look into it if you are interested

@mjbvz Unfortunately I don't have either the capacities nor the required knowledge to contribute. Most likely I'll be trying to find a workaround in the meantime using some script that will format the import groups of a file after it has been saved.


The configuration file supports the properties type

The configuration file supports the properties type

你的docker启动命令是怎么配的

@wenminglei just use seata-spring-boot-starter to support properties type , or not use seata-spring-boot-starter but support properties ?

@slievrly seata-spring-boot-starter is not used, but properties are supported. Because our configuration center is developed by ourselves, only the properties type is supported at present. On the other hand, since typesafe supports multiple types of configurations, the changes to Seata will be small.


brew cask list in a dir containing installed cask file(s) results in file does not exist error

I try to use homebrew-cask to install all software.  So I create cask files locally.
If I do a brew cask list from a directory containing one of those files, and the cask is still installed, it fails.  If do it from a directory that doesn't contain any cask files for installed programs, it succeeds.
In the failure case, brew cask appears to be looking for a file with the correct name but without the .rb extension.
Demo:
 »  (729) 2015-08-31@21:25:46 ishmael@ishcomp-mbp ~/ish-casks> brew cask list
 Error: File '/Users/ishmael/ish-casks/messenger_for_mac_0_1_4' does not exist

 »  (730) 2015-08-31@21:26:13 ishmael@ishcomp-mbp ~/ish-casks> ls -la Messenger*
 -rw-r--r--  1 ishmael  staff  458 Aug 30 16:46 Messenger_for_Mac_0_1_4.rb

 »  (737) 2015-08-31@21:28:00 ishmael@ishcomp-mbp ~/ish-casks> cat Messenger_for_Mac_0_1_4.rb
 cask :v1 => 'Messenger_for_Mac_0_1_4' do
   version '0.1.4'
   sha256 '1b8ea3554aff8a632eb4e39c1b1a2b04e92dfb3a2cc53a805218c3074fac240f'

   url "http://fbmacmessenger.rsms.me/dist/Messenger-<IP_ADDRESS>0786644-f3436781b1e02ea1.zip"
 # appcast 'http://brawersoftware.com/appcasts/feeds/ubar/ubar2.xml'
   name 'Messenger for Mac'
   homepage 'http://fbmacmessenger.rsms.me/'
 # license :commercial

   app 'Messenger.app'

 # depends_on :macos => '>= :mavericks'
end

#eof

 »  (731) 2015-08-31@21:26:19 ishmael@ishcomp-mbp ~/ish-casks> cd ..

 »  (732) 2015-08-31@21:26:21 ishmael@ishcomp-mbp ~> brew cask list
bettertouchtool
java6
paintbrush
dterm
karabiner
sizeup
emacs-mac
keyremap4macbook-mountainlion
sourcetree
firefox
macintosh-explorer
steam
honer
messenger_for_mac_0_1_4(!)
sublime-text3
hyperdock
microsoft-intellitype
ubar_2_4_9(!)
intellij-idea-cenumlock_1_0_3(!)
vlc

 »  (733) 2015-08-31@21:26:25 ishmael@ishcomp-mbp ~>

(I doctored the successful output of brew cask list to put individual casks on their on line.)
Output of brew cask list --debug: https://gist.github.com/IshmaelYavitz/bc360e9baade3651a6af

Closing as I’ll link to it in a single issue pointing out brew cask list bugs.


[notification-hubs] Move to core-lro v3

Packages impacted by this PR

@azure/notification-hubs

Issues associated with this PR
Describe the problem that is addressed by this PR
Moves @azure/notification-hubs to @azure/core-lro v3 beta.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/notification-hubs

Closed in favor of https://github.com/Azure/azure-sdk-for-js/pull/31002


label policy add dark mode / light mode only config option

Preflight Checklist

[X] I could not find a solution in the existing issues, docs, nor discussions
[X] I have joined the ZITADEL chat

Describe your problem
Enable us to completely setup zitadel via terraform.
Describe your ideal solution
As a developer I want to configure the option to restrict the Zitadel UI to use dark mode only via the label policy or another fitting policy in terraform. Currently to complete the setup you have to log in to the UI and change the Mode to Dark Mode only manually.
Version
1.0.4
Additional Context
No response

Thank you for sharing your idea.
If there is a significant demand from customers/community, we will carefully consider implementing the feature.
Currently, the issue will be added to our product backlog.
Meanwhile, if you're interested in implementing it yourself, we also welcome pull requests.


[Divinities' Gaze] Significant balance patch

ADDED: setdivinity command: forces all appearances of a divinity (both in combat and the Divine Visitor event) to use the given divinity
ADDED: clearsetdivinity command: undoes the above command, causing divinities to be chosen randomly once more
CHANGED: Inevitability is now an attack which scales when played and shuffles a Void into your draw pile
CHANGED: Clairvoyance is now played, and draws 3(4) cards, granting them Retain
CHANGED: Guiding Light now costs 1 and draws 2(3) and upgrades your hand when played. It is now ethereal.
CHANGED: Jurors Judge event now Applies 3 Verdict to EVERYONE. Verdict has been adjusted.
BALANCE: Eclectic Learn event choice: 10 cards -> 5 cards
BALANCE: End Forget event: Choose 1 card of 3 to remove. Do this twice. -> Choose a card to remove.
BALANCE: Verdict (card): 10(15) Verdict -> 12(17) Verdict, 2 -> 1 Cost
BALANCE: Verdict (power): +5/turn -> +3/turn
BALANCE: Primordial Propagate event: Choose 1 card to duplicate twice -> Choose 1 card to duplicate. Duplicate 1 other random card.
BALANCE: Mitosis: 2 damage per card -> 3 damage per card, Upgraded energy cost 1 -> 0
BALANCE: Torch Bask event: 15%(10%) healing -> 25%(20%) healing
BALANCE: In zone combats, an additional status is added

All items should be fixed, good spots!


added default args to make, removed match configs and factory, update…

…d examples to work with new changes

Take a look at line 17 of make.py. Python doesn't like default args to be lists so my thought was to keep the argument hint as a list but make the default argument be the goal scored default. I'm totally open to other ideas though.


How to include more than 4 results from Pinecone?

Where can I modify the topK or number of results returned and displayed?

Found the solution:
On line 57 of chat.ts, add:
// Set the number of results to be returned
retriever.k = 10; // Replace 10 with your desired number of results

so that it now looks like this:
// Use a callback to get intermediate sources from the middle of the chain
    let resolveWithDocuments: (value: Document[]) => void;
    const documentPromise = new Promise<Document[]>((resolve) => {
      resolveWithDocuments = resolve;
    });
    const retriever = vectorStore.asRetriever({
      callbacks: [
        {
          handleRetrieverEnd(documents) {
            resolveWithDocuments(documents);
          },
        },
      ],
    });

    // Set the number of results to be returned
    retriever.k = 10; // Replace 10 with your desired number of results

    //create chain
    const chain = makeChain(retriever);