Twig imports broken

I'm on Sculpin v2.0.0-46-g0862cc9. I've been trying to import macros from another Twig source (_views/macros.twig) with no luck. I pulled these macros from my library of macros that I use in most of my Twig projects. I initially thought that it might have been a problem with one or more of my macros, but I'm now down to just:
{% macro tag(name) %}
{{ name }}
{% endmacro %}

{% import 'macros' as macros %} results in no apparent changes to the Twig context.
{% from 'macros' import tag %} results in tag being null in the Twig context.
No matter what, I seem unable to import anything from an external source. I've come across two places demonstrating successful imports, but I tried them myself with no joy. Am I doing something wrong, or is this actually broken?

Hi there. I've had a few issues with this myself, I'm not sure what the exact cause is. A few things to try:

Declare the import at the top of each page or post the macro will be used on
Use the full name for the macros file (either macros.twig or even _views/macros.twig)
Declare the macro within the page and then use the self-importing notation to try and get it working

It's possible that something is pointed the wrong way in Sculpin's twig configuration w/r/t inheritance of macros, as I had a problem with importing a macro in a layout file & having it available in posts. This might be a recent change to Twig itself, however.

The import is presently declared at the top of the only file in which the macro is used.
The FlexibleExtensionFilesystemLoader throws an exception when it can't find the file in question, so it's most certainly not a file-loading issue. That said, attempting to load anything other than macros results in an exception.
Importing _self does not work.

I'm diving into the source now, but I'm unfamiliar with Sculpin under the hood, so it'll take me a bit to track this down.

OK, I just did a test run with a complete clean slate and I was able to get this to work using {% import 'macros' as testy %} in my posts template, then using this in the individual posts (without having to import in each post):
{{ testy.test_macro('test test') }}

Okay. I think you and I have two different situations. You're trying to use your macros in your posts, while I'm trying to use my macros in an ordinary page (currently just my index for testing). Where do you keep your macros? I started off with mine in _views/macros.html, but couldn't get them to work. Having moved them to _includes/macros.html they seem to work now. Does this seem right?

Yep, can confirm that it definitely works when I keep my macros in the _includes directory.

Ah, I see. Hmm. I guess it might related to where Sculpin tells Twig to autoload from in each context; perhaps Sculpin needs a separate _macros location for both post & page contexts.

I haven't tried loading it in posts yet. If it loads from _includes, then perhaps that remains a sensible location for such things?

Heh. Yes, that does seem to work just fine :) Got a little carried away with myself there.

@simensen If I am not mistaken, the documentation seems to overlook this matter. May I recommend adding some documentation to this effect? I am willing to update the docs if need be.

@thomas-p-wilson I'm not opposed to that. Where in the docs do you think this type of information should live? I almost think there needs to be a sub-section under Formatters called Twig that contains other information that relates to Twig. That or else another Misc section under which a Twig specific section could live.

If the _includes directory is specific to Twig, then I agree that it should likely live under Formatters > Twig. If the _includes directory is used elsewhere, by bundles/plugins other than Twig, then perhaps it should live somewhere more central. Also, I'm thinking that spots like https://sculpin.io/documentation/basic-project/, which have an example directory structure should be updated. That seem right?

@thomas-p-wilson well, i guess it already says it on the Twig page. It just might not be obvious what kind of impact this has:

sculpin_twig.view_paths: List of directories (relative to source/) that should be searched for Twig templates. Default value is ['_views', '_layouts', '_partials', '_includes'].

This means that macros and other twig templates (basically anything that Twig tries to load) can live in any of _views, _layouts, _partials, or _includes.

Ahh, so it does. The question then is why I couldn't load my macros from _views or _layouts but could from _includes. That seems sensible to me though.

@thomas-p-wilson yeah, that is weird. i'm not sure why it would not have been. you could try to make sure that you can include templates (not macros) from _views and _layouts... maybe there is something weird in how Twig handles macros that it isn't looking at the loader in the same way that I'm expecting it to be used everywhere else.
Sorry for the trouble. :) It really should be working from all of those directories.

No trouble at all. I've got things working to my satisfaction.
I think the salient point here is that, if I move my macros.twig file back into _views or _layouts, everything works just fine now. I was clearly doing something incorrectly. Closing this issue as I can no longer replicate it, and @beryllium seems to have resolved it on his end as well.


Add SBOM generation to the website build

This PR adds the following to the website build:

Downloads the SBOM manifest generator using nuget.
Extracts the nuget package files.
Runs the manifest generator on the website files after they're generated.
The manifest is included in the build artifact that is generated.
The static web apps step no longer builds the site. Rather, it just uploads the contents generated in earlier steps. (Before this change, the site was effectively built twice.)
Updates the version of the ASWA action.

This PR replaces the abandoned PR #9084.

@heliocliu This is the PR I mentioned to you at standup.


how to configure authentication routes?

first, it's a very good job you do here, thanks for this plugin.
I have several doubts but I will focus on this one.
I have three routes that make up the authentication: 1 login, 2 forgot password and 3 sign up.
How can I navigate between these three views without authentication?
would you give me an example
Thank you.

router.goTo ?

true the back button does not work when I navigate with goTo, it exits the application

I'd suggest using another package then like go_router as it's been endorsed by the flutter team. Regarding your question this is explained in the readme.


ExtraPipPackages are supported for 'airflow' values node, not 'scheduler'

Checks

[X] I have checked for existing issues.
[X] This report is about the User-Community Airflow Helm Chart.

Description
The documentation generated 5 months ago indicates you can modify airflow in the scheduler with extraPipPackages rather than "all" airflow pods by including the scheduler section of values.yaml:
# values.yaml
scheduler:
  extraPipPackages:
    - airflow-provider-foo-bar
    ...

However, that does not work. My mistake here was thinking that meant that extraPipPackages had been deprecated, and I needed to consider other methods such as supporting my own airflow image or adding an init scheme.
After a significant amount of time, I decided to try some of the other nodes to see if the schema would allow extraPipPackages there (in case it was a bug or mistake). The result was good:
# passes schema checks
airflow:
  extraPipPackages:
    - airflow_declarative

airflow: seems like the values node least likely to be supported if a child item is unsupported, since it is the most comprehensive option. But from a testing perspective, it makes sense: it is the first thing you'd try when QA'ing, and the last thing you'd try when using for the first time.
I am not sure whether only scheduler has this option disabled, or everything other than airflow has the option disabled. I can say it took a non trivial amount of time for me to decide the other options weren't worth it and start trying things on the off chance the docs weren't correct.
Are you willing & able to help?

[ ] I am able to submit a PR!
[X] I can provide feedback!

@chrisdonlan I'm confused, what are you having problems with?
I just tested by setting the following values on version 8.9.0 of thechart, and it worked fine:
scheduler:
  extraPipPackages:
    - "tailscale==0.6.1"


Move optimizer integration tests to core_integration

Which issue does this PR close?
Follow up https://github.com/apache/datafusion/pull/11798
Part of https://github.com/apache/datafusion/issues/11502
Rationale for this change
@Weijun-H and I are working to prepare to move all the physical optimizer rules
into a new crate, so ensuring the existing code has a good pattern to follow is
important
What changes are included in this PR?

Leave a comment with a pointer to the new test
Move the tests for aggregate_statistics into a new module (so as we port the other passes, they will go into their own modules too)

Are these changes tested?
Yes, by CI
The optimizer tests can now be run like
cargo test --test core_integration -- optimizer

Are there any user-facing changes?
No

Thank @lewiszlw !


Error

logs (1).txt
I've always fail to install gsi using dsu, at first it was fine i can install 5+ gsi without issue. But now it's keep fail and even I've install the same gsi that works before now it doesn't work anymore
Also I used only apk first but now using the magisk module also doesn't do anything
Edit : I'm sorry i think it's because my storage. I just removed something from 16gbs to 23gbs and now it's started to work again. But i have question how much storage i need because i only have 64gb model

Yes, you need a considerable amount of storage to install images, the error in your logs are because of lacking free storage, the storage you need may vary from:

Images you're trying to install (since the file itself weights something).
Allocation (images might be allocated in sdcard when supported).
Chosen file and installation method (since chosen file may be not "direct installable", thus, needing to be decompressed or compressed, which may take some storage).
How much userdata storage you set in application (default is 2G, but you can set a custom value)

Anyway, Android recommends at least reserving 10G of free space: https://source.android.com/docs/core/ota/dynamic-system-updates#hardware-requirements


[DC-369] Enforce Submission Directory Naming Convention

Generate empty report if submission folder is named incorrectly

This patch now has a conflict.
Try changing @mock.patch('validation.main._write_string_to_file') to @mock.patch('validation.main._write_string_to_file', mock.MagicMock()) to get rid of the codacy message.
Have you rebased Chao's merge to take advantage of DC-676's updated tests?  An integration test is failing now.

I rebased and force pushed just now. How do I check the patch conflict? Is it the "unused argument error" on Codacy?

It looks like rebasing fixed the conflict.  Yea!
I suggested @mock.patch('validation.main._write_string_to_file', mock.MagicMock()) to try to make Codacy's unused argument error go away.  You have to mock that, but Codacy doesn't seem to like it.  This isn't a blocker.  I just wondered if this change would satisfy the Codacy check.

Awesome! The Codacy thing is annoying. Let me try your suggestion

It looks like it doesn't help resolve the Codacy error. I'll remove the commit and push.

One last CircleCI thing.  We can disable the pylint check for that particular mocked argument with # pylint: disable=unused-argument.  It needs to be placed on the same line as the argument you want to ignore.  It will only ignore that argument and will continue to check that the rest of the arguments are used.  I personally like checking that all my arguments are used, but pylint is doing a static analysis and is not picking up on the fact that this mocked argument that is used at runtime.  So, as a general rule, I would only be willing to ignore mocked arguments on a case by case basis.  You can view the StackOverflow explanation here for some other ideas.  https://stackoverflow.com/questions/59136064/python-unused-argument-needed-for-compatibility-how-to-avoid-pylint-complainin
To test this from the command line you can:
$ # Enable your python development environment
$ source <env_file_location>/bin/activate
$ # Run pylint on unit tests from curation/data_steward directory
$ pylint ../tests/unit_tests/data_steward/validation/main_test.py

