services/horizon/ingest: RebuildTradeAggregationBuckets cannot be invoked concurrently during parallel ingestion

What version are you using?
build from latest on master
What did you do?
Run parallel reingestion jobs,
What did you expect to see?
RebuildTradeAggregationBuckets() should work without error given parallel workers.
What did you see instead?
RebuildTradeAggregationBuckets() cannot be invoked concurrently during parallel ingestion because there will be duplicate key constraint errors when two workers invoke the function on adjacent buckets. That is because the buckets occur on minute boundaries and two adjacent ledger ranges will share the same trade aggregations bucket.
This can potentially be fixed by modifying parallel reingestion so that the trade aggregation buckets are built once all the workers have completed their ingestion jobs.
related to #5099

This can potentially be fixed by modifying parallel reingestion so that the trade aggregation buckets are built once all the workers have completed their ingestion jobs.

the suggested solution will work if one reingestion job is running parallel workers on a single  host machine against the one horizon db. However, if two reingestion jobs are running, each job running on a separate host machine, and the jobs are running adjacent ledger ranges to each other, than the same error related to trade agg rebuild can still occur on one of the jobs, whichever one tries to commit to the db last.
error="Error rebuilding trade aggregations: could not rebuild trade aggregation bucket: exec failed: pq: duplicate key value violates unique constraint \"history_trades_60000_pkey\

@mollykarcher , I'm wondering if rather than trying to patch this at the various levels, adding complexity, what if we go the other way and lower complexity by just removing the trade aggregation bucket rebuild attempt from any horizon db reingest range, and add a new sub-command horizon ingest trigger-tradeagg-rebuild which follows existing similar pattern of user initiated sub command to rebuild state horizon ingest trigger-state-rebuild ?

@sreuland was this issue introduced with the changes on 2.28 or did this issue always exist? I know it was called out / referenced here but the wording (....bugs will need to be addressed when implementing this issue) makes it sound as if these were already present issues.
As an aside, is there a good reason that the trade aggregation buckets need to be aligned/bucketed by minutes instead of by ledger? I would think we could achieve the same thing if we bucketed by ledger, and do the to-minute (or whatever unit of real time) conversion on the user request side, and that would also alleviate this issue. I understand this might be more involved (and potentially break the interface) and so not sure it's something we'd want to tackle right now.
Of the two options you presented, I think 1 is the significantly better choice. I think it would actually be nice to have support for trade aggregations be an explicit/intentional opt-in by the Horizon operator (and I actually think not many operators would want to use it). I do worry about people being really confused by this though, given it's a new step we're introducing and they're likely to forgot/skip it. Would there be any way that we could be aware of this state (trade-aggs not properly rebuilt yet) after a reingest and either disable or return some error code on /trade-aggs, rather than junk data?

@mollykarcher , The trade agg bucket rebuild issue with parallel workers was pre-existing prior to 2.28/ingestion perf overhaul.
I think, these may be complementary iterations, and propose moving forward with:
first pass, this ticket, fix the parallel workers as suggested to do trade agg rebuild once at end rather than each worker doing a trade agg rebuild, this will go to 2.28.0 release
second pass, create a new ticket refactor tradeagg buckets to align on ledger boundary to capture your suggestion of changing the alignment to lower complexity for processes to use it above, this will enable parallelism in terms of tradeagg functionality, such as now can run multiple rebuilds with adjacent ledger ranges on same machine or distributed. this would be planned to go in later horizon release.

merged https://github.com/stellar/go/pull/5168


adding Open Source section

💥 Proposal
adding a opne source section in mindwave so user can get started with open source
can you assign this to me, I want to work on this under GSSoC'23

@LegendSumeet - please elaborate on your PoA for this section. Thanks!

i will just a open source folder as well which consit of how to get started with it and git github how to use this tools in open source with tutorails which helps any one who visit your repo can get info about the open source

@LegendSumeet - you can go ahead! You can create a new markdown file named CONTRIBUTING.md  which we will then link to the main README file.

okay sure

Hey @khusheekapoor  I would like to add a open source  section as a GSSOC contributor ,it would be great if you could assign me with the issue


create wranger action.yml

All right, sorry for changing things around while you were on it

No problem


Verify before restore

What is the purpose of this change? What does it change?

extract the operations done by the --verify option into function of Restorer
verify the content of a node before restoring it (skip if already matching)

Was the change discussed in an issue or in the forum before?
https://github.com/restic/restic/issues/2011
Checklist

[x] I have read the Contribution Guidelines
[ ] I have added tests for all changes in this PR
[x] I have added documentation for the changes (in the manual)
[x] There's a new file in changelog/unreleased/ that describes the changes for our users (template here)
[x] I have run gofmt on the code in all commits
[x] All commit messages are formatted in the same style as the other commits in the repo
[x] I'm done, this Pull Request is ready for review

Codecov Report

Merging #2012 into master will decrease coverage by 4.8%.
The diff coverage is 21.42%.

@@            Coverage Diff             @@
##           master    #2012      +/-   ##
==========================================
- Coverage   50.12%   45.31%   -4.81%
==========================================
  Files         169      169
  Lines       13563    13569       +6
==========================================
- Hits         6798     6149     -649
- Misses       5742     6466     +724
+ Partials     1023      954      -69

Impacted Files
Coverage Δ

internal/restorer/restorer.go
47.79% <21.42%> (+2.4%)
:arrow_up:

internal/backend/b2/b2.go
0% <0%> (-78.95%)
:arrow_down:

internal/backend/swift/swift.go
0% <0%> (-78.45%)
:arrow_down:

internal/backend/gs/gs.go
0% <0%> (-73.61%)
:arrow_down:

internal/backend/azure/azure.go
0% <0%> (-69.46%)
:arrow_down:

internal/backend/swift/config.go
36.95% <0%> (-54.35%)
:arrow_down:

cmd/restic/cmd_mount.go
12.98% <0%> (-44.16%)
:arrow_down:

internal/checker/checker.go
64.54% <0%> (-3.87%)
:arrow_down:

internal/archiver/file_saver.go
81.57% <0%> (-2.64%)
:arrow_down:

internal/archiver/blob_saver.go
92.59% <0%> (-2.47%)
:arrow_down:

... and 2 more

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 0882aca...60dc0f4. Read the comment docs.

I suggest this wait until after #1719

Indeed, @ifedorenko is right: This needs to wayt until #1719 is merged.

That's been merged now but there's conflicts.

That's expected: #1719 changed the same code. This needs to be resolved, preferably by @stang :)

Few notes/observations

I suggest to make verify-before-restore behaviour optional. For example, it is likely to slow down restore if the target file system is on 2.5" laptop hdd (i.e. slow mechanical disk) and the backend is on fast 1Gbps connection.
I think we should investigate if pre-restore file content verification should run on single or multiple threads. This likely depends on the of disks and filesystem used but I don't know if we should use different concurrency strategy on ssd vs hdd, for example.
It may be desirable to implement verify-before-restore at blob level, which will allow to resume interrupted restore and incremental restore of large files.
We need to decide what to do with existing files that are not part of the snapshot, i.e. should restore delete or keep them?

Sorry, I was on holiday for a little while.
I'll try to have a look and update this PR, taking @ifedorenko inputs in consideration.

Superseded by #3425.


_entrypoints.py, _scenario_1.py, and _scenario_2.py are unused

Describe the bug
I cannot find any instance where a file imports from _entrypoints.py, _scenario_1.py, or _scenario_2.py, and pytest does not pick them up.
To Reproduce
Steps to reproduce the behavior:

Enumerate pytest tests and observe that the files in question are not present
Use vscode search/grep or similar to check for mentions of the filenames in the project and observe that they are never mentioned

Expected behavior
Are these tests intended to be used? If they are but are just out of commission right now perhaps we can add a comment to them to explain their situation for people looking at them.
Desktop (please complete the following information):

RAiDER git tag:
commit a9bf37cc1b82bc1837860a29a368ad22e6c7e96a (HEAD -> dev, tag: v0.5.3, upstream/main, upstream/dev, upstream/HEAD)
Merge: 2a34802 2d5eb95
Author: Charlie Marshak<EMAIL_ADDRESS>Date:   Tue Jul 30 11:17:05 2024 -0700
    Merge pull request #678 from dbekaert/dev
    v0.5.3
OS: Arch Linux <IP_ADDRESS>-microsoft-standard-WSL2 on Windows 10

@garlic-os I believe the intent with these tests was to temporarily disable them by removing the test prefix from the file name -- e.g., test_entrypoints.py was renamed to _entrypoints.py here:
https://github.com/dbekaert/RAiDER/pull/364#issuecomment-1297635852
test_entrypoints.py at least should be re-enabled to test that these CLI entry points all do exist and are installed properly:
https://github.com/dbekaert/RAiDER/blob/dev/pyproject.toml#L44-L51

@garlic-os yes that's correct, these tests were temporarily disabled due as these were end-to-end tests that were downloading files at testing time instead of mocking and/or using cached files, with the result that they would hang if for example one of the weather model servers was out of commission. Some of these have been replaced in part by other tests (e.g., test_synthetic) but not fully. Eventually we'll need to re-visit and integrated them with the new tests that have been introduced.


test: add cairo0 to integration test

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.66%. Comparing base (e26cb96) to head (e2adcf5).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #273      +/-   ##
==========================================
+ Coverage   78.64%   79.66%   +1.02%
==========================================
  Files          26       26
  Lines        1194     1200       +6
  Branches     1194     1200       +6
==========================================
+ Hits          939      956      +17
+ Misses        201      190      -11
  Partials       54       54

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Integration

Works great with the princess kettle. Are there plans to implement this into one of the known home automation software packages i.e.  HA or Domotics?

Hi @DieterKoblenz,
This is currently integrated in my Home Assistent setup using custom_components.
I'll put it on GitHub later today & update this issue

Hi Lesley, any update?

Yes, I was looking into this but it stopped working locally due to a dependency mismatch with my module & HomeAssistant.
In the mean time you can check out this which @ghys made.
It uses Homie IoT which you can integrate into HomeAssistant
If I fixed the dependency issue I'll update you as well

Thank you, I'll look into it!

Hi Dieter,
If you still require a solution, I just released my HomeAssistant HACS Integration
Kr,
Lesley

Thanks Lesley! Awesome.


Terminal accessible buffer shows resolved aliases

Testing #174625

This is what I ran

blocked by #166501

We're moving to showing the full raw buffer in a monaco instance which will fix this.


KeyError: "Unable to open object (Object 'image_features' doesn't exist)"

