dissallow llvm-openmp 12.* for M1

The llvm-openmp package has a Numba relevant bug that only manifests
when using that package on M1 silicon (new Apple chips) in version 12.
This will allow building Numba (the headers are needed) but dissallow
running it with llvm-openmp in version 12.* on Apple M1 silicon.
The llvm-openmp bug is here:
https://github.com/llvm/llvm-project/issues/49923
This will also be future proof and allow llvm-openmp to be installed
in version 13 as soon as that becomes available from main/defaults or
if people want to use conda-forge, since that already has version 13.

Just focusing on the Python 3.10 and Numpy 1.21 combo to at least get something going.
I can build this with:
conda build -c numba/label/ci --dirty --no-test --python=3.10 --numpy=1.21 buildscripts/condarecipe.local

We need to get the llvmlite 0.39 dev package from numba/label/ci b/c the M1 package never made it to numba/label/dev.

I have now reduced the patch to basically:
  run_constrained:
    ...
    - llvm-openmp > 12.0.0      # [arm64]

I.e. just the change to the run_constrained. Yet still, when I go to try to resolve and install the resulting package, I get:
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: /
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.                                                                                failed

UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package llvmlite conflicts for:
numba==0.56.0dev0=np1.21py3.10h5ae3daa_gd4967d87c_254 -> llvmlite[version='>=0.39.0dev0,<0.39']
numba/label/ci|numba/label/ci::llvmlite
numba/label/ci::llvmlite

Package numpy conflicts for:
numba==0.56.0dev0=np1.21py3.10h5ae3daa_gd4967d87c_254 -> numpy[version='>=1.18']
numpy=1.21

Package setuptools conflicts for:
numba==0.56.0dev0=np1.21py3.10h5ae3daa_gd4967d87c_254 -> setuptools
python=3.10 -> pip -> setuptools

Package python conflicts for:
numba/label/ci::llvmlite -> python[version='>=3.10,<3.11.0a0|>=3.9,<3.10.0a0|>=3.8,<3.9.0a0']
numba==0.56.0dev0=np1.21py3.10h5ae3daa_gd4967d87c_254 -> llvmlite[version='>=0.39.0dev0,<0.39'] -> python[version='>=3.8,<3.9.0a0|>=3.9,<3.10.0a0']
numpy=1.21 -> python[version='>=3.10,<3.11.0a0|>=3.8,<3.9.0a0|>=3.9,<3.10.0a0']
python=3.10
numba==0.56.0dev0=np1.21py3.10h5ae3daa_gd4967d87c_254 -> python[version='>=3.10,<3.11.0a0']

Package expat conflicts for:
numpy=1.21 -> python[version='>=3.9,<3.10.0a0'] -> expat[version='>=2.4.1,<3.0a0']
numba/label/ci::llvmlite -> python[version='>=3.9,<3.10.0a0'] -> expat[version='>=2.4.1,<3.0a0']

I have also manually verified that this doesn't happen if the run_constrained entry about open-llvm is omitted. I.e. the package will seemingly build fine then.
I am now wondering if there are any additional changes to the meta.yaml that need to be made.

Taking a closer look at the "rendered" meta.yaml -- which I obtained from unpacking the conda package and looking in info has the following stanzas:
  run:
    - libcxx >=12.0.0
    - llvm-openmp >=12.0.0
    - llvmlite >=0.39.0dev0,<0.39
    - numpy >=1.18
    - python >=3.10,<3.11.0a0
    - setuptools
  run_constrained:
    - cuda-python >=11.6
    - cudatoolkit >=9.2
    - llvm-openmp > 12.0.0
    - scipy >=1.0
    - tbb >=2021

I see llvm-openmp in both run and run_constrained, yet with potentially conflicting version specifiers. This may explain the strange conflict explanations from conda that don't hint at anything.
Current assumption is that llvm-openmp is "bleeding through" from the build section to the run section.

