Update GOV.UK Frontend dependency

Update to v2.2.0

You can preview this change here:
Built with commit 43e2998e2dd05c2a233a9d85013d149e8b440b2c
https://deploy-preview-576--govuk-design-system-preview.netlify.com


[Proposal] Allow multiple express middleware functions to be passed into app.use

By default in Express 4.x you can pass in multiple middleware functions as an array to app.use, documentation link this allows you to chain middleware functions together on a specific route path.
Currently according to the Feathers documentation for app.use you can only supply one middleware function. Testing the following code reveals the docs are correct and only one function can be provided.
app.use('/will-throw-error', [
        function(req, res, next) {
            console.log('step 1');
            next();
        },
        function(req, res) {
            console.log('step 2');
            res.status(200).send('it worked');
        }
    ]);

I believe implementing this feature will help reduce confusion for people who are familiar with using express on its own and also aid in implementing third party modules into a persons feathers.js application using existing documentation. I personally encountered this while trying to add the swagger-ui-express library.

Closed via #25


Investigate: Observe Sidekiq 7 metrics

Sidekiq 7 (currently in beta) will have built-in support for metrics reporting, viewable via Sidekiq's own web UI.
It's possible that New Relic customers would like to have these metrics collected by the Ruby agent to some degree. We should investigate.
https://github.com/mperham/sidekiq/wiki/Metrics

https://www.mikeperham.com/2022/10/27/introducing-sidekiq-7.0/

Sidekiq metrics display time info related to the jobs and number of success/failures for each job.
Since we already are recording time related information, there isn't anything new for us to gain with those metrics.
For the success and failures, we aren't directly recording number of failures or successes for jobs. However, jobs seem to only be considered failures when an error occurs, which is something the agent keeps track of.
If we wanted to add specific success/failure data, we could create some metrics for each job to record the number of failures and successes. The way the sidekiq metrics gets the success/fail info looks to be by querying the job results when loading up the metrics page, so it doesn't seem like there is anything new for us to hook into specific to success or failure, but we could record after the job is done each time and increment the appropriate metric.

@tannalynn  - Thanks for taking a closer look!
Users! If you use New Relic and are interested in the specific success/failure metrics available in Sidekiq 7, please give us some sort of feedback on this issue (emoji response, comment, etc.)

Internal FR link: https://issues.newrelic.com/browse/NR-138200

Blocked; may not be appropriate for the Ruby Agent to implement

This is better suited to using an OHI and has been transferred to another team. Review the internal ticket for details.


Limited viewer functionality in Safari

What
Looking at the same item in Safari and Chrome, I noticed that I have limited functionality in Safari:
I'm missing:

full screen button
Download button
Thumbnail / View all button

Where
https://wellcomecollection.org/works/cwptbk56/items?canvas=1&langCode=lat&sierraId=b31889566
Safari:

Chrome:

@jennpb that looks like the non js version of the viewer you're seeing in Safari, but it's working fine for me. Which version of Safari do you have?

Version 12.0.3 (14606.4.5)
JS is enabled in Preferences. Odd.

@jennpb This behaviour is expected. Safari versions earlier than 12.1 don't support the Intersection Observer API, which we make use of in the viewer and so we fall back to the basic version.
Looking at google analytics for the last year, Safari versions without support for the Intersection Observer API accounted for fewer than 1% of traffic, and this is decreasing. In the last 2 months they've accounted for fewer than 0.5%.

Great, then it's done! Thanks for investigating further.


Is shelling out in windows really needed ?

Hello, these awesome projects idea you have here
Is this https://github.com/cross-org/dir/blob/main/src/dir.ts#L42 really needed ? this will make using dir on windows with deno require run permission, which basically gives away all security

Good point.
Alot of the Windows folders are not exposed as regular environmental variables on Windows.
Maybe moving the windows system special folders out to an "extended" module would make sense. And leave only environmental variable directories in the main module.

I've added a optional second parameter to dir() which is used to opt-into running powershell to resolve certain directories on Windows.
const userHome = await dir("home", true);


KAFKA-12190: Fix setting of file permissions on non-POSIX filesystems

Previously, StateDirectory used PosixFilePermissions to configure its directories' permissions which fails on Windows as its file system is not POSIX-compliant. This PR updates StateDirectory to fall back to the File API on non-POSIX-compliant file systems. The File API doesn't allow as much control over the permissions so they're as close as the API permits.
The unit tests have been updated to also verify the behaviour on non-POSIX-compliant file systems.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks for the reviews. I've addressed the comments other than possibly passing the File into the configurePermissions and assertPermissions methods. Let me know which way you want to go there.

Thanks for the reviews. I've addressed the comments other than possibly passing the File into the configurePermissions and assertPermissions methods. Let me know which way you want to go there.

I think all the review comments have now been addressed. Please let me know if you'd like the commits to squashed into one.

I think all the review comments have now been addressed. Please let me know if you'd like the commits to squashed into one.

Don't worry about squashing all the commits yourself, we'll do that automatically when merging it.
Three test failures in the build, all unrelated:
org.apache.kafka.clients.consumer.KafkaConsumerTest.testCloseWithTimeUnit()
org.apache.kafka.clients.consumer.internals.FetcherTest.testEarlierOffsetResetArrivesLate()
org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationTest.testReplication()

Don't worry about squashing all the commits yourself, we'll do that automatically when merging it.
Three test failures in the build, all unrelated:
org.apache.kafka.clients.consumer.KafkaConsumerTest.testCloseWithTimeUnit()
org.apache.kafka.clients.consumer.internals.FetcherTest.testEarlierOffsetResetArrivesLate()
org.apache.kafka.connect.mirror.integration.MirrorConnectorsIntegrationTest.testReplication()

Merged to trunk and cherrypicked to 2.7

Merged to trunk and cherrypicked to 2.7

I tried to cherrypick this back to the 2.6 branch but there was a merge conflict. I would be happy to review & merge another PR if you'd like to open one against the 2.6 branch, but realistically I think it's unlikely that we'll have a 2.6.2 release just given the lack of x.x.2 releases in recent history.
We can also just keep an eye out for a proposed 2.6.2 release and then work on another patch for the 2.6 branch if that does happen

I tried to cherrypick this back to the 2.6 branch but there was a merge conflict. I would be happy to review & merge another PR if you'd like to open one against the 2.6 branch, but realistically I think it's unlikely that we'll have a 2.6.2 release just given the lack of x.x.2 releases in recent history.
We can also just keep an eye out for a proposed 2.6.2 release and then work on another patch for the 2.6 branch if that does happen

Thanks for the merge.
Given that the regression in 2.6.1 makes Streams unusable for developers working on Windows, I really think that a 2.6.2 release is needed here. To that end, I've opened a new pull request based on the 2.6 branch.

Thanks for the merge.
Given that the regression in 2.6.1 makes Streams unusable for developers working on Windows, I really think that a 2.6.2 release is needed here. To that end, I've opened a new pull request based on the 2.6 branch.

As I commented on the JIRA issue I think it is important to get a 2.6.2 release out sooner rather than later.

As I commented on the JIRA issue I think it is important to get a 2.6.2 release out sooner rather than later.

@garyrussell I just merged the 2.6 PR so we'll be ready to go if/when the 2.6.2 release is started. To be honest I'm not sure how likely it is for a 2.6.2 release to be rushed out. It's a lot of work to roll out an AK release, even a bugfix. It might be difficult to convince someone to take all that on as a release manager in order to fix a regression that impacts a relatively small subset of users (this is not my personal philosophy, just my expectation).
That said, it's always worth asking, and the dev mailing list is probably the best way to get some attention.

@garyrussell I just merged the 2.6 PR so we'll be ready to go if/when the 2.6.2 release is started. To be honest I'm not sure how likely it is for a 2.6.2 release to be rushed out. It's a lot of work to roll out an AK release, even a bugfix. It might be difficult to convince someone to take all that on as a release manager in order to fix a regression that impacts a relatively small subset of users (this is not my personal philosophy, just my expectation).
That said, it's always worth asking, and the dev mailing list is probably the best way to get some attention.

@ableegoldman I understand, but for the reasons I stated on the JIRA, this was a critical regression and some users have no choice regarding upgrading.
I have no personal ax to grind; I don't use Windows, but many developers have no choice there either.
I wonder if there could be a new mechanism to just release the kafka-clients, e.g. <IP_ADDRESS> ?

@ableegoldman I understand, but for the reasons I stated on the JIRA, this was a critical regression and some users have no choice regarding upgrading.
I have no personal ax to grind; I don't use Windows, but many developers have no choice there either.
I wonder if there could be a new mechanism to just release the kafka-clients, e.g. <IP_ADDRESS> ?

Yeah that's completely valid, but unfortunately it's not up to me 🙂
I do think you should raise this on the mailing list -- maybe someone there will have an idea of how to proceed. I also think it's worth bringing up to get some discussion going on how we can avoid things like this from happening again, since testing on Windows is (obviously) not part of the current release process.

Yeah that's completely valid, but unfortunately it's not up to me 🙂
I do think you should raise this on the mailing list -- maybe someone there will have an idea of how to proceed. I also think it's worth bringing up to get some discussion going on how we can avoid things like this from happening again, since testing on Windows is (obviously) not part of the current release process.