I followed the example (http://fuel.readthedocs.io/en/latest/h5py_dataset.html) and got this error.
Traceback (most recent call last):
File "train.py", line 55, in
tr_data, te_data, tr_stream, val_stream, te_stream = faces(ntrain=ntrain)
File "/home/sandbox/dcgan/faces/load.py", line 12, in faces
tr_data = H5PYDataset('11230_128px.hdf5', which_sets=('train',))
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/hdf5.py", line 188, in init
self._parse_dataset_info()
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/hdf5.py", line 228, in _parse_dataset_info
self.vlen_sources = self.get_vlen_sources(handle)
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/hdf5.py", line 379, in get_vlen_sources
source = h5file[source_name]
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/tmp/pip-4rPeHA-build/h5py/_objects.c:2684)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/tmp/pip-4rPeHA-build/h5py/_objects.c:2642)
File "/usr/local/lib/python2.7/dist-packages/h5py/_hl/group.py", line 166, in getitem
oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/tmp/pip-4rPeHA-build/h5py/_objects.c:2684)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/tmp/pip-4rPeHA-build/h5py/_objects.c:2642)
File "h5py/h5o.pyx", line 190, in h5py.h5o.open (/tmp/pip-4rPeHA-build/h5py/h5o.c:3570)
KeyError: "Unable to open object (Object 'image_features' doesn't exist)"

I just run this example and it worked without any problems. Make sure that you follow all the steps. Try to ask the mail list list for help to put your data into h5py. If you still think that it is a bug in fuel, feel free to reopen, but please provide the minimal code to reproduce it and more information about your system.


feat(schema): Encode qMRI metadata requirements

This updates the schema in the maintenance branch, as this does not change the meaning of the specification. This also fixes a minor bug in the specification text, although we don't have a method to rerender it.
Fixes #2018.

Hi Chris! Yes, this sequence has interleaved TRs, and both of them are of type RepetitionTimeExcitation.
Should we explicitly mention excitation component wherever possible?
https://bids-specification.readthedocs.io/en/stable/appendices/qmri.html#tb1afi-specific-notes


chore: replace puppeteer for playwright

With a little bit of finagling, the migration to playwright was relatively straightforward (compared to my last attempt, where I was trying to also integrate vitest as well).
I'll be leaving some comments attached for reasons behind specific changes.

hmm, have a little bit of a conundrum here. it looks like CI is failing here because i forgot to install the browsers, but I'm also trying to avoid touching the workflows here to prevents conflicts with the other PR 😅
i think we can temporarily solve both by adding the postinstall script back in here, like: "postinstall": "playwright install chromium", and then adjust the workflow files in the other PR accordingly after this PR has merged
what do you think @benmccann?

Sounds fine to me. Thanks again for doing this!!

@AdrianGonz97 As for your comment regarding vitest, that's what I initially tried to implement after seeing that uvu has some serious problems with multithreading
But since vitest is bundeling everything on it's own, I had serious problems with all the shebangs required in the clis. That's why i decided to leave it as is and implement some custom logic for testing.

i think we can temporarily solve both by adding the postinstall script back in here, like: "postinstall": "playwright install chromium", and then adjust the workflow files in the other PR accordingly after this PR has merged

@AdrianGonz97 Both PRs are now merged, you can now proceed with this change. Keep in mind that if someone checks out the repo for the first time, it test's should still be working for that person. Same goes for consumers of @svelte-add/testing-library that can be consumed separately, i.e. as part of a community adder (template)


build sw runtime with user's wheel packages

wheel files in code repo

https://github.com/star-whale/starwhale/pull/766


Permanently syncing and logout doesn't work

Issue description
After sending some Funds from Account 1 to Account 2, the balance of Account 1 was negativ.
Try to logout to check the other account... Logout Button does not work.
Wallet version
0.2.1
System specification
macOS 11.2.2
Is it a repeatable issue?
not sure
Steps To reproduce the issue
Explain how the maintainer can reproduce the issue.

install firefly
finish init process
request tokens from faucet
Logut (button is working fine)
create secound account
Copy RX-Adress from second account
Logout from 2. account
Login into firs account
send some funds to copied address from account 1

Expected behaviour
Balance ist correct
when Logout button is pressed, the user loged out
Actual behaviour
Balance is -2 Mi
Logout button doesn't work
Errors

Fixed in 0.3.0


Gateway API extensions: Usage of Policy Attachment vs. Filters

Description:
Policy Attachment and HTTPRouteFilters represent two different extension points in Gateway API to implement features outside the core/extended APIs provided by the upstream project.
Envoy Gateway is moving forward with implementing more advanced features on top of the core Gateway API and part of this is developing guidelines for implementers/users on how the project will use Policies and Filters.
In this document I wrote up a design/discussion for Contour on differences between using Policies and Filters: https://github.com/projectcontour/contour/pull/4749 which should be relevant to this project as well. In particular the differences between implementing the case-study spikes for rate limiting as a Policy vs. Filter.
Some other key points to discuss that may or may not be included in the above document:

The Policy Attachment spec has content about Policies and Filters serving different purposes here: https://gateway-api.sigs.k8s.io/references/policy-attachment/#interaction-with-custom-route-filters (particular about them not being used to set the same configuration fields)

If we want to use Policies to set defaults or overrides for Filters, we need to address this

How users know what configuration is actually applied/in effect on their data-plane is an open issue, especially for Policy Attachment

See: https://github.com/kubernetes-sigs/gateway-api/discussions/1498#discussioncomment-4030909
While we can create a powerful override/default hierarchy to allow flexible configuration, if users do not know what configuration is actually in effect, that is not a great experience
Adding Policies influencing how Filters work adds another dimension to this, possibly convoluted user experience

Mentioned in the document linked above, but Filters in the HTTPRoute sense to me do not directly translate to Envoy HTTP Filters, as they are configured at a much different scope

They may work in some cases where there are per-Route incarnations of these filters in Envoy, but that does not exist for every filter, rather most filters are created per HTTPConnectionManager FilterChain

@sunjayBhatia  thanks for sharing all the research on this topic !
The EG community too needs a decide on which extension point to use for the supporting advanced API Gateway features.
I'm sharing some options here, so the community can voice their preference.

Use HTTPRoute Filters for all API Gateway features

kind: RateLimit
 apiVersion: gateway.envoyproxy.io/v1alpha1
 metadata:
  name: rl-example
 spec:
 ---
 kind: HTTPRoute
 apiVersion: gateway.networking.k8s.io/v1beta1
 spec:
   parentRefs:
   - group: gateway.networking.k8s.io
     kind: Gateway
   .....
   hostnames:
   - "example.com"
   rules:
   - matches:
     - path:
         type: PathPrefix
         value: /
     backendRefs:
     - kind: Service
       name: example
       port: 8080
     filters:
     - type: ExtensionRef
       extensionRef:
         group: gateway.envoyproxy.io
         kind: RateLimit
         name: rl-example

Use PolicyAttachment for all API Gateway features

kind: RateLimit
apiVersion: gateway.envoyproxy.io
metadata:
  name: rl-policy
  namespace: demo
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: example
  override:
  ....
  default:
  ...

On a case by case basis decide which extension to choose for a specific API Gateway feature

@skriss @danehans @youngnick @AliceProxy @LukeShu @Xunzhuo can you please share your thoughts and preferences on this issue, please also consider sharing alternative options.

Specifically targeting #1, this comment is relevant: https://github.com/envoyproxy/gateway/pull/529#discussion_r1012164693
Not all configuration can be translated to Envoy config from per-Route configuration, due to the nature of particular Envoy filters and how Envoy Gateway's xDS translation logic may set up Listeners/Virtualhosts/Routes

In addition to thinking about how things will be implemented, we should consider in this decision what the intended UX we want is, which involves what resources/personas/scopes we want to target:

What features make sense to expose as a configuration for a whole virtualhost? (e.g. I want a certain configuration for foo.com and a different for bar.com)
What features make sense to expose just per-Route?
etc.

Prefer 2 because

the notion of default and override is powerful, addresses persona hierarchy
Policy can be applied to the Gateway but Filters cannot be applied to the Gateway

this is useful for some auth features such a client-validation / mTLS which haven't made their way into the Gateway API yet

Imho 3. adds cognitive load on the user and

cannot be applied to Gateway as shared above

This has been discussed in the authn policy document as well in this comment. As a result of a brief community call we agreed on something like 2. We might want to add some sort of support with PolicyAttachment to select routes in an HTTPRoute though.
Also note that Filters in HTTPRoute does not directly translate to Envoy HTTP filters as they are configured at different scope and not all Envoy filters support per route basis and the support varies. The Envoy HTTP filters are created per HCM filter chain.

@arkodg I feel like https://github.com/envoyproxy/gateway/issues/675#issuecomment-1301376173 is a repeat of https://github.com/envoyproxy/gateway/issues/677. Can you please clarify?

the notion of default and override is powerful, addresses persona hierarchy

As stated upstream, this can become very complicated which leads to poor UX.

From the draft Gateway API patterns: Policy Attachment and Metaresources doc authored by @youngnick :

Policy Attachment: It’s all about the defaults and overrides
The current Policy Attachment docs list three primary components of the Policy Attachment pattern:

A standardized means of attaching policy to resources.
Support for configuring both default and override values within policy resources.
A hierarchy to illustrate how default and override values should interact.

I think that we should focus “Policy Attachment” around the latter two bullet points

If Policy Attachment should not be used as a standardized means of attaching a policy to resources, then a different mechanism should be used. Let's refer to #529 as a concrete example. A dev creates an HTTPRoute to route traffic to two different backend services. The dev now wishes to attach different JWT AuthN policies to the backend services. A resource should be used to attach these policies. First, the dev creates the AuthN resource, for example:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: AuthN
metadata:
  name: svc1-jwt-auth
spec:
  authType: JWT
  jwtConfig:
    <JWT config for service 1>

The dev repeats the above for service 2 and then attaches the AuthN resource to the HTTPRoute as an implementation-specific filter:
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: pol-attach-example
spec:
  parentRefs:
    - name: eg
  hostnames:
    - www.example.com
  rules:
    - matches:
      - path:
          type: PathPrefix
          value: /svc1
      filters:
      - type: ExtensionRef
        extensionRef:
          group: gateway.envoyproxy.io
          kind: AuthN
          name: svc1-jwt-auth
      backendRefs:
      - name: svc1
        port: 80
    - matches:
      - path:
          type: PathPrefix
          value: /svc2
      filters:
      - type: ExtensionRef
        extensionRef:
          group: gateway.envoyproxy.io
          kind: AuthN
          name: svc2-jwt-auth
      backendRefs:
      - name: svc2
        port: 80

