Crash if i change the liquid that the Remote Inventory Panel uses

Issue Description:
If i  change the type of liquid in the config, my game just crash when the world is loading
What happens:
The game just open fine, but when my world is loading, the game crash
What you expected to happen:
To load the world fine
Steps to reproduce:
1.Go to Ender IO config
2.In the type of fluid, put only nutrient_distillation
3.Go load an world
...

Affected Versions (Do not use "latest"):

EnderIO:<IP_ADDRESS>_beta
EnderCore:<IP_ADDRESS>_beta
Minecraft: 1.10.2
Forge:<IP_ADDRESS>5

Your most recent log file where the issue was present:
http://pastebin.com/EkKTEznb

Did you just delete the other two, or did you replace them?
I'm guessing that the 3 entries correspond to the different panels in order.  If you want all 3 to be nutrient distillation, try entering nutrient_distillation 3 times.


Missing node labels

Bug Report
Some nodes don't have their labels about the zone and instance type attached.
Description
On an OpenStack cluster where I installed CCM, I have one node that gets properly labelled, while the others only have the platform=openstack label added.
k get nodes -o wide --show-labels
NAME               STATUS   ROLES           AGE     VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION   CONTAINER-RUNTIME     LABELS
alex-cp-1          Ready    control-plane   2d16h   v1.26.3   <IP_ADDRESS>   <none>        Talos (v1.3.7)   5.15.106-talos   containerd://1.6.20   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=alex-cp-1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.cloudprovider.kubernetes.io/platform=openstack
alex-worker-os-1   Ready    <none>          2d16h   v1.26.3   <IP_ADDRESS>   <none>        Talos (v1.3.7)   5.15.106-talos   containerd://1.6.20   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=alex-worker-os-1,kubernetes.io/os=linux,node.cloudprovider.kubernetes.io/platform=openstack
alex-worker-os-2   Ready    <none>          2d16h   v1.26.3   <IP_ADDRESS>   <none>        Talos (v1.3.7)   5.15.106-talos   containerd://1.6.20   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=alex-worker-os-2,kubernetes.io/os=linux,node.cloudprovider.kubernetes.io/platform=openstack
alex-worker-os-3   Ready    <none>          2d14h   v1.26.3   <IP_ADDRESS>   <none>        Talos (v1.3.7)   5.15.106-talos   containerd://1.6.20   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=ug4.large,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/zone=z03,kubernetes.io/arch=amd64,kubernetes.io/hostname=alex-worker-os-3,kubernetes.io/os=linux,node.cloudprovider.kubernetes.io/platform=openstack,node.kubernetes.io/instance-type=ug4.large,topology.kubernetes.io/zone=z03

I tried recreating the os-1 node, restarting kubelet, the CCM pod, but it doesn't kick in.
Logs for CCM look okay.
Logs
Environment

Talos CCM version: v1.4.0 and edge
Talos version: v1.3.7
Kubernetes version: 1.26.3
Platform: openstack

Hello,
Can you check the metadata resource:
talosctl --nodes <IP_ADDRESS> get PlatformMetadatas.talos.dev -oyaml
talosctl --nodes <IP_ADDRESS> get PlatformMetadatas.talos.dev -oyaml

Thanks.

Ok, can you set the -v=4 logVerbosityLevel flag to the CCM
logVerbosityLevel: 4

reboot CCM, delete node resource and reboot the deleted instance.
It will register again and you will see more details from TalosCCM.
i think it will help us to understand the issue.
Thanks.

Deleting the k8s node objects and restarting the kubelet service on each Talos worker node solved the problem. The new node resources have all the labels.