@wilkinsona Hello thank you for the fix, I still have an issue, using KeyValueStore and getting
org.apache.kafka.streams.processor.internals.StateDirectory  - Failed to change permissions for the directory C:\Users\user1\AppData\Local\Temp\kafka-streams
when calling         streams = new KafkaStreams(topology, props);
Tried to debug and this always returns false ( set &= file.setWritable(true, true) )
Running win10, admin user, openJdk11 latest, Kafka 3.0.0
The folder has setup Full Control for user1/SYSTEM/Administrators/Everyone, I'm running out of ideas. Thanks for every tip.

@notme159
Same here :( Did you find out something?

@aybefox Well the folder permissions are correct (it is writable), it just logs error when the setWritable is called. So I just suppress the StateDirectory log in log4j config using FATAL level only for this class, not to show ERROR in log.
Of course it's not greatest work around as you might suppress another errors in that class.

by casuse see http ://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6728842


use pdf v1.5 to facilitate review of generated pdf documents

as suggested by @gsautter in a 2024-12-10 email -

[...] PS: if there is any way of convincing PdfBox to save as PDF 1.5 or lower, the resulting files would be far easier to read in a text editor, and the object streams used in PDF 1.6 obscure lots of the objects, if not in a malicious way ... more relevant for testing and trouble shooting than for actual production, of course. [...]

as far as I can tell, rending pdfs in version 1.5 is not supported by PDF box. @gsautter please comment / re-open if you have example to suggest otherwise.


Improve padding and width for Notifications

Per issue here, we want to add some more padding and make the width of notifications more flexible. Screenshots of the changes are in that issue.
https://app.clubhouse.io/glitch/story/8589/change-default-padding-for-notifications#activity-8614

:rocket: PR was released in v0.19.0 :rocket:


WireConnectionFilter does not extend CenterWireConnectionFilter

The Issue
The WireConnectionFilter interface does not adapt the CenterWireConnectionFilter interface like it does for the other two connection filter interfaces.

Fixed in v0.3.9, v0.4.7, and v0.5.2.


Automated cherry pick of #2193: fix: imported esxi VM fail to rebuild root

Cherry pick of #2193 on release/2.11.
#2193: fix: imported esxi VM fail to rebuild root

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@38114c2). Click here to learn what that means.
The diff coverage is 0%.

@@              Coverage Diff               @@
##             release/2.11   #2195   +/-   ##
==============================================
  Coverage                ?   7.07%
==============================================
  Files                   ?     451
  Lines                   ?   71051
  Branches                ?       0
==============================================
  Hits                    ?    5026
  Misses                  ?   65612
  Partials                ?     413

Flag
Coverage Δ

#aFlag
7.07% <0%> (?)

Impacted Files
Coverage Δ

pkg/compute/guestdrivers/esxi.go
4.9% <0%> (ø)

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 38114c2...2f397d1. Read the comment docs.

/approve
/lgtm


feat : rule.if

On Hold
The issue was solvable by making sure that all fragments in a rule must match an element in the document. I'll keep this PR around and in sync with master, should we need it sometime.
Description
Adds a new property if to fragment rules, to only run rules if they match the callback:
{
  rules: [
    {
      from: '/users/:filter?',
      to: '/users/:filter?',
      containers: ['#users'],
      if: () => new Date().getHours() > 20 // only do this after 8pm 👾
    }
  ];
}

Or:
{
  rules: [
    {
      from: '/users/:filter?',
      to: '/users/:filter?',
      containers: ['#users'],
      if: (visit) => visit.to.url !== '/users/my-exception/' // Don't do this for an exact match with '/users/my-exception'/
    }
  ];
}

The real use case I'm using it for:
const rules: Rule[] = [
	/** Home, Projects & Filters <---> Single Project */
	{
		from: ['/', '/projects', '/projects/filter/:filter'],
		to: '/projects/:slug',
		containers: ['#project'],
	},
	{
		from: '/projects/:slug',
		to: ['/'],
		containers: ['#project'],
	},
	{
		from: '/projects/:slug',
		to: ['/projects', '/projects/filter/:filter'],
		containers: ['#project', '#projectslist'],
		name: 'from-project-to-projects',
		if: () => !Boolean(document.querySelector('.page.home'))
	},
	/** Projects & Filters <---> Projects & Filters */
	{
		from: ['/projects', '/projects/filter/:filter'],
		to: ['/projects', '/projects/filter/:filter'],
		containers: ['#projectslist', '#page-header'],
		name: 'projectslist',
		focus: false,
	},
];

Checks

[x] The PR is submitted to the master branch
[x] The code was linted before pushing (npm run lint)
[x] The documentation was updated as required

My reasoning behind putting this on hold is that if I would have have had it on my fingertips before implementing this feature, I would have missed the opportunity for thinking about the root issue. I'm still very much open to merge this the day we find an issue that is absolutely not fixable with the declarative API.

Sounds like a plan!

Actually, I just realized that too many things have changed in master and merging this would be a nightmare. I'll close this PR, we can always get back to it and extract the functionality back into master should we end up needing it sometime in the future.


if UITableViewController or UICollectionViewController don't create by stroyboard how can i use AMScrollingNavbar??

if UITableViewController or UICollectionViewController don't create by stroyboard how can i use AMScrollingNavbar??

Sure, it's a category, you can use it even if you don't have a storyboard at all.


Scan specific barcode (e.g. filtered by [Barcode.qrCode, ...])

What

[ ] Scan specific barcode (e.g. filtered by [Barcode.qrCode, ...])

+1

Please see the formats parameter of the MobileScannerController.


Feature/menu

implemented help and about menu.

@arman-tdev / @apurvabisht97/ @navin9584  ,  Please check if you can find better image for v1.0/frontend/SaralApp/src/assets/images/about.png. current one doesn't look great.

sure @dileep-gadiraju

hi @dileep-gadiraju  i have tested above pr . this pr is working as expected .


Private members being emitted to definition file

If they are supposed to be emitted, they are un-typed.
Seen in 1.4.1 and master.
Example:
Test.ts:
class Test {
    private static BAR: string = 'BAR';
    private _foo: string = 'foo';
}
export = Test;

tsc -d --target ES5 --module commonjs Test.ts
Test.d.ts:
declare class Test {
    private static BAR;
    private _foo;
}
export = Test;

This was found when overloading a superclasses' setter/getter.
Throws error:
Class 'SubClass' incorrectly extends base class 'SuperClass'.   Types have separate declarations of a private property '_foo'.
Parent project:
class ObjectA {
    public value: any;
}
class SuperClass {
    private _foo: ObjectA;
    public get foo(): ObjectA {
         return _foo;
    }
}

Parent defintiion:
declare class ObjectA {
    private value: any;
}
declare class SuperClass {
    private _foo;
    public foo: ObjectA;
}

Child project:
class ObjectB extends ObjectA {
    public value2: any;
}
class SubClass {
    private _foo: ObjectB;
    public get foo(): ObjectB {
         return _foo;
    }
}

This is by design, see #1532.

Interesting.  Thanks for the link. I couldn't seem to find an issue that related.


marge calculator having same inputs ( center and radius)

Proposal
we can merge these in one by providing multiple button for different operation  as they have same input this will reduce the height of page and it became easy to navigate as name of site makes math easy
(A clear and concise description of what the proposal is.)

i like to work on it under gssoc21


incorrect values for azure-dev environment

Describe the bug:
otomi template not working properly due to incorrect values for Azure Dev environment.
To Reproduce
Steps to reproduce the behavior:

Open otomi-core repo in a Terminal window:
export CLOUD=azure CLUSTER=dev
otomi validate-templates true
See errors

Expected behavior:
All charts should be templated correctly but the following chart values are broken: cert-manager-raw, external-dns, ingress-azure
Error Logs:
in helmfile.d/helmfile-20.ingress.yaml: 3 errors:
err 0: failed to render values files "../values/cert-manager/cert-manager-raw.gotmpl": failed to render [../values/cert-manager/cert-manager-raw.gotmpl], because of template: stringTemplate:8:16: executing "stringTemplate" at <$cm.provider.azure.azuredns>: map has no entry for key "azure"
err 1: failed to render values files "../values/external-dns/external-dns.gotmpl": failed to render [../values/external-dns/external-dns.gotmpl], because of template: stringTemplate:21:10: executing "stringTemplate" at <$dns.azure>: map has no entry for key "azure"
err 2: failed to render values files "../values/ingress-azure/ingress-azure.gotmpl": failed to render [../values/ingress-azure/ingress-azure.gotmpl], because of template: stringTemplate:17:19: executing "stringTemplate" at <$i.armAuth.secretJSON>: map has no entry for key "armAuth"

Cluster(s):

Cloud: azure
Cluster: dev

Versions:

Core Version master

@Morriz I found what is causing this issue.
The problem is from sops and this is the only file from the list which is not decrypting correctly. Still working on figuring out what is the actual problem.
Decrypting ./clouds/azure/secrets.overrides.azure.yaml
Error decrypting tree: Error walking tree: Could not decrypt value: Could not decrypt with AES_GCM: cipher: message authentication failed
Error: plugin "secrets" exited with error