Traffic is now authN'd to the two backend services. However, the SecOps team from example corp has more stringent JWT authN requirements. The cluster admin is now required to enforce minimum JWT authN settings and creates an AuthnPolicy that overrides the settings for the above AuthN kinds. For example:
apiVersion: gateway.envoyproxy.io
kind: AuthnPolicy
metadata:
  name: svc1-jwt-auth
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: AuthN
    name: svc1-jwt-auth
  override:
    jwtConfig:
      <INSERT_OVERRIDES>

The cluster admin repeats the above for service 2 and now the JWT authN config for both backend services is overridden.
Although this approach requires two kinds, AuthN and AuthnPolicy, it does provide support for multiple personas inherent in Gateway API. RBAC is properly configured so that Devs are free to configure AuthN kinds for traffic routing and infra admins can configure AuthnPolicy to override traffic routing.

@danehans thanks for raising this case about using two separate CRDs here - Authn and AuthnPolicy. Here are some follow up questions

If the App Dev had the RBAC to apply AuthnPolicy to the HTTPRoute, shouldnt we be able to achieve the same outcome with 1 CRD type AuthnPolicy ?

relevant discussion topic for this as well, given some of the documentation in the Policy Attachment reference: https://github.com/kubernetes-sigs/gateway-api/discussions/1503
currently Filters and Policies aren't "supposed" to overlap, but as you point out and I think others have realized as well, this pattern seems useful

The poor UX issue will be addressed in upstream, I think that option 2 sounds about right here.

If the App Dev had the RBAC to apply AuthnPolicy to the HTTPRoute, shouldnt we be able to achieve the same outcome with 1 CRD type AuthnPolicy

Providing App Devs the ability to CRUD AuthNPolicy would defeat the purpose of separating concerns. App Devs should not be allowed to set or override default policies, e.g. AuthNPolicy. If we need the ability for App Devs to define authN for API endpoints and cluster admins to override/default authN, then separate resources are required.

assigning myself this issue, so that I can help moderate this discussion to a decision.

setting a semi arbitrary deadline for decision to Nov 17th, so the PRs for feature API design (auth, rate-limiting) leveraging this decision can start to be formally reviewed post that.
2 of the maintainers (@arkodg @youngnick ) have already voted, please feel free to change your vote based on the any new information gathered.
@danehans @AliceProxy @LukeShu @Xunzhuo @skriss are yet to vote
others please feel free to share your thoughts and preferences

Raising some further questions around users and features to help drive the debate
Assumptions
We are deciding extensions for these features

Ratelimiting

Global
Local

Authentication from this doc

JWT
OIDC
Client TLS

Questions around Capability

Which personas outlined here are these features relevant to
Will these features need to be applied to a Gateway resource and which will need to be applied to a HTTPRoute resource
Will these features need to be applied at a Connection level (Layer 4/6) and/or which will need to be applied at a Request level (Layer 7)
Do we want these features to have overrides by other personas

Questions around Experience

Which extension type fits better for which persona
Can the project impose specific checks around these extensions such as
adding specific validation web hook checks to quickly signal back errors to the user ?

Okay, I think I wasn't clear enough in my answer before, so let me clarify.
When talking about these features, we have a few extension points that can be used. For Auth and Ratelimiting, it conceptually makes sense that those be a filter that modifies a HTTPRoute match before it's sent on to the backends. That allows for very specific targeting of routes, headers, methods etc for these filters.
But, the downside of using a filter in that way is that then, the filter currently has to be specified for every place where it needs to be used. So if the cluster admin/Envoy Gateway owner wants to specify that all routes must have a global ratelimit, or a certain type of auth, then not only can they not do that, it's on the owner of each HTTPRoute to actually remember to.
So, what I'm going to be proposing in upstream is that there should be a class of Policy Attachment objects that modify the way these custom filters work, either defaulting or overriding the settings.
So, in this way, as a Gateway owner, I could attach a RatelimitingPolicy object to the Gateway, and set the default to be to use a specific ratelimit policy extensionref CRD, just as if every HTTPRoute rule attached to the Gateway specified the policy. This would mean that HTTPRoute owners would be able to override the default, but specifying their own extensionRef CRD.
Or, as a Gateway owner, I could attach a JWTAuthPolicy to the Gateway, that sets an override to use a specific JWTAuth CRD extensionRef, which an HTTPRoute owner cannot override by setting their own auth settings.  Probably not, but that's what it's for).
So, that's how we could combine a custom filter and Policy objects to give both flexibility and control to users. Note that both of these examples require us to build a custom Filter first, then the Policy object to allow it to be overridden.
Alternatively, we could _not_use the extensionRef filters, and only define these functions in terms of Policy objects, and instead of having the ability to define a filter inline in the HTTPRoute YAML, just have these settings attached via a Policy.
Both of the Policy approaches do have the UX limitation that it's very difficult to know if a Policy is augmenting the settings at all - part of the Policy rewrite I'm working on upstream is about trying to design a status section that should make this more clear. (It's a bit tricky though).
So, overall, I'm for Option 3 - which is "use both where necessary", but that's not very helpful right now.
I think that in terms of experimenting and trying things out, a custom filter for both Ratelimiting and Auth are both less design work, and less conceptual overhead for users to understand, at the cost of increased verbosity. I'd recommend using those for now, which puts me actually partially in the Option 1 camp, for now. I think that as I get these changes designed and pushed into upstream, this whole situation should hopefully become clearer.

@youngnick are there any plans on also supporting extensionRef in the Gateway API ? else from a capability perspective
EG will be unable to provide support for extended features at a connection / listener level with just extensionRef filters at the HTTPRoute level

But, the downside of using a filter in that way is that then, the filter currently has to be specified for every place where it needs to be used. So if the cluster admin/Envoy Gateway owner wants to specify that all routes must have a global ratelimit, or a certain type of auth, then not only can they not do that, it's on the owner of each HTTPRoute to actually remember to.

Thanks for clarifying. From reviewing your Policy Attachment doc, this was my understanding and why #529 is designed as an implementation-specific filter. I anticipate EG supporting an AuthenticationPolicy resource in the future that would allow admins to override and/or set default settings defined by an Authentication resource.

Both of the Policy approaches do have the UX limitation that it's very difficult to know if a Policy is augmenting the settings at all - part of the Policy rewrite I'm working on upstream is about trying to design a status section that should make this more clear. (It's a bit tricky though).

This is one of my concerns with Policy Attachment and highlighted by @sunjayBhatia in https://github.com/kubernetes-sigs/gateway-api/discussions/1503.

here's my current take based on three pillars

Capability

Policy - Yes

Can be applied to Gateway as well as HTTPRoute allowing attributes to be applied at
Layer 4-6 (connection) level as well as Layer 7 (request)

Filter - Not Always

Cannot be applied to the Gateway

Persona Hierarchy

Policy - Yes

Can be applied by the platform admin on the Gateway and can also be applied by the application developer on the HTTPRoute

Filter - No

Can only be applied by the application developer on the HTTPRoute

Experience

Policy - You decide

If targeted to HTTPRoute, it is applied to all rules within that route, which might not be the intent. The workaround is to create multiple small HTTPRoutes instead, not ideal, but not end of the world either.
If targeted to Gateway and HTTPRoute the final Policy output will look like
O/P = [Merge (left to right) ]  HTTPRoute defaults + HTTPRoute override+ Gateway defaults + Gateway override.
The final O/P might not be trivial for the HTTPRoute owner / application developer to compute to help them write intent, so implementors are left to surface such o/p in the Status field (thanks for outlining this here @sunjayBhatia ). Again this should be fine, but standardizing this upstream would be great !

Filters - You decide

A filter needs to be applied to every rule within HTTPRoute, not ideal, but not the end of the world either.

Based on this, I am revoting for option 3 (case by case basis). I think Policy should be considered as the default choice of extension, and a Filter should considered if ALL of the below are true

The feature is only valid at a request / route level.
The feature is not privileged (anything relating to security is privileged) that does not need to be applied by a privileged persona / platform admin on a privileged resource / Gateway.

The feature is not privileged (anything relating to security should be considered privileged) that does not need to be applied by a privileged persona / platform admin on a privileged resource / Gateway.

We have already heard feedback from @jcheld for the desire to allow App devs to configure auth for endpoints (HTTPRoute filter) but allow cluster admins to override (Policy Attachment). @jcheld please correct me if I misunderstood your input on this subject. Maybe we need to collect authentication requirements from potential Envoy Gateway users so we can design the API appropriately.

That use case is exactly the sort of thing I was talking about when I meant option 3 - I just have to finish the upstream work to change the wording of Policy Attachment - but I haven't got any objections to that part yet, so I'm reasonably confident it will go ahead.

@danehans, yes, there is typically a "standard" path for auth that is adhered to by the various API producers that I would want to enforce by default from the gateway admin perspective, though there does need to be an exception process by which other auth measures can be applied in cases where the auth being provided to the gateway cannot be adjusted.
As an example, if JWT is your standard auth then you would want to apply that across the various HTTPRoutes by default, however on a specific HTTPRoute you may may need to do an HMAC signature validation because it is a vendor webhook sending a request and they can only send an HMAC signature for validation. As a result, the ability to override a default auth behavior is key - though only as an exception, requiring a special privilege.  Other types of overrides and/or other applied Policies/Filters may not need a special privilege to be applied.  This may complicate user experience, but some flexibility in configuration is required I think.
Overall Policies does seem to be the correct way to go, with limited Filter usecases as mentioned by @arkodg so I'd have to go with option 3 as well

Overall I would prefer Policies over Filters from an end-user perspective if given the choice.

updating this thread to mention that an ExtensionFilter was used for RateLimiting instead of the proposed PolicyAttachment decision because

we were unsure if ratelimiting feature was applicable to the admin as well as app dev persona
policy attachment did not specify how to merge/override non scalar fields such as lists

Due to the above points, it made more sense to go ahead with a filter implementation that has a simpler user experience.


Mat/Pat - CRM - PDF (server side)

Split from #1100
The CRM ticket must contain a pdf of the form attached as well

[x] The ticket should contain the form attached as a pdf
- The pdf should contain only the review & certification pages in the form
- the pdf should contain the form name & logo

@iman could you give us an estimate for this? Thx :)

Pulling it in because it is being work on right now. @bhumin-fw  can you estimate this?

Ticket is ready to test on TEST environment.
If you don't see header (Logo + form name) in attached PDF. Please do let me know and I'll update it as soon as possible (due to some form edit and update that part gone missed so).

Could not test this:

Submitted a Mat/Pat form.
Could not validate my submission to generate the CRM ticket.
Error faced: The form loops back to the 'Before you begin' page.

Next steps:

I have submitted a form with Stella as my supervisor - would request her to try to validate my submission.
If the above does not work, I would request Meghan/Stella to submit a form.

I can confirm we are receiving PDF in the emails, but we need to check in CRM itself is the pdf attached. That has to be tested by someone who has access to CRM.

Tested in checkin, CRM ticket has pdf attached, and pdf is rendered properly. Pdf name could be changed to form name from just "attachment.pdf", but captured that in #1308


Add support for Fastly with envvar provisioning and config file imports

This PR adds support for Fastly CLI. Fixes https://github.com/1Password/shell-plugins/issues/133.
Key things to know:

Fastly uses API Tokens to authenticate.
FASTLY_API_TOKEN envvar (environment variable) is the easiest way to authenticate. The CLI also supports -t, --token as command flags to login, but environment variables are preferred.

Issues that need to be discussed
Issue with profile subcommands
fastly profile command has a bunch of sub-commands create, delete, list, switch, token and update. Of these commands, except for list subcommand, all subcommands can be used in the form of the same environment variable (I think), but that's not possible just yet because Shell Plugins does not offer a simple way to switch to another credential:

https://github.com/1Password/shell-plugins/issues/130

Until that feature is available, I am suggesting that we opt out of 1Password authentication for fastly profile commands.
The other command, fastly profile list basically looks for the list of available profiles in the config file and operate on the data available there. With Shell Plugins though, the config file will basically be void of these profiles, which in turn means that that command will just fail.
Overall, to me, it makes sense to avoid 1Password authentication for fastly profile commands for now.
Issue with config file imports
For some reason, I am unable to get MacOnly and LinuxOnly OS-specific config file imports working. It's probably something simple that I am missing. cc @hculea as we previously scheduled a call to discuss this. 🙏🏼 Thank you for any insights!

👋🏻 @arunsathiya
If there are any issues with the Fastly CLI that you think might make integration with 1Password easier, then do please open an issue at https://github.com/fastly/cli

Converting to draft for now because I need help with OS-specific importers.

Thank you for this addition, Arun! ❤ I've looked over the importers and both look good to me. The paths also look to be correct - user config dir suffixed by fastly/config.toml.
Off the top of my head, I could see a possible problem on UNIX systems (aside from MacOS), in the situation where the user would have the XDG_CONFIG_HOME envvar pointing to a custom location.
Is it possible that this is the case, in your situation? If not, could you maybe describe what is the unexpected behaviour that you're encountering, when trying to run the file importers? Thanks!

Thanks for taking a look, @hculea. XDG_CONFIG_HOME is empty for me:
➜  ~ echo $XDG_CONFIG_HOME

However, I have a positive news. Mac OS config file import is working as expected now. I am not sure what I was doing incorrectly the last week. Perhaps I didn't have any configuration profiles on the /Users/arun/Library/Application\ Support/fastly/config.toml file. 🤷🏼
I tried testing it on Linux (Ubuntu) on Docker, but it seems that Shell Plugins aren't supported on it:
root@c4fc0e1feba7:~/.config/op/plugins/local# ls
fastly
root@c4fc0e1feba7:~/.config/op/plugins/local# cd ~
root@c4fc0e1feba7:~# op plugin init fastly
WARNING:  is not a shell officially supported by 1Password Shell Plugins!
[ERROR] 2023/02/08 04:34:49 unknown plugin: fastly

I am not too sure how to move forward in terms of Linux testing, but given that the path is correct, we could assume that it works fine on Linux.
At this point in time, this PR is ready for a review! 😄

Side note:
I generated the fastly shell plugin build on my Mac and copied to the Docker container using docker cp ~/.op/plugins/local/fastly c4fc0e1feba7:/root/.config/op/plugins/local, but I don't know if that's a sufficient way to do it or if the build for Linux will completely vary.

I think you should copy the config to the .op file location. This is globally used by locally built shell plugins: docker cp ~/.op/plugins/local/fastly c4fc0e1feba7:/root/.op/plugins/local @arunsathiya This should solve the above issue.

@AndyTitu, I am unable to copy to that location because that location doesn't exist:
➜  ~ docker cp ~/.op/plugins/local/fastly a1ac133d0753:/root/.op/plugins/local
Error: No such container:path: a1ac133d0753:/root/.op/plugins

Following this documentation, the envvar XDG_CONFIG_HOME isn't set in my Docker-based Ubuntu container, which is why I am copying to /root/.config/op/plugins/local
root@a1ac133d0753:/# echo $XDG_CONFIG_HOME

Overall though, I believe we don't have any blockers, except that I have not tested the Linux importer.

I think the issue in your tests above @arunsathiya is that the path actually doesn't exist, since those directories never got created (that happens automatically, when building a plugin). Running a mkdir -p /root/.config/op/plugins/local inside the container should fix the issue.
One more thing to have in mind - the binaries are OS dependent, so you may want to set GOOS and GOARCH to those of your container, before running the make build command on the plugin.
That being said, I don't see not having tested the Linux importer as a blocker. Good to go IMO! 🚢


Port to Elm 0.18

Any different to #13? :)

Yep, number of changes is smaller because I didn't format (although that may not be preferable).

Closing in favor of #13.

Thanks anyway :)