I'm not sure yet, but I seem to encounter some race condition in the bootstrapping of the K8s cluster when configured with external cloud provider and Talos CCM.
In one recent case, I've observed that the coredns pods are pending to be scheduled because they don't have the needed tolerations for node.cloudprovider.kubernetes.io/uninitialized which breaks the talos ccm for some DNS resolving (which is strange because metadata is normally at <IP_ADDRESS>, so not sure if there's something else before that), and it becomes stuck.
This can be unblocked by first ensuring that internal dns resolving works with coredns, which in my case may require adding manually the toleration for taint above to coredns deployment to make it run on a CP node with external cloud provider configured, then possibly deleting all the registered node resources and restarting the kubelet on each node.
Once that initial chicken-and-egg problem is resolved, additional worker nodes that register to the cluster get labeled properly.

I'm not sure yet, but I seem to encounter some race condition in the bootstrapping of the K8s cluster when configured with external cloud provider and Talos CCM.
In one recent case, I've observed that the coredns pods are pending to be scheduled because they don't have the needed tolerations for node.cloudprovider.kubernetes.io/uninitialized which breaks the talos ccm for some DNS resolving (which is strange because metadata is normally at <IP_ADDRESS>, so not sure if there's something else before that), and it becomes stuck.
This can be unblocked by first ensuring that internal dns resolving works with coredns, which in my case may require adding manually the toleration for taint above to coredns deployment to make it run on a CP node with external cloud provider configured, then possibly deleting all the registered node resources and restarting the kubelet on each node.
Once that initial chicken-and-egg problem is resolved, additional worker nodes that register to the cluster get labeled properly.

Yep, it was fixed here https://github.com/siderolabs/talos/pull/6938
And you can use Daemonset mode too (check the helm-chart, CCM can work without DNS) https://github.com/siderolabs/talos-cloud-controller-manager/blob/75a8e44b137d06c80651286568a275b102502048/charts/talos-cloud-controller-manager/values.yaml#L108

Ok great, so this fix was added in the v1.4.0 release, hence why I encounter the problem in v1.3.7.


Documentation for several BbS files

This includes updated documentation.
Updated information:

PMO
PMP
PAM

New file formats:

EXA
EPD
OLO
BEP
PTX

Rebased it. Should be fine now.

Rebased it. Should be fine now.

The test still fails. I will look deep into why that is.

The test still fails. I will look deep into why that is.

Apparently, some files you changed causes the tests to fail. For some reason, the SLN file changed and it's changes regard Imgd and Imgz. Can you look into this as I do not understand why tests fail exactly?

Apparently, some files you changed causes the tests to fail. For some reason, the SLN file changed and it's changes regard Imgd and Imgz. Can you look into this as I do not understand why tests fail exactly?

Closing this PR as it's author declared that they would create a new PR with all the fixes necessary.

Closing this PR as it's author declared that they would create a new PR with all the fixes necessary.


Create multiple folders at once in explorer

QOL things that make VSCode more convenient and closer to being basically a replacement for most IDEs for me. The editor gives you some control over what you can do within the project folder using the view panel on the left, e.g. new file, new folder. Languages like Java, its derivatives, and a lot of others organize code through a series of folders containing nothing but yet another folder, eventually leading to actual content. It would be convenient if the editor let one create multiple at once in one action, with each folder separated by a slash character (/, \, \\) like in path definitions.

To add onto this functionality, the view bar can be excessively wide just to display subfolders with their correct indentation. Folders containing nothing but a single other folder can be displayed in short-hand to instead display a path leading to the next folder containing more than one directory.
src/main
|-- java
    |-- me/scarlet/dbot
        |-- DiscordBot.java
|-- scala
    |-- me/scarlet/dbot
        |-- DiscordBot.scala

https://github.com/Microsoft/vscode/issues/12893


Is the server.members cache supposed to update on its own?

Edit : should be worth mentioning I am on 5.2.0 and bot.users is correctly updated in real time.
I'm not sure if this is an issue or not. Basically imagine a command that returns a user's avatarURL.
command : !avatar Enchanted13
bot.on("message", function(msg) {
       var command = messageText.split(" ");
       var keyword = command[0].toLowerCase();
       var params = command[1];
       bot.reply(msg, msg.channel.server.members.get('username', params).avatarURL);
});

This works pretty well, but whenever that user changes username, it isn't updated in msg.channel.server.members. Trying to "get('username', newUsername)" will not work and return null, but doing it with the old one works.
Adding this event handler to my code will make it work, but is it how it's supposed to be? Or should the server cache be updated automatically? :
bot.on("userUpdated", function (userBefore, userAfter) {
    bot.servers[0].members.update(userBefore, userAfter);
});

Hi, could you see if 2000b62b36d92f10f23faada661732ffa1b50c38 fixes this bug for you? Thanks

Hi, could you see if 2000b62b36d92f10f23faada661732ffa1b50c38 fixes this bug for you? Thanks

It did! Thanks a lot!


Sync eng/common directory with azure-sdk-tools for PR 2352

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/2352  See eng/common workflow

Behaves as expected on spelling errors -- https://dev.azure.com/azure-sdk/public/_build/results?buildId=1222783&view=logs&jobId=b70e5e73-bbb6-5567-0939-8415943fadb9&j=b70e5e73-bbb6-5567-0939-8415943fadb9&t=bdeefc16-b669-5ebd-ad94-a2c19ade53b0

Fails with npm version issues -- https://dev.azure.com/azure-sdk/public/_build/results?buildId=1222781&view=logs&jobId=b70e5e73-bbb6-5567-0939-8415943fadb9&j=b70e5e73-bbb6-5567-0939-8415943fadb9&t=72c41882-9d21-5580-4869-7f3ea1bd9c0a

/azp run js - aggregate-reports

The aggregate-reports pipeline is not currently interesting to this change as public API is not being checked here.

Runs as expected


Feature support set brpc_idle_timeout_sec

Proposed changes
In some special circumstances (such as network instability), the brpc server will always retain many tcp connections.

run buildall

run buildall

run buildall

run buildall


Dependency cycle between kubestellar and ocm-transport-plugin repos

Currently there is a cycle of dependencies. Although packaging.md does not represent it, the kubestellar repo depends on the ocm-transport-plugin (OTP) repo in order to have a functioning system. The kubestellar repo wants to have user instructions that reference the OTP repo, wants to have tests (for use by contributors and for use in CI) that reference the OTP repo; these may involve YAML that references the OTP repo.
Four approaches have been suggested so far.
1: Split the ks/ks repo into two repos, one for a lower layer and one for an upper layer. OTP would depend on only the lower layer repo, and the upper layer repo would depend on both the lower layer repo and the OTP repo.
2: Merge the OCM transport plugin into the kubestellar repo. Most likely the OTP part would appear concentrated under one subdirectory of the kubestellar repo and have a distinct go module. Having multiple go modules in one git repo is possible but tricky; we have observed other projects having trouble with this, but are not aware (at this time) of a clear show-stopper for our use of this idea.
3: Synchronized releases. Have a 1:1 relation between ks/ks releases and ks/OTP releases. This would mean that preparing a release pair involves manual editing of both repos to update them to reference the number of the coming release of the other (as well as themselves, sigh).
4: Staggered releases. This relies on the idea that release X.Y.Z is the capstone that appears after a series of test releases X.Y.Z-rc1, X.Y.Z-rc2, ... X.Y.Z-rc$N. Each OTP release is made after a ks release and references it. For example, OTP release 0.1.0-rc1 might be made after ks release 0.20.0-rc2 and reference that. Suppose that the last test release of OTP before 0.1.0 is 0.1.0-rc$M. This references ks/ks release X.Y.Z-$N. By definition of M and N, testing of ks X.Y.Z-rc$N and testing of OTP 0.1.0-rc$M succeeds. Then we make the ks plain release X.Y.Z, referencing OTP release 0.1.0-rc$M (this is odd and confusing, but technically works). Then we make the OTP plain release 0.1.0, referencing ks release X.Y.Z.

We clearly have not converged on the thinking about testing in the staggered release approach. I disagree with what was done about https://github.com/kubestellar/kubestellar/pull/1780#discussion_r1501842654

Let me elaborate on testing in the staggered release approach.
In this discussion the fine structure of release identifiers does not matter; it makes no difference. To avoid irrelevant details, here I will simply speak of a succession of ks/ks releases identified as KS1, KS2, KS3, and so on, and a succession of ks/OTP releases identified as OTP1, OTP2, OTP3, and so on.
Suppose, for example, that OTP2 references KS7. That means that the transport controller binary published for OTP2 uses the generic transport code from KS7. In turn, KS8 references OTP2. A user of KS8 uses OTP2 (examples.md in KS8 will say to use OTP2), which includes the generic transport code from KS7. Thus we get:
Problem: we can not make backward-incompatible changes in ks/ks. In particular, the parts of ks/ks outside the generic transport code in KS8 has to work with the generic transport code in KS7.
Next, consider a contributor working on main between the moments that KS7 and KS8 are created. This contributor should be looking forward to what a user of KS8 will get. This contributor should be testing ks/ks main with OTP2. In particular, with the published artifacts of OTP2 (because that is what the user of the eventual KS8 will do). That is not what test/e2e/common/setup-kubestellar.sh does right now. Now, that script fetches the source for OTP2 and compiles it with the contributor's current source for ks/ks. This is, in general, not the same as the source that the published artifacts for OTP2 were built from and thus can deceive this contributor.
Suppose we fix this, making test/e2e/common/setup-kubestellar.sh in main during that stretch of time use the published artifacts from OTP2. Now, how does a contributor making changes to the generic part of the transport controller test their changes?
Problem: EITHER the E2E tests in ks/ks test the wrong stuff OR a contributor changing the generic transport code can not test their changes.

@MikeSpreitzer FWIW:

PR testing will be driven by a combination of a high-level driver and application drivers that configure and deploy container images and push workload.
Tests may require building temporary container images and temp helm charts and/or modifying application driver scripts for referencing temp artifacts. Ideally the high level [PR test] scripts could default to using the latest releases, but would recognize when temporary image and/or helm artifacts need to be rebuilt and override default references.
The option to eliminate circular dependencies, option 1, should simplify testing more than the other options.

I’m working on a solution to remove the dependency cycle.
Will set a meeting with the team to present my suggestion in few days.

@MikeSpreitzer @ezrasilvera @pdettori @andreyod @eaepstein @vMaroon @effi-ofer @shmuelk
I'm putting here a high level overview of the approach I would like to take to solve the dependency cycle.
before implementing any of this, I would be happy to hear your thoughts.
below are the steps that have to be taken to have this approach working:

export the transport.go interface to a separate repo/module (e.g., transport-plugin-api repo/module). this currently includes only Wrap function (might become more than that when introducing cluster inventory).
from now on, transport plugin implementations are no longer executables. Instead we switch to use go plugins.
OTP becomes a go plugin that implements the interface described in transport-plugin-api. By this we remove the dependency OTP -> KS.
KS code change - generic transport controller becomes a regular controller that runs as part of KS. Upon startup it loads from disk the transport plugin using go plugins without knowing which implementation it loads (soon we'll get to the how).

By doing the above we now have the following dependencies:
KS -> transport-plugin-api
OTP -> transport plugin api
and for running KS e2e (or in general for running KS) we also have:
KS -> OTP.
the last one is not a must if we supply a different plugin implementation and replace it.
How to actually build and run it:
OTP is built as a plugin using - go build -buildmode=plugin (not sure if ko supports building as plugin or not, posted a question is their community slack channel).
In the transport deployment, we use an init-container to put the transport-plugin.so file (file that can be used to load the plugin implementation) in a volume that is shared with the runtime container. Upon startup of the transport runtime container, the transport-plugin.so will be located on the shared volume (shared between init container and runtime container) and loaded from there.
The above decouples OTP as it now no longer has to have any reference to KS.
additional transport plugins may be implemented and have to only reference the transport-plugin-api.
when we want to test with a different plugin, we change the image of the init container to pulls the required plugin image instead of OTP.
as a next step after the above is done, transport controller may be added to KubeStellar-Controller-Manager helm chart, with passing in a variable the docker image to be used for which transport plugin to use. no need to deploy transport controller separately.

Thanks @nirrozenbaum This sounds like the proposal we discussed last week. As I said before I think this is a better approach than what we do today.
BTW, Unless you think the generic transport controller will always be used for all plugins, I would move that to the transport-plugin-api repo as well and allow new plugins to either use it or implement a different functionality. The main question is if the plugin in API are above or bellow the generic transport controller.
One not is the g plugins are much more strict than other languages and require identical version of packages, otherwise go refuses to load the plugin

Nice. It's possible to validate that the OTP version passed into the KS helm chart matches the version of the transport-plugin-api?

Thanks @nirrozenbaum This sounds like the proposal we discussed last week. As I said before I think this is a better approach than what we do today. BTW, Unless you think the generic transport controller will always be used for all plugins, I would move that to the transport-plugin-api repo as well and allow new plugins to either use it or implement a different functionality. The main question is if the plugin in API are above or bellow the generic transport controller.
One not is the g plugins are much more strict than other languages and require identical version of packages, otherwise go refuses to load the plugin

@ezrasilvera the generic transport controller uses Binding which is part of KubeStellar crds (under api dir) and we have generated code for it.
Unless we export Binding along with BindingPolicy to 'API' module, I think this will brings us back to the cycle we want to avoid. IMO it's good that KubeStellar defines and runs the generic transport controller and we allow to plug in only a specific part of the code (atm it's the wrapping only), so I wouldn't go into this direction.
regarding go plugins being strict - you are correct. it validates identical versions of packages.
overall I think it's a good thing.

Nice. It's possible to validate that the OTP version passed into the KS helm chart matches the version of the transport-plugin-api?

@effi-ofer If I'm not mistaken, using different versions will throw an error and we'll be able to see it in transport controller startup log.
as @ezrasilvera said, go plugins is very strict in terms of matching versions.

@effi-ofer the plugin is loaded directly from disk. If we run the tests and the plugin loaded then it's OK- that's the test :-)

@nirrozenbaum please have a look at https://github.com/hashicorp/go-plugin    this is a much more flexible go plugin platform that is based on RPC

@nirrozenbaum please have a look at https://github.com/hashicorp/go-plugin this is a much more flexible go plugin platform that is based on RPC

are we allowed to use it with license MPL-2.0 license?

Good Q :-)

If I'm not mistaken MPL is GPL-alike license, which is not allowed.
I will give go plugins a shot first (assuming we get an agreement with the team).

Another option is to leave everything as is (for now) and pull the OTP as a module into the KS repo.  We can then work to define and design a better separation + plugin.
It's all an issue of the effort needed - if we can separate to a module in few hours work , it may be good option as intermediate solution.

if we get an agreement to export transport.go interface to a separate repo/module, I think I can do the work in few days.
rough estimation 2-3 days.

The last bullet under<EMAIL_ADDRESS>gives me pause.

The last bullet under<EMAIL_ADDRESS>gives me pause.

last bullet in this warning is definitely important.
today we are the only ones who develop both OTP and KS,
so as a solution for current cycle - I'm not concerned with this bullet.
we have a long way to go until other people will implement transport plugins.

I'm not concerned with this bullet. we have a long way to go until other people will implement transport plugins.

I tend to agree with @MikeSpreitzer here.  The above answer is not a good justification for changing to plugin. I would prefer staying with what we have (and document our dependency + have to do steps manually) , rather then switch to something which we know in advance we need to change.

@ezrasilvera @MikeSpreitzer
if the two of you are not in favor of using go plugins, that's a good enough reason to put my suggestion on hold and continue as is until we find a better solution.
maybe a different (and better) framework for plugins can be used in the future.
as of now I haven't found such an alternative.
I will keep looking for solutions for the dependency cycle after release of 0.21 (after running transport in a pod)

@nirrozenbaum: FYI, regarding "until other people will implement transport plugins". I think that is not the relevant criterion. What the last warnings say is that all parts that will run together need to be built in a consistent way. The reliable way to do that is have one repo do the building of all the parts.
Also: @nirrozenbaum, your suggestion falls in existing category 1 (split the ks repo into an upper and lower layer). If we are willing to split the repo, I think we can do it without requiring any new linking/loading technology.

This has been resolved by merging the contents of the ocm-transport-plugin into the kubestellar repo.


dsfdr error