After retrying the otomi decrypt a couple of times it worked.
I traced the issue of broken values to the following file:  VALUES-REPO/env/secrets.settings.yaml
Here the azure and google blocks were top level properties and I guess they should have been under clouds.
clouds:
    azure:  ---
    google: ---

After fixing this, templates are rendering. @Morriz Should I push the fix to values repo?

Actually for the whole repository to work again a fix to values/cert-manager-raw.gotmpl is needed to access values from the same structure.
line 22:      key.json: "{{ $v | getOrNil "clouds.google.cloudDnsKey" | b64enc }}"

Sorry, the values repo is ok, problem is comming from sops not decrypting that file and this gives templating errors hard to debug.
Closing this issue as file decryption is working after couple of retries.

After retrying the otomi decrypt a couple of times it worked.
I traced the issue of broken values to the following file:  VALUES-REPO/env/secrets.settings.yaml
Here the azure and google blocks were top level properties and I guess they should have been under clouds.

clouds:

    azure:  ---

    google: ---

After fixing this, templates are rendering. @Morriz Should I push the fix to values repo?

Yes, those props are now top level. That is by design. So no change needed.
I recommend to regularly do a docker pull otomi/core:master and docker pull otomi/core:latest. After that do otomi bootstrap to get the latest values-schema.yaml.


Add support for Underlined independent of LVB_UNDERSCORE

Discussed with @DHowett-MSFT, as a follow up of #2554.
We've been using LVB_UNDERSCORE for underlines in the console since Windows 10 was released. However, LVB_UNDERSCORE is more of a box-drawing feature, it draws the underline fully under the text.
We should more correctly have a separate Underline state, that draws the underline at the baseline of the text, not just under it.
In VT, underline is in a trinary state: [No Underline, Underlined, Doubly Underlined]. We should make sure to store this in the buffer appropriately.
Technically, we believe characters could have both Underlined and LVB_UNDERSCORE.
Open Questions:

[ ] should Underline be read from the API as LVB_UNDERSCORE? Currently it is, but I think that it shouldn't. If you round-trip the attributes, then that would pollute the state.

The diff to do this directly is pretty minimal (and it looks nicer now that @j4james has done #7107).

Should underline read back as LVB_UNDERSCORE

Nope, for the exact reason you mentioned.

Trinary

There was an open discussion about how underline types stack in #2916.
James asserts, about double/single underline being a trinary state,

Yes and no. There aren't many terminals that support double-underline for real (most treat it as a synonym for single underline) so there's no obvious consensus. In VTE it's a trinary state, where the last choice (single or double) takes precedence. However in XTerm, underline and double-underline are actually separate attributes, and double-underline takes precedence when both are set, regardless of the order they were applied.
I'm not sure it matters that much, but I'd probably be inclined to follow the XTerm approach.

I'm inclined to agree with this.
If we don't have to worry about making underlined/doubly underlined trinary, we can close 2915 with 2 files changed, 7 insertions(+), 4 deletions(-).

Before

After

@DHowett I was just putting together a PR for this, but it looks like you've done it already. Should I leave this with you?
As for the doubly underlined attribute, I was going to suggest we simply render that as a single underline for now, since that's what many other terminals seem to do. We should still parse and store it separately, though, so we can pass on the correct SGR value to the conpty pipe for clients that do actually render it differently.

I wasn’t going to do the Doubly Underlined bits, so I imagine you’re farther along than I am :) I’ll leave it to you
Agree on equating doubly with singly during render for now
Thanks!

OK so I started with rendering the doubly underlined attribute as a simple alias for the single underline, but it occurred to me that it might not be that difficult to add a proper renderer for it with the framework we now have in place. And you can see below some examples of what I've got so far.
I'm still tweaking the look, and there are some issues with the conpty pass-through that I'm not completely happy with, so in the meantime I thought it would be best if I just submit a PR with the basic underline functionality to start with. Then we can continue the doubly-underline discussion in #2916 and add a separate PR for that later.


remix method

Hi
What is the url of remix method in Ideogram? Is it implemented in this repo? Or is there any plan for implementing this feature?
(for generating images according to previous generated images)
tnx

Thank you for your interest in the project. Regarding your question about the remix method in Ideogram, I'd like to inform you that currently, the project is experiencing issues related to Cloudflare security measures, as reported in other comments.
At this moment, I am the sole maintainer of this project and my available time is quite limited. Due to these constraints, I'm unable to commit to implementing new features like the remix method you've inquired about, unless more contributors join the project to help with its development.
Thank you for your understanding.


Support to lower case validation

The control code can be in both uppercase and lowercase

Codecov Report

Merging #5 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##             master     #5   +/-   ##
=======================================
  Coverage       100%   100%
- Complexity       57     62    +5
=======================================
  Files             3      3
  Lines           110    116    +6
=======================================
+ Hits            110    116    +6

Impacted Files
Coverage Δ
Complexity Δ

src/Validator.php
100% <100%> (ø)
37 <0> (+5)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23df5ad...90f946f. Read the comment docs.


Run Spark ValidatesRunner

R: @suztomo

Could not find method exclude() for arguments [**/AvroSchemaTest.class] on configuration

Whoops sorry about that. That's what I get for rushing, let's try this again.

Run Spark ValidatesRunner


Add the Content-Location header

See https://tools.ietf.org/html/rfc7231#section-<IP_ADDRESS>

This may be a better issue for hyper.

Ah. I didn't realize they were pulled directly from hyper (documentation? what documentation?) :)

https://github.com/hyperium/hyper/issues/870


fix: highlights for badges

Description
Changes proposed in this pull request:

fix: highlights for badges

Related issue(s)
https://github.com/kyma-project/busola/issues/3001

/kind lgtm


Notification

hi,
The first commit is working fine. I then tried to use redux-act but there is an issue on how I register the action with store as the reducers are not triggered on action. Can you please check. Also, you may comment on placement of new files.
Cheers,
bsr

just noticed the test is failing. I only use unit tests, and not sure why they fails. Probably because I added new dom elements. can you please comment.

to test, you can stop neo4j and which shows an important notification, which needs explicit acknowledgement. There is also a not important welcome message when we load the page.

Thank you for your PR. First batch of comments is ready.

Hi @vslinko. thanks for your effort on detailed review. I was bit busy last few days. I will finish it when I started using this part again, and hope it helps someone as an example till then. thanks again.


Update to 8.0.0.beta1

This change is

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


[RFC] Set current = true on camera to follow player

This does not fix all the problems in #46 but at least it places the camera on the player and respects camera limits, so that's something.
The camera is still zoomed wrong, but I'm almost sure this is a step in the right direction.

I have no problem with this change. You simply set the default value of current so that the camera is directly active by default, which seems logicial for a newcomer. WDYT @fleskesvor ?

As long as it respects the bounds of the current scene, this sounds like a reasonable default to me. Does it work OK with the current demo scene too? If I remember correctly, the chainsaw has been outside of the viewport in my testing, so there has been no way to interact with it, since the camera doesn't scroll, so that might be fixed by this PR too.
In the future we could implement some kind of elasticity like Adventure Creator has, as described by @mjtorn in #46, but I agree that this PR sounds like an improvement over the current default.

It seems to work a lot better with the camera limits/bounds, yes. If you change the zooms or such, it'll fail but I doubt it's this change's fault.

As for the test scene, I had to set the Screen Size Override setting to true to have a proper size for the window, but the background on it is so small it doesn't really have an effect. I think the test scene may be broken somehow :/

Ok, I think it's ok to merge then.
However I think the next important task is to clean out all Escoria's custom ProjectSettings entries and re-create them in a proper Escoria category. I'll create an issue for this.


CubicalComplex documentation could be more inviting for higher dimensionsal data

Hi Bastian,
As I wrote in my E-mail to you I was a little confused and deterred by the documentation of the CubicalComplex class. I expected that your implementation only works for 2D images and was worried that, when feeding a 3D volume the third dimension would simply be considered channel information. I think especially the explicit example in the forward() method threw me off there:
     1. Tensor of `dim = 2`: a single 2D image
     2. Tensor of `dim = 3`: a single 2D image with channels
     3. Tensor of `dim = 4`: a batch of 2D images with channels

Now after having spend a little time reading the code and documentation again I can see that you were correctly describing the behavior of the method and there was a misunderstanding on my side. Still, I think the docs could be more inviting for higher dimensional data.
One way I thought of to improve the docs is to add an example for higher D data, or mention the usage of volumes etc in the docs.
Another way could be to slightly restructure the code and to simply set the default value of dim not to dim=None but dim=2, which would in my eyes result in the same behavior and to explain the behavior of treating "extra dimensions" of the data as channels/batch in a more general way with a specific example perhaps for 2D.
Thanks again for your help with our Project and your awesome work in the TDA field!

Thanks for raising this issue! Just updated the documentation—please check again and let me know what you think.

Looks good to me :) Thanks for the effort!

You are very welcome!


Forgotten coma in parameters breaks ECS

After optimalization of my function call I forgot comma in function call foo(parameter,) which for some reason died on memory and never finished the run. It took us ages of debugging to find this mistake :D