fix flaky unit test

Motivation
Topic level policy cache will only trigger initialization when OwnedNamespaceBundle. The following unit tests do not create producers or consumers, and just wait through sleep.
The cache will not initialize no matter how long it wait. If the cache is called without initializing, an error of 500 will be reported
So I created a producer or consumer for these tests, and avoided sleep

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

@315157973 your error is this one
~/work/pulsar/pulsar/pulsar-client-all
     [java] The following classes needed for analysis were missing:
     [java]   jline.console.completer.Completer
Error:  Failed to execute goal on project pulsar-io-hbase: Could not resolve dependencies for project org.apache.pulsar:pulsar-io-hbase:jar:2.8.0-SNAPSHOT: Failed to collect dependencies at org.apache.hbase:hbase-server:jar:2.3.0 -> org.glassfish.web:javax.servlet.jsp:jar:2.3.2 -> org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT: Failed to read artifact descriptor for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT: Could not transfer artifact org.glassfish:javax.el:pom:3.0.1-b06-SNAPSHOT from/to spring-plugins-release (https://repo.spring.io/plugins-release/): Authentication failed for https://repo.spring.io/plugins-release/org/glassfish/javax.el/3.0.1-b06-SNAPSHOT/javax.el-3.0.1-b06-SNAPSHOT.pom 401 Unauthorized -> [Help 1]

I guess we should commit #9278 and your error will go away
cc @codelipenghui @zymap

@315157973 your error is this one
~/work/pulsar/pulsar/pulsar-client-all
     [java] The following classes needed for analysis were missing:
     [java]   jline.console.completer.Completer
Error:  Failed to execute goal on project pulsar-io-hbase: Could not resolve dependencies for project org.apache.pulsar:pulsar-io-hbase:jar:2.8.0-SNAPSHOT: Failed to collect dependencies at org.apache.hbase:hbase-server:jar:2.3.0 -> org.glassfish.web:javax.servlet.jsp:jar:2.3.2 -> org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT: Failed to read artifact descriptor for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT: Could not transfer artifact org.glassfish:javax.el:pom:3.0.1-b06-SNAPSHOT from/to spring-plugins-release (https://repo.spring.io/plugins-release/): Authentication failed for https://repo.spring.io/plugins-release/org/glassfish/javax.el/3.0.1-b06-SNAPSHOT/javax.el-3.0.1-b06-SNAPSHOT.pom 401 Unauthorized -> [Help 1]

I guess we should commit #9278 and your error will go away
cc @codelipenghui @zymap

I have cherry picked this patch to branch-2.7


use HUC number of digits or label/level rather than layerid

Have layerid = hucdigits/2 by default, allow lookup of names ("region", "subregion", ..., "watershed", "subwatershed")

Added huc_code() and layer argument, defaults in functions are same as before but now can specify several more readable alternatives to layerid


[WF-8862] Corrected schema version in several .xsd files

Jira: https://issues.jboss.org/browse/WFLY-8862
This PR may need WildFly Core changes: wildfly/wildfly-core#2509

Can one of the admins verify this patch?

This is ok to test


No Significant Improvement Observed in Model Training Speed

🐛 Describe the bug
I am training the meta-llama/Llama-3.2-1B model using LLaMA-Factory with the following YAML configuration:
### model
model_name_or_path: meta-llama/Llama-3.2-1B

### method
stage: pt
do_train: true
do_eval: true
finetuning_type: full
deepspeed: /path/to/ds_z3_config.json
use_liger_kernel: true
enable_liger_kernel: true

### dataset
dataset: /path/to/dir/
eval_dataset: /path/to/dir/
template: llama3
cutoff_len: 4000
max_samples:<PHONE_NUMBER>0
overwrite_cache: true
preprocessing_num_workers: 64
preprocessing_batch_size: 60000
tokenized_path: /path/to/dir/

### output
output_dir: /path/to/dir/
logging_steps: 1
save_steps: 5
plot_loss: true
overwrite_output_dir: true
save_total_limit: 8

### train
per_device_train_batch_size: 94
gradient_accumulation_steps: 32
learning_rate: 5.0e-5
num_train_epochs: 10
lr_scheduler_type: cosine
optim: adamw_torch_fused
warmup_ratio: 0.01
weight_decay: 0.1
bf16: true
ddp_timeout: 1080
ddp_find_unused_parameters: false
max_grad_norm: 1.0
seed: 42
dataloader_num_workers: 64
packing: true
flash_attn: auto

### eval
per_device_eval_batch_size: 4
eval_strategy: steps
eval_steps: 10

However, I have noticed that enabling or disabling liger_kernel does not lead to any noticeable reduction in training time. The runtime metrics remain nearly identical in both cases. Are there specific parameter settings in my YAML configuration that might be preventing liger_kernel from functioning optimally? Thanks :(
Reproduce

Use the YAML configuration provided above.
Train the meta-llama/Llama-3.2-1B model with and without liger_kernel.

llamafactory-cli train /path/to/above/yaml

Compare training times and throughput metrics.

Versions
Environment Report:
Operating System: Linux-5.15.0-107-generic-x86_64-with-glibc2.35
Python version: 3.12.7
PyTorch version: 2.5.1+cu124
CUDA version: 12.4
Triton version: 3.1.0
Transformers version: 4.46.1

It is likely because the model is too small, so it is not fully utilizing the GPU, which causing the effect of liger kernel be non significant.

Can you compare the memory before and after liger?
After liger, the memory should reduce a lot because of the large vocab size. Due to that, you can disable grad ckpt to avoid forward re-computation. You might have to adjust per_device_train_batch_size and gradient_accumulation_steps a bit to fit into the GPU
I would suggest switching DDP to FSDP so you can have even more memory reduction.

It is likely because the model is too small, it is not fully utilizing the GPU, which causes the effect of liger kernel to be non significant.

Can you compare the memory before and after liger?
After liger, the memory should reduce a lot because of the large vocab size. Due to that, you can disable grad ckpt to avoid forward re-computation. You might have to adjust per_device_train_batch_size and gradient_accumulation_steps a bit to fit into the GPU
I would suggest switching DDP to FSDP so you can have even more memory reduction.

Thanks @ByronHsu for your response.
Regarding the first point, I have configured the dataset in the YAML file to fully utilize the memory of the H100 GPU. However, I observed no significant difference in memory usage with or without Liger; the memory consumption remained unchanged.
I will experiment with the second point as you suggested. Could you please explain why disabling gradient checkpointing is recommended? If it's related to Liger's underlying mechanism, I will review the relevant literature for a deeper understanding.
I appreciate your third suggestion and will implement it in future trials.
Thank you.

Gradient checkpointing isn't related to Liger Kernel per-se, but it's a technique that trades off training speed for a reduction in memory consumption. If Liger is enabled (and reducing the memory consumption of your model's training step), then it could enable turning off grad checkpointing and thus speed up training.

Another suggestion is to hook up a profiler to see what time is being spent on over the course of a few training steps.


Sometimes crash

I compile use qt 6.4.0, lua 5.15, vs2019, os is win10.
when write alloc info to buffer
MemoryHook::writeToBuffer
{
	m_mutexInternalBufferPtrs.lock();
}

mutex.lock sometimes will alloc memory, so it casue a endless loop, finally the stack overflow.
but if i just compile MTunerDLL64.dll and copy it to your relase, it don't crash.

Code was written to accommodate for that case (recursive alloc) and will ignore the internal ones. That being said, your description is not sufficient to guess why this could be occurring for you locally.

Closing - inactive and not enough info


Clean up Travis CI scripts

Description

Many of the Travis scripts are a bit outdated. There are several environment variables we no longer set in the .travis.yml so script some logic is redundant or unused.
This is a minor issue that's really just tech-debt related.

Another low-hanging fruit CI tech debt opportunity that can be clubbed into this effort, is the use of assert_raises instead of with pytest.raises(<INSERT ERROR HERE>):. We can remove the custom code and let pytest handle this.

Resolved by pull#83.


⚠ Bofrost.be has degraded performance

In c6724f6, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1355 ms

Resolved: Bofrost.be performance has improved in fa731c3.


ROX-16930: Re-enable skipped ImageManagementTest sub-tests on P/Z

This PR intends to add multi-arch support for the ImageManagementTest QA test.
Test code changes & images used in the test are update to enable test execution on 3 platforms viz. x86_64, ppc64le and s390x.
Few of the sub-tests skipped earlier on P/Z, have been re-enabled in this PR.
Changes are verified manually using ./gradlew test --tests=ImageManagementTest

Thanks Robby for the approval. Will merge the PR once all CI checks are complete.

hi @jdao-rh kindly trigger tests on Z for this PR

/test ibmcloudz-qa-e2e-tests

/test ibmcloudz-qa-e2e-tests

ALl CI checks have passed ✅ on X, ImageManagementTest + all other intended tests passed on P/Z.
Note:
Failures observed in AdmissionControllerTest, ComplianceTest and NetworkFlowTest are flaky on P/Z and would be tracked separately.
Merging the PR.


Custom TLS Connector for SC4S

Hi
Is it possible to create a simple port source with a custom TLS cert associated to it? We have a syslog source that  is trying to do TLS verify and it doesn't recognise our private CA that signed the TLS cert. The vendor has indicated that they have no way of introducing additional CAs into the product. (Don't ask!)
At this stage im thinking i can create a custom syslog-ng config for the port and point the cert option to the public cert we have acquired for this product but im not sure how i can add that config to SC4S. If this was standard Syslog-ng it would be very easy to do.

https://splunk.github.io/splunk-connect-for-syslog/main/configuration/#syslog-source-tls-certificate-configuration , we dont support multiple tls on different ports, we can explore to enhance it.

@pwickham,
We have not heard from you since last two weeks. Please let us know in case of any further queries.
Closing this issue for now.


fix(core): fix check temp path permission on mac os, fix #6256

close #6256

Will check this PR in the upcoming days but am wondering if https://github.com/tauri-apps/tauri/pull/9072/files#diff-903ee43f2eb846686e5baf219fc515ff00de27369cef1e81b37164de847d2e90 does fix the underlying issue, as it resolves symlinks now before checking. This is in dev, so not sure if it can/is/will be back ported and if other changes influence behavior.

@tweidinger I tested how path::is_symlink works, and it seems only check the exact symbolic path, eg.
use std::{
    env,
    path::PathBuf,
};

fn main() {
    let p_var = PathBuf::from("/var");

    println!("{:?}", p_var.is_symlink()); // => true

    let p_var = env::temp_dir();

    println!("{:?}", p_var.is_symlink()); // => false
}

This means any subpath of a symbolic folder will return false, so https://github.com/tauri-apps/tauri/pull/9072/files#diff-903ee43f2eb846686e5baf219fc515ff00de27369cef1e81b37164de847d2e90 may not be able to fix subpath permission check.

The issue happens because the allowed path is actually a symlink so the full path does not match the path we're checking against (which is canonicalized so it resolves to the actual folder).
There is an easier way to fix this which is to canonicalize the temp dir when resolving the path variables.
basically changing https://github.com/tauri-apps/tauri/blob/44e3335da8c1a811a2ebe72f2036dfad2381da24/core/tauri/src/api/path.rs#L296 to BaseDirectory::Temp => temp_dir().canonicalize().ok()
it's probably more secure this way since we would still check canonicalized paths in the end, resolving symlinks and path traversals
cc @tweidinger

Thanks for the guidance, done!

The issue happens because the allowed path is actually a symlink so the full path does not match the path we're checking against (which is canonicalized so it resolves to the actual folder).
There is an easier way to fix this which is to canonicalize the temp dir when resolving the path variables. basically changing
https://github.com/tauri-apps/tauri/blob/44e3335da8c1a811a2ebe72f2036dfad2381da24/core/tauri/src/api/path.rs#L296
to BaseDirectory::Temp => temp_dir().canonicalize().ok()
it's probably more secure this way since we would still check canonicalized paths in the end, resolving symlinks and path traversals
cc @tweidinger

When the user creates a temporary file, the js code should be like this:
import { fs, path } from '@tauri-apps/api'
import { tempdir } from '@tauri-apps/api/os'

const tempFile = await path.join(await tempdir(), 'not-exits-file')

await fs.writeFile(tempFile, 'some data')

it will use os.tempdir() to get the temporary path, when writing the file, the tempFile should not exist, so check permission will only check the path, not the canonicalized path, this will fail because os.tempdir() is not canonicalized, while the permission check is checking the canonicalized temporary path.
So, we may also change os.tempdir() API, and make it return the canonicalized temporary path.

LGTM. The only blocker is that not all commits are signed @0x-jerry could you please amend signatures to previous commits or rewrite to a single commit? The history will be squashed into a single commit anyway.

Done!


Does redb support spill?

redb states itself an embedded kv stoe, but it still defines a file format and create a data file. I wonder if redb supports spilling data on disk if memory is exhausted.

redb is not an in-memory key-value store but a persistent database first. It only uses a built-in in-memory cache, c.f. set_cache_size, to avoid costly I/O to improve performance.


'End' key does not work in large file

Testing #30243.

Generate file as in #31545.
Click on the first line somewhere to see a cursor, press 'End' key on the keyboard.

Expectation: navigating to the end of the line.
Ctrl+End does not navigate to the end of the document also.

Duplicate of #27380


RQRCode::QRCodeRunTimeError (code length overflow. (1004>976). (Try a larger size!)):

Fails for user on prod after migration sometimes. If I check the Ignore2FA then it works else doesn't.
Processing by AccountController#login as HTML
  Parameters: {"utf8"=>"✓", "authenticity_token"=>"5OrvYz8T87xZgpT57Kpt2MxhSL2UgRgCvxAUsrvR8T+Ym7AH1Kdu5/AB8g9f8JDMu6fBCT94kI2wLLW3oGPzEw==", "username"=>"admin", "password"=>"[FILTERED]", "login"=>"Login"}
  Current user: anonymous
Completed 500 Internal Server Error in 13ms (ActiveRecord: 8.0ms)

RQRCode::QRCodeRunTimeError (code length overflow. (1004>976). (Try a larger size!)):
  plugins/redmine_2fa/lib/redmine_2fa/patches/account_controller_patch/second_authentication_init.rb:11:in `new'
  plugins/redmine_2fa/lib/redmine_2fa/patches/account_controller_patch/second_authentication_init.rb:11:in `password_authentication'
  plugins/redmine_2fa/lib/redmine_2fa/patches/account_controller_patch/second_authentication_prepare.rb:16:in `password_authentication'
  app/controllers/account_controller.rb:205:in `authenticate_user'
  app/controllers/account_controller.rb:38:in `login'
  lib/redmine/sudo_mode.rb:63:in `sudo_mode'

Fixed in #55
Gonna release new version on monday.


Return wrong language for the Netherlands holidays

I have updated my code to the latest version and it seems the holiday names do not return in it's own language.
Running this code:
import datetime
import holidays

for ptr in holidays.NL(datetime.datetime.now().year).items():
    print(ptr)

✅ Running the above code using version 0.22 gives (good and expected results):
(datetime.date(2023, 1, 1), 'Nieuwjaarsdag')
(datetime.date(2023, 4, 9), 'Eerste paasdag')
(datetime.date(2023, 4, 7), 'Goede Vrijdag')
(datetime.date(2023, 4, 10), 'Tweede paasdag')
(datetime.date(2023, 5, 18), 'Hemelvaart')
(datetime.date(2023, 5, 28), 'Eerste Pinksterdag')
(datetime.date(2023, 5, 29), 'Tweede Pinksterdag')
(datetime.date(2023, 12, 25), 'Eerste Kerstdag')
(datetime.date(2023, 12, 26), 'Tweede Kerstdag')
(datetime.date(2023, 4, 27), 'Koningsdag')

🔴 Running the code from version 0.23 (also the same results running 0.32) gives the below wrong result:
(datetime.date(2023, 1, 1), "New Year's Day")
(datetime.date(2023, 4, 7), 'Good Friday')
(datetime.date(2023, 4, 9), 'Easter Sunday')
(datetime.date(2023, 4, 10), 'Easter Monday')
(datetime.date(2023, 4, 27), "King's Day")
(datetime.date(2023, 5, 18), 'Ascension Day')
(datetime.date(2023, 5, 28), 'Whit Sunday')
(datetime.date(2023, 5, 29), 'Whit Monday')
(datetime.date(2023, 12, 25), 'Christmas Day')
(datetime.date(2023, 12, 26), 'Second Day of Christmas')

So you can see the dates are correct but the labels (naming) are in English instead of Dutch. If this is the new standard, this is fine for me then I will translate myself. Otherwise, I hope you can fix this.
If you need more info, please me know. I will run version 0.22 in the mean time.
Many thanks for this library!

Hey @jovana
thanks for the detailed issue description!
The reason for this (unexpected) behavior is that we've localized NL holidays some time ago. There are currently 3 languages supported: nl (default), en_US, and uk.
And it seems you're running it under en locale. Please try setting the language explicitly:
import datetime
import holidays

for ptr in holidays.NL(datetime.datetime.now().year, language="nl").items():
    print(ptr)

If you're a native Dutch language speaker we'd appreciate you taking a look at those labels and let us know if something isn't correct.
Thank you!

Hi @arkid15r , Thanks for the quick reply!
Okay, I understand now! I have added the language="nl" option and it gives the correct output.
Many thanks!
I have looked into the documentation, now I know I can find it. But it would be nice if there is an example in the readthedocs.

Hey @jovana thanks for the detailed issue description!
The reason for this (unexpected) behavior is that we've localized NL holidays some time ago. There are currently 3 languages supported: nl (default), en_US, and uk.
And it seems you're running it under en locale. Please try setting the language explicitly:
import datetime
import holidays

for ptr in holidays.NL(datetime.datetime.now().year, language="nl").items():
    print(ptr)

If you're a native Dutch language speaker we'd appreciate you taking a look at those labels and let us know if something isn't correct.
Thank you!

I have added an update in the documentation, in this pull request. Not sure if it is usefull: https://github.com/vacanza/python-holidays/pull/1456
Thanks for helping and this great lib!


composer-cli compose log says compose is still running.

According to the command help, compose log is meant to get information of the running build, however, it complains the compose is still running, which sounds like a contradiction.
[root@fedoravm image-builder]# composer-cli compose list
ID                                     Status    Blueprint   Version   Type
a4abfd36-0b79-4ccb-a6ac-3edea46ec575   RUNNING   fedora-nx   0.0.1     image-installer
17bda711-098a-413d-bbd8-c4f6f7ac6c34   FAILED    fedora-nx   0.0.2     image-installer
b2f165f0-cb6d-4803-880d-1d62b365f6dd   FAILED    fedora-nx   0.0.0     image-installer
[root@fedoravm image-builder]# composer-cli compose log a4abfd36-0b79-4ccb-a6ac-3edea46ec575 100
Build a4abfd36-0b79-4ccb-a6ac-3edea46ec575 is still running.

This is a limitation of the osbuild-composer service. I believe there are plans to improve this at some point.


Large multi-channel inverse FFTs give wrong results

Description
import jax.numpy as jnp
from jax import random

key = random.PRNGKey(0)

def fun(key, length):
    size = (length,) * 3
    last3 = range(-3, 0)
    f = random.normal(key, (3,) + size)  # 3 channels
    f = jnp.fft.fftn(f, axes=last3)

    # 1st way to do the same inverse FFT, all at once
    f_ = jnp.fft.ifftn(f, axes=last3)
    print(f_[0, 0, 0, 1])
    del f_

    # 2nd way to do the same inverse FFT, channel by channel
    f_ = jnp.stack([jnp.fft.ifftn(g) for g in f], axis=0)
    print(f_[0, 0, 0, 1])

fun(key, 890)  # prints (-0.93745315-9.771974e-08j) (-0.93745315-9.771974e-08j)
fun(key, 900)  # prints (-1235954700+99.51599j) (-1.6954112+1.9948014e-07j)

For 3D FFT with grid size <= 890, the two methods to do the same inverse FFT agree and give the correct results (expected to be or close to be real numbers), while for size >= 900, the 1st method gives the wrong result.
What jax/jaxlib version are you using?
jax 0.4.19 jaxlib 0.4.19+cuda12.cudnn89
Which accelerator(s) are you using?
GPU
Additional system info
No response
NVIDIA GPU info
Thu Nov  9 07:27:37 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.86.10              Driver Version: 535.86.10    CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA H100 PCIe               Off | 00000000:19:00.0 Off |                    0 |
| N/A   40C    P0              73W / 350W |  80821MiB / 81559MiB |      0%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A    434548      C   ...ome/yinli/mamba/envs/jax/bin/python    80808MiB |
+---------------------------------------------------------------------------------------+

My strong suspicion is that this is an integer overflow somewhere (in XLA or cufft), because:
In [1]: 890*890*890*3
Out[1]:<PHONE_NUMBER>

In [2]: 900*900*900*3
Out[2]:<PHONE_NUMBER>

In [3]: 2**31
Out[3]:<PHONE_NUMBER>

I'm pretty sure this is an integer overflow in cufft: it looks to me like XLA is passing reasonable parameters to cufft.
(Note: you need a 80GB GPU to reproduce this: it reproduces on H100 at least.)

@eelregit I was able to reproduce on A100 with CUDA 12.2.
Can you try with CUDA 12.3? I just tried it and I got good results.

We conferred and we think this is a bug in JAX actually. Specifically, the normalization here: https://github.com/google/jax/blob/d488714689cb4373dc4ec54149c8746455c95397/jax/_src/numpy/fft.py#L37
will happen in int32 unless JAX_ENABLE_X64=1 is set.

Thanks! That makes sense. Maybe turn s into weak typed float before the prod can help?


[UI] Fix domain resources field not being updated with backend data

Description
When configuring domain resource limits in the UI, writing a value (but not saving) into the input field and then selecting another domain would make the value written in the previous domain resource limits tab appear for the newly selected domain as well. This bug can cause the user to unintentionally change values in the wrong domain, for example:
Setting the "Max. Memory" field in domain A, switching to domain B, setting the "Max. User Vms" field, and then clicking submit would cause both fields to be submitted for domain B.
The proposed change is to reset the fields after calling the API's listResourceLimits.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[X] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[X] Minor
[ ] Trivial

How Has This Been Tested?

The UI was tested in a local lab to verify if changes were effective.

@blueorangutan ui

Hi @JoaoJandre Is this PR good to go in 4.16.1? If so, please rebase with 4.16. Thanks.

@blueorangutan ui

@utchoang a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: :heavy_check_mark:
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/5874 (SL-JID-1039)

If it goes to main its enough to me @shwstppr @sureshanaparti

Verified. LGTM.


No Blazor Web App Option

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/create
Operating System: Windows
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything relevant.
Verified installation of the product like on the previous page. I have the following options.

Blazor Server App
Blazor WebAssembly App
Blazor Server App Empty
Blazor WebAssembly App Empty

@mairaw Did perhaps the names of the template change between versions? If so, we should update the tutorials.

adding @danroth27
I believe this is the new name. Can you confirm Dan?
@schleppen what version of Visual Studio you have installed? You can confirm by opening Visual Studio Installer. The minimum version for this tutorial to work is VS 17.8. Here's what my installer looks like right now

Yup, the new Blazor template in .NET 8 is the "Blazor Web App" template. You may also see the older Blazor Server and Blazor WebAssembly templates if you also have .NET 7 installed.  .NET 8 ships in-the-box with Visual Studio 17.8, so make sure you've updated to the latest Visual Studio version.

Apparently, I need to update Visual Studio.


Ordered Blogger comments

I need to download only the most recent comments from a Blog, but [GTLQueryBlogger queryForCommentsListByBlogWithBlogId:blogID] doesn't support orderBy.

Looks like that api instead uses a startDate/endDate model, so you'd have to keep track of last time you got comments and ask for comments since that time.
On the bottom of the API page, there's a section labeled Connect which lists a forum and G+ community.  You might want to try those since your question isn't really specific to ObjC and is more about the server provided API in general.


bump egui version to 0.26

egui 0.26 has a bunch of features & improvements we're looking for in our project

I attempted to test using the simple example listed in the readme, but found it out of date, so I wasn't able to verify that this didn't break anything other than running cargo check on my fork

LGTM

thank you! 🎉


sfdx force:source:status not working for source tracking sandbox

I am executing force:source:status with a sandbox with source tracking enabled (I can even query SourceMember tooling api object) but when running this command I get "ERROR running force:source:status:  This command can only be used on orgs that have source tracking enabled, such as sandboxes and scratch orgs."

@CaptainDX  im seeing the same.  Even with these enabled and the sandboxes refreshed afterwards:
Can you post your solution?

@CaptainDX  im seeing the same.  Even with these enabled and the sandboxes refreshed afterwards:
Can you post your solution?

I have had this issue off and on for months. I can't tell if they actually want us to use the feature.


Make the API asynchronous

Since we're using hyper under the hood, which is fully async, it is a bit of a shame that shiplift's API isn't. It would be great to change the methods that make a call to Docker to return a Future of some kind.
Some examples of Rust crates with an Async API:

fantoccini
tokio-zookeeper

Maybe for version 0.5? :)

I agree. This should be pretty straight forward There are many calls to block_on that seem unnecessary.

I've been working on it and am slowly making progress. Still a few methods to do, and some clean-up, but the stats example works and properly streams Stats objects as they're received, which I'm quite happy about :) You can see the work in progress here: https://github.com/abusch/shiplift/tree/async_api


FoxPro9 Memo fields are 4 bytes in size

When trying to open a vfp9 DBF, which contains at least one field of type Memo, then this lib throws this error:
Invalid field size (must be 10)
The size 10 is hard-coded inside field-descriptor.ts
if (type === 'M' && size !== 10) throw new Error('Invalid field size (must be 10)');

I'm not sure if this is different from other dBase DBFs, but as far as I know vfp9 always uses the size of 4 bytes for Memo fields
If this is different, maybe there could be a dialect option?

Any chance to merge PR #58?
Thank you

Sorry for the delay - I had GH notifications turned off for a couple of months without realising. PR #58 has been merged and new version 1.8.0 has been published to npm.


[REVIEW]

GitHub Profile Link
https://github.com/priyankarpal

Reviewed on live stream https://www.youtube.com/watch?v=9pXcE3-WnkA


build on mac os not signed correctly

builds for mac might not execute correctly since the mac os gatekeeper will prevent launching an app without a proper signature

resolved


extend merge built-in function

Fixes #5724
Description
extend merge built-in function
Specific Changes
Originally, merge only accepts objects.
For example:
merge({}, {k1:'v1'}, {k2:'v2', k3:'v3'})
but sometimes the input is an array, and there is no way to convert the array into a list of objects.
The solution is to change the merge function to accept array type as well.
The logic is, if the item is array, merge its object children.
For example:
merge({k1:'v1'}, [{k2:'v2'}, {k3: 'v3'}], {k4:'v4'})
The second item is array, if we follows the previous practice, would get en error which shows the input only accepts "structure object", but not array. But now, you would get the right result:
{  "k1":"v1",  "k2":"v2",  "k3":"v3", "k4":"v4"}
But it should be noted that, the flatten operator would be applied for only once. If the array is nested, exception would be thrown too.
For example:
merge([{k1:'v1'}, {k2:'v2'}])  -> ok
merge([{k1:'v1'}, [{k2:'v2'}]])  -> the item of the array should be an object.
Doc change
add [Doc should change] mark

Pull Request Test Coverage Report for Build 255020

0 of 0   changed or added relevant lines in 0 files are covered.
11 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.02%) to 76.174%

Files with Coverage Reduction
New Missed Lines
%

/libraries/AdaptiveExpressions/BuiltinFunctions/Merge.cs
3
93.02%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive.Runtime/Extensions/ServiceCollectionExtensions.cs
8
91.11%

Totals

Change from base Build 254647:
-0.02%

Covered Lines:
23083

Relevant Lines:
30303

💛  - Coveralls


Message count (msgcnt) not working on Android in plugin v1.6.4

I already fixed it manually on my side, but raising this so that it can get fixed in the main code.
The fix:
in GCMIntentService.java setNotificationCount() function,
The function tries to get msgcnt from MSGCNT or BADGE, but both keys have already been normalized into COUNT in normalizeKey() function
so the fix is to change setNotificationCount() to get msgcnt from COUNT, before trying MSGCNT or BADGE
I changed mine to:
private void setNotificationCount(Bundle extras, NotificationCompat.Builder mBuilder) {
        String msgcnt = extras.getString(COUNT);
        if (msgcnt == null) {
            msgcnt = extras.getString(MSGCNT);
        }
        if (msgcnt == null) {
            msgcnt = extras.getString(BADGE);
        }
        if (msgcnt != null) {
            mBuilder.setNumber(Integer.parseInt(msgcnt));
        }
    }
Expected Behaviour
msgcnt in payload will show beside notification item
Actual Behaviour
msgcnt in payload gets ignored
Reproduce Scenario (including but not limited to)
Steps to Reproduce

Send a payload with msgcnt
Notice that message count doesn't show beside notification item

Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android 6.0
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
LG
Cordova CLI version and cordova platform version
cordova --version 5.1.1
cordova platform version android 5.1.1

Plugin version
cordova plugin version | grep phonegap-plugin-push 1.6.4

Sample Push Data Payload
Sample Code that illustrates the problem
Logs taken while reproducing problem

@iori57 this is already fixed in the 1.7.x branch.

Cool, thanks!

@iori57 oh and I'm in the process of merging the 1.7.x branch into master for a release later today.


Implement support for non light entities

Add support for:

Fan (fixed, linear)
Switch (fixed)
Binary sensor (fixed)

Fixed by #9


3rd level of routing is not recognising path.

I am creating an app which requires multiple level of nesting. from 3rd level my routes are not getting recognised.
App Js
const App = () => {
    return (
        <React.Fragment>
            <Router>
                <Switch>
                    <Route path="/login">
                        <Login />
                    </Route>
                    <Route path="/">
                        <Home />
                    </Route>
                </Switch>
            </Router>
        </React.Fragment>
    )
}

HomeJs
export default class Home extends React.Component {
    render() {
        return (
            <React.Fragment>
                <Header></Header>
                <ContentNav></ContentNav>

                <Switch>
                    <Route path="/clients">
                        <Clients />
                    </Route>
                    <Route path="/publishers">
                        <Publishers />
                    </Route>
                    <Route path="/">
                        <Redirect to="/clients" />
                    </Route>
                </Switch>

            </React.Fragment>
        )
    }
}

Client JS
class Clients extends React.Component {
    render() {
        return (
            <React.Fragment>
                Clients Page
                <Switch>
                    <Route path="/add">
                        <AddClient />
                    </Route>
                    <Route path="/edit">
                        <AddClient />
                    </Route>
                    <Route path="/">
                        <Entity />
                    </Route>
                </Switch>
            </React.Fragment>
        )
    }
}

these routers are rendering same component
http://localhost:3000/clients
http://localhost:3000/clients/add
http://localhost:3000/clients/edit
here is stack overflow question :
https://stackoverflow.com/questions/62357789/react-router-v5-3rd-level-of-nesting-is-not-recognising-path

Nested routes aren't relative. You need to use absolute URLs in the paths of those Routes.


Steps do not work for Azure Gov customers

These steps do not work for Azure Gov customers. When you get to step 4 you do not have the ability to Transfer billing ownership. Can you please update this page with how an Azure Gov customer can transfer billing and/or specify that these steps are specific to Azure Commercial and point to a separate page that shares how this is achievable in Azure Gov?
Thank you.

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

ID: a3fc64b6-c4e5-4f47-6a90-8a42955377b2
Version Independent ID: d905e8f9-49c6-19de-1c43-796efc04003f
Content: Transfer billing ownership of an Azure subscription
Content Source: articles/cost-management-billing/manage/billing-subscription-transfer.md
Service: cost-management-billing
Sub-service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

@J227668 I'm investigating this issue with the Billing engineering team. I'll reply here when I have more details.

@J227668 Sorry for the delay. The team has been looking into this issue. I'm working on a documentation update for it, too.
Can you please tell me source and target agreement type? It looks like your source is pay-as-you-go MS-AZR-USGOV-0003P. What is the target agreement? Is it also MS-AZR-USGOV-0003P?

Hi @bandersmsft - That is a great question. This would be in relation to an enterprise customer leveraging an Enterprise agreement.

@J227668 Is the source subscription MS-AZR-USGOV-0003P and the destination MS-AZR-USGOV-0017P?

@J227668 Thanks again for letting us know about the issue you have. I've made updates to https://docs.microsoft.com/azure/cost-management-billing/manage/billing-subscription-transfer to say that the transfer target is MOSP.
And, to update the table at https://docs.microsoft.com/azure/cost-management-billing/manage/subscription-transfer#product-transfer-support for MOSP to EA to say:

If you're transferring the subscription to the EA enrollment, see Transfer a subscription to an EA.
If you're changing billing ownership, see [Change Azure subscription or account ownership](https://docs.microsoft.com/azure/cost-management-billing/manage/ea-portal-administration#change-azure-subscription-or-account-ownership].

https://github.com/MicrosoftDocs/azure-docs-pr/pull/197145
#please-close


Audit, reduce package count, and then pin version numbers

we need web3 and config

All package.json's now use exact version numbers.
The situation has vastly improved since this ticket was cut.


Add CSS to support smaller mobile devices

This change adds support for the "classic" iPhone width. Style copied directly from existing 480px width with necessary width and font modifications. To view proposed changes on an active site, visit jazzace.github.io.

Thanks @jazzace!


Enable tabpfn classifier config

Development
Allow the user to explicitly specify the TabPFN config for the remote TabPFN.
Workflow
No changes to how the user interacts with the libraries.
from tabpfn import tabpfn_classifier

tabpfn_classifier.init()

# The following now works for local and remote
tabpfn = tabpfn_classifier.TabPFNClassifier(N_ensemble_configurations=100)

Rebase before merging

[ ] rebase

Could you please ping me again when you have merged the other PR, s.t the diff is cleaner :)