You can test without the disable comment and then with the disable comment.  When disabled, the complaint should disappear.

I think the Codacy issue will go away once the PR is merged. It will be considered a known issue and won't show up again. I think there are lots of instances where Pylint considers a mock argument to be "unused" even though they are used during runtime, and we need a comprehensive way to deal with all of them together. Regarding the blank lines, the function is quite small and PEP 8 checks weren't complaining so I thought it's fine with regards to readability. I was also hoping yapf would handle issues like these but looks like it doesn't.


[BEAM-289] Examples Use TypeDescriptors

Jira issue BEAM-289 Examples Use TypeDescriptors. Changed example code to use TypeDescriptors.
These could have used static imports to make the lines shorter, but we opted for the more understandable syntax.

The build succeeded, but Jenkins timed out. cc @kennknowles

R: @kennknowles
I'm taking a look. One way you can kick Jenkins is to rebase against the current HEAD.

Any chance you can prune the other commits out of this pull request?

Closing to use a different branch without the extra commits.


allow_insecure_connections not working for OpenTelemetry

Environment info:

KrakenD version: Version: 2.7.0
System info: docker
Hardware specs: N/A
Backend technology: .NET Aspire
Additional environment information: N/A

Describe the bug
The KrakenD container does not trust self signed certs like the dotnet cli dev certs used by a .NET Aspire application. In attempting to build a component I would expect to be able to use the config allow_insecure_connections to publish to an OTEL OTLP Endpoint. However, I can only get this to work on http. Given KrakenD is acting as a client here shouldn't it be able in development to ignore the OTLP endpoint cert? Please note this is in using the GRPC protocol for communicating with the OTEL OTLP Endpoint.
Your configuration file:

{
  "$schema": "https://www.krakend.io/schema/krakend.json",
  "version": 3,
  "tls": {
    "disabled": true
  },
  "client_tls": {
    "allow_insecure_connections": true
  },
  "name": "gateway",
  "extra_config": {
    "telemetry/opentelemetry": {
      "service_name": "gateway",
      "service_version": "0.1",
      "skip_paths": [""],
      "metric_reporting_period": 30,
      "exporters": {
        "otlp": [
          {
            "name": "aspire_dashboard",
            "host": "{{ (split ":" (splitList "://" (env "OTEL_EXPORTER_OTLP_ENDPOINT") | last))._0 }}",
            "port": {{ int ((split ":" (splitList "://" (env "OTEL_EXPORTER_OTLP_ENDPOINT") | last))._1) }},
            "use_http": false,
            "disable_metrics": false,
            "disable_traces": false
          }
        ]
      },
      "layers": {
        "global": {
          "disable_metrics": false,
          "disable_traces": false,
          "disable_propagation": false
        },
        "proxy": {
          "disable_metrics": false,
          "disable_traces": false
        },
        "backend": {
          "metrics": {
            "disable_stage": false,
            "round_trip": false,
            "read_payload": false,
            "detailed_connection": false,
            "static_attributes": []
          },
          "traces": {
            "disable_stage": false,
            "round_trip": false,
            "read_payload": false,
            "detailed_connection": false,
            "static_attributes": []
          }
        }
      }
    },
    "telemetry/logging": {
      "level": "Debug",
      "prefix": "[KRAKEND]",
      "syslog": false,
      "stdout": true,
      "format": "default",
      "syslog_facility": "local3"
    }
  },
  "timeout": "3000ms",
  "cache_ttl": "300s",
  "output_encoding": "json"
}

Commands used
How did you start the software?
The equivalent of this command was ran by .NET Aspire:
`docker run --rm -it -v $PWD:/etc/krakend \
        -e FC_ENABLE=1 \
        -e FC_OUT=result.json \
       -e KRAKEND_ALLOW_INSECURE_CONNECTIONS=true \
        devopsfaith/krakend:2.7.0 \
        run -c /etc/krakend/config/krakend.json -d`

Expected behavior
KrakenD to publish metrics and traces to the local OTLP endpoint provided by .NET Aspire.
Logs
2024-08-15 18:05:29 [KRAKEND] 2024/08/15 - 22:05:29.589 ▶ DEBUG [SERVICE: telemetry/logging] Improved logging started.
2024-08-15 18:05:29 [KRAKEND] 2024/08/15 - 22:05:29.589 ▶ INFO Starting KrakenD v2.7.0
2024-08-15 18:05:29 [KRAKEND] 2024/08/15 - 22:05:29.590 ▶ INFO Working directory is /etc/krakend
2024-08-15 18:05:29 [KRAKEND] 2024/08/15 - 22:05:29.591 ▶ INFO Starting the KrakenD instance
2024-08-15 18:05:29 [KRAKEND] 2024/08/15 - 22:05:29.600 ▶ INFO [SERVICE: Gin] Listening on port: 8080
2024-08-15 18:05:34 [KRAKEND] 2024/08/15 - 22:05:34.590 ▶ DEBUG [SERVICE: Telemetry] Registering usage stats for Cluster ID Yta7MRc8MQb5XN9ZwYcln0YZ2Y1jPMg4vUMx0W2VwQE=
2024-08-15 18:06:09 [KRAKEND] 2024/08/15 - 22:06:09.590 ▶ ERROR [SERVICE: OpenTelemetry] failed to upload metrics: context deadline exceeded: rpc error: code = Unavailable desc = connection error: desc = "error reading server preface: EOF"
2024-08-15 18:06:39 [KRAKEND] 2024/08/15 - 22:06:39.589 ▶ ERROR [SERVICE: OpenTelemetry] failed to upload metrics: context deadline exceeded: rpc error: code = Unavailable desc = connection error: desc = "error reading server preface: EOF"
2024-08-15 18:07:09 [KRAKEND] 2024/08/15 - 22:07:09.588 ▶ ERROR [SERVICE: OpenTelemetry] failed to upload metrics: context deadline exceeded: rpc error: code = Unavailable desc = connection error: desc = "error reading server preface: EOF"
2024-08-15 18:07:39 [KRAKEND] 2024/08/15 - 22:07:39.588 ▶ ERROR [SERVICE: OpenTelemetry] failed to upload metrics: context deadline exceeded: rpc error: code = Unavailable desc = connection error: desc = "error reading server preface: EOF"
2024-08-15 18:05:29 Parsing configuration file: /etc/krakend/krakend.json

I have same issue.


Identation lost after collapsing

The Indentation of child nodes is lost after you collapse and then reexpand the parent.

Thanks @nmase88 - it looks like a few things are broken after I updated to VS 17.4.0 Preview 1.0.
Problems look to be related to recycling CollectionView items, I'll take a look after the weekend.

@nmase88 I've fixed this and updated the NuGet package to version 1.0.2. Thanks for the report and please let me know if you find any more issues.

Yeah I thought that was probably the case. Thank you :-)
On Fri, 12 Aug 2022, 4:30 pm Keith Pickford, @.***>
wrote:

Thanks @nmase88 https://github.com/nmase88 - it looks like a few things
are broken after I updated to VS 17.4.0 Preview 1.0.
Problems look to be related to recycling CollectionView items, I'll take a
look after the weekend.
—
Reply to this email directly, view it on GitHub
https://github.com/Keflon/FunctionZero.Maui.Controls/issues/1#issuecomment-1213235971,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFY2AKHIQ3SFCAPZBEP7NBLVYZUYNANCNFSM56LNNY4Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thats great thanks very much 🙂 yeah will let you know
On Thu, 25 Aug 2022, 8:11 am Keith Pickford, @.***>
wrote:

@nmase88 https://github.com/nmase88 I've fixed this and updated the
NuGet package to version 1.0.2. Thanks for the report and please let me
know if you find any more issues.
—
Reply to this email directly, view it on GitHub
https://github.com/Keflon/FunctionZero.Maui.Controls/issues/1#issuecomment-1226865318,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFY2AKAFE4YHZMKG2B4QZWLV24MALANCNFSM56LNNY4Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add test for anonymous users

Use AnonymousAWSCredentials instead of BasicAWSCredentials gives us a chance to test anonymous user access.

done


[BUG] tool.setuptools.license-files results in invalid metadata

setuptools version
setuptools==74.1.2
Python version
Python 3.13
OS
any
Additional environment information
No response
Description
If any of the the glob patterns specified intool.setuptools.license-files matches a file in the package, setuptools generates invalid metadata: it includes a License-File field while specifying Metadata-Version to be 2.1. This is invalid and packaging raises an exception while parsing the metadata. This likely results in the resulting distributions to not be accepted by PyPI.
Because tool.setuptools.license-files  has a default value of ['LICEN[CS]E*', 'COPYING*', 'NOTICE*', 'AUTHORS*'] the problem can be encountered also in packages that do not explicitly set this field in pyproject.toml but happen to have a file matching the default glob pattern.
Expected behavior
Do not emit the License-File field or do it and specify Metadata-Version: 2.4 as per PEP 639.
How to Reproduce
Here is a short reproducer:
$ cat >pyproject.toml <<EOF
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
[project]
name = "foo"
version = "1.2.3"
[tool.setuptools]
license-files = ["LICENSE"]
EOF
$ touch LICENSE
$ uv build .
$ tar xf dist/foo-1.2.3.tar.gz
$ python
>>> import pathlib
>>> import packaging.metadata
>>> packaging.metadata.Metadata.from_email(pathlib.Path('dist/foo-1.2.3/PKG-INFO').read_text())

Output
  + Exception Group Traceback (most recent call last):
  |   File "<python-input-3>", line 1, in <module>
  |     packaging.metadata.Metadata.from_email(pathlib.Path('dist/foo-1.2.3/PKG-INFO').read_text())
  |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |   File "/Users/daniele/src/twine/.venv/lib/python3.13/site-packages/packaging/metadata.py", line 781, in from_email
  |     raise ExceptionGroup(
  |         "invalid or unparsed metadata", exc_group.exceptions
  |     ) from None
  | ExceptionGroup: invalid or unparsed metadata (1 sub-exception)
  +-+---------------- 1 ----------------
    | packaging.metadata.InvalidMetadata: license-file introduced in metadata version 2.4, not 2.1
    +------------------------------------