I investigated this issue some more with @seibert last night and I managed to work out (I think) why the llvm-openmp requirement was bleeding through to the run section. So, the recipe of llvm-openmp, at least the one on conda-forge, has something called a run_export(https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#export-runtime-requirements). See also:  https://github.com/conda-forge/openmp-feedstock/blob/77d3f5b/recipe/meta.yaml#L28-L32 . Effectively this means that if llvm-openmp is included somewhere in build, then it is automatically exported as a run requirement and this behaviour is inherited into anything requiring llvm-openmp in build.And, yes, we can use conda render to check this.
OK, so far, so good. Now, there is a way to disable this, using the ignore_run_exports section in build (not requirements).
So for the Numba recipe this would be:
build:
  ignore_run_exports_from:
    - llvm-openmp

In fact, this technique has been used before for tbb in the Numba recipe! So we can use the following patch to disable exporting llvm-openmp:
diff --git a/buildscripts/condarecipe.local/meta.yaml b/buildscripts/condarecipe.local/meta.yaml
index bc1c505ae..4c5ace351 100644
--- a/buildscripts/condarecipe.local/meta.yaml
+++ b/buildscripts/condarecipe.local/meta.yaml
@@ -20,6 +20,7 @@ build:
   ignore_run_exports:
     # tbb-devel triggers hard dependency on tbb, this is not the case.
     - tbb     # [not (armv6l or armv7l or aarch64 or linux32)]
+    - llvm-openmp

 requirements:
   # build and run dependencies are duplicated to avoid setuptools issues
@@ -29,6 +30,7 @@ requirements:
     - {{ compiler('cxx') }}    # [not (armv6l or armv7l or aarch64)]
     # OpenMP headers from llvm needed for OSX.
     - llvm-openmp              # [osx]
+
   host:
     - python
     - numpy
@@ -70,7 +72,7 @@ test:
     - ipython                  # [not (armv6l or armv7l or aarch64)]
     - setuptools
     - tbb  >=2021              # [not (armv6l or armv7l or aarch64 or linux32 or ppc64le)]
-    - llvm-openmp              # [osx]
+    - llvm-openmp              # [osx and not arm64]
     # This is for driving gdb tests
     - pexpect                  # [linux64]
     # For testing ipython

Using conda render we get the following:
  run:
    - setuptools
    - numpy >=1.18
    - llvmlite >=0.39.0dev0,<0.39
    - libcxx >=12.0.0
    - python >=3.10,<3.11.0a0
  run_constrained:
    - scipy >=1.0
    - cuda-python >=11.6
    - tbb >=2021
    - cudatoolkit >=9.2

And this is all fine and it builds a package and so on. However, when we then go and attempt to install it, llvm-openmp is still pulled in as a dependency. When I try to remove it from the environment, I get:
The following packages will be REMOVED:

  blas-1.0-openblas
  libgfortran-5.0.0-11_1_0_h6a59814_26
  libgfortran5-11.1.0-h6a59814_26
  libopenblas-0.3.17-hea475bc_1
  llvm-openmp-12.0.0-haf9daa7_1
  numba-0.56.0dev0-np1.21py3.10h5ae3daa_gaed25b8aa_257
  numpy-1.21.2-py310hb38b75b_0
  numpy-base-1.21.2-py310h6269429_0

And we can remove numba but the other packages, blas, libgfortran, libgfortran5, libopenblas, llvm-openmp, numpy numpy-base are all-or-nothing. So, from that my conclusion is that we can not install Numba as a conda package w/o also installing llvm-openmp.
For what it is worth we can attempt to add llvm-openmp to run_constrained:
diff --git a/buildscripts/condarecipe.local/meta.yaml b/buildscripts/condarecipe.local/meta.yaml
index bc1c505ae..3357e7756 100644
--- a/buildscripts/condarecipe.local/meta.yaml
+++ b/buildscripts/condarecipe.local/meta.yaml
@@ -20,6 +20,7 @@ build:
   ignore_run_exports:
     # tbb-devel triggers hard dependency on tbb, this is not the case.
     - tbb     # [not (armv6l or armv7l or aarch64 or linux32)]
+    - llvm-openmp

 requirements:
   # build and run dependencies are duplicated to avoid setuptools issues
@@ -29,6 +30,7 @@ requirements:
     - {{ compiler('cxx') }}    # [not (armv6l or armv7l or aarch64)]
     # OpenMP headers from llvm needed for OSX.
     - llvm-openmp              # [osx]
+
   host:
     - python
     - numpy
@@ -51,6 +53,7 @@ requirements:
   run_constrained:
     # If TBB is present it must be at least version 2021
     - tbb >=2021    # [not (armv6l or armv7l or aarch64 or linux32 or ppc64le)]
+    - llvm-openmp >=13.0.0    # [arm64]
     # avoid confusion from openblas bugs
     - libopenblas !=0.3.6      # [x86_64]
     # CUDA 9.2 or later is required for CUDA support
@@ -70,7 +73,7 @@ test:
     - ipython                  # [not (armv6l or armv7l or aarch64)]
     - setuptools
     - tbb  >=2021              # [not (armv6l or armv7l or aarch64 or linux32 or ppc64le)]
-    - llvm-openmp              # [osx]
+    - llvm-openmp              # [osx and not arm64]
     # This is for driving gdb tests
     - pexpect                  # [linux64]
     # For testing ipython

But then we run into the following conflict (which incidentally says nothing about llvm-openmp:
UnsatisfiableError: The following specifications were found to be incompatible with each other:

Output in format: Requested package -> Available versions

Package setuptools conflicts for:
python=3.10 -> pip -> setuptools
numba==0.56.0dev0=np1.21py3.10h5ae3daa_ge269044c9_260 -> setuptools

Package libiconv conflicts for:
numpy=1.21 -> python[version='>=3.9,<3.10.0a0'] -> libiconv[version='>=1.16,<2.0a0']
numba/label/ci::llvmlite -> python[version='>=3.9,<3.10.0a0'] -> libiconv[version='>=1.16,<2.0a0']

Package numpy conflicts for:
numba==0.56.0dev0=np1.21py3.10h5ae3daa_ge269044c9_260 -> numpy[version='>=1.18']
numpy=1.21

Package python conflicts for:
numpy=1.21 -> python[version='>=3.10,<3.11.0a0|>=3.8,<3.9.0a0|>=3.9,<3.10.0a0']
numba==0.56.0dev0=np1.21py3.10h5ae3daa_ge269044c9_260 -> python[version='>=3.10,<3.11.0a0']
numba/label/ci::llvmlite -> python[version='>=3.10,<3.11.0a0|>=3.9,<3.10.0a0|>=3.8,<3.9.0a0']
numba==0.56.0dev0=np1.21py3.10h5ae3daa_ge269044c9_260 -> llvmlite[version='>=0.39.0dev0,<0.39'] -> python[version='>=3.8,<3.9.0a0|>=3.9,<3.10.0a0']
python=3.10

Package llvmlite conflicts for:
numba==0.56.0dev0=np1.21py3.10h5ae3daa_ge269044c9_260 -> llvmlite[version='>=0.39.0dev0,<0.39']
numba/label/ci|numba/label/ci::llvmlite
numba/label/ci::llvmlite

Finally, my current take on this is that we can not disallow using a broken llvm-openmp 12.0.0 to be installed alongside Numba with the current state of defaults. Having 13.0.0 on defaults is likely to solve this issue w/o any need to alter or change Numba or how it is built.

@stuartarchibald I think it is safe to say, that we can abandon this one?


peers on different networks are often unable to connect.，is this problem solved?

No that unfortunately is an issue that's not been addressed. The problem seems to be at NAT punching level. You might want to check out com.unity.webrtc (or OpenNAT) and make your own networking implementation based on them, leaving univoice to only do the audio stuff.

@adrenak So using an alternative backend for establishing the connection, like going with some relay server could solve this 100% connectivity issue, or have I misunderstood?

@julian-innerchild yes iiuc. Do keep in mind that univoice uses airpeer, which uses airsignal (JS running on cloud) all these are repos on my profile if you need to have a look.
You can directly replace airpeer with unity's webrtc, for example. You'd need to make an IChatroomNetwork implementation that uses unity's webrtc. Then use that instead of AirPeerUniVoiceNetwork, which is the default implementation in the repository.

I have connection issue when peers are not in the same network. Anybody has IChatroomNetwork implementation that uses unity's webrtc?


⚠ Turnos 24x7 has degraded performance

In 4f84e9b, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 1630 ms

Resolved: Turnos 24x7 performance has improved in 7c20611.


Default Option to Exch_13_16_19_Full.xml when no template is provided

If alternate template is not provided, just default to Exch_13_16_19_Full.xml as this is the only supported versions of Exchange now and we don't need an extra step when attempting to create the Experfwiz.

Defaults to 13_16_19 if nothing is selected.


Load images using Dropbox Android SDK

Hello. Is it possible to create a downloader that can fetch images from Dropbox using the SDK? The paths are not public, they are relative to account, and the Dropbox API must be used.

I was able to test it by extending the BaseImageDownloader, and got the exception telling I should implement the support for the Dropbox scheme by myself using the getStreamFromOtherSource method. Was able to get the images. I will leave this here in case someone needs it also.


Tab inline completion

This PR makes nushell tab completion behave more like zsh/bash. Assuming quick_completions = true:

Changes Tab so that it completes instead of selecting the next menu item (arrow keys can be used for that)
Completion is "as far as possible". So, the entire word if there's a unique completion, or else up to the shared prefix of possible completions.
Gets rid of the quick completion behavior whereby a word was completed automatically as soon as the input came to have a unique completion.

See https://github.com/nushell/nushell/pull/6802 to use this with nushell.

I'm guessing we need to land this one so we don't have to point to @dandavison's repo?

Sounds good!


MINIFICPP-273 Simplify configuration of MiNiFi - C++ by allowing defa…

…ult values for scheduling strategy and period.
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

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

[x] Does your PR title start with MINIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

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

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

For code changes:

[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[x] If applicable, have you updated the LICENSE file?
[x] If applicable, have you updated the NOTICE file?

For documentation related changes:

[x] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Fixed review issues. Ready for more review/merge.

Ready for another look.


Support directives at query and mutation locations

The spec allows directives at QUERY and MUTATION locations but code generation doesn't.
For example, the following valid graphql is not supported by the plugin:
mutation @myModifier CreateReviewForEpisode($review: ReviewInput!) {
  val1: createReview(review: $review),
  val2: trackReview(review: $review),
}

Hi! Thanks for the bug report! Just to make sure: this fails at compile time, right?
I'm asking this because I don't think we have code to handle any operation directives. The only directives we support are @include and @skip, which are on fields. So any operation directive would most likely be ignored. Or are you expecting myModifier to have a specific effect?

Custom directives can be created and used in graphql-java:
    GraphQLSchema.Builder builder = new GraphQLSchema.Builder();
    // ...

    builder.additionalDirective(
        GraphQLDirective.newDirective()
            .validLocation(Introspection.DirectiveLocation.MUTATION)
            .name("myModifier")
            .build());

Then, those can be read from the operation definition during execution:
val directives = environment.getOperationDefinition().getDirectives();

But code generation doesn't support it:
[ERROR] Failed to parse GraphQL file /path/to/Sample.graphql (1:21)
[ERROR] Unsupported token `InsertProducts`
[ERROR] ----------------------------------------------------
[ERROR]
[ERROR] [1]:mutation @myModifier InsertProducts(
[ERROR] [2]:    $value: ProductsInput!
[ERROR] ----------------------------------------------------

Then, those can be read from the operation definition during execution:

By execution, you mean server side, right? If I understand correctly, if apollo-android would just "pass these directives through", that'll work for your use case, right?

yes, just blindly pass them through would be great.

Thanks for the confirmation 👍 , I'll look into this.

Turns out, operation directives need to come after the operation name: https://spec.graphql.org/June2018/#OperationDefinition
Everything should work fine if you write to queries like:
mutation InsertProducts($value: ProductsInput!) @myModifier {
  id
}

Let me know if that worked

oh my... 🤦 I've just double checked...it works as expected.

Thanks @martinbonnin for looking into it !


When I source my fish.config it loses the fry path from my $PATH

# For Fry ruby version manager
if test -f /usr/local/share/fry/fry.fish
  source /usr/local/share/fry/fry.fish
  # Set default version of ruby
  fry use 2.0.0-p648
end

I have this in my fish.config and I have fry config prepend on. Whenever I source ~/.config/fish/config.fish it looses the fry path from $PATH and defaults to the system ruby. Any help would be very appreciated.

I found the issue. I was resetting my $PATH in my fish.config which blew away the $fish_user_paths. I've been using fish for a very long time and didn't even know about the $fish_user_paths. 😑


while engine is judging it publish some results into the channel

Why not always keep 2 containers for each language on and pick up submissions to put it into a particular folder inside the container and we have a infinite process of that language running inside it which picks one file from that folder executes it checks if all the answers for a test case is write and prints the output along with status within a time bounded and memory bounded contidions whose output and stuatus is then transmitted to rust orchestrate process

I was thinking of running a process of language inside a container which infinitely looks for same language file in the judge folder and executes it and matches the answers and outputs and then deletes it and transmites it back to the rust process


Algo Selection Sort in Python

Need to make a readme file which should have the
Definition
Explanation in simple terms
Code related explanation.

Could you please assign me this issue.

This issue was taken. @Subhashini014

Ok I am working on this issue .Thank you for assigning me.


[docs]  dashboard access token url broken

Url pointing at example using kubernetes dashboard using access token is broken
https://github.com/sighup-io/fury-kubernetes-aws/blob/master/katalog/dashboard/README.md

the example is here https://github.com/sighup-io/fury-kubernetes-on-premise/tree/master/examples/dashboard-add-user
given dashboard package is the same in both repos, maybe we could extract it and have documentation/examples in a single place

I'm closing this issue due to inactivity


grid-content producing sass error after parameters

Here is the error I'm receiving:

[12:50:35] Starting 'sass'...
[12:50:35] [gulp-sass] error reading values after , on line 10 in /source/mwepd/client/assets/scss/app.scss
[12:50:35] Finished 'sass' after 7.56 ms

And this is my full app.scss file, as it currently exists. Line 10 is the $order: null, //... line

@import "settings";
@import "foundation";

// file content

.navbar {
@include grid-content(
$size: shrink, // Can be expand, shrink, or a number of columns
$offset: null, // Number of columns to offset to the right by
$order: null, // Can be any positive number
);
display: block;
padding: 0 $block-padding;
}

The $order parameter in the mixin has an extra comma. Remove that last comma and you'll be good.
It looks like our documentation has a few formatting issues like these, so we'll make sure they get fixed.


Clicking Userchrome Toggle doesn't pin the sidebar

I've followed the readme and every steps, it does work before I added CSS and restarted it. But afterwards it just doesn't pin on the side anymore.

nevermind, did a little oopsie, || was on the name, not on the prefix, my bad lmao


Bug: JDM Rule Graph (Restyled) Editor Allows Node Connections When Disabled

Issue Description
When using the JDM rule graph editor in read-only mode, specifically while scrolling through different versions of the rules, the editor should not allow any changes to be made, including connecting nodes. However, a bug currently exists where nodes can still be connected even when disabled. This behavior deviates from the expected functionality, where the rule graph editor should be entirely read-only when reviewing rule versions.
Steps to Reproduce

Open the JDM rule graph editor.
Open version mode, scroll through different versions of the rules.
Attempt to connect nodes within the graph editor.

Expected Behavior
The rule graph editor should be disabled (or in a read-only state), preventing any modifications, including connecting nodes between different parts of the graph.
Actual Behavior
Users are able to connect nodes even while in read-only mode, indicating that the editor is not fully disabled.
Possible Impact
Allowing modifications in view mode could lead to unintended changes or confusion about the current state of rule versions, as users might expect their interactions in this mode to have no effect. I haven't checked on whether or not it impacts the simulator, but be wary of that also.
Additional Information

No additional plugins or custom scripts were used that could affect the editor's functionality.
This issue was identified in the version currently deployed on the GoRules platform demo environment.

If this behavior is expected or it has been fixed, please close this issue. Otherwise, please let me know if more details are needed or if there are any workarounds available in the meantime.
Thank you!

Will investigate

Issue has been fixed, new version of the cloud, brms and standalone editor will be released today

Released


Fix exception handling

Currently, the custom error handling only works in debug mode. This is due to some behaviour about propagating exceptions. However, in production mode flask-restful intercepts the exceptions before our custom flask ones can handle them. See: https://flask-restful.readthedocs.io/en/latest/extending.html#custom-error-handlers.
We should either define a custom dictionary like the docs recommend, or instead implement our "own" API and override the handle_error function like detailed in these answers: https://stackoverflow.com/questions/41149409/flask-restful-custom-error-handling
Acceptance criteria:

[x] Our custom exceptions should return the correct error codes to the user in both debug + production mode

The PR associated with this issue has been reviewed and merged, but because it hasn't been merged into master, it hasn't been closed automatically, but the work for this issue has been completed.


Copy-paste mistake in documentation that tries to help you avoiding copy-paste mistakes

The page precisely describes how to modify the INF file in order to not make any copy-paste mistakes. However, it looks like a copy-paste mistake slipped in :)
An excerpt from the "Before" file:
[ECHO_Device_CoInstaller_AddReg]
[ECHO_Device_CoInstaller_CopyFiles]
[ECHO_Device.NT.Wdf]

... and the "After" file:
[MyDevice_CoInstaller_AddReg]
[MyDevice_CoInstaller_CopyFiles]
[MyDevice_Device.NT.Wdf]

Looks like the last section after modification should rather be called [MyDevice.NT.Wdf].

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

ID: 25cc35e8-045f-b920-a6b1-400d1169b28b
Version Independent ID: 83008dd8-bcd8-3fe8-4891-de3797800c61
Content: Specifying the KMDF Co-installer in an INF File - Windows drivers
Content Source: windows-driver-docs-pr/wdf/installing-the-framework-s-co-installer.md
Product: windows-hardware
Technology: windows-devices
GitHub Login: @tedhudek
Microsoft Alias: tedhudek

Thanks @ColinFinck


Crossover PSO

Implemented a few strategies for prof combining PSO and crossover stuff.

What should I test for in the unit tests? These things are pretty much stochastic.
The parameters need to be tweaked so I think the results are still similar to a regular PSO and the velocity update should probably only be used for exploitation.

Vector#orthogonalize and Vector#project should definitely be tested.
I agree, it's difficult to test components that are stochastic, even so, you should try to break down your code into testable units.
E.g. In ParentCentricCrossoverStrategy you calculate the mean of the parents, that's a pretty testable thing in my opinion. It would be easy to refactor that code into a method and test it. It would also make the code cleaner (crossover is quite long).
I see you write comments describing each unit of work (e.g. // construct the offspring), every time you do that, you might want to consider encapsulating the code in a new method, and testing it if possible.
Side note, I see you calculate the mean a number of times, maybe refactor that to share the code, if such code doesn't already exist.
Another technique you can use is the mocking framework, mock out stochastic things (like positions), and ensure other logic works (like selecting the best entity and updating other things appropriately).
This is just my opinion, if @gpampara is happy with the testing and the code, then there's no problem.

This looks better. We need to make a plan regarding all that casting that is happening..... Its really going to be a source of problems in the future.

Yep, I'm done adding stuff. There is still one more crossover strategy but I'll put that in another pull request when I'm done.


"Failed loading TCerts from TCA" when calling POST /chaincode

I'm following the steps highlighted in https://github.com/IBM-Blockchain/learn-chaincode#secure-enrollment using the Swagger UI.
The POST /registrar worked.
but
The POST /chaincode with the JSON payload in the README does not work and gives:
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32001,
    "message": "Deployment failure",
    "data": "Error when deploying chaincode: Failed loading TCerts from TCA"
  },
  "id": 1
}

Are you using a network with the IBM Blockchain service on Bluemix or is it a network you setup yourself?  If its Bluemix, try grabbing a new network.

on Bluemix.

So first delete your current network and get another one.

Make sure only one of the boxes for invoke/deploy/query have any text in them.  For example when doing an invoke the other two fields should be blank.
Also make sure the json is in the correct box for the action you want to perform

Example Invoke:

Closed due to inactivity, but I will say that the bluemix service has gone through some significant stability updates since @dshuffma-ibm 's last response.  This issue was likely caused by a connectivity issue between the peer and it's membership service.  Let us know if you have further issues, @l2fprod .

I'm getting this issue on what was a perfectly stable fabric ... I don't want to simply "get a new network" as I have 1.14 million blocks with something like 6 to 8 million transactions ... any thoughts on how to get the tcerts thing to work again?

I have a client PoC running on a Bluemix fabric and have hit the TCert wall. Getting a new fabric is an awkward thing to explain. And you can't really get the data back :(

@sumanair can you please provide the network ID?


Pass-Through parameters are not being properly deployed

When editing pass-through parameters, sometimes these modifications will be overrode, without any notifications, when there are also regular, non-pass-through, parameter changes.
The problem can be replicated using the following toy example:

Set Personal income (regular/non-AMT/non-pass-through) tax rate 2 (under Personal Income, Regular: Non-Amt, Non-Pass-Through section) to 0.25.

Set Pass-through income tax rate 2 (under Personal Income, Pass-Through section) to 0.15.

Click "Show me the results".

After calculation is done, click "Edit parameters", and check the parameters we just edited.

You will find the actually Pass-through income tax rate 2 being implemented is 0.25, instead of 0.15!

The cause of this problem might be that, for some reasons, pass-through parameters are associated with non-pass-though parameters.
@MattHJensen

I can replicated.
cc @brittainhard

Looking into this now.

@GoFroggyRun @MattHJensen I looked at the code, and it looks like this is an intended feature. If there is a param like II_rt1 set, then PT_rt1 will always be set to the former param value.
The original issue and discussion is here: https://github.com/OpenSourcePolicyCenter/webapp-public/issues/340
The fix was added in https://github.com/OpenSourcePolicyCenter/webapp-public/pull/342
If we do want keep this logic, there is the possibility of hiding all of the PT_* fields, or I can revert the behavior if we want to change it back to the previous behavior.
Let me know what you think.

@brittainhard Thanks for looking into this issue.
@brittainhard said:

I looked at the code, and it looks like this is an intended feature. If there is a param like II_rt1 set, then PT_rt1 will always be set to the former param value.

Yes, this was the case when we have not introduced any PT_rt parameters in tax-calculator to tax-brain (TB) I believe. Before users are able to edit PT_rt parameter themselves on TB, this assumption was a compromise (sort of) we made in past releases.
But right now, in TB, we are splitting PT_rt and II_rt parameters because we want them to be manipulated independently. In other word, the logic that sets corresponding PT_rt to be II_rtis no longer wanted.
@MattHJensen let me know if I have missed something.

@GoFroggyRun, that is correct. Thanks.

Good to know. I'll make a PR that removes this logic from webapp.

I'm confirming that this issue has been fixed in the latest release of TB (test version). So closing.
Thanks @brittainhard for fixing this!

Thanks @brittainhard. Thanks @GoFroggyRun.


[fix-7712][Docker] support docker-compose 2.X

this close #7712
branch env has refactor files related to docker, and there is no docker/docker-swarm/config.env.sh. But not yet merged into branch 2.0.3-prepare. So, please consider if this is necessary to fix this bug.

Codecov Report

:exclamation: No coverage uploaded for pull request base (2.0.3-prepare@46a5d17). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             2.0.3-prepare    #7980   +/-   ##
================================================
  Coverage                 ?   31.21%
  Complexity               ?     1571
================================================
  Files                    ?      440
  Lines                    ?    15058
  Branches                 ?     1508
================================================
  Hits                     ?     4701
  Misses                   ?     9890
  Partials                 ?      467

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 46a5d17...13ddea0. Read the comment docs.


Fix job history page tab highlighting

The job history page tab doesn't highlight when you are on that page. This PR fixes the problem.
@krishnap

+1


Fix HTML indent lasttick update

Since 7.4.345 (2014-06-25), when the check was introduced, the html indent checks and sets b:hi_lasttick inconsistently:
   993   if prevnonblank(v:lnum - 1) == b:hi_indent.lnum && b:hi_lasttick == b:changedtick - 1
  1062   let b:hi_lasttick = b:changedtick

This results in always recomputing a fresh state when the buffer has not changed, and very rarely may attempt to reuse a state after a buffer change. The only case where this is likely to be correct is when indenting the line immediately following a line whose indentation was just changed by the indenter, and can mistakenly reuse state when exactly one unrelated change has occurred in the meantime.
Always using a fresh state almost always gets the right indentation, but has noticeably awful O(n^2) performance when reindenting the entirety of HTML files with many lines.
The fix is trivial. However, I have not checked that the state update in HtmlIndent() is correct and matches the logic in FreshState(); it seems fine on casual inspection, but there may be bugs lurking there that haven't had a chance to manifest in the past four years because state reuse occurs so rarely.
diff --git a/runtime/indent/html.vim b/runtime/indent/html.vim
index bece6614b..03bf207b9 100644
--- a/runtime/indent/html.vim
+++ b/runtime/indent/html.vim
@@ -1059,7 +1059,7 @@ func! HtmlIndent()
     endif
   endif

-  let b:hi_lasttick = b:changedtick
+  let b:hi_lasttick = b:changedtick - 1
   call extend(b:hi_indent, b:hi_newstate, "force")
   return indent
 endfunc "}}}

An alternative would be to change the check instead of making b:hi_lasttick misleadingly named, which is more in line with the example in the documentation for b:changedtick.
My rationale for making the change this way is motivated by backward compatibility:
setl inde=FixedHtmlIndent()
func! FixedHtmlIndent()
        let indent = HtmlIndent()
        let b:hi_lasttick = b:changedtick - 1
        return indent
endfunc

Placed in ~/.vim/after, this snippet monkey-patches the current version of the code to reuse state appropriately. Changing the assignment to b:hi_lasttick merely makes this code redundant, without breaking anything. It is comparatively difficult to write a script which will similarly smooth over the transition to b:hi_lasttick == b:changedtick.

There appears to be an inconsistency such that when the previous line

contains unclosed tags that increase the indent
ends with the closing tag for a tag opened earlier

then the freshly computed state's baseindent is based on the closing tag, while HtmlIndent's incremental update computes baseindent based on the tags being opened. This leads to a behaviour difference between the two modes of operation. A small example:

https://thesaurus.weblio.jp/content/%E6%B0%97<wbr>%E3%81%8C<wbr>%E5%A4%A7<wbr>%E3%81%8D<wbr>%E3%81%8F<wbr>%E3%81%AA<wbr>%E3%82%8B

                                                This line gets indented inconsistently.```

Notice the element in the example, `<wbr>`, is one of the HTML 5 tags which is mistakenly listed as a paired tag, but is in fact a void element. This edge case occurs only when tags expected to close are not closed, which can only correctly occur for self-closing tags.

I have amended the patch above to remove the following self-closing HTML 5 tags from the list of indented tags: area, keygen, rp, rt, track, wbr.

In addition, the following tags *may* be self-closing under certain conditions: body, dd, dt, head, html, li, optgroup, option, td, tfoot, th, thead, tr. However, all of these are likely to contain contents which it may be desirable to indent.

Since 7.4.345 (2014-06-25), when the check was introduced, the html
indent checks and sets b:hi_lasttick inconsistently:
   993   if prevnonblank(v:lnum - 1) == b:hi_indent.lnum && b:hi_lasttick == b:changedtick - 1
  1062   let b:hi_lasttick = b:changedtick

This results in always recomputing a fresh state when the buffer has
not changed, and very rarely may attempt to reuse a state after a
buffer change. The only case where this is likely to be correct is
when indenting the line immediately following a line whose indentation
was just changed by the indenter, and can mistakenly reuse state when
exactly one unrelated change has occurred in the meantime.
Always using a fresh state almost always gets the right indentation,
but has noticeably awful O(n^2) performance when reindenting the
entirety of HTML files with many lines.
The fix is trivial. However, I have not checked that the state update
in HtmlIndent() is correct and matches the logic in FreshState(); it
seems fine on casual inspection, but there may be bugs lurking there
that haven't had a chance to manifest in the past four years because
state reuse occurs so rarely.
diff --git a/runtime/indent/html.vim b/runtime/indent/html.vim
index bece6614b..03bf207b9 100644
--- a/runtime/indent/html.vim
+++ b/runtime/indent/html.vim
@@ -1059,7 +1059,7 @@ func! HtmlIndent()
     endif
   endif

-  let b:hi_lasttick = b:changedtick
+  let b:hi_lasttick = b:changedtick - 1
   call extend(b:hi_indent, b:hi_newstate, "force")
   return indent
 endfunc "}}}

I started looking into this and improving a few things, but quickly got
lost in the undocumented parts.  I'll have to get back to this when I
have more time.
I'll include the parts that should be OK.
--
ARTHUR: What are you going to do. bleed on me?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Enabled the visibility of Twitter-icon

Description
fixes the problem in visibility of Twitter icon
Related Issue
Fixes #1057
Screenshot

@sanjay-kv
When I opened this website in my local device, it was visible. So, I have changed something that I thought that it can be the reason of not visibility of the Twitter icon and updated the code accordingly.
Please check once that is it visible in your side and inform me and I will try to do in other ways.

@sanjay-kv please add levels and gssoc and hactoberfest approval.


Delete MacPorts Portfile

A MacPorts Portfile was added in 71a4a506bbf95fb25f636e3346f1fb841a7af432. It should be deleted. Portfiles are maintained in the macports-ports repository. Keeping an outdated copy of it in your repository offers no benefit and only creates confusion.

This repo is unmaintained. Thanks for letting us know. I have removed it my fork: https://github.com/hoytech/lmdbxx/commit/6f497d1d8e1a6e0afa8ae83891d13b3fac68b62c


Make the ranged enemy

the ranged enemy works just as the melee enemy.
But the ranged enemy starts attacking from a specific range and can throw a ball that does AOE damage.

Assets should all be removed accept the one you are using


Turicreate 6.2.2 Style Transfer parameters not working?

Hi, i  have been using the style transfer in Turicreate - mostly used v5.8 with some good results. Just tried V6.2.2 on google colabs and Macbook pro 2018, Catalina 10.15.4 (19E287), AMD 560x. i have noticed a couple of issues

Macbook - it can use the AMD GPU, but the results are a mess, not usable (although im impressed with the speed it completes the task)
Macbook - CPU - gives good results, but obviously slow
Google Colabs - after installing Tensorflow-GPU - it uses the GPU and results are similar to the macbook pro CPU results - but obviously faster
The advanced parameters is not recognised and thus no adjustments are made to the style loss- the same results are produced each time - regardless of how i change the parameters.

This is the code
!pip install turicreate
!pip install -y tensorflow
!pip install tensorflow-gpu
import turicreate as tc
tc.config.set_num_gpus(-1)
style = tc.load_images('style')
content = tc.load_images('content')
params = {
'print_loss_breakdown': True,
'content_loss_mult': 1.0,
'style_loss_mult': [ 1e-2, 1e-3, 1e-3, 1e-2],
    'finetune_all_params': True,

    'vgg16_content_loss_layer': 2,
  'use_augmentation': True, #'aug_pca_noise' : 0.5,

    'input_shape': (256, 256),'batch_size': 1,
   'pretrained_weights' : True
}

model = tc.style_transfer.create(style, content, max_iterations = 50000, _advanced_parameters=params)
The above code - minus the tensorflowGPU (instead i used !pip uninstall -y mxnet
!pip install mxnet-cu100==1.4.0.post0) would work fine on v5.8 - and i can fully customise the parameters.
So in summary

AMD GPU does not work
Parameters are not being utilised.

Has the parameters code changed some how?
Thanks

@saddif - Thanks for the great summary.
It's clear we have an issue with style transfer on macOS with GPU. Related issues: #3036, #3018, #2349, #2392.

Hey Toby, So awesome to be able to run on the Mac GPU! But having similar experience as the related issues.
Steps to build...
python3 -m venv p3env
cd p3env/bin/
source activate
pip install notebook
pip install -U turicreate
pip uninstall -y tensor-flow
pip install tensorflow-gpu (caused errors)
pip uninstall -y tensorflow-gpu
pip install tensorflow (worked!)
jupyter notebook
(over to jupyter in the browser)
import turicreate as tc
tc.config.set_num_gpus(-1)
style = tc.load_images('/Users/computer/style/')
content = tc.load_images('/Users/computer/train/')
model = tc.style_transfer.create(style, content, max_iterations=20000)
Using 'image' in style_dataset as feature column and using 'image' in content_dataset as feature column
Using GPU ("AMD Radeon Pro Vega 20") to create model.
+--------------+--------------+--------------+
| Iteration    | Loss         | Elapsed Time |
+--------------+--------------+--------------+
| 1            | 103.05       | 821.416ms    |
| 2            | 40.5286      | 1.26s        |
| 3            | 155.076      | 1.76s        |
...
| 19961        | 5.15211      | 3h 0m        |
| 19971        | 42.4333      | 3h 0m        |
| 19981        | 2.74253      | 3h 1m        |
| 19991        | 4.95479      | 3h 1m        |
| 20000        | 0.850161     | 3h 1m        |
+--------------+--------------+--------------+
model.save('/Users/computer/turicreate/save')
Image used in example
JPEG image - 160 KB
Dimensions: 1000 × 667
Various JPEG Style images used to train
Approximately 623 KB - 1.5 MB
Dimensions: 3840 × 2160
Various JPEG Images used during training
Approximately 48 KB - 8 MB (average was 1.2 MB)
Dimensions: 300 X 300 to 6000 × 4000 (average was 3264 × 2448)
Previously months ago with TuriCreate and MXnet @ 10,000 iterations on Linux GPU with CUDA 8 did a good job for me. Maybe we need to run more iterations for AMD on Mac. Will keep trying various things and watching for any changes to TuriCreate.

@TobyRoseman Thanks for the reply.
Just wondering if you know how to fix the advanced parameters issues (i.e. style loss and other advanced parameters not being utilised to train the model) when using Nvidia GPU on Google Colabs (using tensorflow-gpu). Has this issue popped up before?
@robertallenmartin - i have gone up to 40,000 iterations on the Mac AMD GPU - no improvement from the 10,000 iterations unfortunately.
Thanks for all the great work on this!

Hi, Just wondering if there has been any updates on being able to use the advanced parameters to fine tune the style transfer in V6.3?
@robertallenmartin - you posted a video (rather than a photo) which had style transfer applied to it  #3186 -just wondering what you used to make that? It looks amazing Thanks

@TobyRoseman
some extra bits of info that might help - using Google Colabs
i downgraded the CUDA to V10.0
I installed CuDNN V7.4.1
then did this:
!pip uninstall -y tensorflow
!pip uninstall -y tensorflow_gpu
!pip install tensorflow-gpu==1.14.0
And when checking if GPU is working with
import tensorflow as tf
print(tf.test.is_gpu_available())
print(tf.config.experimental.list_physical_devices(device_type=None))
the output is:
True
[PhysicalDevice(name='/physical_device:CPU:0', device_type='CPU'), PhysicalDevice(name='/physical_device:XLA_CPU:0', device_type='XLA_CPU'), PhysicalDevice(name='/physical_device:XLA_GPU:0', device_type='XLA_GPU'), PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]
however if i check using this command:
print(tf.config.list_physical_devices('GPU'))
i get an error AttributeError: module 'tensorflow._api.v1.config' has no attribute 'list_physical_devices'
If i then install turicreate - pip install turicreate and then rerun the GPU-checking command i get FALSE
If i reinstall tensorflow_GPU 1.14 (and uninstall tensorflow) - i then get TRUE
now when i try to run a model using GPU i get the following error
RuntimeError                              Traceback (most recent call last)
/usr/local/lib/python3.7/dist-packages/turicreate/extensions.py in __run_class_function(self, fnname, args, kwargs)
289         try:
--> 290             ret = self._tkclass.call_function(fnname, argument_dict)
291         except RuntimeError as exc:
cy_model.pyx in turicreate._cython.cy_model.UnityModel.call_function()
cy_model.pyx in turicreate._cython.cy_model.UnityModel.call_function()
RuntimeError: An error occurred: AttributeError: module 'tensorflow._api.v1.config' has no attribute 'list_physical_devices'
Hope that can help with diagnosing the problem

TuriCreate doesn't work with TensorFlow 1.x. It's uses TensorFlow 2.x.
See our instructions for Linux GPU support. Start with a new environment and install TuriCreate. Take note which version of TensorFlow get installed. Then uninstall TensorFlow. Then install that same version of tensorflow-gpu. Also make sure your versions of CUDA and CuDNN are compatible with that version of tensorflow-gpu.


Mosquitto module prohibits some configurations

Describe the bug
The mosquitto module has multiple problems:

It changes the mosquitto default persistence to true, without documenting it or making it configurable
It uses the now deprecated bind_address and port options
Its ssl part is not able to bind to ipv4 and ipv6 simultaniously (workaround: configuring manually via extraConf)
Its main listener cannot bind to ipv4 and ipv6 simultaniously (workaround: configure it on an unused port and configure another listerner manually via extraConf)
It does not play well with per_listener_settings, as it configures options, that could be specific per listener

Concerning no 1.: This one is open for debate. Personally i find this kind of hidden behaviour to be one of the biggerst downsides of nixos. It is a pitfall for all new users of this module, as mosquitto has the opposite default. Now we are in a bad situation: Either we break expectations for new users by leaving the default as is, or we break expectations of the current users, by changing it and aligning it with the package default.
Concerning no 2.: This alone means, that a good part of the module needs to be redone, wich is a very good time to also address no. 3 and no. 4, as these all have to do with the listener configuration.
Concerning no 5.: This one also is a big one. The per_listener_settings option changes the semantics of a lot of options of mosquitto. The easiest solution to this is simply avoiding the topic by not lifting any of the mosqitto options in question to the nixos module and solely relying on the extraConfig option in nixos. This is probably the best solution for most of the options but does not allow for any higlevel configuration of these options (like done with services.mosquitto.checkPasswords).
My proposed solution

Remove services.mosquitto.host
Remove services.mosquitto.port
Remove services.mosquitto.ssl
Remove services.mosquitto.allowAnonymous
Remove services.mosquitto.checkPasswords
Add a services.mosquitto.listeners option with type list of submodules
Add a services.mosquitto.listeners.*.host option with type null or string with default null
Add a services.mosquitto.listeners.*.port option with type unsingned integer with default 1883
Add a services.mosquitto.listeners.*.extraConfig option with type strings concatenated with "\n" with default ""
Remove persistence true from the generated configuration

With this aproach we can maintain a secure and less open default, simply by reacting on if the services.mosquitto.listeners is an empty list. Also the listeners can be configured more freely because of the services.mosquitto.listeners.*.extraConfig.
The biggest problem i see with this is the password_file option. At the moment it is generated whenever the services.mosquitto.checkPasswords option is set. The problem with that is, that the  per_listener_settings options changes the semantics of a lot of mosquitto options including the password_file option. When someone enables per_listener_settings, it is no longer sufficient to have a single services.mosquitto.checkPasswords option, but you would need one option per listener to be able to describe the same data, that you can natively describe in the config file. Indeed that would also not be enough either, because all password_file options for the different listeners could point to different files.
I would love to see a solution, that allows these kind of setups and also does not leave any nixos options, that simply do not work any longer, when you enable per_listener_settings. Maybe lifting per_listener_settings to a nixos option and then asserting the heck out of it could work, but it simply feels not right. Also removing the generation of password files seems like a compomise to me. I am actually quite uncertain on what to do here.
Please join the discussion on any of the above topics and help me clarify where we are heading. I would simply implement it, if all points would be cristal clear to me, but they aren't (yet).
Notify maintainers
@bjornfor
@Cornu
@felschr
@richardlarocque
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module: nixos/modules/services/networking/mosquitto.nix

I am using mosquitto on a NixOS server. When I migrated that host from Arch (i.e. from mostly upstream configuration files) it was highly confusing that mosquitto wasn't working as expected out-of-the-box. NixOS provides "secure by default" ACLs (which are IMO worthless without also enforcing SSL), which I had to undo by configuring aclExtraConf. I think this should be moved into a recommendedSecuritySettings-Option (this is inspired by the nginx-Module), which I would leave off by default.
Regarding persistence=true: I didn't know this! I just checked and my server is running with persistence enabled in a situation where it is undesirable! I see no reason to change the upstream default at all, or would at least add an option to make this discoverable.
Regarding the listeners: I like your proposed solution. I would add a defaultListener-Option (enabled by default) for simple deployments (this would be the analog to the upstream config file). The existing host- and port-Options could configure that default listener, if there is interest in keeping the options.
Im also not sure how to deal with the breaking changes; I personally think they are justified in this case, but I'm not sure if there is a NixOS policy that would apply here. I would be interested in more maintainer/user feedback.

I am using mosquitto on a NixOS server. When I migrated that host from Arch (i.e. from mostly upstream configuration files) it was highly confusing that mosquitto wasn't working as expected out-of-the-box. NixOS provides "secure by default" ACLs (which are IMO worthless without also enforcing SSL), which I had to undo by configuring aclExtraConf. I think this should be moved into a recommendedSecuritySettings-Option (this is inspired by the nginx-Module), which I would leave off by default.
Regarding persistence=true: I didn't know this! I just checked and my server is running with persistence enabled in a situation where it is undesirable! I see no reason to change the upstream default at all, or would at least add an option to make this discoverable.
Regarding the listeners: I like your proposed solution. I would add a defaultListener-Option (enabled by default) for simple deployments (this would be the analog to the upstream config file). The existing host- and port-Options could configure that default listener, if there is interest in keeping the options.
Im also not sure how to deal with the breaking changes; I personally think they are justified in this case, but I'm not sure if there is a NixOS policy that would apply here. I would be interested in more maintainer/user feedback.

Using settings like options instead of the various "extra" configuration options that exist in the module might alleviate some of these problems.
As far as breaking changes go, if the changes are truly justified and provide large value (which in this case definitely sounds true), providing detailed release notes on how existing users can successfully upgrade is an acceptable solution (usually).
I would encourage you to work on a PR 👍

Using settings like options instead of the various "extra" configuration options that exist in the module might alleviate some of these problems.
As far as breaking changes go, if the changes are truly justified and provide large value (which in this case definitely sounds true), providing detailed release notes on how existing users can successfully upgrade is an acceptable solution (usually).
I would encourage you to work on a PR 👍

Relevant: https://github.com/NixOS/nixpkgs/pull/110863

Relevant: https://github.com/NixOS/nixpkgs/pull/110863


App doesn't see added displays while connected to RDP. Functionality works, but they don't show up.

When connected via RDP, it will appear as though the "Add Display" button does nothing, but it does actually add the display and it shows up when connecting to a normal session afterwards.
My understanding is that the display APIs act weird when RDP is in the mix, so I don't know if this is even properly "fixable", however, maybe an alternative could be showing a count or placeholder image when the button is pressed to indicate something happened.
Tagging:
@hooke-49 @xzhonour @kawanoii @bigruid @yqs112358 (People who posted about the app not working in RDP; it does work, just doesn't provide feedback)
Note: I saw RDP mentioned on the roadmap here: https://github.com/nomi-san/parsec-vdd/issues/71 - however, the title is "Use WinForms tray menu", maybe the wrong issue was linked?
Edit: To clarify, I can open the Parsec VDD app, click "Add Display", use a script to tscon the session to /dest:console and launch Sunshine, then connect just fine. So other than not showing the display in the UI, it fully works from RDP. The basic CLI program isn't affected because it doesn't list current displays, just shows the log of additions and removals.

Thank you so much for detailed feeback. I have added this issue to #71 as a bug and updated the issue mention.


repsonse file option missing?

Which version of the AzCopy was used?
10.2.1
Note: The version is visible when running AzCopy without any argument
Which platform are you using? (ex: Windows, Mac, Linux)
Windows
What command did you run?
azcopy /@c:...\x.responsefile
Note: Please remove the SAS to avoid exposing your credentials. If you cannot remember the exact command, please retrieve it from the beginning of the log file.
What problem was encountered?
The standard help string showed up
How can we reproduce the problem in the simplest way?
Call azcopy with the usual responsefile option
Have you found a mitigation/solution?
No. I can use the command line, but with all those special characters in the SAS, I found it impossible to put it into a batch file

Sorry, found the hint in the documentation. Problem solved.


Introduce schematic to FILL action

Description
This PR wraps triples of "FILL" action inside a schematic key.
Fixes #267
Type of change
Please check the options that are relevant.

[ ] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[x] Refactor
[ ] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change

Type of requested review

[ ] I want a thorough review of the implementation.
[x] I want a high level review.
[ ] I want a deep design review.

Before and After
"fill the swimming pool with water from the hose"
BEFORE:
{'action_sequence': [{'action_type': 'FILL',
                      'reference_object': {'filters': {'triples': [{'obj_text': [0,
                                                                                [2,
                                                                                3]],
                                                                    'pred_text': 'has_name'}]},
                                           'text_span': [0, [2, 3]]},
                      'triples': [{'obj_text': [0, [5, 8]],
                                   'pred_text': 'has_block_type'}]}],
 'dialogue_type': 'HUMAN_GIVE_COMMAND'}

AFTER:
{'action_sequence': [{'action_type': 'FILL',
                      'reference_object': {'filters': {'triples': [{'obj_text': [0,
                                                                                [2,
                                                                                3]],
                                                                    'pred_text': 'has_name'}]},
                                           'text_span': [0, [2, 3]]},
                      'schematics': {'filters': {'triples': [{'obj_text': [0,
                                                                           [5,
                                                                            8]],
                                                              'pred_text': 'has_block_type'}]}}}],
 'dialogue_type': 'HUMAN_GIVE_COMMAND'}

Testing
Tested locally
Checklist:

[x] I have performed manual end-to-end testing of the feature in my environment.
[x] I have added Docstrings and comments to the code.
[ ] I have made changes to existing documentation where needed.
[ ] I have added tests that show that the PR is functional.
[x] New and existing unit tests pass locally with my changes.
[x] I have added relevant collaborators to review the PR before merge.

will fix this in interpreter and then you can push....


Upgrade to React 15

@ajithranka as you're working on https://github.com/osmlab/to-fix/issues/155 can you note here the difficulty of upgrading to React 15?
We want to do this to have compatibility with some of the code already being used in autochethan.

Upgraded to React 15 and ES2015 after PR #160.


Scvi scarches xgb

Submission type

[ ] This submission adds a new dataset
[X] This submission adds a new method
[ ] This submission adds a new metric
[ ] This submission adds a new task
[ ] This submission adds a new Docker image
[ ] This submission fixes a bug (link to related issue: )
[ ] This submission adds a new feature not listed above

Testing

[X] This submission was written on a forked copy of SingleCellOpenProblems
[ ] GitHub Actions "Run Benchmark" tests are passing on this base branch of this pull request (include link to passed test: )
[ ] If this pull request is not ready for review (including passing the "Run Benchmark" tests), I will open this PR as a draft (click on the down arrow next to the "Create Pull Request" button)

Submission guidelines

[X] This submission follows the guidelines in our Contributing document
[X] I have checked to ensure there aren't other open Pull Requests for the same update/change

PR review checklist
This PR will be evaluated on the basis of the following checks:

[X] The task addresses a valid open problem in single-cell analysis
[X] The latest version of master is merged and tested
[X] The methods/metrics are imported to __init__.py and were tested in the pipeline
[X] Method and metric decorators are annotated with paper title, year, author, code version, and date
[ ] The README gives an outline of the methods, metrics and datasets in the folder
[X] The README provides a satisfactory task explanation (for new tasks)
[ ] The sample test data is appropriate to test implementation of all methods and metrics (for new tasks)

Notes:
The following error in label encoding:
Traceback (most recent call last):
  File "/tmp/tmpc7ezwktc/test_method.py", line 31, in <module>
    test_method(*('label_projection', 'scarches_scanvi_xgb_all_genes', 'openproblems-python-scvi'), **{})
  File "/tmp/tmpc7ezwktc/test_method.py", line 12, in test_method
    adata = method(adata, test=True)
  File "/__w/SingleCellOpenProblems/SingleCellOpenProblems/openproblems/tools/decorators.py", line 80, in apply_method
    return func(*args, **kwargs)
  File "/__w/SingleCellOpenProblems/SingleCellOpenProblems/openproblems/tasks/label_projection/methods/scvi_tools.py", line 251, in scarches_scanvi_xgb_all_genes
    adata.obs["labels_pred"] = _scanvi_scarches(
  File "/__w/SingleCellOpenProblems/SingleCellOpenProblems/openproblems/tasks/label_projection/methods/scvi_tools.py", line 152, in _scanvi_scarches
    preds = _pred_xgb(adata, adata_train, adata_test, query_model, test=test)
  File "/__w/SingleCellOpenProblems/SingleCellOpenProblems/openproblems/tasks/label_projection/methods/scvi_tools.py", line 193, in _pred_xgb
    xgbc.fit(X_train, y_train)
  File "/usr/local/lib/python3.8/site-packages/xgboost/core.py", line 532, in inner_f
    return f(**kwargs)
  File "/usr/local/lib/python3.8/site-packages/xgboost/sklearn.py", line 1357, in fit
    raise ValueError(
ValueError: Invalid classes inferred from unique values of `y`.  Expected: [0 1 2 3 4], got ['0' '1' '2' '3' '4']

Tested:

local install of xgboost 1.5.2 and 1.6.1 with different dataset but same prediction function -> works

Todo:

get docker running locally to test the env


New icon needed

Because why tf would you need a penguin, we should make an icon that has more aesthetic appeal.

Never mind, it's iconic by now.


Generic interface

Summary
This PR covers:

updating all blocking code to be async
creating a standard message format between the core library and client libraries
moving all terminal-specific logic and dependencies under mentat/terminal

Things that will be covered in a later PR:

A JSON RPC server with an LSP-compantible API that any editors with language server support can connect to
A SessionManager to coordinate multiple, concurrent chats

To-do

[ ] merge with main and resolve merge conflicts
[ ] validate cprint colors received from core
[ ] check/test for race conditions b/w core and terminal client (specifically w/ inputs and interrupts)
[ ] fix test cases
[ ] create existing test cases

[ ] core library
[ ] terminal client

[ ] fix misc typing errors

I'm confused about why Github is showing a bunch of changes that have already been merged as part of the diff for this PR. Like my change here for PyPI going from mentat-ai to mentat is showing up in this PR:

I added ipdb to requirements.txt

It looks like we lost the call to setup_api_key(), so I added it back in.

ctrl-c while the model is streaming closes mentat completely instead of returning to prompt.
Colors aren't working for me in streamed output removal. e.g. see the following conversation with coloring symbols instead of colors:
When mentat encounters an error e.g. the model doesn't correctly respond with line numbers then mentat starts streaming all the logs to stdout. Not sure if that's the intended behavior.

I'm setting the same errors as @jakethekoenig. I also got some logging to the terminal when running a diff:
granthawkins@Grants-MacBook-Air mentat % mentat --diff HEAD~1
Diff annotations:
 ─•─ HEAD~1: a3063419: Fix logging config git conflict token | 2 files | 1 lines

DEBUG:root:Skipping /Users/granthawkins/mentat/.gitignore. Reason: lexer not found
Files included in context:
mentat
├── * .gitignore
└── mentat
    └── session.py
INFO:root:StreamMessage(id=UUID('71ba8857-3bb6-466f-9411-b3dce0a2d980'), channel='default', source=<StreamMessageSource.SERVER: 'server'>, data='\nIncluding CodeMap (filepaths only)', extra={'color': 'green'}, created_at=datetime.datetime(2023, 9, 28, 23, 31, 2, 618374))
INFO:root:StreamMessage(id=UUID('9651a3bf-e483-48da-8ca7-23c6a84470be'), channel='default', source=<StreamMessageSource.SERVER: 'server'>, data='File and prompt token count: 5979 / 8192', extra={'color': 'cyan'}, created_at=datetime.datetime(2023, 9, 28, 23, 31, 2, 621870))
INFO:root:StreamMessage(id=UUID('470117d2-e6c3-43e5-a705-672a525a62b0'), channel='default', source=<StreamMessageSource.SERVER: 'server'>, data="Type 'q' or use Ctrl-C to quit at any time.", extra={'color': 'cyan'}, created_at=datetime.datetime(2023, 9, 28, 23, 31, 2, 621913))
INFO:root:StreamMessage(id=UUID('d3598fd7-8925-4043-a805-c6fcc927b09d'), channel='default', source=<StreamMessageSource.SERVER: 'server'>, data='What can I do for you?', extra={'color': 'light_blue'}, created_at=datetime.datetime(2023, 9, 28, 23, 31, 2, 621932))
INFO:root:StreamMessage(id=UUID('a3f188bb-aabb-437b-96e2-7e58550f218f'), channel='input_request', source=<StreamMessageSource.SERVER: 'server'>, data='', extra={}, created_at=datetime.datetime(2023, 9, 28, 23, 31, 2, 621953))

Including CodeMap (filepaths only)
File and prompt token count: 5979 / 8192
Type 'q' or use Ctrl-C to quit at any time.
What can I do for you?

Thanks for all of the comments everyone! I'm going to close and re-open this PR in an effort to get Github to show the proper git history (this might not be a github thing but we'll quickly find out lol).


Improve Site build times with cached includes

:wave: Michael
Did you know that you can cache rendered outputs from stateless includes and improve your build times with a plugin..?
The plugin is called jekyll-include-cache and is whitelisted for use at GHP
(just not bundled by default, since its dangerous for novices)
The plugin can be used to cache any "include" that does not change its output from page-to-page.
Such includes can simply be plain HTML without any Liquid or an include that only references the global constant {{ site }} e.g., src/_includes/footer.html
I did not submit a PR because I thought I'd gather your feedback first and allow you to implement it first-hand so that you know where it can be used and where it should not be used..
Results from --profile on my system show that you may be able to shave of ~15 seconds but I may be wrong..

Nice! I definitely have a few includes that could benefit from this. Will have to give it a try.
Not sure of the impact it'll have. Most of my build times are stuck building tons of paginated tag/category pages with the jekyll-paginate-v2 plugin.

Not sure of the impact it'll have

I'm guessing at most 15-20s.. Also, you can gain more time by avoiding unnecessary fragmentation.
For example, inserting the contents of related.html include into post layout will free Jekyll from having to parse and render the include each time the post layout is rendered (exactly 1002 times according to output from --profile)
Of course, the above observation would be futile if related.html was being included in more than one layout.


Update main.tf

Update cloudposse modules: terraform-null-label and route53 versions in order to support terraform 0.13

/test all


Unify example dataset in configs

We use alpaca cleaned and alpaca. Should just use one for our example datasets.

There are memory and perf implications with using one or the other, I think some were purposely set to cleaned or normal alpaca but not sure, cc @rohan-varma

I think @ebsmothers has more context on this, IIUC some were set to clean when we were trying to replicate existing studies.

Personally I would just recommend making cleaned the default as that's what most folks seem to have converged on


easy response types

What if the server's response isn't the content-type you were expecting? What if you want to check the content-type before you wade into the body? Right now you have to muck about in the headers manually to be sure, worrying about incidentals like "; charset=UTF-8".
It would be really convenient if responses had a simple type property set to "json", "multipart", or "xml". It would also be convenient to have an option when the request goes out to only bother parsing the correct content-type and pass errors otherhow.

I'm not sure what you mean. You'd like Needle's responses to contain a .type property set to the header's Content-Type?

yes, with any additional information scraped off. Since you're reading the
content-type and parsing the body selectively by type, I imagine there's a
convenient place in the code to save this handy property onto the response.
And when it gets saved, there's probably no need to save
"application/json" when just "json" will do.
On Wed, Jan 28, 2015 at 4:08 AM, Tomás Pollak<EMAIL_ADDRESS>wrote:

I'm not sure what you mean. You'd like Needle's responses to contain a
.type property set to the header's Content-Type?
—
Reply to this email directly or view it on GitHub
https://github.com/tomas/needle/issues/95#issuecomment-71825255.

Sounds like a good idea, but I think there are many cases in which the dev wouldn't know what to expect. For example, what do the following content types map to?
'application/octet-stream' # data?
'application/atom+xml' # atom or xml?
'application/font-woff' # font or woff?

I think it would be clearer for everyone to use the regular Content-Type. We could, though, include a response.json = true or response.xml = true whenever one of those parsers come into action. This would let you do:
if (response.json)
  console.log('JSON')
else if (response.xml)
  console.log('XML')
else if (response.type.match(/text/)
  console.log('Text response')
else
  console.log('Binary data')

Yeah, I like that idea: standard Content-Type and boolean props for the common parsers. And like I said initially, it would be nice to avoid parsing anything I'm not expecting with a request option.
needle.get (
  resourcePath,
  { contentType:'application/json' },
  function (err, response) {
    // if there's no err, we got json
  }
);

Ok mister, just landed in c3cd16ea2077b872a00c8f7a90b267543718316c. Needle's responses will now contain a parser property that can be either json or xml if one of those parsers was used. If parsing fails for any reason, the property will not be there.
If not using callback, the returned stream will also contain the parser property, however in that case it may occur that the parsing fails and the resulting data is not an object as you would expect.
As for the "don't parse stuff I'm not interested in", I think it makes sense to map it some way to the accept option. Eg. if you say: accept: application/json only application/json responses will be parsed -- but it's not as simple as it sounds, though. What happens if one accepts application/xml but the server replies with test/xml?

That all sounds great. I like the idea of using the accept option except that it's not a desirable behavior in all cases, so maybe a Boolean option to turn it on. restrictType:true or something. You could potentially go with strict:true as a general Boolean for turning all response filters on and off, if you can see yourself thinking up more response filters.

What about simply passing { parse: 'application/json' } instead of true?
And why wouldn't you want to parse other content types, by the way?

Your second question made me realize my first answer doesn't address my own situation. A String parse property is actually necessary but it should accept the same Strings held in the new parser property and not proper content types. My specific example would be { accept:'application/schema+json', parse:'json' }.

re: why, my JSON Schema validator is designed to handle foreign schemata which may be incorrect or even hostile. I don't want it wasting cpu resources parsing a bad response.

Makes sense. Now with the new parser property this should be trivial. A beer or two tonight might pull the trick.

Thanks, enjoy!

Took a bit longer than expected, but 7380884 makes the parse/parse_response option accept 'json' or 'xml'.
Sidenote: I think this is the first time I've seen a fully numeric short commit hash. Will this break Github? hehe

Righteous. Thanks for staying on it.


Could you please add the EWelink Smart Wifi Switch Relay Module Timer DC 5 B/12 B/24 B/32  to your component ? ?

Hi Alex,
For your reference:
https://aliexpress.ru/i/33027260480.html
It seems to be a TISHRIC TSR620/DC
Sonoff cloud info about is:
"1000926297":{"settings":{"opsNotify":0,"opsHistory":1,"alarmNotify":1,"wxAlarmNotify":0,"wxOpsNotify":0,"wxDoorbellNotify":0},"group":"","online":true,"shareUsersInfo":[],"groups":[],"devGroups":[],"_id":"5d84c2daa4285d754675c139","name":"SW_Puerta_Calle","type":"10","deviceid":"1000926297","apikey":"23effe28-d521-4d8f-8a79-e23c97e5c9d9","extra":{"extra":{"uiid":6,"description":"20190516002","brandId":"5735f5f906d9751d4f109629","apmac":"d0:27:01:24:c2:7f","mac":"d0:27:01:24:c2:7e","ui":"单通道开关","modelInfo":"589833ac2f979b623e2f503f","model":"PSF-B01-GL","manufacturer":"郑州市中原区汇诚电子材料经营部","staMac":"60:01:94:D5:BC:41","chipid":"00D5BC41"},"_id":"5cdd2fbb211f3b10753dee66"},"params":{"bindInfos":{"alexa":["621f7a3a-6015-449f-a4ae-9d7403cdc5bc_26ca1996a20e8bd63617ab272d4eeede1d2d8e32"]},"sledOnline":"on","switch":"off","fwVersion":"3.4.0","rssi":-86,"staMac":"60:01:94:D5:BC:41","startup":"off","init":1,"pulse":"off","pulseWidth":500,"version":8},"createdAt":"2019-09-20T12:15:22.938Z","__v":0,"onlineTime":"2020-05-01T07:15:33.008Z","ip":"<IP_ADDRESS>","location":"","offlineTime":"2020-05-01T07:14:51.754Z","tags":{"m_c9d9_jime":"on"},"devicekey":"621f7a3a-6015-449f-a4ae-9d7403cdc5bc","deviceUrl":"","brandName":"New Smart ","showBrand":true,"brandLogoUrl":"","productModel":"G1","devConfig":{},"uiid":6},
Alternatively if you give some hint I can look to the code and try a contribution on my own. I look to your code and looks pretty well organized and done. Only issue is that my russian is really poor, not more of 10-15 words after 10y travelling frequently to Moscow for work.

Apologies, it work fine. My fault.


NIFI-12967: Introducing Back action

NIFI-12967:

Adding support for navigating back to the users previous location in certain circumstances like going to a Controller Service, managing access policies, going to parameters, viewing documentation, opening advanced UIs, and viewing data provenance.
Cleaning unnecessary instances of postUpdateNavigation.

The scenarios mentioned in the commit message above have a slightly different UX from the existing application. In the old UI, these actions would open in a large modal on top of the current component. When the user was done they could return to where they were by closing the modal. In the new UI, the user currently needs to use their browser back button as the application did not directly offer a back option. This PR introduces that back option but only in the cases identified above. Scenarios outside of this (other links in the application like Referencing Components) are not included here but could be considered in the future as a further improvement over the old UI.

reviewing...


how to transform from pixel coordinate to world coordinate?

Hi,
I have some points in the pixel coordinate frame (for example locations and orientations of cars in the scene) and want to transform it into the world frame. I see that you have location_to_pixel() and apply_agent_following_transformation_to_masks() functions to do it in the other direction (world to pixel). Can you help me to do the inverse?
Thanks

@kargarisaac Hi, sorry for such a huge delay in reponse :(
I rotated the car on purpose to show you that agent's yaw (relative to the map) is important to properly compute the final carla.Location:

Point O is the agent's location on birdview (which is always in the middle of an image), but at the same time we know his carla.Location which is agent_vehicle_loc:
https://github.com/deepsense-ai/carla-birdeye-view/blob/f666b0f5c11e9a3eb29ea2f9465d6b5526ab1ae0/carla_birdeye_view/__init__.py#L238-L240
Output array produced by BirdViewProducer has:

h = DEFAULT_HEIGHT # 336
w = DEFAULT_WIDTH # 150
pixels_per_meter = 4
https://github.com/deepsense-ai/carla-birdeye-view/blob/f666b0f5c11e9a3eb29ea2f9465d6b5526ab1ae0/carla_birdeye_view/__main__.py#L46-L52

O = (h/2, w/2) (in pixels)
Let's say you want to know carla.Location for pixel at X = (20, 10).
We know that b = h/2 - 20 and a = w/2 - 10, then c = sqrt(a**2 + b**2) (in pixels).
So X is radius = c / pixels_per_meter  meters away from point O (in CARLA world).
At this point we know that our X lies somewhere on a circle with radius.
The only thing that now we need is to consider current yaw of the agent's vehicle transform using: agent_transform.rotation.yaw
I hope this will do the job. Once again, sorry for not responding so long.  I'm planning to focus a bit more on maintaining my stuff 😛.
If you're still doing something fun with this package, feel free to submit a PR with some new feature.

@kargarisaac Hi, sorry for such a huge delay in reponse :(
I rotated the car on purpose to show you that agent's yaw (relative to the map) is important to properly compute the final carla.Location:

Point O is the agent's location on birdview (which is always in the middle of an image), but at the same time we know his carla.Location which is agent_vehicle_loc:
https://github.com/deepsense-ai/carla-birdeye-view/blob/f666b0f5c11e9a3eb29ea2f9465d6b5526ab1ae0/carla_birdeye_view/__init__.py#L238-L240
Output array produced by BirdViewProducer has:

h = DEFAULT_HEIGHT # 336
w = DEFAULT_WIDTH # 150
pixels_per_meter = 4
https://github.com/deepsense-ai/carla-birdeye-view/blob/f666b0f5c11e9a3eb29ea2f9465d6b5526ab1ae0/carla_birdeye_view/__main__.py#L46-L52

O = (h/2, w/2) (in pixels)
Let's say you want to know carla.Location for pixel at X = (20, 10).
We know that b = h/2 - 20 and a = w/2 - 10, then c = sqrt(a**2 + b**2) (in pixels).
So X is radius = c / pixels_per_meter  meters away from point O (in CARLA world).
At this point we know that our X lies somewhere on a circle with radius.
The only thing that now we need is to consider current yaw of the agent's vehicle transform using: agent_transform.rotation.yaw
I hope this will do the job. Once again, sorry for not responding so long.  I'm planning to focus a bit more on maintaining my stuff 😛.
If you're still doing something fun with this package, feel free to submit a PR with some new feature.

I'll commit this utility method at some point

I'll commit this utility method at some point


fix(tap-agent): unaggregated_fees metric last RAV

The Unaggregated fees metric was not updating on last RAV.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.01%) to 66.908%

Files with Coverage Reduction
New Missed Lines
%

common/src/tap/checks/deny_list_check.rs
1
93.64%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
3878

Relevant Lines:
5796

💛  - Coveralls


Change name of built source file in /dist folder

Should be azure-mobile-apps-client.js and .min.js

Noted.

https://github.com/Azure/azure-mobile-apps-js-client/pull/210 closes https://github.com/Azure/azure-mobile-apps-js-client/issues/182


Release v0.8.1

Primary interest is pulling in bugfix #22 from commit bfd0a93
Changes since v0.8.0
dc77af4 Prepare for v0.8.2 development
45450c0 Release v0.8.1
a150fee Merge pull request #23 from ghaskins/issue22-fix
b4bb0cd Merge pull request #20 from ghaskins/v0.8.0-proposal
bfd0a93 Allow zero length args in the golang stub to accommodate parameterless functions
cd2c99b Merge pull request #19 from christo4ferris/fix-default-loc
447fb66 Prepare for v0.8.1 development
5cf118a add build artifacts to .gitignore
5c78194 Merge pull request #17 from ghaskins/parameterless-example

Signed-off-by: Greg Haskins<EMAIL_ADDRESS>

thanks @ghaskins , merged


Exceptions or return codes

Is there any example how I can get exception messages?
How can I detect in my code that the parsing did not work because of wrong css?
I use the first Example - neded exactly this - but with wrong css it gives me an empty result but no error.
any hints?

It’s not currently possible to do what you want. You can:

Either use lenient mode (default), in which errors are silently ignored
Or use strict parsing, which throws a UnexpectedTokenException on the first error it encounters.

I agree, though, that a modus operandi that logs errors but does not choke on them could be useful for certain scenarios.

right - this would be nice
now I help myself counting the Declaration Blocks like this:
		$oParser = new \Sabberworm\CSS\Parser($css);
		$oCss = $oParser->parse();
		$decBlocks = $oCss->getAllDeclarationBlocks();
		if(count($decBlocks) > 0){
                         OK - go n
                    }

should work...
BTW: thanks for sharing this software

Adding to the exception handling, I think it would be nice to provide the selector that the error occurred in for the exception message. For instance, on UnexpectedTokenExceptions you get something like:
Identifier expected. Got “/\00a”

Which can be difficult to debug to a user.


UploadFile decorator makes return value of original method undefined.

Is there an existing issue for this?

[X] I have searched the existing issues

Current behavior
Inside UploadFile decorator Multer is used and required. the descriptor.value is assigned to a function as follows
 descriptor.value = function (...args: Array<any>): any {
      const req = args[0] as Request;
      const res = args[1] as Response;
      // const next = args[2] as NextFunction;

      const multerMiddleware: RequestHandler = getMulterMiddleware(upload, options, method);
      multerMiddleware(req, res, (err: any) => {
        if (err) {
          return res.status(400).json({ error: err.message });
        }
        return originalMethod.apply(this, args);
      });
    };

due to the asynchronous nature of the multerMiddleware the value that is returned is undefined because the descriptor.value is completed before the callback excuted, thus results in undefined return.
Steps to reproduce

Create new project using the CLI.
Use the FileUpload Decorator and return something from the controller function as following

@Post("/")
    @FileUpload({ fieldName: "file" })
    execute() {
        return { message: "success" };
    }

this will hang the response and cause a timeout.
Expected behavior
It should allow to send the return of the function to the client without explicitly using res.send or its equivelent to stay consistent with the overall implementation of the framework.
Package version
1.81
Node.js version
20.14.0
In which operating systems have you tested?

[ ] macOS
[ ] Windows
[X] Linux

Other
No response

@rsaz Just two notes which kind of relates to this issue and the solution at PR #114, first is that the value of originalMethod will be undefined still because of the same problem mentioned in this issue the asynchronus nature of MulterMiddleware  you can log it at the handleFactory method
 const value = await (controller[key] as ControllerHandler)(...args); // whatever the value of the method is
 // it becomes undefined if the FileUpload decorator is used.
console.log(value);

So I dont know if this is gonna cause issues in the future.
Secondly, if a user returns undefined  the request hangs and never sends back a response, because of this != "undefined" check here
if (
         res &&
         result &&
         typeof result != "undefined" &&
         !isRequest(result) &&
         !isResponse(result)
       ) {
         return res.send(result);
       }

usually when undefined is returned a response with no body is returned to client, or transformed into a 204 no content response.
These are 2 points to consider so to make sure unexpected behaviors does not happen.

In the version v.3.0.0 this issue was analyzed. There is just one point missing in your example above,
@Post("/")
    @FileUpload({ fieldName: "file" })
    execute() {
        return { message: "success" };
    }

If you want to have your file upload you need to specify a folder:
    @Get("/")
    @FileUpload({ fieldName: "file" }, { dest: "uploads" })
    async execute() {
        return { message: "success" };
    }

Now you can return anything, a string, an object, using the res object or not, simple return, the controller will handle it, it will return the content to the user as res.send by default.


generate a FISH-1 form

As a fisherman I want to be able to generate a FISH-1 form for submission to the Fisheries Office

Must


Thread Sanitizer Data race in [GDTCCTUploadOperation finishOperation]

I've just ran my code trough Thread Sanitizer and got report for data race in GDTCCTUploadOperation
We use the following Pods
  pod 'Firebase/Core'
  pod 'Firebase/Performance'
  pod 'Firebase/Messaging'
  pod 'Firebase/Analytics'
  pod 'Firebase/Crashlytics'

Already updated to latest versions:
Installing Firebase 7.9.0 (was 7.8.1)
Installing FirebaseABTesting 7.9.0 (was 7.8.0)
Installing FirebaseAnalytics 7.9.0 (was 7.8.1)
Installing FirebaseCore 7.9.0 (was 7.8.0)
Installing FirebaseCoreDiagnostics 7.9.0 (was 7.8.0)
Installing FirebaseCrashlytics 7.9.0 (was 7.8.0)
Installing FirebaseInstallations 7.9.0 (was 7.8.0)
Installing FirebaseInstanceID 7.9.0 (was 7.8.0)
Installing FirebaseMessaging 7.9.0 (was 7.8.0)
Installing FirebasePerformance 7.9.0 (was 7.8.0)
Installing FirebaseRemoteConfig 7.9.0 (was 7.8.0)
Installing GoogleAppMeasurement 7.9.0 (was 7.8.1)

In code we have custom Crashlytics logs and custom analytics event and screen tracking.
The project uses Swift + SwiftUI and targets iOS 14.
The issue has been detected on iOS 14 Simulator.
Console output:
WARNING: ThreadSanitizer: data race (pid=72528)
  Write of size 1 at 0x7b44000901f9 by thread T18:
    #0 -[GDTCCTUploadOperation finishOperation] GDTCCTUploadOperation.m:508 (GoogleDataTransport:x86_64+0x11821)
    #1 __53-[GDTCCTUploadOperation uploadTarget:withConditions:]_block_invoke.72 GDTCCTUploadOperation.m:184 (GoogleDataTransport:x86_64+0xccdf)
    #2 __44-[FBLPromise(CatchAdditions) onQueue:catch:]_block_invoke FBLPromise+Catch.m:34 (FBLPromises:x86_64+0xbf1e)
    #3 __56-[FBLPromise chainOnQueue:chainedFulfill:chainedReject:]_block_invoke.68 FBLPromise.m:277 (FBLPromises:x86_64+0x2378f)
    #4 __44-[FBLPromise observeOnQueue:fulfill:reject:]_block_invoke_2 FBLPromise.m:229 (FBLPromises:x86_64+0x22738)
    #5 __wrap_dispatch_group_async_block_invoke <null>:2 (libclang_rt.tsan_iossim_dynamic.dylib:x86_64+0x71c37)
    #6 _dispatch_client_callout <null>:2 (libdispatch.dylib:x86_64+0x39c7)

  Previous read of size 1 at 0x7b44000901f9 by thread T16:
    #0 -[GDTCCTUploadOperation isFinished] GDTCCTUploadOperation.m:489 (GoogleDataTransport:x86_64+0x11cec)
    #1 __NSOQSchedule_f <null>:2 (Foundation:x86_64+0xddcee)
    #2 _dispatch_client_callout <null>:2 (libdispatch.dylib:x86_64+0x39c7)

  Location is heap block of size 320 at 0x7b4400090100 allocated by thread T16:
    #0 calloc <null>:2 (libclang_rt.tsan_iossim_dynamic.dylib:x86_64+0x4f072)
    #1 _objc_rootAllocWithZone <null>:2 (libobjc.A.dylib:x86_64+0x16a99)
    #2 __52-[GDTCORUploadCoordinator uploadTargets:conditions:]_block_invoke GDTCORUploadCoordinator.m:112 (GoogleDataTransport:x86_64+0x4352b)
    #3 __tsan::invoke_and_release_block(void*) <null>:2 (libclang_rt.tsan_iossim_dynamic.dylib:x86_64+0x70ebb)
    #4 _dispatch_client_callout <null>:2 (libdispatch.dylib:x86_64+0x39c7)

  Thread T18 (tid=3005412, running) is a GCD worker thread

  Thread T16 (tid=3004697, running) is a GCD worker thread

SUMMARY: ThreadSanitizer: data race GDTCCTUploadOperation.m:508 in -[GDTCCTUploadOperation finishOperation]

Screenshots:

Thanks for the report. These should be fixed by #11 and we'll see if we can publish an update in the next few days.

The should be fixed in GoogleDataTransport 8.3.1. Please try to update and let us know if you still have the issue.

Thanks for the update, it appears to be fixed.


HTML renderer doesn't ignore unknown tags' contents

tagsouppullparser translates <bogus>contents</bogus> into three events:

START_TAG with text "bogus";
TEXT with text "contents";
END_TAG with text "bogus".

htmlrenderer doesn't know a tag named "bogus", to it skips over it, but doesn't fast-forward to a matching closing tag. This leads to "contents" appearing in renderer's output (the closing tag is unknown and is thus ignored.)
I believe this is in violation of HTML spec, which IIRC specifies that tags unknown to parser should be ignored as well as their contents.
TODO:

[ ] check if HTML spec does say what I recall it says; close the issue if I'm wrong
[ ] check what other HTML 4 and HTML 5 tags we aren't supporting at the moment
[ ] try to estimate if we'll break a lot of stuff if we start ignoring tags. What if someone has their site in pre-standardization HTML5, is it likely we'll break anything essential?

I think the the contents of an unknown tag should be rendered.
Looking for evidence, I searched the HTML specs, but surprisingly I couldn't find anything. According to this guy on stackexchange the HTML 2 spec has a section Undeclared Markup Error Handling, which is interpreted and summarized by him as follows:

This means that unknown tags are ignored. Any data between them is processed normally. That is, the tags are skipped, the (purported) element is not: its content is handled as if the tags were not there. So instead of being treated as inline elements, the constructs were treated as content.

This behavior is also reflected in Firefox and Konqueror, regardless of the doc types. Using this HTML below and adding different doc types resulted in the same output (ignoring the slightly different top margins).

Rendering Test

        <foo>inside unknown tag</foo>
        <bar>
Heading inside unknown tag
</bar>
        <eggs><and><spam>text inside multiple unknown tags</spam></and></eggs>

Firefox renders both without any doc type or the HTML 2 doc type: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

And using

HTML 4 Strict: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> or
XHTML 1.1: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> or
HTML 5: <!DOCTYPE html>

So the contents is always rendered in both Firefox and Konqueror (and in most browsers I reckon). I advocate keeping the rendering in newsbeuter as well. However, as current HTML specs do not cover the topic of unknown tag handling (or hide it extremely well ;-)), this is pretty much undefined behavior, so user agents may deal with that as they wish.


pyqt5: 5.14.2 -> 5.15.1

Update pyqt and sip.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This does not solve https://github.com/NixOS/nixpkgs/issues/99937

This does not solve #99937

It cannot, because qt5 is overridden in pythonInterpreters.

Done in #99956 .


Test & Merge for Release v0.10.2

Description
Test & Merge for Release v0.10.2
Motivation and Context

SCR Fixes
Update Setup Script & Dockerfile
Update CI/CD Workflows
Added Vulnerability Scanning Workflow

Type of Change

fix: A bug fix
chore: Routine tasks, maintenance, or tooling changes
ci: Changes to the CI/CD configuration or scripts

How to Test

Integration Test
Test Models, Datasets, Pipelines & API Connector

Checklist
Please check all the boxes that apply to this pull request using "x":

[x]  I have tested the changes locally and verified that they work as expected.
[x]  I have added or updated the necessary documentation (README, API docs, etc.).
[x]  I have added appropriate unit tests or functional tests for the changes made.
[x]  I have followed the project's coding conventions and style guidelines.
[x]  I have rebased my branch onto the latest commit of the main branch.
[x]  I have squashed or reorganized my commits into logical units.
[x]  I have added any necessary dependencies or packages to the project's build configuration.
[x]  I have performed a self-review of my own code.
[x]  I have read, understood and agree to the Developer Certificate of Origin below, which this project utilises.

Screenshots (if applicable)
[If the changes involve visual modifications, include screenshots or GIFs that demonstrate the changes.]
Additional Notes
[Add any additional information or context that might be relevant to reviewers.]

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
   have the right to submit it under the open source license
   indicated in the file; or

(b) The contribution is based upon previous work that, to the best
   of my knowledge, is covered under an appropriate open source
   license and I have the right under that license to submit that
   work with modifications, whether created in whole or in part
   by me, under the same open source license (unless I am
   permitted to submit under a different license), as indicated
   in the file; or

(c) The contribution was provided directly to me by some other
   person who certified (a), (b) or (c) and I have not modified
   it.

(d) I understand and agree that this project and the contribution
   are public and that a record of the contribution (including all
   personal information I submit with it, including my sign-off) is
   maintained indefinitely and may be redistributed consistent with
   this project or the open source license(s) involved.

Pipeline for Dev Script Passed
Pipeline Testing For Dev Script.zip

Pipeline for Docker Passed
Pipeline Testing For Docker.zip

SCA Workflow still requires some refactoring. Can ignore SCA Failure.


[release-0.45] add the output of 'make generate' command

What this PR does / why we need it:
This adds the output of 'make generate' command.
This is done in order to be able to back-port PRs
to the 'release-0.45' branch in 2022.
Signed-off-by: Orel Misan<EMAIL_ADDRESS>Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/cc @enp0s3

Change: Updated the commit message and PR's description.


Function to update calendar component

I am trying to create filter for the calendar events as well as updating the event details. However, the new update does not reflect directly to the calendar. I need to refresh first in order to see the new updates.
It will be cool if there is a function that when I call it, the web immediately update the calendar component only. As it might be weird if need to refresh the whole page.
Im using the @schedule-x/vue. Hope this can be developed as soon as possible. I really appreciate it.

The configuration object is immutable. You need to use the events service to update events:
https://schedule-x.dev/docs/calendar/plugins/events-service


Run firebase hosting:github

Force complete - npm run deploy doesn't work yet as there isn't any js yet?


better error in .feed method

When a "No possible parsings" error is thrown, now it shows the line
number and column number where the character in question is (instead of
its position in the whole chunk), as well as the content of that line.
Also changed the wording a bit.
Note: As to Line 104, the tailing whitespace was automatically deleted
by my code editor...

Hi! Thanks for contributing.
There appears to be some changes missing here? Unfortunately I don't think we will want to merge this anyway; implementing this efficiently and in an input-agnostic way (Nearley supports custom tokens too!) will be quite subtle.

Very sorry.
I failed to include the "bin/nearley.js" which I had edited when I first commited.
And I then had a struggle with GitHub client. So now there are six commits...
Anyway, you can see my changes in "bin/nearley.js" now.
BTW, I use yarn to manage packages. I added "yarn.lock" in ".gitignore" and accidentally included this change in this RP, too.
Sorry. However, I guess sooner or later "yarn.lock" will be added since yarn is really hot nowadays.

Very sorry but as explained above I don't think we can merge this.
Thank you for your time :)

I don't quite understand you by "input-agnostic way" and "custom tokens".
How are they relative to this issue about lack of info in errors?
Were you really talking about THIS PR of mine exactly?
I am a new comer. Nearley impressed me and I believe it will be very efficient to debug my parser.
I began my learning with testing several lines of lua against the lua.ne. It works well until I added "for i == 2, n do". The "No possible parsings" error occured.
It simply shown me ONE character and its position in the chunk (as a whole bulk of string!).
That unfriendly error dampened my enthusiasm.
I don't like what I imagined: days later, when I deal with many lines of text, I get such a simple error which can help me very little to find out where the hell that character in question is!
I think the deficiency would trouble many users like me, so my improvement can be rather a necesity.
Why decline my PR and keep the errors as bad as they used to be?

I'm very glad you like Nearley, and thank you for contributing :) I'll try and explain my concerns more fully.
Nearley doesn't require your input to be a string; you can give feed() a list of token objects, for example. So looking for newlines in this way won't work for everyone.
We do agree that the error messages need improving! (See #188.) But line numbers are probably something we should handle at an earlier tokenization stage, not in the Earley parser itself.
I hope that helps explain things. Sorry for the confusion :)

I see.
I may come back to this topic when I learn more about other kinds of input to feed().

"line numbers are probably something we should handle at an earlier tokenization stage"

Does that mean someday there can be a solution out-of-box for new comers like me? Or Nearley will never have line number feature?

Does that mean someday there can be a solution out-of-box for new comers like me?

Yes, have a look at #188—we're planning for nearleyc errors to include line numbers.

Great!

Just wanted to weigh in — I'm glad you are enjoying nearley, and I thank you very much for contributing. As Tim said, we're working on implementing this functionality in a more general, robust way. Until then, keep in mind that you can convert the "offset" of the character to a line number pretty easily yourself! :-)

Thanks for your additional feedback.
My improvement works well for me so far and thus I will keep it for myself.
Still, looking forwards to your official solutions.