@SamuelGabriel @noahho
This PR is updated and ready for review. Thanks :)

Reimplemented in #21


Units error in substitutions

This has been a recurrent problem, and I have been putting off an issue on it for a while. Now it is time.
Look at CFP_Fuselage_Performance_int_HT.py in hoburg/d8, commit 8cac3d6.
If you run the code, you will get the following error:
  File "c:\users\berk\dropbox (mit)\mit graduate school\code\gpkit\gpkit\nomials\nomial_math.py", line 358, in mono_lower_bound
    return self.mono_approximation(x0)
  File "c:\users\berk\dropbox (mit)\mit graduate school\code\gpkit\gpkit\nomials\nomial_math.py", line 194, in mono_approximation
    m0 *= (x0[vk])**e
  File "C:\Users\Berk\Anaconda2\lib\site-packages\pint\quantity.py", line 851, in __pow__
    raise DimensionalityError(self._units, 'dimensionless')
DimensionalityError: Cannot convert from 'force_pound' to 'dimensionless'

This is because of the following substitution on line 984:
'W_{engine}': 11000*units('lbf'), # Engine weight substitution

Extremely puzzling why this doesn't work, since I have put units in other substitutions and it has worked fine. Let me know if you have any ideas @bqpd.

Seem like that substitution is in the exponent of the monomial approx. Will take a look!