I am getting the following error while using dsfdr plugin in qiime2-2017.12. Command is as follows-
qiime dsfdr permutation-fdr --i-table table.qza --m-metadata-file metadata.tsv --m-metadata-category MStatus --output-dir test-dsFDR
Plugin error from dsfdr:
'module' object is not callable
Debug info has been saved to /var/folders/64/58fk04bx2335w895j8x608080000gn/T/qiime2-q2cli-err-tx3k5t3k.log
and log file looks like this-
Traceback (most recent call last):
File "/Users/Schmidtlab/anaconda3/envs/qiime2-2017.12/lib/python3.5/site-packages/q2cli/commands.py", line 224, in call
results = action(**arguments)
File "", line 2, in permutation_fdr
File "/Users/Schmidtlab/anaconda3/envs/qiime2-2017.12/lib/python3.5/site-packages/qiime2/sdk/action.py", line 228, in bound_callable
output_types, provenance)
File "/Users/Schmidtlab/anaconda3/envs/qiime2-2017.12/lib/python3.5/site-packages/qiime2/sdk/action.py", line 363, in callable_executor
output_views = self._callable(**view_args)
File "/Users/Schmidtlab/anaconda3/envs/qiime2-2017.12/lib/python3.5/site-packages/q2_dsfdr/plugin_setup.py", line 40, in permutation_fdr
alpha, permutations)
TypeError: 'module' object is not callable
Please let me know.
Thanks,
Rabindra

@rkmandal1 We have fixed the errors in the plug-in; it should be ready to be used now. Please check the demo notebook. Thanks!


Optimize DOM selector lookups by pre-warming by selectors' parents

Part of #287