Hi, I'm not sure what you're trying to report. Is there issue somewhere or you for a rule to find those? :)

Also, this is rather topic for linter, as coding standard tool cannot work with invalid code.
See https://github.com/php-parallel-lint/PHP-Parallel-Lint
We use it as a standalone workflow run in our CI :+1:


alevin-fry and/or UMI Tools

Hi @drneavin,
This isn't really an issue, I was just wondering if you have run Demuxafy using the outs from other UMI calling tools like alevin-fry or UMI tools? If one uses a tool that employs pseudoalignment to the transcriptome and creates a rad file instead of a bam file, is it still possible to demultiplex with tools like Demuxalot that require a bam file? As I am doing single nuclei RNA seq on challenging tissues, I wanted to directly compare the resolution of mapping issues between optimizing the cellranger reference and the way that alevin-fry deals with mapping issues. This may be a naive question, but is there a way to convert the rad file to a bam file (I guess not because it wasn't mapped to the genome?), or just use the rad file instead?
Thanks!

Hi @changostraw, I'm not very familiar with rad files but in looking online it looks like it is effectively a counts table that is missing the read information, can you confirm if you have a rad file that this is accurate? In this case, it would be missing the information about the allele at each SNP location so it wouldn't be suitable. Is there the possible of outputting a bam file alevin-fry processing?

Thanks for your input @drneavin. I have already asked the alevin-fry authors about the bam issue, as their psudeoalignment method maps to the transcriptome and not the genome, it probably cannot do this. However, their other method "selective alignment" is a more traditional mapping approach so perhaps can produce a bam. I also might try to see if I can use the cellranger bam from the same pool with the alevin-fry filtered matrix just to see the differences in mapping - thanks!


pytorch version: 2.4.1+cu124 inapplicability？

Error(s) in loading state_dict for ImageProjModel:
size mismatch for proj.weight: copying a param with shape torch.Size([65536, 768]) from checkpoint, the shape in current model is torch.Size([16384, 768]).
size mismatch for proj.bias: copying a param with shape torch.Size([65536]) from checkpoint, the shape in current model is torch.Size([16384]).
I tried to update xlab, re-download the model, and tried again and again, but it didn't work under dev, dev8, and dev16
Does anyone have a problem with that？

Same problem..

Same here, any solution yet?


Cas: make token as service ticket more general

Presently the token as service ticket is specific for JWT.
Convert the relevant classes to operate at a general level so tokens other than JWT can be used.

RegisteredServiceProperty

change JWT_SERVICE_TICKETS to TOKEN_SERVICE_TICKETS
change content of TOKEN_AS_SERVICE_TICKET to be generic
add JWT_AS_SERVICE_TICKET with content of prior TOKEN_AS_SERVICE_TICKET
global search and replace

TokenWebApplicationServiceResponseBuilder

add ability to detect multiple token types maybe in generateToken()
move JWT specific actions to builder or utility

TokenTicketsConfiguration

change tokenTicketBuilder to be a map of TokenTicketBuilder types keyed on ??_AS_SERVICE_TICKET


fixed userhash encoding for python3

Making the userhash work on Python3 with Python2 backward compatibility.
cf https://github.com/nicolaiarocci/flask-sentinel/pull/8#issuecomment-237471984

Merged with https://github.com/nicolaiarocci/flask-sentinel/commit/ce7bc554baf4357a8984e78351227ca9c7a78863
Thanks!


fix doc for ISO date input

original code contains error
Changes to be committed:
modified:   docs/Inputs.md
modified:   docs/_layouts/default.html

There is no mention of the store anywhere in the doc, on purpose. At a basic level, a developer shouldn't need to know about Flux to use aor. Can you remove the comments in the jsx and the section name change?

What if I change the wording from store to record?
AOR does store the value somewhere and sent that to the API endpoint.
It seems the term record has been used in the docs.

I'm fine with that.

Thanks!


How to get quantity of elements?

Hi @typicode
First, thanks for cool peoject!
I'd like to ask, is it possible to get the number of elements in the resposne? And if so, how to do this.
Thnx :)

You can send this request

And response will be sent with X-Total-Count header.


Problem with 9c070a789029792a75be34aed408906ee3e3653f

i try install and got strange error:
Obtaining pgoapi from git+https://github.com/keyphact/pgoapi.git@9c070a789029792a75be34aed408906ee3e3653f#egg=pgoapi (from -r requirements.txt (line 3))
Cloning https://github.com/keyphact/pgoapi.git (to 9c070a789029792a75be34aed408906ee3e3653f) to ./src/pgoapi
Could not find a tag or branch '9c070a789029792a75be34aed408906ee3e3653f', assuming commit.
Best Regards
TaKeN

run again the:
pip install -r requirements.txt


Create parent loggers upon initialization

This PR:

[X] Removes findParent method, which happens to create multiple root loggers with the empty name ""
[X] Instead added prepareParentLoggerOf(name) to ensure creating and registering the parent loggers in advance. This also reduces the overhead of resolving parent loggers

Could we have appropriate tests for this PR?

@sjrd OK. I'll add test cases

@sjrd Added test cases.

test_single_root fails in the current master branch
Fixed to use the root logger for the parent of the anonymous logger

I'll check test failures at Travis

@sjrd Changed the design to be compatible with Scala JVM/JS.

The parent logger is resolved at newLogger creation. The parent will be an already existing parent or ancestor (including root).
All child loggers will be updated if a new parent logger is added.
The root and global logger are now registered at Logger object initialization time.

@sjrd Could you review this PR again? Actually this is a blocker for supporting Scala.js in our projects: https://github.com/wvlet/log/pull/8, https://github.com/wvlet/airframe/pull/45, etc.
Thanks in advance.

@sjrd Thanks for the review and applied the review comment. And also added more comments to updateChildLoggerParent to make clear its behavior.


Updated sencha to <IP_ADDRESS>

Thank you for the contribution. It was merged directly as 7b2e06170aa55fd4143ab708e0dd3e2757c91e96 to keep commit history cleaner. Your contribution is still credited to you.


Java 6.2: Switch Blocks

Description
DescriptionAdd audio, documentation, and video regarding the Switch Blocks.

Location of File to be added
The files should be added inside the Switch Blocks  folder which is inside the Control Statements  folder present in the   Java  main folder.  The documentation file can be in the .md/.py/.ipynb format. Audio should be in .mp3 format and to be submitted through a Google drive link. Video can be in any format and should be submitted through a Google Drive link.
Note:

You are required to comment with \assign CONTENT_TYPE, so that other content types can be created at the same time.
Failing to comment in the above manner will lead to the removal of assignment from the issue even if the bot assigns.
You are required to do a PR within 7 days otherwise you will be unassigned and others will be assigned.
Issues will be assigned on a first come first serve basis.

Domain
Java_Domain
Type of Contribution
Audio, Video, Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign document

\assign document

Please assign me for Audio

@ShikhaSwati60 You have been assigned documentation and @subhradwip01 You have been assigned audio

\assign video

@avinashkranjan go with the video

@Shraddha-Jaggi Audio content has already been merged.

/assign documentation

\assign documentation


Feature: option to manage a cron which removes dangling images

We've been using this Puppet module to deploy a Docker lab. However, we've found out that we accumulate dangling images and we need to clean it up regularly.
It would be nice if the module let you create a cron file which does:
$ docker rmi $(docker images --quiet --filter "dangling=true")
daily, or something like that.

I\d recommend something like https://github.com/spotify/docker-gc for this purpose. You could certainly write a defined type around creating a cron for this but I think that's probabl outside the scope of this module at the moment (although if someone submitted a compelling PR I might be convinced to change my mind).


[FEATURE] Render full video based on keystroke history

As the title, is it possible to render a full video based on keystroke history using ffmpeg? That could be another useful feature.

Hi @chunribu ! Thank you for your question :-)
If I understand well, you want to present slides, record keystrokes at the same time, and then have a video file that shows exactly what has been shown during the slide presentation?
If so, this is currently not implemented, but should be very easy to do.

Well, this is harder than expected, because rendering or saving frames in the same time as presenting, actually slows down the presentation.
I might need to implement some kind of Presentation.get_current_state, then save the state for every frame, and re-read the same files after the presentation to generate output video.

Hi @jeertmans
Glad to see you considering this advice. Thanks for letting me know how it goes.
Please continue at your own pace, and have a nice day!

Hi @chunribu , when you have time, can you try to new feature, see #25 ?
To test it, please install:
pip install git+https://github.com/jeertmans/manim-slides@record-presentation

Thanks!

I am re-opening this as this might be worth reconsidering the way we write the video: maybe use PyAV instead?

Oops, forgot I removed this feature in #243. It's just probably better to use a separate tool to record the screen.


Image license

I think Camtrap DP should allow publishers to indicate the license of the images. It can be different from the license of the data. In general, Camtrap DP doesn't make many assumptions about the images (size, whether they are accessible, etc.), but most of those properties can be derived (by machines) by following the path or URL. That is not the case with the license, which is why I think it would be good to have it as a term in media.csv.
This issue is not about what license(s) should be applied to media files, only that it should be possible to indicate it.
Field properties