Any updates on this? Kind of seems like a trivial problem, but one that has relatively immediate importance. If we cannot make use of units in substitutions array, we cannot validate that we are substituting the right values without checking the variable definitions.

let's make sure we add a unit test before closing this


Make compatible with Node

At the moment, if the library is run in Node, it will not work as it depends on some functions and variables (window) that are only available in browsers. Will be helpful if all these are replaced with Node compatible equivalents.

https://github.com/PathwayCommons/sbgnml-to-cytoscape/releases/tag/v3.0.0


fixed iteration exception when clicking on handles

fixes #744
I break after update segment list is updated to avoid exception. next loop will have a fresh start.
I can confirm that we don't get similar exceptions in speed limit tool or parking tool.

This is a small review. why can't I merge it in with one approval?


Update rapids JNI dependency to 24.04.0, private to 24.04.2

Wait for the pre-merge CI job to SUCCEED

build


Update HomeScreen.kt

Removed fillMaxWidth() from CenterAlignedTopAppBar's title because when switching between My garden and Plant list then  filter icon pops up and pushes CenterAlignedTopAppBar to the left
------------->This is the app before Change

.
.
.
.
------------->This is the app after Change

                  **^
                  ||**

I updated the code successfully.

Sorry, I was off work Thursday and Friday, but I've merged now. Thanks for your contribution!