I used this page to test things: https://www.peterbe.com/plog-original.html
It uses Semantic-UI which is horribly verbose! (Hint view source and look at the CSS)
Because this patch introduces some changes to how it prepopulates the decision cache with some dead-obvious selectors, the output is different compared to master. Diff:
183c183,185
< * {
---
> *,
> :after,
> :before {
196,197d197
<   height: 100%;
<   font-size: 14px;
203,206d202
< body,
< h1 {
<   padding: 0;
< }
208a205,206
>   margin: 0.67em 0;
>   line-height: 1.28571429em;
210a209
>   padding: 0;
213,214d211
<   margin: 0.67em 0;
<   line-height: 1.28571429em;
231c228,233
< body {
---
> ::-webkit-file-upload-button {
>   -webkit-appearance: button;
>   font: inherit;
> }
> body,
> html {
232a235,239
> }
> html {
>   font-size: 14px;
> }
> body {
233a241
>   padding: 0;
259a268,279
> ::-webkit-selection {
>   background-color: #cce2ff;
>   color: rgba(0, 0, 0, 0.87);
> }
> ::-moz-selection {
>   background-color: #cce2ff;
>   color: rgba(0, 0, 0, 0.87);
> }
> ::selection {
>   background-color: #cce2ff;
>   color: rgba(0, 0, 0, 0.87);
> }

(red means output with master and green output with this branch)
Here's the master.css and branch.css outputs prettierfied.
I'm pretty sure this is correct fix. Things like Semantic-UI does like...
*, :before, :after {
  -webkit-box-sizing:inherit;box-sizing:inherit
}

should not be deleted from the final CSS. (not that I understand the CSS itself)

In terms of speed...
Before:
▶ run-forever.sh time node bin/minimalcss.js https://www.peterbe.com/plog-original.html -o /dev/null
To stop this forever loop created a file called stopnow.
E.g: touch stopnow

Now going to run 'time node bin/minimalcss.js https://www.peterbe.com/plog-original.html -o /dev/null' forever (or until stopnow exists)

real	0m6.837s
user	0m3.733s
sys	0m0.357s

real	0m6.728s
user	0m4.254s
sys	0m0.273s

real	0m6.713s
user	0m4.225s
sys	0m0.295s

real	0m6.175s
user	0m3.726s
sys	0m0.272s

real	0m6.206s
user	0m3.785s
sys	0m0.263s

real	0m6.341s
user	0m3.906s
sys	0m0.258s

real	0m6.187s
user	0m3.735s
sys	0m0.265s

real	0m6.165s
user	0m3.730s
sys	0m0.251s

After:
▶ run-forever.sh time node bin/minimalcss.js https://www.peterbe.com/plog-original.html -o /dev/null
To stop this forever loop created a file called stopnow.
E.g: touch stopnow

Now going to run 'time node bin/minimalcss.js https://www.peterbe.com/plog-original.html -o /dev/null' forever (or until stopnow exists)

real	0m4.941s
user	0m2.470s
sys	0m0.239s

real	0m5.020s
user	0m2.521s
sys	0m0.234s

real	0m4.984s
user	0m2.564s
sys	0m0.231s

real	0m5.302s
user	0m2.787s
sys	0m0.244s

real	0m4.888s
user	0m2.454s
sys	0m0.233s

real	0m5.210s
user	0m2.481s
sys	0m0.233s

real	0m5.161s
user	0m2.769s
sys	0m0.248s

real	0m5.282s
user	0m2.841s
sys	0m0.248s

real	0m5.013s
user	0m2.609s
sys	0m0.238s

real	0m5.068s
user	0m2.671s
sys	0m0.248s

real	0m5.113s
user	0m2.664s
sys	0m0.252s

That means, on median the total processing time goes from 6.3s to 5.1s.

@stereobooster This one is quite complex but I think it's valuable. Not expecting a deep code review but if you could take a look I'd appreciate it. Thanks in advance.

Thank you @stereobooster !
It still saddens me that it takes ~5 seconds to execute against these monster CSS files. The blame lies with Semantic-UI for being so overly verbose in its style.

By the way, for https://www.peterbe.com/plog-original.html prior to this branch there had to be 3,285 calls to dom(selectorString).length > 0. As of this patch there now needs only to be 1,563 calls.
So 3,285 cheerio DOM lookups to 1,563 essentially reduced the total lookup time from ~6s to ~5s.


CMake C++ GTK 3 Community Template

Create a CMake C++ GTK 3 community template (sponsored by Toradex, but not regularly maintained like the Toradex-supported ones).
This template is based on the cmakeConsole and modified inspired on the cppQML for enabling graphics.
This PR is a fork of https://github.com/torizon/vscode-torizon-templates/pull/268 and depends on https://github.com/toradex/vscode-torizon-templates-documentation/pull/16

Tested on Local AMD64 and Torizon ARMv8.
This PR is ready for review.


New PR to test SignCLA at 2020-04-20 11:49:06.458846172 -0700 PDT m=+3.712035665

Body of PR

indiv-pass-fork-staging: test succeeded


Pixel Ratio in userAgentInfoRX is null

After updating from 4.0.1 to 5.0.6 and using the update guide, i switched to services based approach. However i noticed the userAgentInfoRx values are coming out fine except for pixelratio property which is null on my Retina Mac.
Here is a copy of the object:
bot:false
browser:"chrome"
desktop:{name: "Mac", state: true}
device:"desktop"
game_device:{name: "", state: false}
ie_version:{name: "", state: false}
linux_os:{name: "", state: false}
mobile:{name: "", state: false}
pixelratio:null
smart_tv:{name: "", state: false}
tablet:{name: "", state: false}
window_os:{name: "", state: false}

Can you please check it out. Thanks!

Thanks @hassanasad !  I fix this bug in wekend. ; )

Fixed @hassanasad ! 👍  v5.0.8.


needs benchmarking baked in

looking over #22 i see that we have not made enough use of testing Benchmarks.

working on https://github.com/vbatts/tar-split/pull/25

still need a tar/asm bench

#27 is another for now.


Manual Mocks for scoped packages

Is it possible to create a manual mock for a scoped package? Since the file system doesn't allow for @scoped/package.js as a file name, I tried creating a @scoped directory with a package.js file that exports a mock
node_modules
--@scoped
----package

__mocks__
--@scoped
----package.js

but I'm just getting the default jest mocking behavior when calling jest.mock('@scoped/package') within a test file.

I also just discovered that jest cannot discover a manual mock when the package is scoped like this or put into a scoped directory. Using Jest 15
Had to resort to mocking and stubbing out functions to return mock data.

Duplicate of #462. Unfortunately there are some bugs here but we are hoping to fix this soonish.


in Tabular Editor 2.16.5 loading custom dll from arbitrary path seems not to be working

Hello,
I just tried to run a test script I am doing to test my custom dll thing, and the script runs in Tabular Editor 3 but not in Tabular Editor 3. I get the same error that I got before arbitrary path dll loading was introduced. Is it a Tabular Editor 3 only feature?

Different versions of TE might use different versions of TOMWrapper.dll, as new features are released. Since your custom DLL references TOMWrapper.dll you must ensure that the version references by your DLL matches the version used by TE - otherwise, the script might not execute.
In fact, this limitation is the main reason why we don’t encourage the use of custom DLLs, as you have to recompile the DLL whenever there is a new version of TE that uses an updated version of TOMWrapper.dll. Longer term, we want to make it easier to store custom classes and methods in a way that lets you reuse them across scripts, without relying on custom DLLs.

I see!
If the Tomwrapper.dll used by tabular editor is newer than the one I used
to compile the custom dll should it work? Maybe I can keep a slightly older
version installed just for this purpose.
Looking forward to the new feature for custom classes
El dom, 20 feb 2022 4:26, Daniel Otykier @.***>
escribió:

Different versions of TE might use different versions of TOMWrapper.dll,
as new features are released. Since your custom DLL references
TOMWrapper.dll you must ensure that the version references by your DLL
matches the version used by TE - otherwise, the script might not execute.
In fact, this limitation is the main reason why we don’t encourage the use
of custom DLLs, as you have to recompile the DLL whenever there is a new
version of TE that uses an updated version of TOMWrapper.dll. Longer term,
we want to make it easier to store custom classes and methods in a way that
lets you reuse them across scripts, without relying on custom DLLs.
—
Reply to this email directly, view it on GitHub
https://github.com/TabularEditor/TabularEditor/issues/965#issuecomment-1046151721,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJUUXHNHGCDLKQQLEMG7EUDU4BNPDANCNFSM5O3QZ2XQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

There are no guarantees it will work. Your best option right now is probably to compile two versions of your custom dll - one for each version of TE you intend to target.

I just realized that there's no TOMWrapper.dll in the install folder from Tabular Editor 2 -- where is the dll I should reference to make sure it works with Tabular Editor 2?
Regards!

%localappdata%\TabularEditor\TOMWrapper.dll (it should appear after TE2 has been launched at least once)


goerli: Text in Modal Appears Vertically in Simple Giveaway Scene

Explorer Alpha build version:
v0.12.0
Issue Description:
In the Goerli scene "simple-giveaway-scene" (83,-4), the text within the modal appears vertically in a single line, extending through the modal and making it difficult to read.
⚠ This issue is also happening on Prod.
Steps to reproduce:

/goto goerli Navigate to simple-giveaway-scene at coordinates (83,-4)
Observe the text within the modal.

Expected behavior:
The text within the modal should appear horizontally, wrapping properly within the boundaries of the modal.
Current behavior:

Additional Notes:
Windows 11. 12th Gen Intel(R) Core(TM) i7-12650H 2.30 GHz. nvidia geforce RTX

This is a scene-side problem, caused by the textWrapping change
I'm seeing the same broken text in prod


How to increase the default ephemeral storage volume size for a node?

Is an existing page relevant?
No response
What karpenter features are relevant?
Blockdevice mappings
How should the docs be improved?
I haven't been able to find how to can increase the default ephemeral storage volume size for a node, I'm guessing this is done through the blockdevice mappings of the  AWSNodeTemplate, but I've tried different configurations without any luck.
This is the provisioner I'm using:
apiVersion: karpenter.sh/v1alpha5
    kind: Provisioner
    metadata:
      name: default
    spec:
      requirements:
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["t3", "m6g"]
        - key: "karpenter.k8s.aws/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32"]
        - key: "karpenter.k8s.aws/instance-hypervisor"
          operator: In
          values: ["nitro"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["arm64", "amd64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
      limits:
        resources:
          cpu: 1000
          memory: 1000Gi
      providerRef:
        name: default
      consolidation:
        enabled: true

And this is the AwsNodeTemplate:
apiVersion: karpenter.k8s.aws/v1alpha1
    kind: AWSNodeTemplate
    metadata:
      name: default
    spec:
      subnetSelector:
        karpenter.sh/discovery: ${module.eks.cluster_name}
      securityGroupSelector:
        karpenter.sh/discovery: ${module.eks.cluster_name}
      tags:
        karpenter.sh/discovery: ${module.eks.cluster_name}
      blockDeviceMappings:
      - deviceName: /dev/sdb
        ebs:
          volumeSize: 100Gi

Could you please provide an example on how to do this?
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

That worked thanks!


[Low priority] Domain and Range-restriction are unsupported

At the very least, by the lastchecker.rkt and other descents.

These are supported as syntactic sugar: <: expands to an expression using &, ->, etc.


Manage contacts cache

[x] Setup actions
[x] Get + transform contacts
[ ] Get android build working
[x] Hook up to rpc
[x] Green banner on success

This is ready for review. I've been having trouble building android.

[ ] Verify works on android

cc @keybase/y2ksquad

@chrisnojima thanks ready for another look


egui-wgpu docs failed to build on docs.rs

See https://docs.rs/crate/egui-wgpu/0.23.0

I believe this is related to https://github.com/emilk/egui/pull/3228. I got that error on my CI when updating to egui 0.23 (https://github.com/abey79/vsvg/pull/54). Without the x11 or wayland feature, winit isn't able to detect the platform on linux (https://github.com/rust-windowing/winit/blob/772b21ce095b655f0fe50b89253910cd2ff9fa78/build.rs#L13). My workaround was to run that part on a mac runner, which is probably not an option for docs.rs.

winit issue: https://github.com/rust-windowing/winit/issues/3173

This is still an issue at 0.24.0 https://docs.rs/crate/egui-wgpu/0.24.0

But they seem to build fine on my local, weird...


Processing the template failed. See inner exception for details error

Hi
When I try to create a query it fails with the message:
Date: 14/01/2019 10:39:16
Application: Operations Manager
Application Version: 7.3.13142.0
Severity: Error
Message:
: Processing the template failed. See inner exception for details.
Verification failed with 2 errors:
Error 1:
Found error in 1|Bridgewater.Management.Pack|<IP_ADDRESS>|QueryOleDbMonitorInitialDiscovery.0d8796374c574b0a8cfaf32272a5686f|| with message:
Failed to verify Discovery: QueryOleDbMonitorInitialDiscovery.0d8796374c574b0a8cfaf32272a5686f
: Cannot find ManagementPackElement [Type=ManagementPackClass, ID=Microsoft.Windows.Computer] in management pack ManagementPack:[Name=Microsoft.Windows.Server.2016.Discovery, KeyToken=31bf3856ad364e35, Version=<IP_ADDRESS>].

Error 2:
Found error in 1|Bridgewater.Management.Pack|<IP_ADDRESS>|QueryOleDbMonitorInitialDiscovery.0d8796374c574b0a8cfaf32272a5686f/DS|| with message:
The configuration specified for Module DS is not valid.
: Cannot find specified MPElement Windows!Microsoft.Windows.Computer in expression: $MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$
Cannot find ManagementPackElement [Type=ManagementPackElement, ID=Microsoft.Windows.Computer] in management pack ManagementPack:[Name=Microsoft.Windows.Server.2016.Discovery, KeyToken=31bf3856ad364e35, Version=<IP_ADDRESS>].
Failed to verify Discovery: QueryOleDbMonitorInitialDiscovery.0d8796374c574b0a8cfaf32272a5686fCannot find ManagementPackElement [Type=ManagementPackClass, ID=Microsoft.Windows.Computer] in management pack ManagementPack:[Name=Microsoft.Windows.Server.2016.Discovery, KeyToken=31bf3856ad364e35, Version=<IP_ADDRESS>].
: Verification failed with 2 errors:
I've tried searching the forum for previous solutions but I cant find any that match. Are you able to help?
Thanks in advance.
Rob

fixed https://www.savision.com/free-management-packs/


added a test for template file in a subdirectory

Related to https://github.com/IBM-Swift/Kitura-StencilTemplateEngine/issues/14

LGTM.

Codecov Report

Merging #71 into master will decrease coverage by 0.17%.
The diff coverage is 88.23%.

@@            Coverage Diff             @@
##           master      #71      +/-   ##
==========================================
- Coverage    90.4%   90.23%   -0.18%
==========================================
  Files           1        1
  Lines         198      215      +17
==========================================
+ Hits          179      194      +15
- Misses         19       21       +2

Flag
Coverage Δ

#KituraSampleRouter
90.23% <88.23%> (-0.18%)
:arrow_down:

Impacted Files
Coverage Δ

Sources/KituraSampleRouter/RouterCreator.swift
90.23% <88.23%> (-0.18%)
: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 25bd210...d203389. Read the comment docs.


Not able to get tokens / msal objects after successful login

Hello, I am using msal.js 1.3.2 library for azure AD authentication in angularJS. After successful login after redirect, not getting userInfo object/msal objects as they are getting initialized after redirect. Here is the code I am using
refApp.config(['$locationProvider', function($locationProvider) {
$locationProvider.html5Mode(false).hashPrefix('');
}]);
refApp.config(['msalAuthenticationServiceProvider', '$httpProvider', function (msalProvider,$httpProvider) {

	window.applicationConfig = {
        clientID: '<client id>'
	};

   msalProvider.init(
		{
			authority: 'https://login.microsoftonline.com/<tenant>.onmicrosoft.com',
			validateAuthority : false,
            clientID: applicationConfig.clientID,
            cacheLocation: 'sessionStorage',
            postLogoutRedirectUri: 'https://localhost:8080/logout',
			tokenReceivedCallback: function (errorDesc, token, error, tokenType) {
				console.log(token);
			}
		},
		$httpProvider
	);
}]);

refApp.controller('myController', ['$scope', '$rootScope','$stateParams', '$state', '$location','accountServices', 'msalAuthenticationService', function($scope,$rootScope,$stateParams, $state,  $location,  accountServices,msalService){
$scope.dispWelcomePage = true;
console.log(msalService); // prints all initialised values after redirect
console.log(msal); // prints all initialised values after redirect
if(!(typeof msalService.userInfo === 'undefined'  )){
console.log('userInfo.isAuthenticated is '+msalService.userInfo.isAuthenticated);}
$scope.redirectToLoginPage = function(){
console.log("Redirecting to Login page");
msalService.loginRedirect();
}
Please can some one suggest?

I may be misunderstanding the problem, but I think you may just need to change your code a bit.
After logging in, you also need to call one of the acquireToken APIs listed here. There's also more information on the flow on the msal npm page.
Additionally, after logging in, you'll want to use getAccount() in order to get information about the user currently logged in.

Thanks alot for your reply. What I have observed is below set of code has never executed after successful login redirect
$scope.$on("msal:loginSuccess", function () {
console.log("loginSuccess");
});
	$scope.$on("msal:loginFailure", function () {
		console.log("loginFailure");
	});

	$scope.$on("msal:notAuthorized", function (event, rejection, forResource) {
		console.log("notAuthorized");
	});

	$scope.$on("msal:acquireTokenSuccess", function (event, tokenOut) {
		console.log("acquireTokenSuccess");
	});

Also I think the issue is msal and msalService objects are getting initialised after success login redirect. Sorry if I am missing any details

Can you confirm that you are on version 1.0.0 of msal-angular? Please consider updating if you aren't.
Can you also provide the rest of your msal-related code? If you're never executing on that logicSuccess event, even after an actual successful login, it's likely just not hooked up properly.

Closing this as we're assuming that this is no longer an issue due to no activity. Please open a new issue if you see further problems. Thanks!


Add onabort handler for rw transactions

I added  the onabort callback to avoid blocking Lwt when the  QuotaExceededError fires :)

Thanks!


[Feature request] Trackpad Handwriting

LOVE THE APP!!! Saved my life when writing papers.
However, as a MacBook user with only a trackpad, I'd love to have the option to toggle on trackpad handwriting (where your finger can simply touch the trackpad as if interacting on a mobile screen, without exerting any pressure, and the drawing will register). I believe this is a feature that Detexify has, and I'd love to see it being added here in this amazing app!

Hmm right now it is possible to draw using three-finger drag — which may need to be enabled in System Settings > Accessibility > Pointer Control > Trackpad Options > Set 'Dragging style' to Three Finger Drag. I think this is better than trying to implement drawing with single finger (if even possible on macOS) as this may register a false drawing anytime the cursor goes over the drawing canvas of the open DeTeXt window.
Closing this feature request for this reason. Thank you for the feedback though! Hope three finger drag satisfies your use case for drawing quickly.


[mongodb-replicaset] Add support for init standalone maintenance scripts

What this PR does / why we need it:
Introduce a way to run maintenance scripts in Mongodb replicasets. This is especially useful for creating new indexes in a rolling fashion with no downtime and fastest performance according to the best practices. More info added in README.md.
 See details link for directions.

/lgtm


Plugin build from Git incompatible with 2017.1

I build the plugin from my repository clone and seemed to get a zipfile with 1.12-SNAPSHOT, but when I tried to load this into IDEA 2017.1 it rejects it with the message:
Plugin 'D Language' is incompatible with this installation

which is a bit of a blocker on me trying this out.
(I want to avoid using the downloaded 2016.3.)

not started looking at 2017.1 compatibility yet. You wouldn't need to manually download an earlier version of intellij. The Gradle plugin handles all that so it's just a case of setting the ideaVersion in gradle.properties to an Inteliij version you want to start running the plugin in such as 171-EAP-SNAPSHOT. Then just ./gradlew runIdea from the root of the project.
For when we start focusing on 2017.* versions it'll probably be best to edit the plugin.xml to have the idea version as being since 171:
<idea-version since-build="171"/>

I've done this locally and found there was a minor issue in DLanguageLibraryType.class that needed fixing and it seems to not work with Gradle 2.13 so I updated the gradle-wrapper.properties to use v2.14 and it now boots up.
I've pushed the changes to the develop branch. see commit: https://github.com/kingsleyh/DLanguage/commit/55c0963efecdb197bba1a85a7e3dacad1ce3605b

Seems ok but I've tested thoroughly.

makes sense to focus attention on 2017.1 now so in commit https://github.com/kingsleyh/DLanguage/commit/4f8ba746ad8dd0e67cf38b8a690d566ed25b4451 have set it to be min supported version and dropped the 2016.* builds.


HFE output is hardcoded to double density

Hi,
I just build the Greaseweazel board and used an adapter board for this. Flashing the software was no problem and the device gets recognized on my Windows 10 system. I also can read and write disks with the software, but reading does not work. To test the device, I used the DSKA0000.hfe from the HxC floppy emulator software and wrote it to a 3.5" disk. After that, I checked that the disk is readable with an USB floppy drive and it works fine. However, when I read it back, the HFE file is not readable in the HxC floppy emulator software. Also writing it back to a 3.5" disk and testing it with the USB drive does not work.
I used the simple command "gw.exe read test.hfe" to read the disk on my system.
Do you have any ideas or a hint for my what might cause the problem? I have attached the hfe file that I read back on my system (it should contain the DSKA0000.hfe content).
testhfe.zip

GW tool is not switching to HD rate to decode the flux and write the HFE. It's actually hardcoded at double density. I will work out a way to let you specify HD on the command line, and also add some sanity checking or auto-detection for the usual case that it is pretty easy to distinguish DD from HD (number of flux samples per track is usually enough!) Thanks!

Hi,
great, thanks a lot for your fast reply and of course for your work on the Greaseweazle :-)! Can't wait to test it.

Latest v0.18 release fixes this. Specify --rate 500 on the gw read command line to create a HD HFE image file.

Let me know how you get on!

@keirf would it be better to have a way of converting scp to HFE? An issue with the HFE approach to imaging is that it can't represent fluctuating bitrates well — that would require lots and lots of bitrate-change opcodes, or imaging at a bitrate a few orders of magnitude higher than the disk's bitcell width. Some Apple II software uses copy protection that depends on such fluctuations.

Just to chime in: --rate 500 produces a hd .hfe for me, but HxC Floppy Emulator doesn't show any of the files on the disk in the disk browser, and the Track format: says UNKNOWN_ENCODING.
(I also tried --rate 512, same result)
Disk was a brand new sealed floppy (driver disk), opened to try this out!
The disk I used reads fine in a standard PC drive, and an external PC usb drive.
The drive on the GW is an Alps DF334.
I can test on another disk drive, if needed.
3.zip

@d235j I will implement transcoding in future so you can convert between image formats with no physical disk access involved. I will also implement a sensible flux format for storing incremental disk dumps, and provide tools for transcoding that too.

@M1kerochip A failed test, how sad. I will have a look. It did work for me earlier today!

If you rip to SCP does that look OK in hxc?

The HD disk? No.
Same. Shows up as a blank 1.39mb disk. 0kb used. Unknown encoding format.

The problem isn't directly related to the new --rate option then. Try another drive and/or upload the bad scp somewhere.

Same result, but a bit better.
At least this drive picked it up as ISOIBM_MFM_ENCODING.
https://mega.nz/file/EWI0mSzK#TOTxhjcXYzLXEKG1L5WWHqI1tiZwbouLV-HtTwc0hHU
Using different drive, hxc reports:
Track RPM : 300 RPM
Bitrate : VARIABLE
Track format : ISOIBM_MFM_ENCODING
Track len : 199450 cells
Number of side : 2
Interface mode: GENERIC_SHUGART_DD_FLOPPYMODE
Shugart Interface
https://mega.nz/file/EWI0mSzK#TOTxhjcXYzLXEKG1L5WWHqI1tiZwbouLV-HtTwc0hHU

I just looked at your SCP and it is perfect? All sectors are there. So presumably something was up with the previous drive you used.

Yeah, maybe!
Maybe it was just having a bad day :)
HxC still can't see any of the files on the disk though, using the disk browser.
(That's what I usually use to check an IBM image is ok)

There are a couple of extra sectors at cylinder 80, which might have confused the browser. If I decode cyls 0-79 only, I see a FAT12 FS, but the filenames are garbage. Maybe this is not a standard FAT-formatted disk? All I can say is the sectors are okay as they are CRC validated. So there's nothing wrong with the dump.

Fair enough.
I've dumped 3 more disks, all the same.
Each disk reads fine in a older normal PC drive connected to a PC under windows, and a usb drive on my main PC, none show in HxC browser.
(And all files can be copied off, etc, fine)
I'll try writing that disk image back to a blank, and see if it's picked up ok in windows.
And I'll try a new read and write ending on track 80.

Sure. Make another one available for download and tell me what files you expect to see on it.

Oh hang on, I see the problem. You are reading side 0 twice! So either this drive is bad too, or you have a bad cable or something, such that the side-select signal is being ignored.
When you view the SCP in HxC 'Track Analyzer' note that sector header contains 'H:0' for all sectors on side 1. In fact side 1 is just a re-dump of side 0!

Ah! Excellent.
Yup, that was the problem. There must be something up with my cable.

Ok, I think this ticket is done.


Test on MacOS Sequoia

[x] test build acton itself on macos-15
[x] use acton to compile an acton program on macos-15
[ ] start running CI for macos-15 (replacing macos-14)

Seems to be working just fine. Acton itself builds and it can in turn build apps. Somewhat surprisingly I notice that GitHub actions already has support for macos-15 it seems. They usually lag behind by like 1 year, so this is both surprising and obviously a good thing(tm). Should add to CI.

Turns out, it's not actually available. GitHub just uses the most confusing wording / tense ever, so https://github.com/github/roadmap/issues/986 says

Actions: macOS 15 is now available for GitHub-hosted runners (GA)

but that apparently means it is NOT AVAILABLE, because you know, this issue is scheduled in the future. How about using a future tense or something stating what should be done, not past tense like "this is done". WDAF. I opened #1926, but it's stalled. I guess we can just leave it around, macos-15 should be available in a few months or so.

Maybe I was too quick in declaring that it works. So yesterday macos-15 becamse available on GH runners and our build fails while it works for me locally. https://github.com/actonlang/acton/actions/runs/11018169022/job/30672147008
I just noticed when installing stuff via Brew that I have an outdated XCode version:
Error: Your Xcode (15.3) at /Applications/Xcode.app is too outdated.
Please update to Xcode 16.0 (or delete it).
Xcode can be updated from the App Store.

So maybe after I upgrade, Acton will not build. Presumably, the macos-15 GH runner has the latest XCode. Let's see

I opted to not replace macos-14 for PR builds. Instead we stick with macos-14 for the build but add a macos-15 for run-macos.
On the nightly run, we do add a complete build with macos-15!


prepare release v1.5.0

Signed-off-by: Zbynek Roubalik<EMAIL_ADDRESS>
Provide a description of what has been changed
Checklist

[ ] A PR is opened to update the documentation on https://github.com/kedacore/keda-docs
[ ] Commits are signed with Developer Certificate of Origin (DCO)
[ ] Tests have been added

Fixes #

Ok to merge for you @zroubalik ?


Add NNODE example

Currently stuck on adding an NNODE - an important prerequisite for using NeuralPDE.jl to fit PDE models. See https://discourse.julialang.org/t/constraints-in-neuralpde-nnode/92723/2 for a toy example that fails.

Yeah the simple MLP neural networks are usually not sufficient. I'm not sure if that's just a documentation issue or something we can handle more easily within the package itself, given that NNODE is a constrained form. Maybe it should default to an architecture we know well and only give options for layer sizes.


[Feature Request]: React Hooks Equality AKA: [isEqual] Callback

I would like useMemo, useCallback etc. to accepts some arguments that will allow us to handle the equality function for each dependencies, just something similar to react's memo which accepts optional 2nd argument to control the equality check.
Example:
const value = useMemo(
    () => computeSomething(),
    [decencies[0], decencies[1]],
    (nextDependency, prevDependency, dependencyIndex) => {
        if(dependencyIndex === 0){
            return nextDependency === prevDependency;
        } else {
            return nextDependency == prevDependency;
        }
    }
);

Or single equality callback
const value = useMemo(
    () => computeSomething(),
    [decencies[0], decencies[1]],
    (nextDependency, prevDependency) => {
       return nextDependency === prevDependency;
    }
);

Please could this feature be considered?

Like the same comparator we have in React.memo function.

Like the same comparator we have in React.memo function.

Yes exactly!

Hi, thanks for your suggestion. RFCs should be submitted as pull requests, not issues. I will close this issue but feel free to resubmit in the PR format.


pixsfm needs ceres-solver=2.1.0

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
After the issue https://github.com/conda-forge/pixsfm-feedstock/issues/6 has been solved on Nov 22, all new builds require ceres-solver >=2.2.0 . This unfortunately, forces the system to install a conda-forge version of pycolmap=0.4.0 that doesn't work. This has been documented in this issue. Unfortunately it seems that the problem is upstream and the package maintainers can't do anything about it and was fixed on 0.5.0.
However, pycolmap 0.5.0 is not compatible with pixsfm because it introduces breaking API changes.
Furthermore, pycolmap version 0.4.0 is specified as requirement in pixsfm, and many have pointed out that ceres-solver=2.1.0 is also a requirement, as 2.2.0 does not work.
Finally, there are working versions of 0.4.0, but all of them require ceres-solver >=2.1.0,<2.2.0a0 . I have tested all working versions of pycolmap and their requirements. The results are in the Installed packages box (it was too long to put it in the comment). Similarly, a list of the builds of pixsfm and their corresponding ceres-solver dependency is in Environment info.
My question is: Could you add a build of pixsfm that requires ceres-solver 2.1.0? How can I add it myself?
Thank you!
C
Installed packages
|pycolmap Version | Build | Status | Timestamp | ceres-solver version |
|0.4.0 | cpu_py310h2e7845b_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py310h38d2f4e_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py310h38d2f4e_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py310h38d2f4e_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py310h473e93f_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py310h473e93f_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py310hf3ab050_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py311h1077263_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py311h697e329_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py311h697e329_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py311hf5ffdfa_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py312h2f9418b_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py312h9c648e2_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py312hf34809f_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py38h2eeeec8_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py38h2eeeec8_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py38h35874b1_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py38h8178fc1_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py38h8178fc1_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py38h8178fc1_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py38hd0aab34_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py39h4ce60aa_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py39h636fbf4_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py39h636fbf4_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py39h636fbf4_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cpu_py39h920ca5b_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py39h920ca5b_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cpu_py39hdf416ab_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda102py310h6845ecd_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py310h6845ecd_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py310h6845ecd_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py38hfa57998_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py38hfa57998_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py38hfa57998_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py39h0b2bb32_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py39h0b2bb32_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda102py39h0b2bb32_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py310he56561f_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py310he56561f_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py310he56561f_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py38hde1633a_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py38hde1633a_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py38hde1633a_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py39h1d77e36_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py39h1d77e36_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda110py39h1d77e36_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py310hfd58f78_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py310hfd58f78_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py310hfd58f78_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py38hf735ca5_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py38hf735ca5_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py38hf735ca5_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py39he5245de_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py39he5245de_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda111py39he5245de_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py310h2ee5878_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py310h8f87eda_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py310h8f87eda_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py310hb5d9171_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py310hd504fed_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py310hef26f72_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py310hef26f72_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py310hef26f72_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py311h355d691_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py311h35f17e9_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py311hb8d6633_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py311hddf73e8_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py311hddf73e8_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py312h16a1355_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py312h978a83e_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py312hce5cabc_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38h58494e9_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38h5a36054_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38h9652703_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38h9652703_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38hefe82e1_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py38hf15c867_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py38hf15c867_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py38hf15c867_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py39h100f9ca_0 | OK | 23-05-10 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py39h100f9ca_1 | OK | 23-05-20 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py39h100f9ca_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda112py39h59ecd11_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py39h7ffca7b_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py39h7ffca7b_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py39hb153ea0_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda112py39hb2b1bdd_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py310h10cf193_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py310h256e785_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py310h622adca_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py310h6960d9f_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py310h6960d9f_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py311h18dfc40_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py311h67352d3_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py311hdfa17bf_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py311hdfa17bf_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py311hfd0fc85_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py312h0dd0389_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py312h211dc5d_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py312h622f203_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py312he4e8649_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py38h7a7b7cb_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py38h7a7b7cb_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py38h823c417_6 | TypeError | 23-12-14 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py38hebd6979_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py38hfd5fb30_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py39h5e6075c_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py39hc74b0e8_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py39hc74b0e8_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda118py39hff4c96f_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py310h0e33dcb_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda120py310h8ccfe34_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py310h8ccfe34_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py310ha450a80_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py310hf152fe7_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py311h1ae8448_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py311h4a23493_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py311h4a23493_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py311hb134df4_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py312h53a4bca_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py312h5412203_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py312he6e7684_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py38h28bfb11_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda120py38h560532e_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py38h62f741b_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py38hb7856db_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py38hb7856db_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py39h2b34c5b_2 | OK | 23-06-16 | >=2.1.0,<2.2.0a0 |
|0.4.0 | cuda120py39h63f9b19_6 | TypeError | 23-12-08 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py39h6c27c7e_5 | TypeError | 23-11-17 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py39hbe76766_3 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |
|0.4.0 | cuda120py39hbe76766_4 | TypeError | 23-10-22 | >=2.2.0,<2.3.0a0 |

Environment info
|pixsfm Version | Build | Status | Timestamp | ceres-solver-version |
| 1.0.0 | cpuh1012b9a_5 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh32645c2_4 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh4f63258_3 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh521bc1b_5 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh8358b3f_3 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh84f5113_4 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh87ff2b7_5 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh8ca378d_4 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | cpuh93e78a4_3 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh04d5e59_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh0d37221_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh198f6bf_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh1c3b146_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh1e395ae_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh2680da3_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh27750d8_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh3be515a_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh402c837_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh4128e56_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh44ae1af_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh57d97b0_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh58301eb_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh65ad786_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh6850268_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh6fc8e5f_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh71c9b82_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh7b7852b_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh7eaf48c_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh7f3e92c_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh81cb83b_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh8468e51_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh88ddbe0_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuh9a9c2e8_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuha1fe230_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhb254465_104 | 23-11-27 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhdb14635_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhe00762b_103 | 23-11-22 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhef776a1_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhf31afc4_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhf616ff6_105 | 23-12-13 | >=2.2.0,<2.3.0a0
| 1.0.0 | gpuhf8b7515_103 | 23-11-22 | >=2.2.0,<2.3.0a0

You can open a pull request. You can edit https://github.com/conda-forge/pixsfm-feedstock/blob/main/recipe/meta.yaml and pin the version of ceres-solver. You will also need to increase the build number.

Opened PR pinning ceres-solver to 2.1.0 in https://github.com/conda-forge/pixsfm-feedstock/pull/18.

See #23


Getting the value of an non-standard EDNS option

I'm experimenting with a not-yet-standard EDNS option. I can create it easily with new(dns.EDNS0_LOCAL) and send it to the remote server, but I have problem getting the value of the returned option. I parse the response with:
opt := in.IsEdns0()
for _, v := range opt.Option {
     switch v.(type) {
         case *dns.EDNS0_LOCAL:
              if v.Option() == MYOPTION {
                                        fmt.Printf("EDNS my option found, \"%s\"\n", v.String())
                                }

But I don't want to just print it with String(), I would like to get the value but I don't find an accessor for the data?

[ Quoting @.***> in "[miekg/dns] Getting the value of an..." ]

I'm experimenting with a not-yet-standard EDNS option. I can create it easily
with new(dns.EDNS0_LOCAL) and send it to the remote server, but I have problem
getting the value of the returned option. I parse the response with:
opt := in.IsEdns0()
for _, v := range opt.Option {
switch v.(type) {
case *dns.EDNS0_LOCAL:
if v.Option() == MYOPTION {
fmt.Printf("EDNS my option found, "%s"\n", v.String())
}
But I don't want to just print it with String(), I would like to get the value
but I don't find an accessor for the data?

Are you looking for v.Data ? That's just the raw byte slice.

v.Data undefined (type dns.EDNS0 has no field or method Data)

[ Quoting @.***> in "Re: [miekg/dns] Getting the value o..." ]

v.Data undefined (type dns.EDNS0 has no field or method Data)

dns.EDNS0_LOCAL or did you type the above?
https://github.com/miekg/dns/blob/master/edns.go#L583

You have to use a concrete type of dns.EDNS0_LOCAL, something like this:
opt := in.IsEdns0()
for _, v := range opt.Option {
     switch v := v.(type) {
         case *dns.EDNS0_LOCAL:
              if v.Option() == MYOPTION {
                  _ = v.Data // use Data here
              }

Note the v :=  in the type switch.

You have to use a concrete type of dns.EDNS0_LOCAL, something like this:
...
Note the v :=  in the type switch.

Thanks, that was indeed the solution.


IAPHelper Not handling transactions at application launch?

@saturngod
From the Apple's document In-App Purchase Best Practices
https://developer.apple.com/library/ios/technotes/tn2387/_index.html
Transaction observer SHOULD be added to SKPaymentQueue at application launch, the reason is that some transaction may be still in purchasing status when user closes the app.
But IAPHelper doesn't initialise it self at launch. Moreover buyProductCompleteBlock in IAPHelper isn't initialised until buyProduct:onCompletion: or restoreProductsWithCompletion:  is invoked. So the updatedTransactions will be lost before any purchase or restore if user relaunches the app.
Am i correct?

yes, it's correct. That why , I use addTransactionObserver at object allocate and removeTransactionObserver at dealloc of IAPHelper class.

but at that time, _buyProductCompleteBlock is still nil, customer code can't get any notification or callback.


'Suomi' home page view with partly translated text strings

Steps:

Visit https://nightly.apinf.io
Go to language and select 'Suomi'

Result:  'Suomi' home page view includes partly translated text strings.
- Latest API list have untranslated text strings:  'Lisätty 4 hours ago / 10 days ago'
- User 'Contact' details input field titles with untranslated text
- 'Submit' and 'Reset' button titles untranslated.
Screenshots:

Related to #965

@bajiat , verified on https://nightly.apinf.io
Findings:

Latest API details has English text
Input field titles in 'Contact form' are in English

Screenshot:

Verified in nightly. Contact form texts have been translated to Finnish. There are no English details in API cards in latest APIs. This issue can be closed.


Fix codeblock tag in classes.xml for EditorSettings

http://docs.godotengine.org/en/stable/classes/class_editorsettings.html?highlight=EditorSettings#member-function-description
codeblock tag is currently not working for there.

Cherry-picked and fixed manually.


[BUG] Dify - Cannot change STORAGE_TYPE env value

Describe the bug

In Dify helmchart there is no option to change hardcoded s3 value of env STORAGE_TYPE. And there is no option to use anything else than S3 storage. Env is hardcoded in _helpers.tpl
To Reproduce

?
Expected behavior
A clear and concise description of what you expected to happen.
Option to use other storages than S3.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

PR are welcomed, I think it’s a feature not a bug

I think using s3 would bring the user more convenience since it would not require a shared directory.
Shared directory between pods can lead to many problems like write conflict, please consult to this SO answer if you want to know more: https://stackoverflow.com/a/36524584
Apart from the potential issue brought by shared directory, you have to define volume mount for each component of dify.
I would recommend not to implement it, but like I said before, PRs are always welcomed as long as it brings no breaking change.

Thanks for answer. I want to use Google Cloud Storage instead s3. But maybe someone else will want use something else. Dify allow usage of different storage methods and IMHO your helm chart is the best from these that I have found. Later I'll try to do some PR.

Thanks for your clarification, now I totally understand you, it should be very simple to achieve your goal, just change the code here
https://github.com/douban/charts/blob/164332b343625649e8cdae44505b0fa65174ffcd/charts/dify/templates/_helpers.tpl#L107 and set default value of global.stroageType to s3 and everything would be ok.
More documents in readme are also welcomed.


How to debug nodejs internal javascript code?

When I debug a nodejs application, I can step into internal source code of nodejs such as http.js or fs.js, but when I restart debugging, the opened http.js disappeared, and so are the breakpoints, and the breakpoints which I set in http.js doesn't work. How can I solve the problem? Thanks.

I don't think we have a good answer here for now.. since the files are internal to node we don't track them between debug sessions. As much as I hate to suggest this, I would use Chrome, which may work better in this case.


the step file from the sample code exported looks weird

cc @jgomez720 to make sure its not this shitty viewer i used

const sigmaAllow = 15000 // psi
const width = 11 // inch
const p = 150 // Force on shelf - lbs
const distance = 12 // inches
const FOS = 2
const thickness = sqrt(distance * p * FOS * 6 / ( sigmaAllow * width ))
const filletR = thickness * 2
const shelfMountL = 9
const wallMountL = 8

const bracket = startSketchAt([0, 0])
  |> line([0, wallMountL], %)
  |> tangentalArc({
    radius: filletR,
    offset: 90
  }, %)
  |> line([-shelfMountL, 0], %)
  |> line([0, -thickness], %)
  |> line([shelfMountL, 0], %)
  |> tangentalArc({
    radius: filletR - thickness,
    offset: -90
  }, %)
  |> line([0, -wallMountL], %)
  |> close(%)
  |> extrude(width, %)

show(bracket)

Nope, something is certainly weird.
Also, the tauri dev app doesn't export something readable at all. I could only get something from the web app. I think @franknoirot and I talked about that once before too

@alteous, this has something to do with the tangentialArcs, because @franknoirot and I exported a good looking bracket without that before.

I can def look into the specific tauri side

is it just step on tauri or all types?

Just tested. All file types. Creating an issue now

That’s interesting. I expect this is a problem with the export code in the engine repository although it is strange we don’t get the same(?) output from the dev app. If you happen to have it at hand,  could you provide the glTF output from both the dev app and the web app? I’ll try to reproduce today otherwise.

Issue766.zip
There's one GLTF from the tauri app and one from the web app

For my reference, this is what the model should look like.

I'm attempting to reproduce this issue in the engine tests. Are these the expected commands? https://github.com/KittyCAD/engine/pull/1501/files

yeah pretty much that looks right! thanks!

Fwiw the issue was fixed so you do get the same output from both the web and tauri side so it’s just the tangential arc bit remaining :)

 66 SelectClear
 67 SelectAdd(SelectAdd { entities: [] })
 68 CameraDragStart(CameraDragStart { interaction: Rotate, window: Point2d { x: 994.0, y: 278.0 } })
 69 CameraDragEnd(CameraDragEnd { interaction: Rotate, window: Point2d { x: 1000.0, y: 290.0 } })
 70 ReconfigureStream(ReconfigureStream { width: 1708, height: 884, fps: 60 })
 71 ReconfigureStream(ReconfigureStream { width: 1708, height: 928, fps: 60 })
 72 SelectClear
 73 SelectAdd(SelectAdd { entities: [] })
 74 SelectClear
 75 SelectAdd(SelectAdd { entities: [] })
 76 SelectClear
 77 SelectAdd(SelectAdd { entities: [] })
 78 RemoveSceneObjects(RemoveSceneObjects { object_ids: {4c9c1917-d432-4f84-b180-8578b43a6aa6} })
 79 StartPath
 80 MovePathPen(MovePathPen { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), to: Point3d { x: 0.0, y: 0.0, z: 0.0 } })
 81 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: Line { end: Point3d { x: 0.0, y: 8.0, z: 0.0 }, relative: true } })
 82 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: TangentialArc { radius: 0.7236272269866327, offset: Angle { unit: Degrees, value: 90.0 } } })
 83 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: Line { end: Point3d { x: -9.0, y: 0.0, z: 0.0 }, relative: true } })
 84 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: Line { end: Point3d { x: 0.0, y: -0.3618136134933164, z: 0.0 }, relative: true } })
 85 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: Line { end: Point3d { x: 9.0, y: 0.0, z: 0.0 }, relative: true } })
 86 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: TangentialArc { radius: 0.3618136134933164, offset: Angle { unit: Degrees, value: -90.0 } } })
 87 ExtendPath(ExtendPath { path: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), segment: Line { end: Point3d { x: 0.0, y: -8.0, z: 0.0 }, relative: true } })
 88 ClosePath(ClosePath { path_id: 5f182efe-cfe5-4bbe-b058-58aef57de04a })
 89 Extrude(Extrude { target: ModelingCmdId(5f182efe-cfe5-4bbe-b058-58aef57de04a), distance: 11.0, cap: true })
 90 PathGetInfo(PathGetInfo { path_id: 5f182efe-cfe5-4bbe-b058-58aef57de04a })
 91 Export(Export { entity_ids: [], source_unit: Inches, format: Step(ExportOptions { coords: System { forward: AxisDirectionPair { axis: Y, direction: Negative }, up: AxisDirectionPair { axis: Z, direction: Positive } }, created: None })     })