The field would be optional (no license typically assumes "all rights reserved")
The value would be a URL, e.g. https://creativecommons.org/publicdomain/zero/1.0/. Note that the license property in Data Package requires a name and/or path property. The name must be the name of one of the 100 licenses at https://opendefinition.org/licenses/api/#all-licenses. For our field, we could also opt to use license name rather than license URL. That would offer more control that the provided value is actually a license, but it offers less freedom (could be a good thing) and it's less consumable by users/machines than a URL.
The definition could refer to the rightsHolder (see further).
Update Url to URL in https://github.com/tdwg/camtrap-dp/blob/293ec5dcbf27f7605138a1585272229c06b3bd68/media-table-schema.json#L67

Proposal
{
      "name": "license",
      "type": "string",
      "format": "uri",
      "description": "URL of the license under which the media file is provided. The rights holder can be indicated in `rightsHolder` in the data package metadata.",
      "example": "https://creativecommons.org/publicdomain/zero/1.0/",
      "constraints": {
        "required": false
      }
}

Size increase
This proposal would add a license value to every record in the media.csv, which increases file size. However:

Adding a license to the media.csv resource is not a good alternative, as that one applies to the csv data, not the linked media files
Adding an additional license at Data Package level is not a good alternatives, as it cannot be indicate which one applies to the data and which one to the media files.
It offers the flexibility to use different licenses.
The repetition would zip well.

Credit
Ideally, we should also indicate how the image should be credited (if required by the license). Adding that information for every image might be overkill, so I suggest that the definition refer to the rightsHolder. That definition could be extended to ... owning or managing rights over this data package and associated media files.
https://github.com/tdwg/camtrap-dp/blob/293ec5dcbf27f7605138a1585272229c06b3bd68/camtrap-dp-profile.json#L80-L84

@ben-norton @kbubnicki others, thoughts?

@peterdesmet @kbubnicki

The images and data should always be licensed separately. A provider can use the same license for both, but separate licensing should be required.
In most cases, I support the provision of general flexibility in areas where it doesn't compromise data integrity. This is different. We should not provide the flexibility to license every image differently in a data package.
A. Most data package providers will not license images individually. Its a time consuming and usually unnecessary. This can be a problem for images that contain an entity (such as a person) that is subject to additional restrictions. However, that situation shouldn't be handled by a separate license, rather a data policy or withholding the image are better strategies.
B. Allowing the license field to vary for each record in the media csv file will increase the likelihood of error during data entry. Since the field will most likely not vary, the possible rewards are minimal and therefore only the risk will remain.
C. Reuse becomes very cumbersome if images are licensed individually. A user would need to parse through every single row in a media.csv file to view the license information before reusing the data.
D. If we stipulate that all images must adhere to a single license in a data package, then there isn't a need to annotate them individually. Instead, the license field should be moved to the data package json file.

The Data Package documentation allows for an array called licenses that must contain a name and/or URL with an optional title. These are insufficient for a dual-licensing model, where one license applies to the metadata and the other applies to media. Fortunately, the licenses property is an array, which can accommodate multiple licenses. The only missing piece is the scope with a controlled vocabulary (metadata, media). If the scope field can be added to objects in the licensing array, then the problem is solved. It might look like the following:
"licenses": [{
"scope": "media"
"name": "ODC-PDDL-1.0",
"path": "http://opendatacommons.org/licenses/pddl/",
"title": "Open Data Commons Public Domain Dedication and License v1.0",
},
{
"scope": "metadata"
"name": "CC0 1.0",
"path": "https://creativecommons.org/publicdomain/zero/1.0/",
"title": "CC0 1.0 Universal Public Domain Dedication",
}
]
In terms of business rules, I suggest the following:
2 Options.
Option 1.

The licenses array is required.
The licenses array must contain at least one license object. If one object is provided, even if the scope is included, then the license applies to both media and metadata.
Example: A data package contains a single license object scoped to media that looks like the following:
"licenses": [{
"scope": "media"
"name": "ODC-PDDL-1.0",
"path": "http://opendatacommons.org/licenses/pddl/",
"title": "Open Data Commons Public Domain Dedication and License v1.0",
}],
Since a second license object was not provided for the metadata, the object above applies to both, even though the scope is listed as media.
A scope is required if two objects are provided in the licenses array (otherwise, it's impossible to know which one applies to which content.)
Rules governing the presence of path, name, and title follow the existing frictionless documentation (https://specs.frictionlessdata.io/data-package/#metadata)
Option 2.
The licenses array is optional. If it is not provided, then both metadata and media are distributed under a single default license. Otherwise, numbers 2, 3, and 4 in Option 1 apply.

I would like to weigh in, mixed license datasets are an annoying reality that seriously hinders reuse, and should be avoided as much as possible. However, while this is currently not the case for our camera trap images (CC-0, data is CC-BY-SA). I can certainly imagine deployments where a partner would like their images included in our dataset (and identified in our pipeline) but would not be able to give a license waiver like CC-0.
So, while I think it's unlikely to be a big problem for single deployment datasets, I think it will be when it comes to exchanging multi year/deployment datasets that had multiple collaborators, and perhaps different iterations of data management planning.
So, I would suggest a solution similar to DwC-A, having a license per record, and allowing (but discouraging) mixed licenses in a comment. Aligning with the Multimedia extension in this aspect is also user friendly, and might perhaps avoid some confusion.

@ben-norton I like that suggestion! I'd make some minor changes to the business rules you list: I'll see how that can be implemented.
@PietrH I understand your concern, which is why I originally suggested a license per image. However:

when it comes to exchanging multi year/deployment datasets that had multiple collaborators

I think that is something they could reasonably agree upon. The scope of a Camtrap DP dataset is a study, so there is generally a single person (e.g. PI) that can make final decisions.

Aligning with the Multimedia extension in this aspect is also user friendly, and might perhaps avoid some confusion.

A translation to Darwin Core or the Multimedia extension will have to take the properties of the datapackage.json profile into account anyway (e.g. for dataset name), so it's quite easy to assign the single media license to every image when transforming to DwC.

I asked the Frictionless Community regarding this approach on their Discord. This use case hasn't been encountered before, but the approach suggested by @ben-norton sounds reasonable. Here's a copy/paste of that discussion:
1 @peterdesmet
Hi all, for our frictionless camera trap data, we want data publishers to be able to indicate the license of the CSV data and the license of the image files referenced in media.csv. A datapackage license allows multiple licenses https://specs.frictionlessdata.io/data-package/#licenses We would like to build upon that to indicate scope:
"licenses": [{
  "name": "CC0-1.0",
  "scope": "data" <- License applies to the data in the package
},
{
  "name": "CC-BY-4.0",
  "scope": "media" <- License applies to the referenced media files
}]

Is that a good approach? Has anyone else encountered a similar use case? Suggestions?
Note that a resource can have its own license property, but still applies to the CSV data itself, not the referenced images.
2 user1
Hi @peterdesmet . Interesting question.If I understand correctly, the referenced media files are just included as links to another URL, and the media files themselves are not included in the data package and are hosted elsewhere, right? In that case, wouldn't it be the responsibility of the server which serves the media files to declare the license, instead of the data package that merely links to it?
3 @peterdesmet
That is correct, although the image files could be included as part of a data package, but Camtrap DP doesn't make any assumptions regarding that.
It could indeed be seen as the responsibility of the server, but a) the URLs hotlink the images themselves (easier to consume), so it would have to be embedded in the exif metadata, b) having to assess the license per image is a burden to the user, and c) many servers might not provide that functionality. It would therefore still be useful if the data producer can indicate that at package level.
4 user1
Well, in that case, each link to each image could also be included as a resource in the data package, and their specific licenses could be indicated at the resource level. Would that be a good solution for your use case?
5 @peterdesmet
Thanks for the suggestion, but that would seriously bloat the package: some contain over 1 million+ images. It would also be difficult to consume, since every resource would need its own unique name, which a user doesn't necessarily know.
A more straightforward solution would be to indicate the license for every record in the media.csv, which was my initial suggestion in an issue discussing this https://github.com/tdwg/camtrap-dp/issues/189, but in reality, all images within a package are very likely to have the same license.
Someone suggested to use the license array, which looks like an elegant approach, but wanted to check here if that solution make sense. 🙂
6 user1
Well, it does make sense, except that

Apparently the "scope" attribute for licenses is not yet in the specs. https://specs.frictionlessdata.io/data-package/#licenses Are you proposing we include it?
In some cases, there may be different groups of images with different licenses. Then grouping by "scope": "media" would not be enough.

7 @peterdesmet

I'm not sure it is general enough to suggest in the specs. Maybe. I currently see it more as a custom attribute to differentiate multiple licenses. I always found it odd that one can indicate multiple licenses for a package, but here it comes in useful.
Correct, I consider that the main downside, but for our use case likely sufficient.

8 @lwinfree
I like the license array approach, but I don't know of other use cases. I agree with you that it is better to include the license info for the images in the DP as opposed to leaving it the the server's responsibility. ("having to assess the license per image is a burden to the user" --> this is a real problem for research data, so I totally agree with you here)
9 @peterdesmet
Thanks, I think we will use that approach then, and add a property scope to the license. Although no software would currently be able to derive meaning from that, users reasonably might. And software would still be aware that two licenses are at play.