Sorry, I was off work Thursday and Friday, but I've merged now. Thanks for your contribution!

Thanku so much sir. You reviewed it that means a lot thanku for giving me my first contribution to open source.


build failing - appears related to phantom JS

I have a couple Meteor apps (latest version of Meteor 1.0.2) that fail to build. The error message is:
	remote: -----> Adding PATH environment
	remote: -----> Running extras
	remote: -----> Adding MONGOHQ_URL -> MONGO_URL env
	remote: -----> Adding MONGOLAB_URI -> MONGO_URL env
	remote: -----> Installing phantomjs.
	remote: bzip2: (stdin) is not a bzip2 file.
	remote: tar: Child returned status 2
	remote: tar: Error is not recoverable: exiting now
	remote:
	remote:  !     Push rejected, failed to compile Node.js app

I've forked the buildpack to try using Phantom's latest version, 2.0.0, but received the same error.
Any ideas? Anybody else experiencing this?

I'm also having this problem. It's really intermittent, though, maybe because Heroku has the builds cached or something. I pushed up HEAD~1 and it builds, then HEAD~2 and that builds, then I try HEAD~1 again and it fails, and so on down the line. Except one time when I went forward again it build correctly... I have no idea what's going on.

I'm having the same problem and I need to deploy right now. @sgtpepper43 Can you explain how to solve it?