Modelling commands dumped from local dev-stack.

Startpath movepathpen extendpath closepath extrude are all that really matters

The model doesn't display immediately, even in the local setup. The commands are at least correct and still produce the same export data as reported.

This explains why the test image doesn't show any geometry.

I wrote a program that edits the glTF file and inserts points to visualise the control points of the NURBS surfaces. The points are coloured differently for each surface. These are the only points I can see and they are in weird places. The export data says there are six control points in each surface.

I amended the code to display little cubes instead. The control points are much easier to see now. They are still in strange places.

The contents of the dump for the NURBS surfaces from OpenNURBS doesn't match the glTF output.
ON_NurbsSurface dim = 3 is_rat = 1
        order = 3 X 2 cv_count = 3 X 2
Knot Vector 0 ( 4 knots )
index                     value  mult       delta
    0       27.361813613493318     2
    2       28.361813613493318     2           1
Knot Vector 1 ( 2 knots )
index                     value  mult       delta
    0                        0     1
    1                       11     1          11
Control Points  6 rational points
  index               value
  CV[ 0][ 0] [-0.72362722698663262, 8.3618136134933163, 0, 1] = (-0.72362722698663262, 8.3618136134933163, 0)
  CV[ 0][ 1] [-0.72362722698663262, 8.3618136134933163, 11, 1] = (-0.72362722698663262, 8.3618136134933163, 11)

  CV[ 1][ 0] [-0.25584085962673253, 5.912695109119114, 0, 0.70710678118654757] = (-0.36181361349331631, 8.3618136134933181, 0)
  CV[ 1][ 1] [-0.25584085962673253, 5.912695109119114, 7.7781745930520234, 0.70710678118654757] = (-0.36181361349331631, 8.3618136134933181, 11)

  CV[ 2][ 0] [-0.36181361349331626, 8, 0, 1] = (-0.36181361349331626, 8, 0)
  CV[ 2][ 1] [-0.36181361349331626, 8, 11, 1] = (-0.36181361349331626, 8, 11)