Good discussion, @peterdesmet!
If you're going to use the non-standard "scope" attribute I would suggest that document what it means, what are the allowed values and how does one determine to which resources they apply, etc.

@augusto-herrmann exactly! 👌

Fixed in https://github.com/tdwg/camtrap-dp/pull/193

This may solve the problem for camtrap-dp, but if you are going to make the scope attribute able to generalize to any data package, you realize that this is probably going to need to change, right? And that these changes might not be compatible with the current solution. I.e., specify which media types are selected by the scope when the "media" value is used.
I might even suggest using "linked_media", because the media is not even included in the data package, just linked there.

attribute able to generalize to any data package, you realize that this is probably going to need to change, right?

Yes, I might do a PR to the frictionless specs to support that.
Regarding linked_media: that is a good suggestion, might write it as linked media to be consistent with other vocabs we have.


HOTFIX: change value to be double [ES]

Values should be double, as we found out in: https://github.com/elastic/elasticsearch/issues/21885

This change is

@k8s-bot ok to test

@DirectXMan12 can we merge this?

LGTM :+1:


Evaluating cgmlst-dists as a faster alternative to distance.py

cgmlst-dists performs the same distance calculation as does distance.py. It is written in C and has better execution time.
execution time for cgmlst-dists:

execution time for distance.py

Next step is to compare the distance matrix to see if distance.py can be replaced.
by comparing the output from the clustering on these two matrices.

I did a validation of the pipeline with cgmlst-dists. The resulting score is comparable to the score when using distance.py.
Normalized mutual info score when using distance.py

score when using cgmlst-dists:

cgmlst-dists is a faster approach with comparable scoring results.


Fix global transform validity for Node2D and Control

Set global transform to invalid when changing transform
resolve #79453
Add unit-tests for the bug

@kleonc Thank you for pointing me in the right direction. I have included your improvements in the PR.

I have included the invalidation for transform-changing operations in Control.

@kleonc may I ask if your requested changes have been resolved by my updates?

@kleonc may I ask if your requested changes have been resolved by my updates?