>>>

This is a well-known case of an early implementation of a PEP 639 draft. Right now tools are equipped to accept this variation.
In time it will be fixed. But not immediately, due to effort constraints and release scheduling.
Probably we can close this as a "kind of duplicate" of the request to implement PEP 639.

This is a well-known case of an early implementation of a PEP 639 draft. Right now tools are equipped to accept this variation.

What I am trying to say is that tools are not equipped to accept this variation. packaging is the PyPA library for parsing distribution metadata and, as shown above, it does not handle this variation. Which other tools dealing with packages metadata that handle this correctly do you have in mind?

@dnicolodi Is right here. The License-File metadata generated by setuptools causes an error during validation with packaging==24.2 since the metadata version isn't >=2.4. This hasn't been an issue so far as twine doesn't support version 2.4 and thus License-File isn't included in the form fields during upload.
What I'm uncertain about is the solution. Sure, we can remove the License-File field from the generated metadata, and probably do so anyway as it isn't spec compliant even with 2.4. However that wouldn't resolve the issue for all packages which pin older setuptool versions. As it was added here quite a while ago, I suspect the impact will be quite large. This might be something which needs to be handled upstream (twine / warehouse) too, e.g. only push the License-File field if the metadata version is >=2.4 and ignore it for older versions.

Which other tools dealing with packages metadata that handle this correctly do you have in mind?