ON_NurbsSurface dim = 3 is_rat = 1
        order = 3 X 2 cv_count = 3 X 2
Knot Vector 0 ( 4 knots )
index                     value  mult       delta
    0                        8     2
    2                        9     2           1
Knot Vector 1 ( 2 knots )
index                     value  mult       delta
    0                        0     1
    1                       11     1          11
Control Points  6 rational points
  index               value
  CV[ 0][ 0] [0, 8, 0, 1] = (0, 8, 0)
  CV[ 0][ 1] [0, 8, 11, 1] = (0, 8, 11)

  CV[ 1][ 0] [0, 6.1685359687458456, 0, 0.70710678118654757] = (0, 8.7236272269866326, 0)
  CV[ 1][ 1] [0, 6.1685359687458456, 7.7781745930520234, 0.70710678118654757] = (0, 8.7236272269866326, 11)

  CV[ 2][ 0] [-0.72362722698663273, 8.7236272269866326, 0, 1] = (-0.72362722698663273, 8.7236272269866326, 0)
  CV[ 2][ 1] [-0.72362722698663273, 8.7236272269866326, 11, 1] = (-0.72362722698663273, 8.7236272269866326, 11)

        {
          "type": "nurbs",
          "nurbs": {
            "controlPoints": [
              [
                0.0,
                0.203,
                0.0,
                1.0
              ],
              [
                0.0,
                0.203,
                0.279,
                1.0
              ],
              [
                0.0,
                0.157,
                0.0,
                0.707
              ],
              [
                0.0,
                0.157,
                0.198,
                0.707
              ],
              [
                -0.018000000000000002,
                0.222,
                0.0,
                1.0
              ],
              [
                -0.018000000000000002,
                0.222,
                0.279,
                1.0
              ]
            ],
            "numControlPoints": [
              3,
              2
            ],
            "numKnots": [
              6,
              4
            ],
            "knotVector": [
              8.0,
              8.0,
              8.0,
              9.0,
              9.0,
              9.0,
              0.0,
              0.0,
              11.0,
              11.0
            ],
            "order": [
              3,
              2
            ]
          }
        },

        {
          "type": "nurbs",
          "nurbs": {
            "controlPoints": [
              [
                -0.018000000000000002,
                0.212,
                0.0,
                1.0
              ],
              [
                -0.018000000000000002,
                0.212,
                0.279,
                1.0
              ],
              [
                -0.006,
                0.15,
                0.0,
                0.707
              ],
              [
                -0.006,
                0.15,
                0.198,
                0.707
              ],
              [
                -0.009000000000000001,
                0.203,
                0.0,
                1.0
              ],
              [
                -0.009000000000000001,
                0.203,
                0.279,
                1.0
              ]
            ],
            "numControlPoints": [
              3,
              2
            ],
            "numKnots": [
              6,
              4
            ],
            "knotVector": [
              27.362,
              27.362,
              27.362,
              28.362,
              28.362,
              28.362,
              0.0,
              0.0,
              11.0,
              11.0
            ],
            "order": [
              3,
              2
            ]
          }
        },