Hmm, seems like it should now be properly invalidating the global transforms. :+1:
However, I'm not sure if these added invalidations don't affect transform notifications in some unwanted manner. Specifically, after brief look at the code, when in the tree CanvasItem::_notify_transform calls _notify_transform(this):
https://github.com/godotengine/godot/blob/16a93563bfd3b02ca0a8f6df2026f3a3217f5571/scene/main/canvas_item.h#L154-L162
which early returns in case global transform is invalid:
https://github.com/godotengine/godot/blob/16a93563bfd3b02ca0a8f6df2026f3a3217f5571/scene/main/canvas_item.cpp#L877-L886
Hence I wonder if adding _invalidate_global_transform(); before _notify_transform(); (like it's done in many of the changed methods) could have broken some notification propagation or something like that. :thinking: We'll need to ensure nothing is broken I guess (or maybe you've already did that?).

Thank you for taking the time to guide me through the maze of Transform-caching.
The case, that you have identified was indeed problematic.
With the latest updated I made sure that

the behavior while is_inside_tree() == true is not changed
while not inside tree, caching status traverses down the scene-tree

Thanks!

Cherry-picked for 4.1.2.


Unexpected union (T.any) behavior?

Input
→ View on sorbet.run
extend T::Sig

Number = T.type_alias(T.any(Integer, Float))

sig { params(a: Integer, b: Number).returns(Integer) }
def multiply(a, b)
  (a * b).round
end

Observed output
editor.rb:7: Expected Integer but found T.any(Integer, Float) for argument arg0 https://srb.help/7002
     7 |  (a * b).round
           ^^^^^
    https://github.com/sorbet/sorbet/tree/0c6bdf75780d2f5dd627c7054ce09c67a938304f/rbi/core/integer.rbi#L40: Method Integer#* has specified arg0 as Integer
    40 |        arg0: Integer,
                ^^^^
  Got T.any(Integer, Float) originating from:
    editor.rb:6:
     6 |def multiply(a, b)
                        ^
Errors: 1

Expected behavior
This is a simplified example, but variations on this theme all produce similar errors (for example, replace a: Integer with a: Number in the type signature). I would expect this type signature to work. Integer supports multiplication with both Integer and Float.

This is a known limitation of our current overload selection algorithm.
It's unlikely that we'll fix it soon, as the complexity of supporting it is tremendous.
The workaround is either (a * b.to_f).round or (a * b.to_i).round.
Note that we also consider the current behavior as beneficial, as otherwise figuring out what happens from user perspective with more complex overload resolution is quite hard.

As we don't currently intend to fix this limitation, closing to not pile up issues.


Localized strings not appearing when set to Simplified Chinese

Verify if simulator only.

Change language in Settings.app to Simplified Chinese
Launch AlphaWallet app
Activity tab

Dates are in Chinese but "Wallet" tab title is still in English. Our localization effort is somewhat patchy and incomplete so not all English strings are localized, but it seems like none of the localized ones are used.
Let's figure out why this is broken before fixing it. It might well be good to stay this way until we patch up the missing localization strings.

It appears that all the internationalised strings have to be called.
(lldb) po NSLocalizedString("walletTokens.tabbar.item.title", comment: "")
"Wallet"

(lldb) po Locale.current
▿ zh-Hans_US (current)
  - identifier : "zh-Hans_US"
  - kind : "current"

(lldb) po Locale.current.languageCode
▿ Optional<String>
  - some : "zh"

(lldb) po R.string.localizable.walletTokensTabbarItemTitle(preferredLanguages: ["zh"])
"Wallet"

(lldb) po R.string.localizable.walletTokensTabbarItemTitle(preferredLanguages: ["zh-Hans"])
"我的钱包"

(lldb) po R.string.localizable.walletTokensTabbarItemTitle(preferredLanguages: [])
"Wallet"

(lldb) po Locale.preferredLanguages
▿ 2 elements
  - 0 : "zh-Hans-US"
  - 1 : "en"

(lldb) po Bundle.main.preferredLocalizations
▿ 1 element
  - 0 : "zh-Hans"

Using regular expressions, I was able to convert all the R.string. localizable.xxx to R.string. localizable.xxx(preferredLanguages: nil)
Regular expression:
R\.string\.localizable.([a-zA-Z0-0]+)(\()(\))
Replaced by:
R.string.localizable.$1$2preferredLanguages: nil$3
There were some instances where I used nil when I first started on this project. Then I'll convert the nil to Bundle.main.preferredLocalizations

It appears that all the internationalised strings have to be called with the preferredLanguages parameter. I think ALL our localization will not appear.

@eviltofu Can you dig further? Go further back in our repo history, if it still builds. Say around the early in the year 2020. Unless it's changed recently, R never requires us to pass in the language to use.
In 257a5308c2617b0aaca1de92ff51311c531f886c (Oct 2021), R was upgraded, maybe that and the commit before that is a good place to start with.

Ok I created a new project, localised the strings files, switch to Simplified Chinese, and it works just like you said.
    override func viewDidLoad() {
        super.viewDidLoad()
        titleLabel.text = R.string.file.aTitle()
    }

English: "a.title"="Me";
Chinese (Simplified): "a.title"="我";
Japanese: "a.title"="私";

x`

It appears that all the internationalised strings have to be called with the preferredLanguages parameter. I think ALL our localization will not appear.

@eviltofu Can you dig further? Go further back in our repo history, if it still builds. Say around the early in the year 2020. Unless it's changed recently, R never requires us to pass in the language to use.
In 257a5308c2617b0aaca1de92ff51311c531f886c (Oct 2021), R was upgraded, maybe that and the commit before that is a good place to start with.

I am not able to build. Xcode is failing to compile several (6 instances) Pods.

Some suggestions:

try manually "bisect" it and see if you can find a commit where it works (and still builds for you)
strip down the project of most of the code, the extensions and reproduce?
look at the commit logs messages and see there's a deliberate change to languages/locale that unintentionally broke this. For example I see that in 304f5d1ec8b93c5df3ca5240b5c88df32e62b165, we hide the in-app language switcher. Could that PR have broken it?

BTW, if it doesn't build on the simulator, try build for the device.

The App Store version doesn't appear to display simplified Chinese.

I went back to (129c7b14866e5060930745385f6457fc91eefd54) 31/3/21 when the app doesn't compile anymore. All the versions I compiled never displayed Simplified Chinese.

Ok. Do what you can and buzz me if you want me to check too.

Ok. Do what you can and buzz me if you want me to check too.

The temporary fix is #3680. I'm puzzled because the new project file I created displays the Simplified Chinese text perfectly!


Use from() for lossless numerical type conversion

Resolves #66
Note about clippy
As suggested in the issue, I used cargo clippy to find instances of casting using as. Running clippy reports a ton of warnings and some errors, so I used the following command to allow clippy::all but warn on clippy::cast_lossless, and output to file:
cargo clippy -- -A clippy::all -W clippy::cast_lossless > /path/to/output.txt 2>&1

Unhandled cases
There were two cases reported by clippy which I did not handle. The first case is casting that involves macro invocation and the warning looks like the following:
warning: casting u8 to u32 may become silently lossy if types change
   --> src/macros.rs:220:41
    |
220 |                       $imp::$method(self, other as $promo)
    |  _________________________________________^
221 | |                 }
222 | |             }
223 | |
...   |
249 | |     (impl $imp:ident for $res:ty, $method:ident) => {
250 | |         promote_scalars!(impl $imp<u32> for $res, $method, u8, u16);
    | |______________________________________^ help: try: `u32::from(other)`
    |
   ::: src/bigint.rs:964:1
    |
964 |   promote_all_scalars!(impl Add for BigInt, add);
    |   ----------------------------------------------- in this macro invocation
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless

The second case was when clippy recommends i64::from(n) for example, but making the change causes a compilation error:
2351 |                 BigInt::from(i64::from(n))
     |                              ^^^^^^^^^ the trait `std::convert::From<isize>` is not implemented for `i64`

Undetected
I also noticed that there are some instances of casting using as that are not reported by clippy. I'm not sure if this is a bug in clippy, or if there's a reason clippy didn't report them. For now, I also ignored these undetected instances.
How the changes were made
For standard types, I simply followed clippy's suggestion, e.g. u32::from(c).
For internal types such as DoubleBigDigit, clippy would suggest to use u64::from(), but I used DoubleBigDigit::from() instead.
To avoid any potential changes in behavior, I kept all parenthesis I encountered. In the following example, it looks safe to remove them, but I kept them all for consistency:
# previously:
*acc += (b as DoubleBigDigit) * (c as DoubleBigDigit);

# replaced with:
*acc += (DoubleBigDigit::from(b)) * (DoubleBigDigit::from(c));

Should I remove the parenthesis when it's clearly safe, but keep them when I'm not sure? Or maybe I should remove all of them, and let the tests catch any potential issue?
Please advise if I should try to fix the undetected instances. Also, I didn't review casting with as in the comments/documentation. Should I look into the comments too?
If I make these additional changes, let me know if I should squash all changes into one commit.

Hi, thanks for doing this.
I think for the macro-incurred errors, we should just allow the lints. Since we support older compilers, this will need to use the old style like #[cfg_attr(feature = "cargo-clippy", allow(foo))], rather than the newer #[allow(clippy::foo)].
For the parentheses, let's remove the obvious cases like (DoubleBigDigit::from(x)). If there's some other operator in the expression where precedence might be a question, we can keep that.
For undetected cases -- do you have an example? I wonder if they're actually lossy or not...
I don't mind multiple commits in a PR if they're building on each other. It's only when commits go back and forth, like cleaning up after unintended changes, then I prefer squashing that stuff.

Noted on allowing the lints and that we should use the old style. I'll add a separate commit for this in this PR. I'll also address the parentheses soon after we decide what to do with the undetected cases.
Btw, the recent force-push in this PR is just to rebase my branch against the recent changes in master.
Undetected Examples
I just checked src/bigint.rs and I found that almost all of the conversions were undetected. For example, here's the code for negate_carry:
https://github.com/rust-num/num-bigint/blob/447abda7ba1ab04708368baede925c1a0f8b6d2c/src/bigint.rs#L221-L226
The as DoubleBigDigit was the only conversion detected by clippy in the entire src/bigint.rs. The line with as BigDigit right after it was not detected. There are 50 more undetected conversions in this file. Here's another example:
https://github.com/rust-num/num-bigint/blob/447abda7ba1ab04708368baede925c1a0f8b6d2c/src/bigint.rs#L875-L881
Should I handle these instances not detected by clippy?
rustfmt
Looks like rustfmt has been added to the CI. I suppose that's also another change I need to incorporate in this PR, correct? I can also add it as a separate commit in this PR so it's easy to track the changes.

Those "undetected" instances are not lossless conversions, so From won't work. The first *acc as BigDigit is a truncating conversion, and then the upper bits are shifted in acc for the next loop. In i32_abs_as_u32, this is a sign conversion which is also technically lossy, though safe in this context.
For rustfmt, yes I'll want that to pass. It looks like only a couple locations changed, so I don't mind either way whether it's a separate commit.

Thanks for taking the time explaining why these aren't actually lossless conversions. I've updated my changes, with the first commit updated to remove the unnecessary parentheses in the conversions. The last commit is to address the rustfmt error.
The second commit is to allow the cast_lossless lint. I initially used just #[cfg_attr(feature = "cargo-clippy", allow(cast_lossless))], but I get a warning:
warning: lint name `cast_lossless` is deprecated and may not have an effect in the future. Also `cfg_attr(cargo-clippy)` won't be necessary anymore
   --> src/macros.rs:218:60
    |
218 |                 #[cfg_attr(feature = "cargo-clippy", allow(cast_lossless))]
    |                                                            ^^^^^^^^^^^^^ help: change it to: `clippy::cast_lossless`
    |
   ::: src/bigint.rs:976:1
    |
976 | promote_all_scalars!(impl Add for BigInt, add);
    | ----------------------------------------------- in this macro invocation
    |
    = note: #[warn(renamed_and_removed_lints)] on by default

The recommendation to change it to #[cfg_attr(feature = "cargo-clippy", allow(clippy::cast_lossless))] fixes the warning but causes a compilation error on Rust 1.15.0. So instead, I'm using the following which has been added to 3 places in src/macros.rs:
#[cfg_attr(feature = "cargo-clippy", allow(renamed_and_removed_lints))]
#[cfg_attr(feature = "cargo-clippy", allow(cast_lossless))]

Thanks, this looks good.
bors r+


SCRIPT5007: Unable to set property 'innerHTML' @ IE 9 & 10

I received an error in IE 9 and 10. My code works fine in IE 11.
SCRIPT5007: Unable to set property 'innerHTML' of undefined or null reference
File: jspdf.js, Line: 177, Column: 1912

Thank you ZyshchykMaksim :)


Consider getting superenv from /etc/profile and /etc/environment

Verification

[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature
According to https://docs.brew.sh/Formula-Cookbook#superenv-notes, when building a Formula will

removing /usr/local/bin and all user PATHs that are not essential for the build

However, from the source code I found that it's actually building a new PATH, with nothing from the original PATH, instead of removing unneeded parts from the original PATH.
The building process in the source code is basically appending four hard-coded paths, /usr/bin, /bin, /usr/sbin and /sbin, to a list of brew-specific paths.

I think the intention of adding the four paths here is to allow access to some binaries from the system. In the document, it says:

user PATHs are often full of stuff that breaks builds

So you want to include neither user-writable paths nor PATHs set by users. On the other hand, the system-wide PATHs set by admins can still be respected.
Unfortunately, the current approach is not perfect for accessing system-wide binaries. Admins can append to PATH by editing /etc/profile or /etc/environment, and this case can be common.

For example, for CentOS, it's common for admins to install Red Hat Developer Toolset, which is a set of more up-to-date toolchain from Red Hat. The toolset will be located at /opt/rh/devtoolset-<version>/ and it won't be symlinked to paths like /usr/bin. With devtoolset installed, some admins may remove the gcc package so the only compiler in the system will be from devtoolsets and there will be no compiler under /usr/bin.
Admins usually then add a source /opt/rh/devtoolset-<version>/enable line to /etc/profile. This will modify PATH so the gcc will be /opt/rh/devtoolset-<version>/root/usr/bin/gcc. By doing this, they hope that the system will have a compiler available, and the compiler is from the devtoolset.
But it's not the case for Homebrew. Since it hard-codes the four paths, it won't be able to locate the correct compiler, or even locate any compiler at all. I think for Brew on Linux, it should get its PATH of superenv from /etc/profile and /etc/environment.
Admins are supposed to know what they are doing, and for the previous example, doing so is tested and supported by Red Hat. Getting PATH from /etc/profile and /etc/environment is not only a more idiomatic and correct approach but also is not likely to break the build. If it breaks the build, it can be the admin's responsibility.
I can write code for this feature if you think this proposal is OK.
What is the motivation for the feature?
This feature allows Homebrew to work more robustly and adapt to differently-configured systems. Like the CentOS example mentioned above.
How will the feature be relevant to at least 90% of Homebrew users?
I think since most of the users are using Homebrew on Macs, not Linux, this may not be beneficial for most Mac users.
However, I believe that this may help lots of users who trying to use Homebrew on CentOS.
What alternatives to the feature have been considered?
I don't really know what to write here, maybe keep the status quo?

Admins are supposed to know what they are doing
If it breaks the build, it can be the admin's responsibility.

Sorry, this is not in keeping with our ideology or experience running Homebrew.
If we do something like this (and I'd want a bunch of @Homebrew/maintainers to approve) it would need to be:

opt-in only using an environment variable
flagged by brew doctor if there's any issues
probably CentOS/Red Hat only

Since this would only apply to gcc and curl (everything else is from Homebrew on Linux) I'd rather just check if a redhat software collection is available in addition to the usual /usr/bin/gcc check.

@SMillerDev Yeh, this is a good idea 👍🏻

I'm sorry that this proposal does not align with Homebrew's ideology.
I still appreciate a workaround of only checking the Red Hat Developer Toolset.
Do you have any ideas on how this should be implemented? If you want, I can make a PR for this.

Do you have any ideas on how this should be implemented? If you want, I can make a PR for this.

Yes, I think locate in https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/linux/development_tools.rb would be the best place to add this.
Feel free to open a PR even before it's working/done and we can help.
Closing issue just because the answer to original question is "no" and we'll talk more on PR (which we're excited about).
Thanks ❤!


HelmRelease does redundant validation on chart name

Hello,
I'm setting up a workflow with the following components:

Private Dockerhub OCI repository where my Helm Charts are stored
EKS Cluster
Kustomizations stored in a Private Github repo
Flux deploying my customizations to my EKS Cluster

I've setup the following HelmRepository:
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: my-dockerhub-oci
  namespace: flux-system
spec:
  type: "oci"
  interval: 1m
  url: oci://registry-1.docker.io/my-org
  secretRef:
    name: dockerhub-credentials

and the following HelmRelease:
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: my-application
  namespace: flux-system
spec:
  interval: 1m
  chart:
    spec:
      chart: internal.my-chart
      version: "2024.3.0"
      sourceRef:
        kind: HelmRepository
        name: my-dockerhub-oci
        namespace: flux-system
      interval: 1m
  values:
    key: value

The issue I'm running into is that the internal.my-chart format isn't supported, specifically the . and I'm receiving the following error on my HelmRelease object:
HelmChart ''flux-system/flux-system-my-application'' is not ready: invalid chart reference: invalid chart name ''internal.my-chart'': a valid name must be lower case letters and numbers and MAY be separated with dashes (-)

And when I remove the internal. it works without any issues (but obviously targeting the wrong chart).
Now the reason that I'm submitting this issues is that my chart has already been uploaded to our Dockerhub OCI repo and helm pull works, making the validation that's going on here redundant; if there were an error with the name the OCI repo would've already errored before it even gets pushed in.
I was wondering what the reason for this drift from typical helm functionality and if there really isn't, if it's possible to remove the redundant validation. I'm happy to make those contributions myself 😃
Cheers,
Varun

Nevermind. As I was looking into where the validation is occuring, it seems like it's actually in the fluxcd/source-controller repository. I'll open my issue there.


Fixed incorrectly marking "class" in "A::class" as a keyword.

Hi!
There's a special class constant "::class" in PHP (https://www.php.net/manual/en/language.oop5.constants.php). If you have an expression like "$a = SomeClass::class;", the "class" is currently wrongly rendered as a keyword. This pull request fixes the behavior so that the "::class" constant would be rendered as a generic Name token.
I spent the last 5 hours figuring out the best way to tackle this problem and this solution is the best thing I can think of, given my very limited knowledge of the lezer philosophy. If you think that there's a better way to fix this, please just give me a nudge in that direction and I'll update the code.

Hi, thanks for the pull request. This is mostly the correct approach. But for consistency, and in order to support upper-case CLASS tokens, could you align the definition of the class token with the one for static, which has a similar issue in PHP? I.e.
class { @extend[@name=class]<Name, "class" | "CLASS"> }

and then use class wherever you now have ckw<"class">.

Thanks! I didn't notice the "static"-related code before, I wish I saw it earlier. Anyway, I have updated the code.

Thanks!

I'm glad I was able to help. Thanks for your hard work!


PLUGIN-654:Pub/Sub source fails when subscription is a macro.

Pub/Sub source fails when subscription is a macro.
JIRA Ticket: https://cdap.atlassian.net/browse/PLUGIN-654

/gcbrun


Detect recommended roll combos and mods

Add this new information from light.gg, (maybe to the UI modal )

initial implementation on 0.7 released


Accessing owner email from WorkflowStatusListner

Is there a way to access the owner email field from WorkflowStatusListner which has a parameter for common.run.workflow?

Yes. The methods in WorkflowStatusListener receive Workflow as the argument. Workflow.getWorkflowDef().getOwnerEmail() is the way to access owner email.


'*' in Rdata causes the return code to be NOERROR instead of NX

Hi again,
Short description
When the target of a CNAME that belongs to the same zone does not exist, it is returned with the NXDOMAIN return code. NSD handles this very well except when there is a * label in the Rdata. It returns with NOERROR, whereas Bind, Knot, and PowerDNS return with NXDOMAIN  (Sorry for nitpicking a minor corner case).
Steps to reproduce
Consider the following sample zone file:

campus.edu.
500  SOA
ns1.campus.edu. root.campus.edu. 3 86400 7200 604800 300

campus.edu.
500  NS
ns1.outside.edu.

foo.campus.edu.
500 CNAME
www.*.campus.edu.

For the query <foo.campus.edu., A> the answer from the NSD server is:
          "rcode NOERROR",
          "flags QR AA",
          ";QUESTION",
          "foo.campus.edu. IN A",
          ";ANSWER",
          "foo.campus.edu. 500 IN CNAME www.*.campus.edu.",
          ";AUTHORITY",
          ";ADDITIONAL"

Expected/Actual behavior
The answer section would be the same for the above query, but the RCODE should be NXDOMAIN.
Thank you for your quick replies.

Fixed it.  It has to do with the internal data structure for storing domains in the memory of NSD, there a domain struct is created for the right hand of the CNAME, and it is set to be non-existing.  The is_existing was not checked for the wildcard expansion, and this is fixed by the commit.  So this fix is only for CNAMEs to a wildcard right hand, where that wildcard right hand does not exist in the zone.  Thanks for the report!

Fixed it.  It has to do with the internal data structure for storing domains in the memory of NSD, there a domain struct is created for the right hand of the CNAME, and it is set to be non-existing.  The is_existing was not checked for the wildcard expansion, and this is fixed by the commit.  So this fix is only for CNAMEs to a wildcard right hand, where that wildcard right hand does not exist in the zone.  Thanks for the report!


CEdit::GetHighlight is only defined for UNICODE

I tried to use CEdit::GetHighlight in a non-UNICODE project and kept getting
"error C2039: 'GetHighlight': is not a member of 'CEdit'".
I looked in afxwin.h and found both SetHighlight and GetHighlight are inside an "#if defined(UNICODE)" block.
Aside from the fact that I can't understand why this should be the case, the documentation should at least mention this fact. Thank you.

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

ID: f86b1a15-2ebf-6f85-4dad-06687c22be5c
Version Independent ID: 4794949e-d6a0-4d30-747a-2fc47199aad4
Content: CEdit Class
Content Source: docs/mfc/reference/cedit-class.md
Product: visual-cpp
GitHub Login: @mikeblome
Microsoft Alias: mblome

Thanks @jmporter34 . Investigating.

Possibly a product bug. Waiting on response from developer team.

@jmporter34  I have updated the doc to describe the actual behavior. Should be visible on 09-13. Since this is a product issue, possibly a bug, I encourage you to post it to the C++ forum on DeveloperCommunity: https://developercommunity.visualstudio.com/spaces/62/index.html


Dangling volumes after restarting systemd unit

If I have a container running with a use_name, and with volume; the systemd service to restart the container doesn't remove the volume.
In case if the container mounts a volume, I think adding -v flag in following line will delete the volumes as part of service restart.
https://github.com/garethr/garethr-docker/blob/master/templates/etc/systemd/system/docker-run.erb#L16
The only way I could tackle this now, is to find and remove dangling volumes periodically with something like: https://github.com/chadoe/docker-cleanup-volumes

@nikhilo thanks, you're correct. This should be fixed in master since https://github.com/garethr/garethr-docker/commit/c361a3787bbe558ace18f78980c045760889a5d0 and should be in the next released version.


How to achieve substitution in tests with mocks if interface references cannot be injected?

Like so many others before, I'd like to leverage the benefits of DI by using the same references on a struct I'm testing for manually set mock/stub structs in addition to having Inject populate them at normal runtime.
However, in Golang, there's no Liskov-style substitution unless you're using interfaces.  The Inject doc mentions that "supports injection for interface types as long as they’re unambiguous", but I'm not sure what is meant there or if it's even relevant to this problem.
I'd rather avoid having to manually create all such substitutable structs, because that means I'd have to create all such things at the top level, partially negating the value of using Inject (having a highly-polluted main()).
Perhaps an extra parameter to the inject tag to indicate which object should be constructed to satisfy the interface requirement by default?

Construction of non-concrete objects is not something inject supports. This has worked well for us, and our main()s are not sufficiently large yet to be of concern. I'm not entirely sure how an extra parameter to the inject tag would work either since it's essentially impossible to go from a string to a concrete implementation/constructor without also having another mapping table somewhere, at which point the current approach of main() having a list of concrete implementations seems comparable anyways.

Ah well, I figured it was worth asking!  Thank you :)


Add content to "All exports" drawer

Add content to "All exports" drawer

Added validation for export name
All inputs in export dialog should be required

https://issues.redhat.com/browse/COST-2339
Name validation

Codecov Report

Merging #2348 (c54ff5a) into master (e50ef0c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2348   +/-   ##
=======================================
  Coverage   68.85%   68.85%
=======================================
  Files         412      412
  Lines        7858     7858
  Branches     1736     1736
=======================================
  Hits         5411     5411
  Misses       2443     2443
  Partials        4        4

Impacted Files
Coverage Δ

src/locales/messages.ts
100.00% <ø> (ø)

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 e50ef0c...c54ff5a. Read the comment docs.