Magically works now...

Oh, no, I have no idea. It just works sometimes.

hmm still failing here.
I noticed that BitBucket, which is hosting PhantomJS downloads, gave me a 500 error when I visited the URL in a web browser today and then loaded successfully when I visited that URL another time. It's possible this is related to a BitBucket issue.

Ah, that would explain the is not a bzip2 file error. It's because it's not downloading the file.

Using the buildpack mentioned in issue https://github.com/AdmitHub/meteor-buildpack-horse/issues/53 worked for me.
https://github.com/alykoshin/meteor-buildpack-horse-1202-fixed

By default, we are including the phantomjs extra that downloads phantomjs from their distribution on bitbucket.  If bitbucket responds with a 404 or 503 or something (as it did for me today), this error can come up -- so unfortunately, we're dependent on bitbucket's reliability.
If you don't need phantomjs for spiderable, you can fork this pack and remove the phantomjs extra; or replace it with a version that fetches phantomjs from a more reliable endpoint than bitbucket.

Still getting this issue, can we remove phantomjs as a dep?


The default fcrepo_syn_default_public_key_path should use the fcrepo_syn_tomcat_home variable

Currently the default value for fcrepo_syn_default_public_key_path is hardcoded to use Ubuntu's tomcat8. This requires both fcrepo_syn_default_public_key_path and fcrepo_syn_tomcat_home to be updated in group_vars if someone wants to use CentOS.
Instead, fcrepo_syn_default_public_key_path should include the fcrepo_syn_tomcat_home variable which would allow us to set the location once in group_vars.
Further, since our tomcat8 role can dynamically set the appropriate tomcat8_home value (once the CentOS PR is merged) we can simply set fcrepo_syn_tomcat_home to use tomcat8_home in group_vars to pass along the correct tomcat8 home without having to update group_vars themselves unless they use another tomcat8 role.

@seth-shaw-unlv I have no problem with this, and I can add it to this existing PR if that is ok?
https://github.com/Islandora-Devops/ansible-role-fcrepo-syn/pull/3

Sounds good to me.

@seth-shaw-unlv I clearly shouldn't have added the fix to this on to #3.
Can you open a PR for this, so it can be merged separate from other issues.

See my comment on another thread.

You are correct that https://github.com/Islandora-Devops/claw-playbook/pull/60 will work, but ideally it would be nice to have the internal variables use the {{ fcrepo_syn_tomcat_home }} and then we only need to set fcrepo_syn_tomcat_home: "{{ tomcat8_home }}" in claw-playbook. But I'll see if I can dig someone up to merge that PR.


Can't bind to 'text-right' since it isn't a known property of 'ion-item'.

Ionic version:  (check one with "x")
[ ] 1.x
[x] 2.x
I'm submitting a ...  (check one with "x")
[x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
I have an ion-list, where I iterate over an array (with *ngFor) and add multiple ion-items. I also wanted to conditionally set the direction of the item, but neither [text-right]="booleanVariable" nor [item-right]="booleanVariable" seem to work. The error I get is
Error: Uncaught (in promise): Error: Template parse errors:
Can't bind to 'item-right' since it isn't a known property of 'ion-item'.

If 'ion-item' is an Angular component and it has 'item-right' input, then verify that it is part of this module.
If 'ion-item' is a Web Component then add "CUSTOM_ELEMENTS_SCHEMA" to the<EMAIL_ADDRESS>of this component to suppress this message.

Expected behavior:
Conditionally setting the direction of the text in ion-item.
Steps to reproduce:
http://plnkr.co/edit/VEHMqZ?p=preview

Thanks for the issue! text-right is just a CSS attribute (see https://github.com/driftyco/ionic/blob/master/src/components/typography/typography.scss#L126). It isn't an input for ion-item so you can't bind to it. If you look at the API docs there is a section called Input Properties for each component: http://ionicframework.com/docs/v2/api/components/item/Item/#input-properties
For more information on property binding, take a look at Angular's documentation: https://angular.io/docs/ts/latest/guide/template-syntax.html#!#property-binding
To conditionally add an attribute, you can use the following syntax:
<ion-item [attr.text-right]="isTrue ? '' : null">
  ...
</ion-item>

For more information on attribute binding: https://angular.io/docs/ts/latest/guide/template-syntax.html#!#other-bindings

Also, item-right is an attribute of ion-icon or ion-avatar, because how is an item going to be to the right of itself 😄 ?


EOL 3.1

.NET 3.1 goes out of support on December 13 and .NET 5 is already out of support.
Creating this draft to discuss as a team what legacy information we may still want to keep in our docs.
I'm starting extremely aggressive and assuming that anyone reading our docs will be working with a supported version of EF Core (they had a year to upgrade), and that any references to previous versions and behaviors will just create distracting noise for anyone trying to understand the current, supported versions.
TODO

[x] Make sure the metadata dates are up to date
[x] Figure out what to do with the platforms page

📝 Design meeting notes

Keep providers for older versions
Keep extensions for 3.1 or newer
Keep older versions on provider/extension compatibility lists
Rework the platforms page

Get rid of the table
Link to .NET docs
Have sections for different platforms

Say the last version that worked with .NET Framework & MAUI
Add MAUI
Talk about AoT here?

@ajcvickers @jcjiang Could you review the Supported .NET implementations page to make sure my messaging is all in alignment?


no error when re-exporting wildcard import from module and redefining a name from it

🔎 Search Terms
wildcard import redefine
🕗 Version & Regression Information
5.5.0-dev.20240421
⏯ Playground Link
No response
💻 Code
// foo.ts

export const foo: number = 1;

// bar.ts

export * from "./foo";
export const foo: string = "asdf"; // no error

🙁 Actual behavior
no error
🙂 Expected behavior
error, because foo is already defined in foo.ts, so it's likely a mistake to redeclare it in bar.ts.
Additional information about the issue
No response

There's no runtime error and "last one in wins" semantics is well-precedented in JS. Plus, there'd be no reasonable way to opt out of this error. This seems like a job for a lint rule if it's really idiomatically an error in your codebase.


chore: add 3.6.5

本次更新的内容主要为...
欢迎前来学习

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


request help: Can supported to bind consumer to service or route?

Issue description
At present, it seems that only by creating a consumer and adding the same plugin to route or service can route and service be authenticated.
Whether it should be allowed to bind consumers directly to a route or service to achieve exact matching of consumers instead of allowing all routes and services using the same authentication plug-in to be globally matched.
Environment

apisix version (cmd: apisix version): 1.1
OS: CentOS 7.7

it should be allowed to bind consumers directly to a route or service

why do we need this feature?

It can help solve access control and control which routes and services a consumer can access.
In the current program, it seems that several routes and services with the same authentication plug-in can be accessed by the same consumer, which may cause unauthorized access.

similar issues #1062 #1243 #385

you are right, that is a todo feature

we can use plugin consumer-restriction to support this.
https://github.com/apache/incubator-apisix/blob/master/doc/plugins/consumer-restriction.md


Support opacity in ThemableDecorationAttachmentRenderOptions

I would like to be able to set opacity in ThemableDecorationAttachmentRenderOptions
I use before/after to insert a graphic. Since unused variables have a lower opacity that also affects the inserted graphic which I don't want.

Did a bit of exploration here, and it seems that the problem is that when the :before pseudo-element is generated, it is wrapped in a span which also has the squiggly-inline-unnecessary class set.  We propose not to add the squiggly-inline-unnecessary class to the span wrapping the :before pseudoelement


fix: centered the bar chart component

Related issue(s)
Fixes #2595
Description
Aligned the bar chart component
Before fix:

After fix:

/rtm


MINIFI-304: Update testing strategy

MINIFI-306: Move Docs and Docker cmake code into a separate module.
this will clean-up the end of the file. We will continue to do cleanup
but this has a great impact to improve the readability of the root
cmake
MINIFI-305: Add header to iOS.cmake module
Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

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

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

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

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

For code changes:

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

For documentation related changes:

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

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

LGTM, but we may also want to take a look at the CMake integration approach provided by Catch (ParseAndAddCatchTests.cmake), which will automatically scan from tests and add them: https://github.com/philsquared/Catch/blob/master/docs/build-systems.md

reviewing

@phrocker These changes look good and good to merge.  Would it be easier if we wait for #83 to finalize and merge first?
@kevdoran Definitely worth exploring.  Want to create a JIRA and we can evaluate at some point?

@aldrin I created MINIFI-319 to track the CMake Catch scanning.

@apiri I would prefer to wait on #83 .

Sounds good.  We can finish that up and go from there.

@phrocker I got #83 in, would you be able to please rebase this on master?

Thanks for the rebase.  Ran through the usual battery of stuff and looks good.  Will get this merged.


fix(openapi): don't rebuild openapi twice

Cargo keeps an internal timestamp of files to trigger rebuilds. If the version of the library did not change then don't touch the file otherwise we could rebuild twice.

bors merge