@mlfarrell, are you able to confirm you are using the same B-rep data to render with? I can only work with the data I'm given, so either I'm reading the wrong data or the data is incorrect.

@alteous the ON data is generated from ON itself when converting curves (tangent arcs in this case) to nurbs curves and eventually nurbs surfaces.   When I render, I'm simply calling the ON surface evaluator.  So i'd be very surprised if the data that I was using to render is wrong.

I created a similar part which renders correctly in the modelling app but fails to generate a valid B-rep when calling Scene::Model::Brep::Brep::getForRust:

BC and FG are the expected control points for the NURBS curves.

I have modified a test to reproduce the issue locally: https://github.com/KittyCAD/engine/pull/1501/commits/767182c17647feeea0e1f3a53c80a1266fa69683#diff-a0262fea108af44a98cc49e5eb72641963dd816513f2d0a22eb738fcfed55ebe
This is the output:
running 1 test
KittyCAD Engine Renderer Initialized
  NVIDIA GeForce RTX 3060 Laptop GPU (2)
  Vulkan 1.3
CUDA (nvenc) GPU in use: NVIDIA GeForce RTX 3060 Laptop GPU
center: (0, 0)
pole: (0, -1)
angle: 90 degrees
offset: 0 degrees
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
endpoint: (2, 0, 0)
Warning: Brep validation failed!
Warning: brep.m_E[19] edge is not valid.
	edge.m_tolerance=-1.23432e+308 (should be >= 0.0)