I was thinking that twine/PyPI/pip have been accepting License-File with metadata version 2.2 for a while.
Just to emphasize that we are going to tackle this problem in time (btw, thanks @cdce8p for the PRs). But before that we will implement metadata version 2.3 (I just got a review recently on one of the PRs necessary for 2.3, but this week I don't have the time to delve into it).
Meanwhile, my strong preference is to not change anything that has been in place for the last 2 or 3 years.
If you need the process core metadata using packaging before we proceed with the updates in setuptools from 2.2 > 2.3 > 2.4, maybe you can consider deleting/ignoring the License-File field before the validation?

I was thinking that twine/PyPI/pip have been accepting License-File with metadata version 2.2 for a while.

I am not very familiar with all the consumers of package metadata. I have the impression that there are several tools using different approaches for metadata parsing and validation. Only relatively recently packaging implemented metadata validation. I hope there is going to be a convergence toward more strict parsing of metadata, either via packaging or via equivalent tools.
Indeed, I bumped into the issue with License-File because I would like to move twine from using a semi-maintained library for extracting metadata from distribution files to a solution based on packaging https://github.com/pypa/twine/pull/1180 This comes with stricter metadata validation, which IMHO is a good thing. I have now implemented a "work-around" for the metadata emitted by existing setuptools versions as there is nothing we can do about those.
I was under the impression that PyPI implements validation of the distribution files metadata, but if it does, the validation is not very strict. What is validated strictly is the form data that is sent alongside the distribution files. That can be tweaked as needed to support the metadata emitted by existing setuptools releases.
pip is most likely the most permissive consumer of metadata, thus I don't expect it to do any validation.
I don't see any reason to change setuptools to fix this issue straight away. I filed this issue to make sure that you are aware of it. Because, as I wrote above, metadata parsing has not been very strict so far, it could have been that you are not aware of it.

Thank you very much @dnicolodi.
Hopefully we can have it soon and start to converge towards packaging.
One thing that would help a lot is if packaging itself could provide functionally to emit metadata.
This way we use a single and consistent library for both emitting and parsing metadata.
It is probably been already tracked by https://github.com/pypa/packaging/issues/570.

meson-python and scikit-core (and possibly other build backends) use pytproject-metadata https://github.com/pypa/pyproject-metadata/ for translating pyproject.toml into an RFC822 metadata file (I am one of the maintainers of meson-python).
There is some work toward incorporating pyproject-metadata into packaging https://github.com/pypa/packaging/pull/846 https://github.com/pypa/packaging/pull/847
On the other hand, I like that there are more that one implementation of the standard: that makes it easier to ensure that the only implementation does not diverge from the standard and avoids such implementation, bugs included, to become the de-facto standard. We were in that situation before PEP 517 and PEP 621, and we are still cleaning up the mess... 🙂

I was thinking that twine/PyPI/pip have been accepting License-File with metadata version 2.2 for a while.

PyPI uses packaging.metadata to validate the submitted form fields. Unknown fields are just ignored. With 24.2 license_files was defined as being added in 2.4 thus it would start to fail now when submitted with older version.
Saw the commit from @dnicolodi on the packaging PR: https://github.com/dnicolodi/twine/commit/ab3bf7dccecaad9f65e3affac59205c4dc935bdf. All considered, that's probably the most practical solution here.

Just to emphasize that we are going to tackle this problem in time (btw, thanks @cdce8p for the PRs). But before that we will implement metadata version 2.3.
Meanwhile, my strong preference is to not change anything that has been in place for the last 2 or 3 years.

Sorry in advance if I'm a bit annoying here. I can understand your position, but wouldn't fully agree with it. We can do more even before we implement metadata version 2.3.

https://github.com/pypa/setuptools/pull/4728
We already include the License-File file in the core metadata. Why not make it spec compliant then? It would also fix an issue were license files with the same names but in different folders would just be overwritten, see https://github.com/pypa/setuptools/issues/3596.
#4706
While the initial approach for it was wrong, adding the License-Expression field now would just result in the same issue we have with License-File already, there is nothing stopping us from repurposing the existing License field. In fact that's the same approach hatchling and poetry use as they are also blocked on the twine update and can't yet move to 2.4.

Why am I pushing for these changes? For Home Assistant we use a script to try to validate the licenses of all requirements and tbh it's just a mess. Some packages use the outdated classifiers, some custom license strings and others the full license in the metadata. I'm prepared to open PRs for some of these dependencies but it only really makes sense if I can use the final pyproject.toml metadata. Otherwise I'd have to do that all over again once setuptools is able to emit valid 2.4 metadata. With the changes above, it only needs a new release with an updated setuptools version and everything would be fine.

PyPI uses packaging.metadata to validate the submitted form fields. Unknown fields are just ignored. With 24.2 license_files was defined as being added in 2.4 thus it would start to fail now when submitted with older version.

AFAIU warehouse (the software powering PyPI) does not ignore unknown fields. This should be the validation code: https://github.com/pypi/warehouse/blob/d57082ee37327bc1e8a28f96470b00ed226c0f87/warehouse/forklift/metadata.py#L263-L348
However, twine submits only fields it known about, and it does not know yet about license_files (which should appear as multiple license_file in the form data, but this is a minor technical detail).

hatchling and poetry [...] are also blocked on the twine update and can't yet move to 2.4.

Can you point me to more information regarding this? I was under the impression that hatchling users use the upload mechanism provided by the hatch framework, and same for poetry. Isn't this the case? One of the PyPI maintainers on Discourse said that there are PyPI uploads conforming to metadata 2.4. I thought those were hatchling projects.

PyPI uses packaging.metadata to validate the submitted form fields. Unknown fields are just ignored. With 24.2 license_files was defined as being added in 2.4 thus it would start to fail now when submitted with older version.

AFAIU warehouse (the software powering PyPI) does not ignore unknown fields. This should be the validation code: https://github.com/pypi/warehouse/blob/d57082ee37327bc1e8a28f96470b00ed226c0f87/warehouse/forklift/metadata.py#L263-L348

You're right. I only checked the packaging call Metadata.from_raw(...) which ignores unknown fields. Didn't know warehouse implemented additional checks.

hatchling and poetry [...] are also blocked on the twine update and can't yet move to 2.4.

Can you point me to more information regarding this? I was under the impression that hatchling users use the upload mechanism provided by the hatch framework, and same for poetry. Isn't this the case?

For hatchling see https://github.com/pypa/hatch/issues/1828#issuecomment-2501659883. The same would likely apply to poetry as well. Although they haven't yet started implementing PEP 639 to begin with https://github.com/python-poetry/poetry/issues/9670. The comment for poetry was more referencing the fact that they already allow project.license = MIT in pyproject.toml and just back-populate it to the License field instead of License-Expression.

One of the PyPI maintainers on Discourse said that there are PyPI uploads conforming to metadata 2.4. I thought those were hatchling projects.

AFAIK you can overwrite the Metadata-Version with hatchling and at some point (before PyPI added official support for it I believe) this was even the default. It has since been reverted though.
The last comment on discuss I saw was

No further uploads have occurred since that first attempt.

Hi guys, I understand the urgency of the topic, but I am also very conscious that we need to move very carefully to avoid breaking the ecosystem all at once. In the past we had a lot of bad experiences with botched releases, so I am trying to take the most conservative approach possible (and even with that it is possible there will be problems).
The good thing is that we have most of the pieces already in place (thanks again for the PRs). We now need to coordinate to release them, collect feedback and fix if things are broken.
My preference is to do things step by step and wait one week or so between steps to receive feedback of early adopters on edge cases (of course respecting the holiday season coming ahead and the times of all collaborations, so probably longer than that). I suggest the following:

Setuptools to finish testing Metadata 2.2 implementation (followed by release + feedback + bug fixing)
Setuptools to bump Metadata 2.3 - should be trivial - (followed by release + feedback + bug fixing)
Setuptools to implement PEP 639 and Metadata 2.4 - (followed by release + feedback + bug fixing)
Twine and other downstream consumers to support strict Metadata 2.4 [^1]

I think that step 2 is going to be trivial to support, once we concede that we don't have to worry to much about the https://github.com/pypa/packaging/issues/845 and treat it as a temporary bug.
[^1]: I am not sure twine will be able to fully drop lenient parsing for Metadata < 2.4 (many users do pin the version of their build dependencies, so there may be some backlash form the community). But this is a decision that the twine team can decide to take.

One last post from me and then I'll shut up and respect your decision :)

we need to move very carefully to avoid breaking the ecosystem all at once. In the past we had a lot of bad experiences with botched releases, so I am trying to take the most conservative approach possible (and even with that it is possible there will be problems).

Absolutely! The only thing our opinions differ I believe is in the risk these PRs actually pose. What I'm trying to say is it's quite small and we can safely do it now. Let me explain

https://github.com/pypa/setuptools/pull/4706
This will only effect project which opt-in to using the new string value for project.license. That syntax is currently an error, so all existing projects will be unaffected.
https://github.com/pypa/setuptools/pull/4728
The current handling of license files might have been in place a long time, I was the one who added it initially after all., but it's fundamentally broken, so no project can rely on it. We might as well fix it then.

Doing these now would provide valuable feedback way before we'd consider moving to 2.4. That's the only thing I would change about your proposed timeline.

I think this is the only way to proceed as pre PEP 639 and post PEP 639 license declaration formats are not compatible with each other, thus emitting metadata version 2.4 with a pyproject.toml using an older metadata format is at minimum very tricky.

I'm proposing the reverse: Emitting the current core metadata 2.1 with a post PEP 639 pyproject.toml. Even if that means some fields wouldn't be written even though the data in the project table is there (namely License-Expression).
That approach works fine for hatchling. I've also opened PRs to add the same to flit.

https://github.com/pypa/flit/pull/707
https://github.com/pypa/flit/pull/705

I'm proposing the reverse: Emitting the current core metadata 2.1 with a post PEP 639 pyproject.toml.

I don't understand what the advantage of doing this is. IIUC, your goal is to move as fast as possible to have packages with PEP 639 metadata. However, with this approach, having packages with PEP 639 license metadata will require two releases of the packages involved: one that updated the metadata fields in pyproject.toml to the ones specified in PEP 639 and one to rebuild the package metadata shipped in the distribution files with a future setuptools release.
The cost of doing this is not only the two releases, but also that between the two releases the involved packages will not have clear license information displayed on PyPI. IIRC, PEP 639 forbids having classifiers indicating the package license while using the License-Expression metadata field. Because currently PyPI takes the license information displayed on the package pages from the classifiers, the packages will do not show clear license information.

However, with this approach, having packages with PEP 639 license metadata will require two releases of the packages involved: one that updated the metadata fields in pyproject.toml to the ones specified in PEP 639 and one to rebuild the package metadata shipped in the distribution files with a future setuptools release.

Correct.

I don't understand what the advantage of doing this is. IIUC, your goal is to move as fast as possible to have packages with PEP 639 metadata.

Updating packages always takes time. What can be optimized though is developer time. I can either fix / convert all wrong licenses to SPDX expressions now and do a second pass to convert {text = "..."} to the new syntax, or just to the update once knowing that eventually a new release will just use the License-Expression instead. Given that it often takes >1 month for smaller projects to merge PRs, this would just be exhausting. So for now, I've paused updating the license strings until the new syntax in whatever form is supported.
To give an example, poetry already supports the license = "MIT" syntax while still missing PEP 639 support. So these aren't an issue.
Just for Home Assistant, I currently track over 650 packages with inaccurate license data.

The cost of doing this is not only the two releases, but also that between the two releases the involved packages will not have clear license information displayed on PyPI.

Not entirely. PyPI can handle all case. This is with both classifier and (old) license metadata ^1

and here an example with only the (old) license metadata, but still a valid SPDX expression. ^2

IIRC, PEP 639 forbids having classifiers indicating the package license while using the License-Expression metadata field. Because currently PyPI takes the license information displayed on the package pages from the classifiers, the packages will do not show clear license information.

No, build tools MAY raise an error if a license classifier is present.^3 PyPI must only reject uploads with both License and License-Expression fields but those don't collide here.^4

My user story:

At some point I added license = {file = "LICENSE"} to some project. I think I got this from packaging.python.org
Later, I try to upload to PyPI. I get Caused by: Upload failed with status code 400 Bad Request. Server says: 400 license-file introduced in metadata version 2.4, not 2.1. See https://packaging.python.org/specifications/core-metadata for more information.
As far as I can tell, I haven't done anything packaging special. I quickly shake a fist at Python packaging, then Google the error
There are only two hits on Google, one is this uv issue https://github.com/astral-sh/uv/issues/9513. I get from there to here
If there's a workaround setuptools would like to encourage, it would be nice to post here!

Thanks for explaining that! Yeah, I ended up just using twine (before I saw your post and konstin's post here)... so I guess I just uploaded a wheel with invalid METADATA that will fail packaging.metadata.Metadata validation. At least I have a lot of company (IIUC ~every setuptools wheel in the last few years?). I guess off-topic for this tracker, but if so maybe packaging.metadata should be lenient here?


Error message about locked file on startup

Microsoft PowerToys version
0.51.1
Running as admin

[ ] Yes

Area(s) with issue?
General
Steps to reproduce
It happens immediately after startup:
Version: <IP_ADDRESS>
OS Version: Microsoft Windows NT 10.0.22543.0
IntPtr Length: 8
x64: True
Date: 08/02/2022 07:46:10
Exception:
System.IO.IOException: The process cannot access the file 'C:\Users\tfenster\AppData\Local\Microsoft\PowerToys\PowerToys Run\Cache\Image.cache' because it is being used by another process.
at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.FileStream..ctor(String path, FileMode mode)
at System.IO.Abstractions.FileStreamFactory.Create(String path, FileMode mode)
at Wox.Infrastructure.Storage.BinaryStorage`1.TryLoad(T defaultData)
at Wox.Infrastructure.Image.ImageLoader.Initialize(Theme theme)
at PowerLauncher.App.<>c__DisplayClass14_0.b__0()
at Wox.Infrastructure.Stopwatch.Normal(String message, Action action)
at PowerLauncher.App.OnStartup(Object sender, StartupEventArgs e)
at System.Windows.Application.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
✔ Expected Behavior
PowerToys starts without an error
❌ Actual Behavior
The error pops up
Other Software
No response

This should have been fixed with 0.53. https://github.com/microsoft/PowerToys/issues/12908
Please updated to latest.


Add support for Apartment gem

Add support for Apartment gem with excluded models -- tables of which exist in public schema.
If Apartment class is defined, excluded models are inspected. In case the current table that we are generating foreign keys for is one of the excluded tables, it means it needs to have 'public.' prepended to it's table name

@nagi Fixed according to your review.

Is Apartment supported in Rails 4.2 implementation of foreign keys?

@matthuhiggins Hi there, thanks for responding. Unfortunately I have no idea how this works on Rail 4.2 as the application running this fork is on Rails 3.2.
Me personally cannot perform any work other than what I already contributed almost 2 years ago, I am no longer at the company.
So if you decide to approve and merge this, afaik this works on Rails 3.2. I have no idea how Apartment works on Rails 4.x


Added math_pointing.rst from SVN

From https://katfs.kat.ac.za/svnDS/doc/trunk/sphinx/source/specification_records/math_pointing.rst, with only minor modification to de-emphasize "Fringe Finder"

@ludwigschwardt please have a look at this. i think it provides newcomers with a valuable overview even though it is somewhat in need of a refresh.

This looks useful! I can also add some details (like the origin of our refraction model, which is no longer lost :joy:). I'll eventually update coord_chain for katpoint 1.0, because it has had a few tweaks.
Is this integrated with the rest of the documentation?

nope, i haven't added it to the TOC


[Core] Support offloading KV cache to CPU

A minmal implementation for CPU KV cache offloading (#7697)
Benchmarking results:
A long document QA workload (see google doc for more discriptions). GPU can cache 10 documents and CPU can cache 40 documents.

CPU offloading is better when GPU space is not enough to cache all documents but CPU can.
google doc link
Implementation
This PR has much less features compared to #8694, but it is really minimum and creates very little core change. So I guess we can use this PR to enable CPU KV cache offloading first, and then focus on disk.
The key idea of this implementation is to maintain those allocated blocks that didn't hit the cache, and constantly copy them into CPU after each scheduler step.
Here is the flow diagram

This idea is borrowed from ConServe (paper link: https://arxiv.org/abs/2410.01228), based on the assumption that the CPU-GPU bandwidth is much higher than GPU KV cache generation throughput. Thanks Yifan for this idea.
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

We also observe similar issue.

@KuntaiDu I tested this PR on A100 GPU and it will have listed issues: [rank0]:[W1030 22:42:25.307407705 ProcessGroupNCCL.cpp:1250] Warning: WARNING: process group has NOT been destroyed before we destruct ProcessGroupNCCL. On normal program exit, the application should call destroy_process_group to ensure that any pending NCCL operations have finished in this process. In rare cases this process can exit before this point and block the progress of another member of the process group. This constraint has always been present, but this warning has only been added since PyTorch 2.4 (function operator())
After this warning, the process will lockup and machine should restart! kernel:[67924.212374] watchdog: BUG: soft lockup - CPU#101 stuck for 22s! [python:187618]

Oh weird .... I didn't touch distributed initialization and destroying part. This should not be the case >.< Let me try to reproduce.
BTW, I am also working on a more performant cuda kernel for CPU-GPU memcpy, current memcpy kernel is ... really slow.

Clean implementation! Just to verify my understanding, so some data will have copies in both GPU and CPU?
And do we still need to overlap the memory copies with the computation

Clean implementation! Just to verify my understanding, so some data will have copies in both GPU and CPU? And do we still need to overlap the memory copies with the computation

Yes
Yes (but not in this PR)

Hi
It seems that there is a bug when you try to extend the mapping list returned from the function get_and_reset_swaps to blocks_to_swap_out and blocks_to_swap_in lists. The index in blocks_to_swap_out/in lists should be the zero-offset block id on certain device instead of the absolute global block id, but index in the returned mapping list use global block id.


[vcpkg-docs] Add Policy document for maintainers

From https://github.com/Microsoft/vcpkg/pull/1111#issuecomment-302555645

For contributors new to package managers, it would be nice to have a document on general packaging philosophy, covering issues like build reproducibility or why libraries shouldn't bring their own dependencies.

Additional contents:

Guidelines for closed-source libraries as well; see https://github.com/Microsoft/vcpkg/issues/1108
Naming collision avoidance and resolution; see https://github.com/Microsoft/vcpkg/pull/1009

This issue has been fixed. So I am closing this issue for now.


Upload our first artifact to Maven Central

Done! Behold: http://search.maven.org/#search|ga|1|cuppa


goreporter report error by run in terminal

Sorry, you must specify your project path. Just like :

Sorry, you must specify your project path. Like
goreporter -p [projectRelativePath] -r [reportPath] -e [exceptPackagesName] -f [json/html/text]  {-t templatePathIfHtml}


Sumbission dl2

LGTM chef

Hi, the deadline is close! Please consider making the tests pass to make this submission valid for the challenge :)

Hello, @XVmecha! Thank you for your submission. As we near the end of the challenge, I am collecting participant info for the purpose of selecting and announcing winners. Please email me (or have one member of your team email me) at<EMAIL_ADDRESS>so I can share access to the voting form. In your email, please include:

your first and last name (as well as any other team members)
the title of the method you implemented
the input domain of the method you implemented
the output domain of the method you implemented
your pull request number (https://github.com/pyt-team/challenge-icml-2024/pull/4 )

Before July 12, make sure that your submission respects all Submission Requirements laid out on the challenge page. Any submission that fails to meet this criteria will be automatically disqualified.


Implemented one endpoint for span creation - Span.new/1 [WIP]

This way we can ensure that we always set sane defaults based on configuration settings.

Wondering if we should also apply Span.new/1 in Span.child_of/1?
We should probably use %Span{} struct everywhere instead of plain map, wdys?
Any other places to look for?

Fixes #7

[x] Span.new/1 constructor with defaults
[ ] clean up adapter from Span.begin(new())
[ ] improve test coverage for Span

Coverage increased (+2.2%) to 44.681% when pulling 11decb014c6b6c6f009733dab93407f3536b0f58 on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.

Coverage increased (+1.7%) to 44.17% when pulling a670c609e12847d986421a9e4334c18c7a6a8229 on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.

I would also check the add context plug to make sure that it behaves well w/ the defaults

I wonder if the test failure we're seeing here implies that we're adding over 2ms overhead every time we make a span :/ I think after we get this cleanup setup that some benchmarking is in order.

Makes sense although from what I quickly checked it's just first execution only, in iex first run for Spandex.Datadog.Span.new() takes ~4ms, next calls are around ~26-50 microseconds. Still we should check it out, I would say that at least publishing trace to agent should be made from a separate gen server with some retries asynchronously (as now it take place on trace finish as far as I understand)

Coverage increased (+2.0%) to 44.444% when pulling 23cd446dd2142709d276e04b2ddcd68e8642cdd4 on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.

Coverage increased (+2.1%) to 44.604% when pulling 00d9ac014b7500b1414657d63c9d01680492358c on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.

I definitely agree about starting a trace sending server.

Coverage increased (+18.4%) to 60.932% when pulling 56b10b84ccb1108a484ed3cf495b32c5479b224a on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.

Ok, I think that's all for this PR, I actually should only update AddContext plug by removing entries which are already set in start_trace, but I also added tests and check if we actually trace stuff. Still a lot of tests to add.
I'll tackle #6 in separate PR after this one is merged

Coverage increased (+18.4%) to 60.932% when pulling c9f901e66dedbecff94bc3a2901b08be087f2e94 on driv3r:bugfix/7-use-config-for-defaults into 6fc831b7a90bcfcbbac0dddf136c9bb8f1d3146f on zachdaniel:master.


How to add other devices to homebridge such as smartthings, nest and dyson.

I had no problem getting my setup up and running on my raspberry pi and it interacts with smartthings just fine and controls all my smartthings devices.  I want to also add my nest and my dyson cool link fan.  I have seen how to add each one and there example config.json.  I can not figure out how to add all the devices into one config.json  Just need some help adding nest and dyson to this config file
Here is my current config.json
{
"description": "JSON API",
"platforms": [
{
"platform": "homebridge-smartthings.SmartThings",
"name": "SmartThings",
"app_url": "https://graph-na02-useast1.api.smartthings.com:443/api/smartapps/installations/",
"app_id": "",
"access_token": ""
}
],
"bridge": {
"name": "Homebridge",
"username": "AA:BB:CC:DD:EE:FF",
"port": 51826,
"pin": "123-45-678"
}
}

@sjmarkham this question is more relevant for the ST plugin repo, I used to be a contributor there but ST's unreliability has me using homebridge-homeassistant these days.


adding an extra example to use with rails/devise

While starting to work with message_bus I struggled to find the right way to get the current user ids, I found this issue https://github.com/SamSaffron/message_bus/issues/64 and just wanted to share it with new-comers.
Thanks for this tool!!! 👍

cool! thanks!


Remove Act 5 merc from Faster Hit Recovery table

The Act 5 merc has no faster hit recovery animation, so it can't be put into hit recovery period (e.g. see https://reddit.com/r/ProjectDiablo2/comments/kpmqnc/act5_merc_guide and https://forums.d2jsp.org/topic.php?t=83866670&f=87). Because of this, the breakpoints exist only on paper, yet they have zero effect in the game itself.

Thanks for the bugfix!


New: generated help markdown documentation

This PR allows us to generate the full help of our CLI in markdown format. I also added a workflow job verifying that docs/CommandLineHelp.md has been updated. This allows us to see how new changes (PRs) affect the documentation.
Example of the failed job: https://github.com/Screenly/cli/actions/runs/9792520351/job/27038547184
I'd like to link to this file in our articles instead of hardcoded commands.
For the doc file generation, I use clap-markdown.

@rusko124 Why not make it a build task, instead of a runtime parameter? And it would be uploaded/handled by CI with the releases. With runtime parameter, I first thought it will be served directly to customer. But I guess it's not, right?

And it would be great if you can squash the branch.

@rusko124 Why not make it a build task, instead of a runtime parameter? And it would be uploaded/handled by CI with the releases. With runtime parameter, I first thought it will be served directly to customer. But I guess it's not, right?

Why not make it a build task
It pulls a ton of dependencies to build-dependencies. Just don't want to pollute it.

And it would be uploaded/handled by CI with the releases.
The file should be generated manually, and be part of the next Pull Requests. We should see what changed.

It's runtime yes, but hidden. So basically how it's done in the lib docs.

IMHO, this looks not right. A change should be happening atomically, and docs should reflect the same change moment. That's why the same PR should also include doc changes, and it's easy with a build task. Sure, it could be handled with a runtime param, but it doesn't feel right, even if it is hidden.
I wonder what others are thinking.

IMHO, this doesn't look right. A change should be happening atomically, and docs should reflect the same change moment. That's why the same PR should also include doc changes, and it's easy with a build task. Sure, it could be handled with a runtime param, but it doesn't feel right, even if it is hidden.

Do you mean the build process should overwrite files outside of the build dir? If so it doesn't sound correct. Or, do you mean to copy a file from the build dir and replace it in the docs? It also doesn't sound more automatic than it is now.
Also during CI, we should not deliver generated documentation. It should be done manually in PRs, in CI we can only make sure that the documentation is up to date.

Do you mean the build process should overwrite files outside of the build dir?

Hmmm, I think I haven't thought it thoroughly. But I guess it would be the same, as where we put them right now, in the PR.
It's just not felt right, but apparently I don't know the better one, too ;) So I withdraw.


Specify a small initial number of reports to provide our first "vertical" implementation

Select around 3 of the reports, and run through the process of specifying and designing them, and then do preliminary implementations as per #44 for review by the team prior to making decision in #29

I've selected the following 3 reports as a reasonable cross-section of those required which will give us insights into the key report types and objects:

[ ] G001: Article Downloads for Unit Administrators
[ ] G014: Workflow Progress for Editors
[ ] G031: Journal Usage for Publishers

Full docs about the report types are in the requirements analysis here: https://docs.google.com/spreadsheets/d/1SmYBe4Ope2tViyXbjvQIjGzNNSQGTVVJi98Y2xjTn7o/edit#gid=802817120

We discussed the approach here in the NGLP team meeting and agreed that this approach and these reports make sense.

We agreed at our last meeting that G031 is a special case of G001, so we would focus only on G001 and G014.  These are now fully specified, and prototype implementations have been made.

@Pcolar I'm assigning this one to you too, so you can review the prototypes and tell us if there are any changes to the specifications.  I don't think Sarah is on the github, so I can't assign to her, but I expect she will want to sign off on those reports.


Successive calls to Must, Should, MustNot and Filter are not additive

Consider
var predicate = true;
var b = new BoolQueryDescriptor<Document>();

b.Must(m => m.Term(f => f.Field1, "value1"));

if (predicate)
{
    b.Must(m => m.Term(f => f.Field2, "value2"));
}

client.Search<Document>(s => s
    .Query(q => q
        .Bool(_ => b)
    )
);

this results in the following query
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "field2": {
              "value": "value2"
            }
          }
        }
      ]
    }
  }
}

The last call to .Must() overrides any previously passed queries. I know there are other ways to write this query to combine the two must clauses, for example
var predicate = true;

client.Search<Document>(s => s
    .Query(q => q
        .Bool(b => b
            .Must(
                m => m.Term(f => f.Field1, "value1"),
                m =>
                {
                    // intentional use of method group vs. expression
                    if (predicate)
                        return m.Term(f => f.Field2, "value2");

                    return m;
                }
            )
        )
    )
);

but the behaviour seems surprising for the simple usage case.
I propose to make the calls to .Must(), etc. be additive such that it would produce the following query
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "field1": {
              "value": "value1"
            }
          }
        },
        {
          "term": {
            "field2": {
              "value": "value2"
            }
          }
        }
      ]
    }
  }
}

Thoughts? /cc @elastic/microsoft

Big :-1: from me 😄
All .Fluent() assignments override just as Must = would. I'd hate to reintroduce exceptions to this rule like we had with Sort() in 1.x.
The first example as given to me reads: if (predicate) { do this must array instead }
You can rely quite easily on the bitwise operators to generate more dynamic queries.
.Bool(b=> q.Term() && q.Term()) with a multiline lambda to introduce branching or rely on condition less queries e.g .Bool(b=>q.Term && q.Term(field, predicate ? value : null)
Another mechanism in the client is q.Conditionless(query, fallbackQuery) construct that can be used to introduce branching.
Then you can mix and match OIS and Fluent queries where you build your mustclauses as a list dynamically and inject it in the fluent version.
.Must(MethodThatDynamicallyYieldsQueries.ToArray())
Loads of options here already IMO.

I can see argument in both directions to be honest. (This was probably spurred on by conversation between @russcam and myself on slack if I had to guess)
I can see the argument for some alignment with elastic APIs, but at the same time, seems like some of this doesn't appear to support "building" the way people are expecting to be able to use fluent builders. (or at least that's the case for me, compared to how I'd use a fluent builder in most other frameworks).
I've found the fluent and lambda stuff in nest to be fairly un-intuitive, even though I know roughly what to expect a query needing to look like, output wise from nest.
@Russcam gave me ideas about how to get around this for now, just thought I'd put in my .02c.

Appreciate the feedback @ronnyek , closing this out as we wont be changing the way the API's work.
I get your point though but for e.g simpler properties it will become rather ambiguous
.Field()
.Field()

The "proper" fluent builder interfaces would protect against this by having the first return a new instance of a closed builder that does not allow field to be set again. This would be super impractical for the amount of request classes we need for all the Elasticsearch APIs.
NEST was never designed to be a "proper" fluent DSL, rather a way to fluently assign. In that model the overwriting makes total sense IMO.


Globally remove advertisements from all pages

Hi,
Is is possible to remove the advertisements globally from all pages (e.g., posts) in order to user the full screen. I tried entering ads: false as shown below in _config.ymlbut it doesn't seem to have the desired effect.
# Site owner
owner:
  name:
  email:
  twitter:
  google:
    ad-client:
    ad-slot:
    ads: false
  bio:
  avatar: bio-photo.jpg # 160x160 px image for author byline

Yes it is. You need to modify the CSS as well. The main content container is set to span 9 out of 12 columns leaving 3 columns worth of space for ads (or anything else you'd like to stick in as a sidebar).
If you in change 9 to 12 in _layout.scss it should span the full width of the parent container.
#main {
	.inner-wrap {
		@include media($medium) {
			@include span-columns(12); // change 9 to 12
		}
	}
}

You might want to permanently remove {% if page.ads == true %}
{% include advertising.html %}
{% endif %} from each of the _layouts as well just to make sure ads aren't ever displayed, which would likely break the layout once you widen #main div.inner-wrap.

Cheers,
Got it up and running as desired. Thanks you for making this available!


range() is not returning proper results

Related: https://github.com/supabase/supabase/discussions/6753
Hi, How can we implement pagination with supabase and flutter, like when scrolled down 80% in a listview load next page, without knowing how many pages we have. can this be done without playing with limits?
I am trying to use range(start, end), but this is not working, every time, it's returning the same x rows, though it is supposed to return new rows with an updated range index.
like range(0,5), for first 6 rows, and range(6,106) for next 100 rows. it's the same for both. both times first 6 rows are being returned.
(289, 288, 287, 286, 285, 284) these are the ids for first 6 rows to be fetched, for next range, it is supposed to be 100 next rows, (284,283,. . . . . . . .  184 ).

Seems like It always pick first 6 rows:
     final response = await supabaseClient.from('Sales').select('''
     *,Customer:customer_id(id,last_name,first_name),Users:user(token,name,email).
     .filter('location_id', 'eq', appLocationController.currentLocation.value.id)
     .filter('created_at','gte',DateTime(start_date.year,start_date.month,start_date.day,0,0,0,0,0,).toIso8601String(),)
     .filter('created_at','lte',DateTime(end_date.year,end_date.month,end_date.day,23,59,59,999,9999,).toIso8601String(),)
     .range(range_from,range_to,)
     .order('created_at',).execute(count: CountOption.exact)

Closing as it was actually working properly.


Fix the read button goes out it's parent block (#1562)

Related Issue
Closes: #issue_number

issue number: (#1562)
Description
Made a minimal changes ensuring read button is inside a parent block.
Screenshots

Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

Add margin bottom to fully separate the button from the parent class. @0rigin-c0de

@akshitagupta15june can you approve this and  close this issue please ?


TOOL: Draft forms not getting deleted from table after delete button

Background: When draft forms are deleted the entry is persisting in the draft forms table. Potential impact to telework users
Steps to Reproduce: go to the draft forms tab and click on delete. After confirmation, the entry to the deleted draft form needs to disappear
Actual Behavior: The entry is persisting. If clicked on edit on the deleted entry it's taking users to an error 404 page.
Expected Behaviour: the entry on the table needs to get deleted as well.
Environment: DEV/TEST

@Stella-Archer This is ready for testing on TEST.
The fix has been applied to both drafts and submitted forms, so for testing please test deleting drafts and the submitted SL Review forms.
There is also an update to the Telework confirmation page after employee submission, changing 30 days to 60 days in one of the bullet points.

@iman-jamali-fw works great for draft forms in test

@iman-jamali-fw I don't have access to the SL leaders form in TEST so can't test the summitted form delete

@Stella-Archer  No worries. I added you to the ADM group. Could you try again to see have access?

Thanks @iman-jamali-fw I can access and deleting the submission worked fine >

successfully tested in PROD. Closing ticket


Changed config format from periods to underscores

This is done to match patterns seen around various cloud foundry projects
Signed-off-by: Huan Wang<EMAIL_ADDRESS>

@kcboyle Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@kcboyle Thank you for signing the Contributor License Agreement!

Some background on this for those coming in late. I changed the name of the Issue to I think better reflect the changes.
This would fix #189
It's not a change to the config schema, but rather a change to the generated placeholder parameter names when running config-template --include-placeholders

The underlying issue is that in #169, we added the support for --include-placeholder to the staged-config and config-template commands (https://github.com/pivotal-cf/om/commit/7d0cf8140f7a5f7aa9b94a2bf6ffc689a484e124). The naming scheme of the generated placeholders started off by being ((.properties.some-property.value)).
Then later in #181 this got changed to ((properties_some-property.value)), but only for the staged-config command. There was a discrepancy that existed after that got fixed where config-template was still generating them using the other format.
I asked @kcboyle to add to this PR by making the two dependent on the same "PlaceholderGenerating" logic.

Closing as we do additional work


Add a slider for changing the logo's size

Info
Add a slider for changing the logo's size using a scale value. Reference: #36
Library used: https://github.com/tajo/react-range
Preview

Update


[Firefox] Firefox 51 Beta and 52 Developer Edition come with some important changes

https://www.fxsitecompat.com/en-CA/blog/2016/firefox-51-beta-and-52-developer-edition-come-with-some-important-changes/

Nothing crazy new here that our other issues don't cover.


Client / Server crash

Issue description:
The Server and the Client in Singleplayer crashes if you place a Wind generator on a place where it has Sky and right click it.
Steps to reproduce:

Go in Singleplayer
place a Wind generator on a place with Wind
right click it

Version (make sure you are on the latest version before reporting):
**Forge: 1.12.2 -<IP_ADDRESS>97
Mekanism: All Latest
If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)
https://pastebin.com/XC98euZX (Singleplayer)

I found this now: https://github.com/aidancbrady/Mekanism/issues/4842
I will have a look at it. Sorry.

Now it Works!
:)


"--fine_grained"  has some problems when runing vaitrace on KV260, vitis 3.5,

The profiler works normally when I run python3 -m vaitrace_py --fine-grained test_accuracy_core1.py resnet5000.xmodel
xmodel is complied by vitis3.5
ERROR:root:This xmodel does not support fine grained profiling
How does one enable the fine-grained profiling on an xmodel?
Is anyone solved this problem?
The following reference is not work on KV260.
https://github.com/Xilinx/Vitis-AI/tree/v3.5/examples/vai_profiler
https://docs.xilinx.com/r/en-US/ug1414-vitis-ai/Vitis-AI-Profiler?tocId=Luv7e02rhpEpdYpzLa0cpg
same problems
https://github.com/Xilinx/Vitis-AI/issues/1279

To use fine grained profiling debug mode needs to be enabled when compiling the xmodel.
Recompile the model in the vai compiler and add the following  option: --options "{'mode':'debug'}"
The default option for mode is 'normal'. Using debug mode can slightly reduce the model performance by a few percent and its recommended to set this back to normal when after you are done profiling.

Yes, use: vai_q_tensorflow2 -m quantized_model.h5 -a /opt/vitis_ai/compiler/arch/DPUCZDX8G/KV260/arch.json -o dpu_deploy.xmodel --options "{'mode':'debug'}"

I recompile the xmodel, and run it in --fine_grained, the results are not in expectations, I'm not sure if there are any other solutions.  I have unified all versions to Vitis ai2.5
vai_c_tensorflow2 -m quantized_model.h5 -a /opt/vitis_ai/compiler/arch/DPUCZDX8G/KV260/arch.json -o dpu_deploy.xmodel --options "{'mode':'debug'}"

VITIS_AI Compilation - Xilinx Inc.

[INFO] Namespace(batchsize=1, inputs_shape=None, layout='NHWC', model_files=['quantized_model.h5'], model_type='tensorflow2', named_inputs_shape=None, out_filename='/tmp/deploy_DPUCZDX8G_ISA1_B4096_org.xmodel', proto=None)
[INFO] tensorflow2 model: /workspace/workspace/rff_fpga_workspace/resnet_fpga_rff_5000/quantized_model.h5
[INFO] keras version: 2.6.0
[INFO] Tensorflow Keras model type: functional
[INFO] parse raw model     :100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 51/51 [00:00<00:00, 54154.30it/s]
[INFO] infer shape (NHWC)  :100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 83/83 [00:00<00:00, 44608.82it/s]
[INFO] perform level-0 opt :100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00, 294.54it/s]
[INFO] perform level-1 opt :100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:00<00:00, 1286.00it/s]
[INFO] generate xmodel     :100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 83/83 [00:00<00:00, 5635.59it/s]
[INFO] dump xmodel: /tmp/deploy_DPUCZDX8G_ISA1_B4096_org.xmodel
[UNILOG][INFO] Compile mode: dpu
[UNILOG][INFO] Debug mode: null
[UNILOG][INFO] Target architecture: DPUCZDX8G_ISA1_B4096
[UNILOG][INFO] Graph name: model, with op num: 165
[UNILOG][INFO] Begin to compile...
[UNILOG][INFO] Total device subgraph number 3, DPU subgraph number 1
[UNILOG][INFO] Compile done.
[UNILOG][INFO] The meta json is saved to "/workspace/workspace/dpu_deploy.xmodel/meta.json"
[UNILOG][INFO] The compiled xmodel is saved to "/workspace/workspace/dpu_deploy.xmodel/deploy.xmodel"
[UNILOG][INFO] The compiled xmodel's md5sum is d4223604745d48da5f4de8069d5ec89b, and has been saved to "/workspace/workspace//dpu_deploy.xmodel/md5sum.txt"
python3 -m vaitrace_py --fine_grained test_accuracy_core1.py deploy.xmodel
WARNING:root:The fine grained profiling model is enabled. Models will be run subgraph-by-subgraph.

It will interduce significant scheduling and memory access overhead, especially for small models.
Some xcompiler's optimizations will be turned-off.

INFO:root:VART will run xmodel in [DEBUG] mode
Analyzing symbol tables...
61 / 61
81 / 81
6 / 6
45 / 45
3 / 3
INFO:root:vaitrace compile python code: test_accuracy_core1.py
INFO:root:vaitrace exec poython code: test_accuracy_core1.py
['test_accuracy_core1.py', 'deploy.xmodel']
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0311 18:56:16.364677  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block1_conv has no mc_code
I0311 18:56:16.364840  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block2_1_conv1 has no mc_code
I0311 18:56:16.364879  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block2_1_conv2 has no mc_code
I0311 18:56:16.364918  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block2_2_conv1 has no mc_code
I0311 18:56:16.364955  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block2_2_conv2 has no mc_code
I0311 18:56:16.364997  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block3_1_conv1 has no mc_code
I0311 18:56:16.365039  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block3_1_conv2 has no mc_code
I0311 18:56:16.365082  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block3_1_shortcut has no mc_code
I0311 18:56:16.365120  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block3_2_conv1 has no mc_code
I0311 18:56:16.365159  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block3_2_conv2 has no mc_code
I0311 18:56:16.365197  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block4_1_conv1 has no mc_code
I0311 18:56:16.365236  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block4_1_conv2 has no mc_code
I0311 18:56:16.365274  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block4_1_shortcut has no mc_code
I0311 18:56:16.365314  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block4_2_conv1 has no mc_code
I0311 18:56:16.365355  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block4_2_conv2 has no mc_code
I0311 18:56:16.365394  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block5_1_conv1 has no mc_code
I0311 18:56:16.365435  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block5_1_conv2 has no mc_code
I0311 18:56:16.365476  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block5_1_shortcut has no mc_code
I0311 18:56:16.365520  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block5_2_conv1 has no mc_code
I0311 18:56:16.365562  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Block5_2_conv2 has no mc_code
I0311 18:56:16.365604  2135 dpu_kernel.cpp:178] child_name subgraph_quant_flatten_fix_reshaped has no mc_code
I0311 18:56:16.365641  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Dense_dense(TransferMatMulToConv2d) has no mc_code
I0311 18:56:16.365684  2135 dpu_kernel.cpp:178] child_name subgraph_quant_Dense_dense(TransferMatMulToConv2d)_inserted_fix_2_reshaped has no mc_code
Number of RF Samples Tested is  3499
Batch Size is  1
Top1 accuracy =  0.0286
Pred Performance =  100
identification_time_per_slice=0.0006, total time = 2.0432 , total slice = 3500.0000
INFO:root:vaitrace timeout, waiting for Python thread terminated
APM Stop Collecting
INFO:root:Generating VTF
INFO:root:Processing xmodel information
INFO:root:[vart_trace.csv]: Events number: 0

What results were unexpected, are you referring to the bad Top1 accuracy you are getting?

there are errors in the log. address that there is no mc_code. if i run it without —fine_grained，there only 1 layer information and the accuracy will be normal
| |
TianTian Zhang
|
|
@.***
|
---- Replied Message ----
| From | Jim @.> |
| Date | 03/12/2024 23:45 |
| To | Xilinx/Vitis-AI @.> |
| Cc | TiantianZhang @.>,
Author @.> |
| Subject | Re: [Xilinx/Vitis-AI] "--fine_grained" has some problems when runing vaitrace on KV260, vitis 3.5, (Issue #1412) |
What results were unexpected, are you referring to the bad Top1 accuracy you are getting?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Update UG

Previously, user guide did not include command summary for income, as well as image of output for income command
Let's
*include income in the command summary, as well as include images of output for income command

Can you help include the exit command in the Command Summary also, please?

Okay I will do that


React: Storybook - Add/enable Customizable the 8-bar IBM logo on react version.

Detailed description
Issue:
Add Customizable the 8-bar IBM logo on react version.
Additional information

@RobertaJHahn @Praveen-sr This was completed in https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/4878


Update bundler

Fixes #208

Run docker exec code-snek bundle config set with 'dev' && docker exec code-snek bundle config unset frozen && docker exec code-snek bundle update && docker exec code-snek /bin/bash -c 'script/test djdefi'
  docker exec code-snek bundle config set with 'dev' && docker exec code-snek bundle config unset frozen && docker exec code-snek bundle update && docker exec code-snek /bin/bash -c 'script/test djdefi'
  shell: /usr/bin/bash -e {0}
Setting `with` to [:dev] failed:
 - a group cannot be in both `with` & `without` simultaneously
 - `without` is current set to [:dev]
 - the `dev` groups conflict
Error: Process completed with exit code 1[5](https://github.com/es-na-battlesnake/snakes/runs/6928248560?check_suite_focus=true#step:13:6).

Not really sure I understand this since it is working fine in https://github.com/es-na-battlesnake/snakes/pull/207
Might try docker exec code-snek bundle config unset without  in the Rspec test.


I volunteer for French translation

Feature request
Linked to https://github.com/nordicopen/easee_hass/issues/374

If you create a French locale on Lokalise, I can do my part and translate it into French 😄
While creating this issue, I want to take the opportunity to thank you and all the contributors for this integration with Home Assistant 👏 🎉
What version of the integration are you using?
0.9.59
Anything in the logs that might be useful for us?
No response
Additional information
No response

@alepee Thank you. French (fr) is now open for translation.

And I think I'm done :) I needed to search a few things within the codebase to better understand the context.
Just to be sure, "Idle current" refer to
1.	Courant de repos : The current that flows in a circuit when it is powered on but not supplying any active load. It is often the minimum current required to keep a device operational, ready to respond to a demand.
2.	Courant à vide : The current consumed by a device or circuit when it operates without any connected load. It is the current drawn in the absence of an active energy demand.

Despite this one it should be ok

That was fast!
The term "enable idle current" is used by Easee to ensure that the car can get up to 6A for heating/cooling even when it it not charging. It is only relevant if there are more than one charger in a circuit. In the swedish translation we have used "Viloström" which is translated literally to "Resting current".
The french translation will be included in next release of the integration.

Ok, so "Courant de repos" seems to fit best :)


Feature/setup django oidc

WIP
Companion to WorldBank-Transport/DRIVER#183 for django-oidc configuration.
The template files here were pulled directly from the django-oidc project directory; its template files were not auto-discovered by Django. We'll probably want to override their styling, anyways.

Superseded by WorldBank-Transport/DRIVER#322


chore: enable yarn.lock maintenance

Types of changes

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

Description
Related docs for Renovate: https://renovatebot.com/docs/configuration-options/#lockfilemaintenance
Will keep the lock files fresh after dep updates.
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

Codecov Report

Merging #5063 into dev will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff          @@
##            dev   #5063   +/-   ##
====================================
  Coverage    95%     95%
====================================
  Files        72      72
  Lines      2421    2421
  Branches    614     614
====================================
  Hits       2300    2300
  Misses      101     101
  Partials     20      20

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 b1753e4...2f8203f. Read the comment docs.

AWESOME

I'm not sure if all repos need this options, so only add in nuxt.js for now.


Updated default hosts + checking for if running locally

Codecov Report

Merging #43 into develop will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff            @@
##           develop      #43   +/-   ##
========================================
  Coverage    26.62%   26.62%
========================================
  Files           16       16
  Lines         1720     1720
========================================
  Hits           458      458
  Misses        1204     1204
  Partials        58       58

Impacted Files
Coverage Δ

server/mixnode/mixServer.go
0% <0%> (ø)
:arrow_up:

server/provider/providerServer.go
17.54% <0%> (ø)
:arrow_up:

helpers/network.go
0% <0%> (ø)
:arrow_up:

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 eaac487...081a3ee. Read the comment docs.


update admin role has error

WriteError{code=121, message='Document failed validation'

Thanks for reporting. The bug has been fixed on both develop and master branches, and you can pull the latest docker images to have a try.


Delete IAM login profile during user delete

Without this change, IAM user deletion fails if the account has MFA
tokens, passwords set, or other access keys assigned to the account.
Here we remove the login profile, access keys, and associated MFA tokens
for the user account.  This allows successful removal of the account.

Hold on.  This is incomplete.  I will update after I've completely removed a user from my account.

I've updated the commit and the message to accurately reflect the change.  This is the work that was required to remove a user from my environment.


ConvertedNavigableMap.get() can return null

^ I don't know why the thing thinks there is nothing in the map. I'll try to debug to a solution for that separately.
However, this method returning null is at odds with example usages from the documentation. Like so:

Not sure what you're asking here... of course a Map is supposed to return null if there is no value corresponding to the given key.
In ConvertedNavigableMap, it is assumed that null always converts to null. So if the wrapped Map returns null for a given wrapped key wkey, then the outer Map should also return null.
Regarding the unit test examples, they all "know what they are doing" in assuming that the key is present in the map.

No you're right. Even the examples in the Introduction wiki page are null checking.


[SPARK-10395] [SQL] Simplifies CatalystReadSupport

Please refer to [SPARK-10395] 1 for details.

Merged build triggered.

Merged build started.

Test build #41870 has started for   PR 8553 at commit d7173a9.

Test build #41870 has finished for   PR 8553 at commit d7173a9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/41870/
Test PASSed.

Merged build triggered.

Merged build started.

Test build #42412 has started for   PR 8553 at commit d8a1ba4.

Test build #42412 has finished for   PR 8553 at commit d8a1ba4.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42412/
Test FAILed.

Merged build triggered.

Merged build started.

Test build #42543 has started for   PR 8553 at commit 4dfab07.

Test build #42543 has finished for   PR 8553 at commit 4dfab07.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/42543/
Test PASSed.

LGTM

Merged into master, thanks!


add email update alerting

add email_alert.py, which will send an email to alert when a new paper that does not exist in ./docs/cv-arxiv-daily.json is searched and the email will look like this

Please delete temp json files and solve conflicts.


x/tools/gopls: inaccurate completion results for partial function call syntax inside an if condition

Reported on Slack:
When typing out a function call inside an if condition, gopls provides incorrect completion results, apparently due to inferring that it is completing a type name:

Generally gopls struggles with partial syntax and imbalanced delimiters, but in this case specifically it seems like we can do better. For example, the same syntax outside of an if condition generally works.

Looked briefly. We have a source fix that adds missing "{}" curlies to *ast.BlockStmts that are missing curlies in the source. Things parse really poorly when curlies are missing, and this helps. However, in this case with the closing paren missing, we convert this:
if foo(bar

Into:
if foo(bar{}

After parsing, "bar{}" looks like a composite literal, so we expect a type name.
If I were to not think very hard and do something, it would be to add another pass to stick missing closing parens in the source. But, all these fixes have really turned into a mess. Maybe a better workaround is to disable the only-offer-type-name-candidates filtering if we have doctored the source.

Thanks for looking into this Muir.  I think disabling the filter makes sense.
Aside: don't feel obligated to send a CL. We can take care of it! :)


[BUG] fix int64-int32 types comparison

Fix bug which fails CI (comparison of size_t and int64_t values)
cc @tqchen

T5hanks @vvchernov . this is fixed in another commit


Need to support hardware variants with multiple possible ECC locations

It turns out that Syncrobit miners have several possible locations for the ECC key on the i2c bus...
https://github.com/NebraLtd/helium-syncrobit/issues/2
We should add handling for this scenario

mfr throws exec error if we try to read a slot that is not programmed before.
root@78eef93a415c:/opt# ./python-dependencies/hm_pyhelper/gateway_mfr_aarch64 --device 'ecc://i2c-7:96?slot=5' key
Error: ecc608 error

Caused by:
    ecc error ExecError

Between i2cdetect and cycling through the slots, we can probably find out the correct combo. Assuming that multiple slots were not programmed.

@pritamghanghas sadly I've found that sometimes multiple are programmed. See output here...
https://github.com/NebraLtd/helium-syncrobit/issues/2#issuecomment-1427342499

Also, currently the i2c address on the bus is hard coded in diagnostics - https://github.com/NebraLtd/hm-diag/blob/master/hw_diag/utilities/hardware.py#L235
This address is 0x60 / decimal 96 which is in the swarm key uri already for example ecc://i2c-1:96?slot=0
We should change this also at same time
Ref - https://github.com/NebraLtd/hm-diag/issues/500

This will also need significant updates in:

hm-miner
hm-block-tracker

Ref https://github.com/helium/onboarding-server
Ref https://onboarding.dewi.org/api/v2/hotspots/11n6ApbTNiNhCLf84Hm3mZGDyqNhP83dsj4Cvj2juTXuKD7byf


Improve release notes for 3.4.1

Add clear migration instructions for custom script paths

Thanks!


The software linked in your paper has a faulty url

This is the url that you're redirected to if you try to download the software ( the one mentioned in your paper )
http://ima.mgedata.cn/static/software/ImageAnalysis_V_1      .4_Setup.exe
To download it you've have to delete te %20 part , could you fix it for the other people who can't figure out why they're redirected to a 404 page?
It would mean a lot for me, also because I want to cite your software in my thesis.

Thank you for your advisement. I have fixed that url

❤

If I must I'll say something else :

https://www.mgedata.cn/app_entrance/microscope , when you press the "en" button doesn't translate;
the setup of the installer is only in chinese;
after you've successfully installed the software it doesn't open anything, does it work for you?

Thank you for your advice. The software in 'https://www.mgedata.cn/app_entrance/microscope' asks you to upload data to exchange for the software license. Recently, we will publish a new version of MicroStitch with a new stitching algorithm and safely software license. All the questions that you proposed will be handled in the latest version. If you like, I will invite you to test software after software online.

Oh, ok, didn't know that.
Well, it depends on if I'm available, I'm quite tight on schedule until March 😄, but you can contact me anyway.
Thank you for your work,
Best regards,
@Edodums


Install pip3 on jump / bastion for running Viya4-ARK

The jump / bastion host already has python 3, but is missing pip3.
This is required to run the Viya4-ARK: https://github.com/sassoftware/viya4-ark.
I manually installed for now with:
sudo apt update
sudo apt install python3-pip

Given OS version using Snap install, installing all the packages in requirements.txt would do, I'd think.

I would continue to use the apt tools as Snap does not always have the outcome one desires. As a side note, python3 is not the default python version on the Jump box, 2.7 still is setup as the default. If needed the alternate option needs to be setup to force python3 as the default on this system.

Do I need to do a fork and PR for this to be included ... or are you saying that someone will add using apt like I indicated above?

I believe there is already a section in the cloud-init script to add packages it could be added there. Yes as a clone/fork and PR would be appreciated.  Will there be a focus on making python3 the default on the vm once it's active?

I can look at that, I cannot recall offhand if I had to make it the default or if I just ran the commands as python3 ...

I've done this on Ubuntu before here are the commands:
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1
sudo update-alternatives --install /usr/bin/pip pip /usr/bin/pip3 1

In talking with Norm on this one, the IAC code base will install only docker. That will be the extent of the 3rd party tooling installation on the Jump VM. If folks want to enhance the server on their own, they can.


Users connecting form an unknown source

Hi,
I have seen recently that there are many users who connect from this address "https://smba.trafficmanager.net/apis/" Which platform is it? or how are they connecting my bots from this address?
Can anyone Help?

Hi @alokraj68, this is the Skype service.

Closing as we've answered the question. Please at-mention or open a new issue if you'd like to discuss further.


Python: Verify that Ollama and LLM Studio work

Ollama and LLM Studio should work with the current OpenAI connector but we need to verify this.

This is a good opportunity to update our connector to use the Ollama Python SDK, which we aren't using right now.

https://github.com/ollama/ollama-python

This is a good opportunity to update our connector to use the Ollama Python SDK, which we aren't using right now.

Item that tracks the migration: https://github.com/microsoft/semantic-kernel/issues/6841#issue-2363075660


Use short array syntax

as the travis build targets php version 4 and 5 i think it is safe to use the short array syntax in this repo?! no?
//cc @EvanDotPro @Hounddog

Some factors to consider:
Packagist stats:
Overall: 1,159 installs
30 days: 270 installs
Today: 10 installs

We've had "php": ">=5.3.3" in composer.json since the beginning.
I think it's fair to assume that developers relied on the composer requirements rather than looking to see what versions the travis builds covers (which should cover all versions in compser.json).
Conclusion: There's likely some number of 5.3 applications in the wild that are already built around this module that will break. Maybe 10. Maybe 2. Maybe 0.
So, I guess it depends on how sympathetic you're feeling, and how badly you want those short arrays. :smile:
Honestly, I don't have a strong opinion on this at all, so I'll happily roll with the majority opinion.

@ins0 In my opinion the short array syntax is not a good way to lose the 5.3 version :skull:

yeah wasn't thinking about this


Flushing cache not working for ApcCache

I used yii\filters\PageCache to cache some actions and ApcCache is being used. When i run yii cache/flush-all, the page is still cached. I even cleared the runtime folder and still nothing.

APC or APCu?

APC.

What's PHP version?

PHP 5.6.4-4ubuntu6.4 (cli) (built: Oct 28 2015 01:21:29)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies

Wait, you have OpCache, right? Are you sure you're using APC and not APCu?

Just checked it, yep it's APCu.

Do you have cache configured for your console app?

The cache config is in my common configuration. So it's for everything. Should i move it?

No, that should be fine.

So anything i can do to fix this?

Don't know. I see no obvious mistakes. Will check it after 2.0.7 release.

Ok that seems good.

Not time to verify for 2.0.8, moving to next release.

http://stackoverflow.com/questions/12860487/is-apc-opcode-cache-shared-between-php-fpm-pools-workers

Internet has a lot of discussions that calling apc_cache_clear() in CLI does not clear opcode caches from "web" PHP processes, whether they are run inside Apache or by FPM (see How to clear APC cache entries? ). As a suggested solution, it's possible to create a simple PHP page that calls apc_cache_clear(), and call that from CLI.

thanks @rob006

This definitely should be documented. AFAIK APC(u) cache doesn't really work in CLI, because CLI process can not share cache with other process. So each command use only cache which itself generated.

Documented.


User story:  Tubular Object - Frontend Edit/Delete

As a Data Manager, I want to be able to edit and delete the tubular object in WE
Acceptance criteria

[ ] The WE  frontend is extended to support edit and delete operations on  the Tubular object

Also, here are a few points that need to be addressed:

[ ] Constraint 1
[ ] Constraint 2

Resources

Resource A
Resource B

Implemented through PR #1228
closing