ON_Brep.m_E[19] is invalid.

test tests::serial_test_run_engine_stream_check_lines_with_extrude_export_to_step ... FAILED

failures:

---- tests::serial_test_run_engine_stream_check_lines_with_extrude_export_to_step stdout ----
thread 'tests::serial_test_run_engine_stream_check_lines_with_extrude_export_to_step' panicked at src/tests.rs:894:23:
called `Result::unwrap()` on an `Err` value: CppErrors([CppError { code: InternalEngine, msg_internal: "Invalid boundary representation", msg_external: "Invalid boundary representation" }])
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Note the endpoint of the tangental arc is point C as expected. I'm not sure why the B-rep is invalid in this case but it is certainly related to the arcs. If I replace the arcs with simple line curves then I get a correct result:

I also notice some artifacts which may or may not be related:

I understand the surfaces are being evaluated using the 2D trim space rather than the 3D curves. If the 2D curves and the 3D curves do not agree with each other then this would explain why it is rendered correctly but does not produce a valid B-rep.
Until now, I have only been exporting the 3D curves in the glTF, since this is the all that's strictly necessary. I plan to add the 2D curves next and will verify the correctness then.

https://github.com/KittyCAD/engine/pull/1515

for the rendering glitch - https://github.com/KittyCAD/engine/pull/1516

For clarity, the point I'm trying to get across is the path is counter-clockwise when viewed from below as the picture above it doing, so I would expect the face to be visible on this side.

I can make the B-rep appear as expected by tweaks the control points. The NURBS control points are computed at ON_ArcCurve::GetNurbForm which is called by Scene::Model::Brep::Face::updateDrawInfo. Using the debugger, I inspected the values computed by GetNurbForm and found them to be the same as what I'm getting. I have no idea how the engine is rendering this correctly but I am quite certain these values are wrong. My tweaked values are those based on this document: https://www.geometrictools.com/Documentation/NURBSCircleSphere.pdf.
diff -u lines_with_extrude.gltf original_lines_with_extrude.gltf
--- lines_with_extrude.gltf	2023-10-10 17:18:42.911129785 +0100
+++ original_lines_with_extrude.gltf	2023-10-10 17:15:50.476390344 +0100
@@ -810,9 +810,9 @@
                 1.0
               ],
               [
-                1.0,
+                0.707,
                 0.0,
-                -1.0,
+                -0.707,
                 0.707
               ],
               [
@@ -863,9 +863,9 @@
                 1.0
               ],
               [
-                1.0,
-                2.0,
-                -1.0,
+                0.707,
+                1.414,
+                -0.707,
                 0.707
               ],
               [
@@ -1201,15 +1201,15 @@
                 1.0
               ],
               [
-                1.0,
+                0.707,
                 0.0,
-                -1.0,
+                -0.707,
                 0.707
               ],
               [
-                1.0,
-                2.0,
-                -1.0,
+                0.707,
+                1.414,
+                -0.707,
                 0.707
               ],
               [

@alteous i'll take a closer look.   i dont have your full path set up (the brep export step part), but I'll at least see if I can understand why you're getting the values that you do.

@mlfarrell and I discussed this on Slack. Mike recognised the 3D part of the control points were pre-multiplied by the 4D homogeneous component.
I'm disappointed I didn't notice this myself sooner but at least we know what the problem is now. Amending the export code to un-pre-multiply (i.e., divide :stuck_out_tongue:) the spatial components by the w component fixes the issue.
I'll make the required changes soon and add a new test for this arc case soon. This will add more work to the looming engine test refactor but this fix really can't wait.

https://github.com/KittyCAD/engine/pull/1518 fixes this issue and adds my reproducer code as a new test.
STEP

glTF


Search SDK: Removing unnecessary analysis components

Some analyzers, tokenizers, token filters, and character filters do not take any parameters. For this reason, it is confusing to leave their corresponding types in the API surface area when it is sufficient to refer to them by name.
Also fixed some other documentation and changed lightItalian to light_italian to work around a bug in the API (fix coming soon).
FYI @Yahnoosh @mhko

No modification for NodeJS

No modification for Python


Typed support for SIZE parameter (RFC 1870)

This PR main adds typed support for SIZE parameter but also:

makes Parameter type an enum so future type support for other parameters can be more easily added. Note that such addtions would still be an API-breaks though since the enum is exhaustive (I'm happy to change that as well if desired).

Don't mind the failing CI. This will be fixed in https://github.com/duesee/smtp-codec/pull/5.

@duesee I also added an additional commit now to declare the existing open-ended enums as non-exhaustive. Let me know if you disagree and I'll remove that commit.

🎉


User scraping broken, returns User does not exists or does not have answers...

Looks like they've changed something on their end. Other modes work fine.

I updated the module, Please run
pip install quora-scraper --upgrade
to update the scraper to its latest version, and let me know if its working

Still getting the error.
The questions mode is working, but scraping answers from them isn't. Getting the very useful

cant get answers
Error on line 225 TimeoutException Message:
Message:

I updated the answers module, it should be working now, Please run again
pip install quora-scraper --upgrade


Bug: Slideshow Paused Glitch

This bug has been giving me headaches for a while now. More often than not, I would click on a photo and it would say, "Slideshow paused, would you like to unpause it?" or something like that, then it skips over to the next photo. This is irritating me because I can't browse through photos without this problem persisting.

This has to do with Roku's HDMI CEC integration. I've seen with as well on multiple applications before. I would suggest rebooting your Roku device and see if the problems persist.


[BUG] Proxy to API with "URIs only" performs exact match

Summary
If you create a new API in Kong which only references a list of uris as the routing capability, it seems to perform an exact match on the URI.
For example if we create an api for /v0/myproject this will get routed to the upstream server, but a request with /v0/myproject/toto won't.
Steps To Reproduce

Add a kong admin endpoint: curl -X POST http://$(docker-machine ip microservice):8001/apis -d 'name=kong-admin' -d 'hosts=kong-admin.service.consul' -d 'uris=/' -d 'upstream_url=http://<IP_ADDRESS>:8001'
Create an API on Kong: curl -X POST http://kong:8001/apis -d 'name=myproject' -d 'uris=/v0/myproject' -d 'upstream_url=http://myproject.service.consul'
Query the newly created api on the exact URI: curl http://kong/v0/myproject -> 200 Ok
Query the newly created api with extract path in the URI: curl http://kong/v0/myproject/toto -> 404 -> {"message":"no API found with those values"}

Mitigation:
If you want to solve the problem you can add a a host and/or a method the query will go through:

curl -X PATCH http://<IP_ADDRESS>:8001/apis/myproject -d 'hosts=toto.com'
Query the api one more time with extract path in the URI: curl -H 'Host: toto.com' http://kong/v0/myproject/toto -> 200 ok

Additional Details & Logs

Kong version 0.10.1

After doing a bit of it seems that this behavior comes from that block of code https://github.com/Mashape/kong/blob/master/kong/core/router.lua#L518
Since it matches on the / from the first api it just break and stops looking. Problem is that the header won't match so we end up with  no api found. Might be worth to keep going on something like if req_category & MATCH_RULES.HOST ?

Hi! This should have been fixed with #2343, please give it a try and re-open if the issue still occurs, thanks!