pgremapper performance limit?

Hi, I find the cluster, where cancel-backfill is not super fast as usual (took minutes)
1423 osds | 37920 pgs - not super big. But have 38 rack buckets with 67 hosts
What I see is that pgremapper use only ~ 3 cores of 24 cores CPU, and that's suspicious (low) for golang. May be this some limit in code or on compiler? Or scalability milestone for an application?

Were any PGs unclean at the time? pgremapper will issue quite a few extra commands in that case, and would be limited in performance by command round-tripping. Increasing --concurrency can help with this.
If you run with --verbose it will spit out all of the Ceph commands being run; I'd be interested to know whether it's issuing commands the whole time or if it was sitting there thinking.

If you run with --verbose it will spit out all of the Ceph commands being run; I'd be interested to know whether it's issuing commands the whole time or if it was sitting there thinking.

It was thinking. Everything I said concerns not what the pgremapper will do actually, but the moment when the pgremapper plan what to do, e.g. dry-run: cancel-backfill --verbose (without --yes)

Hmm, OK. The OSD and PG counts are consistent with some systems we've tested on in the past, and I don't think the rack/host count should affect cancel-backfill. Reviewing the code, I see that we do run the PG calculations in parallel, controlled by the concurrency setting, but depending on how much of the computation time is spent in mappingState.tryRemap(), the lock in that function might be a bottleneck...

the lock in that function might be a bottleneck...

In perf top I see this

This guy?

 Maybe there are things we can do to be more memory-allocation-efficient here.

Maybe there are things we can do to be more memory-allocation-efficient here

We would be happy to test the patch if it is possible to do something in this place. According to my observations, the pgremapper can consume 7-8 cores in another places. In this cluster it is limited to 2-3 cores

Apologies - this is still on our list but it hasn't been able to bubble to the top yet


The icon of MongoDB/DocumentDB Account is incorrect

Storage Explorer Version: 1.5.0
Platform/OS Version: Windows 10/ Linux Ubuntu 16.04/ MacOS High Sierra
Architecture: ia32
Build Number:20180905.3
Commit: 66ac14b9
Regression From: Previous release 1.4.1(20180822.1)
Steps to Reproduce:

Apply one subscription -> Drill down Cosmos DB Accounts.
Check the icon of MongoDB/DocumentDB Account.

Expected Experience:
The icon of MongoDB/DocumentDB Account is correct.
Actual Experience:
1.The icon of MongoDB/DocumentDB Account is incorrect.
2. The icon of database is also incorrect under all Cosmos DB Accounts.

By design. The icons better reflect what the portal has. Unless @djlan disagrees, I'm going to close this.


Receive updates for other Microsoft products?

Hi, just wondering if there is a tweak for controlling whether or not the machine will "Receive updates for other Microsoft products when you update Windows"? This setting is visible under: Settings > Windows Update > Advanced Options.
Excellent tool by the way - has saved me hours of pain!

Try this
If (!(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d")) {
	New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d" -Force | Out-Null
}
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d" -Name "RegisterWithAU" -Type DWord -Value 1

I haven't tested it extensively, though.
There is also GPO setting AllowMUUpdateService value under HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU, but it seems that the registry modification alone isn't enough. Moreover this GPO is bundled with other updates settings and affects more than just the downloads for other MS products, so the snippet above is probably a safer bet. I'll consider adding it after I do some more tests.

I tried both the keys you provided as well as the GPO setting, but couldn't generate any changes.
Out of interest, I used ProcMon to watch the registry while I changed the settings manually in the GUI and I did notice that the keys in your suggestion are only used temporarily. If you look at the screenshot, you can see that they are subsequently copied and the original key (with the "Pending" in the path) is deleted.
I modified your code to exclude the Pending from the path, but didn't have any success with that either.

I reverted to your original suggestion and I can see that it registry change stays in the Pending state even after logging in/out. I'm not sure what the trigger is, but when I  watch the registry, it never seems to copy the key to the other location.
I also tried to imitate all the changes that I see in the registry with the following code, but it doesn't seem to work. I can't see any registry differences between what I end up with when I run this and what I get when I make the change via the GUI, but it doesn't work. Maybe there's config stored outside the registry?
If (!(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d")) {
	New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d" -Force | Out-Null
}
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d" -Name "ClientApplicationID" -Type String -Value "UpdateOrchestrator"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971f918-a847-4430-9279-4a52d1efe18d" -Name "RegisterWithAU" -Type DWord -Value 1

If (!(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services")) {
	New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services" -Force | Out-Null
}
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services" -Name "DefaultService" -Type String -Value "7971f918-a847-4430-9279-4a52d1efe18d"

If (!(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\7971F918-A847-4430-9279-4A52D1EFE18D")) {
	New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\7971F918-A847-4430-9279-4A52D1EFE18D" -Force | Out-Null
}
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\7971F918-A847-4430-9279-4A52D1EFE18D" -Name "RegisteredWithAU" -Type DWord -Value 1

Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Services\Pending\7971F918-A847-4430-9279-4A52D1EFE18D" -Force | Out-Null

@abrookewood
https://github.com/farag2/Setup-Windows-10/blob/master/Win 10.ps1#L488

For anyone looking for the solution, @farag2 has provided the following, which works perfectly:
(New-Object -ComObject Microsoft.Update.ServiceManager).AddService2("7971f918-a847-4430-9279-4a52d1efe18d", 7, "")


add more keycodes

@glennsl suggested adding key codes to Key.Keycode in revery, but seeing that that module simply includes the keycodes from here and there is a comment saying that more key codes should be added if needed I though I add all letters here.

Could you do a release @bryphe?

Sure thing @glennsl @despairblue - released as<EMAIL_ADDRESS>Thanks for adding these, @despairblue !


Custom whereIn of custom query builder not invoked with withGraphFetched

This is a follow up of issue #2096. I have created a custom query builder as suggested in the comments. It looks like this:
class CustomWhereInQueryBuilder<M extends Model, R = M[]> extends QueryBuilder<M, R> {
    ArrayQueryBuilderType!: CustomWhereInQueryBuilder<M, M[]>;
    SingleQueryBuilderType!: CustomWhereInQueryBuilder<M, M>;
    NumberQueryBuilderType!: CustomWhereInQueryBuilder<M, number>;
    PageQueryBuilderType!: CustomWhereInQueryBuilder<M, Page<M>>;

    whereIn: WhereInMethod<this> = (...args) => {
        console.log('whereIn', args);
        return super.whereIn.apply(this, args);
    };

    where: WhereMethod<this> = (...args) => {
        console.log('where', args);
        return super.where.apply(this, args);
    }
}

This is how I set the custom query builder and how my query looks like:
export class UserModel extends Model {
    ...
    static get QueryBuilder() {
        return CustomWhereInQueryBuilder;
    }
}

await UserModel.query().withGraphFetched('[inventory]').where(true);

which produces the following output:
where [ true ]
[
  UserModel {
    id: 1,
    name: 'name',
    inventory: UserInventoryModel { user_id: 1, coins: 300 }
  }
]

As you can see it did not enter the custom whereIn, but it did execute the custom where.
What am I doing wrong? I can fully provide both model files if necessary.

The inventories are not of class UserModel. The inventories are fetched using the InventoryModel. You need to install the custom query builder for that model too.

The inventories are not of class UserModel. The inventories are fetched using the InventoryModel. You need to install the custom query builder for that model too.

@koskimas I had already tried that with no success. These are the models:
// user-inventory-model.ts
export class UserInventoryModel extends Model {
    static tableName = 'user_inventory';
    static idColumn = 'user_id';

    static get QueryBuilder() {
        return CustomWhereInQueryBuilder;
    }

    static tableMetadata() {
        return { columns: ['user_id', 'coins'] };
    }

    static relationMappings = {
        user: {
            relation: Model.BelongsToOneRelation,
            modelClass: require('./user-model').UserModel,
            join: {
                from: 'user_inventory.user_id',
                to: 'user.id'
            }
        }
    };

    user_id!: number;
    coins!: number;
}

// user-model.ts
export class UserModel extends Model {
    static tableName = 'user';
    static idColumn = 'id';

    static get QueryBuilder() {
        return CustomWhereInQueryBuilder;
    }

    static tableMetadata() {
        return { columns: ['id'] };
    }

    static relationMappings = {
        inventory: {
            relation: Model.HasOneRelation,
            modelClass: require('./user-inventory-model').UserInventoryModel,
            join: {
                from: 'user.id',
                to: 'user_inventory.user_id'
            }
        }
    };

    id!: number;
    name!: string;
}

Produces the same output. Is this incorrect?

Don't know what to tell you. That' seems correct and objetion has a bunch of tests that prove it works. You are also doing something else wrong that is not in either of these files.

@koskimas please take a look at my code test.zip.
I'm compiling with tsc -t es6 *.ts --downLevelIteration --module commonjs. In order to reproduce the situation a postgresql database is needed with data. There's a test.sql for that and then I created some records with INSERT INTO "user" (name) VALUES ('name'); and INSERT INTO "user_inventory" (user_id, coins) VALUES (1, 300);
Can you see something wrong in the files? I started using the BaseModel that is suggested in Objection.js documentation, but still the custom whereIn is not invoked.

Sure, if you bake me a cake and do my laundry for a week.

Sure, if you bake me a cake and do my laundry for a week.

Instead, I can make a unit test that fails this use case just to show how good objection tests are. I'll even open a pull request for objection. Take it or leave it.

If you can do that, I'll happily fix the bug. But I'm guessing you are having hard time making that happen.

Actually, there is no bug. You are overriding the wrong method. whereInComposite is called internally by withGraphFetched and not whereIn.

Actually, there is no bug. You are overriding the wrong method. whereInComposite is called internally by withGraphFetched and not whereIn.

That seems to be the case, yes.

withGraphFetched (and I think also the eager method in the old objection) uses the objection query builder's whereIn method. You can override the query builder's whereIn method with your own implementation. Ultimately objection calls knex's whereIn method that does the actual query building, but you could call where(raw('YOUR SQL')) in your custom implementation.

However, this comment in the other issue clearly mentions whereIn and not whereInComposite. There is no mention of whereInComposite in that issue and even the custom query builder suggested in the comments doesn't override whereInComposite.
Thanks for everything.


How to invoke native-image with --module argument via helidon-maven-plugin?

For Helidon Maven plugin:
https://github.com/oracle/helidon-build-tools/tree/master/maven-plugins/helidon-maven-plugin
we have the goal native-image, which till recent was fine to use as input some jar from target folder.
But what if we want to utilize Java9+ modules and supply --module parameter instead of -jar? Looking at current Plugin's Mojo code - seems not yet covered:
https://github.com/oracle/helidon-build-tools/blob/master/maven-plugins/helidon-maven-plugin/src/main/java/io/helidon/build/maven/GraalNativeMojo.java
but possible if doing native-image binary invocation directly:
https://www.graalvm.org/22.1/reference-manual/native-image/Options/
and this part from it:

native-image [options] --module <module>[/<mainclass>] [options] to build a native executable for a module. --module is equivalent to -m.

Any thoughts? At the moment in use helidon-maven-plugin v2.3.4.

Did you try using additionalArgs ?

I did, but that led to incorrect execution command like such:
Executing command: [/opt/graalvm-ee-java17-22.2.0/bin/native-image ... , --module=org.example.myfeature/org.example.MyFeature, -jar, /dev/target/service.jar, ...]

and such mix itself is incorrect from native-image invocation standpoint.

@romain-grecourt - if this issue could be prioritised - it will help to use both approaches for modularized and non-modularized native images building via same plugin.

Just to clarify - here we need to have 2 options now to be supported:
--module-path and --module for Java modularized jars to be used.

Do you have any update here? Maybe some Snapshot build I could try and report back?

If this could be somehow prioritized - it will help. Thank you for your support.

@romain-grecourt - with this closed - I cannot yet reach needed goal, i.e. have ability to specify arbitrary module path in a way like such:
          <configuration>
            <!-- Try here just for internal case first -->
            <execMode>module</execMode>
            <module>mymodule/mypackage.Main</module>
            <modulePath>myDir</modulePath>
          </configuration>

Could we re-open this and add that? See my clarified request 26 days ago here above.

To clarify my previous comment:
I.e. at the end I need this:
          <configuration>
            <!-- Try here just for internal case first -->
            <execMode>module</execMode>
            <module>mymodule/mypackage.Main</module>
            <modulePath>target/service.jar:target/libs</modulePath>
          </configuration>

to be passed like this to native-image generation:
--module-path target/service.jar:target/libs

and override project dependencies logic, which is currently introduced for module case.

@andrejusc You could have made that comment before we merged the pull requests...
@tvallin I can think of a few updates:

module can be derived automatically, and the configuration can be used as an override, similar to jarFile
module should probably imply mainClass (IIRC the last part of the command should be module/mainClass)
add a new execution mode none that requires using additionalArgs ; the ordering with -H:Name may be an issue though

@romain-grecourt - I was awaiting some movement in this issue as it was stuck for some time and had a chance to build locally only today once PR was merged. I was assuming that need to have arbitrary module-path setting capability was obvious and that using instead project's dependencies not always could work within Maven multi-module projects and different phases of Maven execution.
Hoping that we could improve this further without another long wait time. Thank you for your support.

You don't have to wait for a PR to be merged in order to pull the changes.

FYI there is an official Maven plugin GraalVM Native Image: https://graalvm.github.io/native-build-tools/latest/maven-plugin.html ; You have the option of using the official plugin or use the exec-plugin and invoke native-image directly.

There is no direct equivalent to java -jar when using modules. When using java -jar the reference to target/libs is done in the MANIFEST.MF class-path entry, not in the plugin's defaults. Having the defaults for the new module execMode use -m target/libs would hard-code the reference to target/libs. This is not desired.
We implemented the default by following the same approach as the  official maven plugins (e.g. maven-javadoc-plugin).
We will support your use-case through configuration:

either by specifying execMode=none and supplying required arguments with additionalArgs
or by using a wildcard module exclusions and additional module-path entries

--
What specific problems are you having that are related to multi-module setup and/or Maven life-cycle ?

@romain-grecourt - my few comments to above:

You don't have to wait for a PR to be merged in order to pull the changes.

In normal Dev process I'm treating not merged PR as work in progress, which may or may not require further changes/corrections/etc. I'm also doing my best trying to evaluate 3+ different Open source projects changes together and so merged PRs in that case make my life easier. And as you folks have tons of other everyday activities.

FYI there is an official Maven plugin GraalVM Native Image: https://graalvm.github.io/native-build-tools/latest/maven-plugin.html ; You have the option of using the official plugin or using the exec-plugin and invoke native-image directly.

I'm treating that Helidon as a project is Native image friendly thing and such doc in it's code base makes me think so, where it explicitly mentions presence/usage of helidon-maven-plugin: https://github.com/oracle/helidon/blob/3.0.0/docs/includes/guides/maven-build.adoc#the-helidon-maven-plugin
You're right saying that other ways are possible to achieve native image generation, but then Helidon project's documentation should remove references to helidon-maven-plugin usage itself. And for my use case it will complicate things of gradual progression with what is already defined in related Maven pom files and try to change that to something else just because helidon-maven-plugin is having limitations. I prefer we work together on those limitations and eliminate them instead. In a hope that such could be of use for wider Dev community to utilize.

There is no direct equivalent to java -jar when using modules.

True, but I'm not asking here about equivalent. I'm asking simply about some Mojo setting which pass what is in it into command line and into --module-path option of it. And I'm as consumer will be in full position to specify what is inside that setting.

Having the defaults for the new module execMode use -m target/libs

In this case my target/libs sting was one of many examples, it not supposed to be hardcoded. Generic syntax of it would be folder1_jar:folder2:folder3, where folder1_jar could be target/service.jar, folder2 could be target/libs and so on. Nothing default in that case, but configurable via my proposed <modulePath> setting of plugin configuration and in that case switching off currently implemented dependencies calculation.

What specific problems are you having that are related to multi-module setup and/or Maven life-cycle ?

As you know - preparation of some JAR (in our case service.jar) happens usually within Maven package phase. Native image generation could also happen within same phase if related Maven native-image profile is active/effective. But in our case part of package phase does collection of needed dependencies into target/libs folder (and few more adjustments) and that is then fully ready for native image generation step to take. Those adjustments right now done to make sure none of dependencies are conflicting by any means from Java module angle - there are several such cases when they are.

In normal Dev process I'm treating not merged PR as work in progress, which may or may not require further changes/corrections/etc. I'm also doing my best trying to evaluate 3+ different Open source projects changes together and so merged PRs in that case make my life easier. And as you folks have tons of other everyday activities.

A pull request is where we review the code. If you comment on a pull request asking about merging, that means you agree with the changes. Our everyday activities are irrelevant to this.

Helidon project's documentation should remove references to helidon-maven-plugin usage itself.

GraalVM Native Image 22 is not yet officially supported by Helidon, prior versions did not support --module. There is currently no reason to remove the usage of helidon-maven-plugin:native-image.
Note that this doesn't mean that won't switch to the official plugin in future versions of Helidon.

Nothing default in that case, but configurable via my proposed <modulePath> setting of plugin configuration and in that case switching off currently implemented dependencies calculation.

You have a custom use-case, we do not want to support it as the default because it requires hard-coding a convention in the plugin. Like you said this will be done with additional configuration.
The configuration will be a bit different than what you've shared, though it should enable your use-case.

I was assuming that need to have arbitrary module-path setting capability was obvious and that using instead project's dependencies not always could work within Maven multi-module projects and different phases of Maven execution.

What specific problems are you having that are related to multi-module setup and/or Maven life-cycle ?

As you know - preparation of some JAR (in our case service.jar) happens usually within Maven package phase. Native image generation could also happen within same phase if related Maven native-image profile is active/effective. But in our case part of package phase does collection of needed dependencies into target/libs folder (and few more adjustments) and that is then fully ready for native image generation step to take. Those adjustments right now done to make sure none of dependencies are conflicting by any means from Java module angle - there are several such cases when they are.

The life-cycle that you describe is the one that is configured in Helidon applications (via parent pom). This is valid in a multi-module Maven project as well.
What are the adjustments that you mentioned ?
FYI the approach of using a mix of class-path / module-path computed from the project dependencies is used by official plugins such as maven-compiler-plugin and maven-javadoc-plugin. If you are currently having to work-around specific issues related to Java modules they may also surface with these plugins. E.g. try javadoc:aggregate

TL;DR ;)

You have a custom use-case, we do not want to support it as the default because it requires hard-coding a convention in the plugin.

I don't see how my proposal of extra Mojo/configuration property <modulePath> leads to any hard-coding beside this config property name itself needs to be in code, which is usual thing for Mojos to be extended with. It's optional by nature for this use case. If I specify it - use it when invoking native-image. If not - use whatever logic you've implemented already.

What are the adjustments that you mentioned ?

As you may know Helidon SE 2.5.x already (and soon Helidon MP 3.x) is based on jakarta.* namespace now versus javax.* namespace used by some libraries/jars before. If Maven via dependencies brings both namespaces in form of jars - that will potentially work for compilation purposes, but will fail for Java modules runtime bootstrap with so called Split package problem. So part of adjustment is to make sure only jakarta.* namespace related jars are in final POM dependencies and then inside target/libs folder (name of folder here arbitrary, could be anything) I have for my case.
Other adjustment is modification of one of jars, which has "-native-" part in name as such is not valid from Java module angle and so I'm changing that on the fly by adding Automatic-Module-Name to it's Manifest. So then it's good Java modules citizen and both java/native-image are happy having it inside my target/libs area.

FYI the approach of using a mix of class-path / module-path computed from the project dependencies is used by official plugins such as maven-compiler-plugin and maven-javadoc-plugin.

I simply want to be in position to override that if/when needed like previously we did with jarFile and finalName Mojo settings use cases.

We do not want to support it as the default because it requires hard-coding a convention in the plugin.

I don't see how my proposal of extra Mojo/configuration property <modulePath> leads to any hard-coding beside this config property name itself needs to be in code, which is usual thing for Mojos to be extended with.

You did not understand my statement. I'm talking about the default behavior, out of the box ; to justify why we implemented the default the way we did.
The very next sentence:

Like you said this will be done with additional configuration.

What are the adjustments that you mentioned ?

As you may know Helidon SE 2.5.x already (and soon Helidon MP 3.x) is based on jakarta.* namespace now versus javax.* namespace used by some libraries/jars before. So part of adjustment is to make sure only jakarta.* namespace related jars are in final POM dependencies and then inside target/libs folder (name of folder here arbitrary, could be anything) I have for my case.

Helidon does not mix javax.* and jakarta.* namespaces, 2.x supports javax.* 3.x supports jakarta.* ; the provided dependency management takes care of all the exclusions in order to provide a clean dependency tree (see helidon-dependencies).
If you are not using helidon-dependencies or an application parent pom, you have to do these exclusions yourself which can be tricky.
Assuming you have a clean dependency graph, I don't think this has any impact on your native-image build.

Other adjustment is modification of one of jars, which has "-native-" part in name as such is not valid from Java module angle and so I'm changing that on the fly by adding Automatic-Module-Name to it's Manifest. So then it's good Java modules citizen and both java/native-image are happy having it inside my target/libs area.

How are you modifying the jar name ? I'm assuming it's a dependency since you mention having it inside target/libs.

Helidon does not mix javax.* and jakarta.* namespaces

Correct, but other projects/dependencies are not yet there. You could read more here about challenges: https://helidon.io/docs/v3/#/se/integrations/oci#oci-compatibility

Assuming you have a clean dependency graph, I don't think this has any impact on your native-image build.

What I could guarantee (and that is enforced via our Maven package phase logic) is that dependencies collected into target/libs folder are passing such command:
java -p target/libs --validate-modules

which I cannot fully guarantee for project's Maven dependencies. Ideally it should be as well, but it's harder to prove without collecting them all into 1 single folder and using above command. Maven dependency plugin could help generate long line of involved dependencies, but I'm finding it's hard to use comparing to just listing/using 1 single folder.

How are you modifying the jar name ?

Not jar name. MANIFEST.MF inside that jar via Maven jar plugin. This will be not needed with Helidon 3.x, but currently we're using Helidon 2.5.x. For more background - see this: https://github.com/oracle/helidon/issues/4425

I'm assuming it's a dependency since you mention having it inside target/libs

Yes, in some cases we have helidon-graal-native-image-extension-2.5.X.jar jar/dependency presence there, which is invalid right now from Java modules angle usage due to presence of Java key word "native" in it, cause it's automatic module right now. In Helidon 3.x it will be named odule, so problem will be gone.
More background on Java reserved keywords - here: https://www.w3schools.com/java/java_ref_keywords.asp
In short - any automatic module having in it's jar name such key word (for example "byte") will fail Java modules validation. That's why temporary workaround is possible (where applicable) via addition of extra Manifest attribute.

Helidon does not mix javax.* and jakarta.* namespaces

Correct, but other projects/dependencies are not yet there. You could read more here about challenges: https://helidon.io/docs/v3/#/se/integrations/oci#oci-compatibility

We are part of the Helidon dev team, you know that.. right ?
Like I said before, Helidon + managed dependencies are okay WRT to javax vs jakarta.
The oci-sdk is available in a shaded form that works around the actual issue.

How are you modifying the jar name ?

Not jar name. MANIFEST.MF inside that jar via Maven jar plugin. This will be not needed with Helidon 3.x, but currently we're using Helidon 2.5.x. For more background - see this: oracle/helidon#4425

That issue has been fixed in 3.x and back ported in 2.x. There is a release available for both code lines.
Even if you are using an older version you should be able to fix for the entire build. I.e. you would repackage the offending jars, include module information and add dependency exclusions for the offending dependency and replace it with the repackaged one.
See also https://github.com/moditect/moditect#adding-module-descriptors-to-existing-jar-files
It seems to me that you have a few hacks that are not working properly with a Maven reactor or different life cycles (e.g. the jar is fixed only within a directory as part of a given execution). This is driving you down a path where you want to operate on a set of jars in a directory rather rely on the dependency graph.

That issue has been fixed in 3.x and back ported in 2.x. There is a release available for both code lines.

You're right, I could see backport mentioned here:
https://github.com/oracle/helidon/releases/tag/2.5.2
but reality though for one of components I'm dealing with - it's still with 2.5.0. And update of it yet out of my control, so I'm dealing under constraints I have.

Even if you are using an older version you should be able to fix for the entire build. I.e. you would repackage the offending jars...

Yes, it's kind of repackaging via invocation of jar --update --manifest file  command

It seems to me that you have a few hacks that are not working properly with a Maven reactor or different life cycles

Who would be able to reach anything workable without them these days? ;) And in ideal world with Maven enforcer plugin/etc/etc there would be just 1 version of some dependency to deal with in clean dependency graph. Some (including myself) people understand importance of that, many others don't. It takes quite an effort to explain rationale and make it actually happen.
I appreciate all this thread/conversation and thank you for your support.

Even if you are using an older version you should be able to fix for the entire build. I.e. you would repackage the offending jars...

Yes, it's kind of repackaging via invocation of jar --update --manifest file  command

It's about making a new Maven artifact that replaces the bad one. See https://github.com/oracle/helidon/tree/2.5.1/grpc/io.grpc

See https://github.com/helidon-io/helidon-build-tools/pull/784

@tvallin - thank you for update. I'll try to test new code earliest this Wed, Sep 21. At the moment I'm trying to invoke native-image with modules directly via maven exec plugin (one of proposals in the middle of our long discussion by @romain-grecourt ) to see what else could be needed. One addition to original ask came in form to support --features argument. But I need to make it work initially via maven exec plugin before starting asking you/Romain on same.
Also - please see this my Graal related issue for native-image invocation, which could be related to all this activity: https://github.com/oracle/graal/issues/5004

The documentation mention --module <module>[/<mainclass>] and not --module=<module>[/<mainclass>]. Have you tried it ?

@romain-grecourt - could you double-check if this went into v2.3.5 properly? It looks like tag 2.3.5 is pointing to some other commit: https://github.com/helidon-io/helidon-build-tools/tags ?

The fix for this issue is not included in any release yet.
2.3.5 was released 5 months ago (May 2022), the PR for this issue was merged 2 weeks ago.

I see, probably that was misunderstanding on my side as was consumed by other activities and only now returning to this. Do you want me to test this more or if you're confident about that PR - could you cut then next/2.3.6 release?

@romain-grecourt - I've tested now from 2.x master using such:
<execMode>none</execMode>

for my advanced use case and exact same arguments I had before for direct execution of native-image via maven exec plugin. All works fine. If you could cut 2.3.6 release to contain this enhancement - would be appreciated.

Done. The bits should be available in Maven Central shortly.

@romain-grecourt - now I've looked also into related Readme here for 2.3.6 tag:
https://github.com/helidon-io/helidon-build-tools/blob/2.3.6/helidon-maven-plugin/README.md?plain=1#L35
and so far it misses to mention module or none as available choices, having so far:
| execMode | enum | `jar` | Execution mode - `jar`, `jar-cp`, or `main` |

Not big deal for me - but could you cut some backlog ticket to adjust Readme later? Thank you

See https://github.com/helidon-io/helidon-build-tools/issues/795

@andrejusc Can you please stop commenting on a closed issue. If you find anything else that is related, please file a new issue.


Network integration tests

We currently have network integration tests (test/integration/port-filter.bats) that verify host mode networking (contributed by @chanwit).
We should add tests to verify bridge mode as well

@aluzzardi let me know if you've got something else needed to test.


Coalesce expression doesn't appear to be skipping empty string inputs

The following YAML expression
https://github.com/xamarin/Xamarin.Forms/blob/4f24701c64b63f7616493f197c6cc57cbdcdc068/build/steps/build-windows.yml#L41
"Install .net core COALESCE: ${{ coalesce(parameters.DOTNET_VERSION_GLOBAL, parameters.DOTNET_VERSION_PARAM) }} PARAM: '${{ parameters.DOTNET_VERSION_PARAM }}' GLOBAL: '${{ parameters.DOTNET_VERSION_GLOBAL }}' "

Yields the following string when my build runs
Install .net core COALESCE: PARAM: '2.1.801' GLOBAL: ''

According to the documentation of coalesce
coalesce
Evaluates the parameters in order, and returns the value that does not equal null or empty-string.

So it seems like the coalesce expression should be returning parameters.DOTNET_VERSION_PARAM since that's not an empty string where as parameters.DOTNET_VERSION_GLOBAL is

I'm having a very similar issue. Its pretty frustrating that it doesn't appear to be working as described in the docs.


[Minor] [Bug] [Recommended Items] Eagles' Peak (possibly others)

Have 51+ Magic
Have 2 Water Runes and 2 Law runes
Recommended items list does not highlight "Ardogne Teleport" as green for "in inventory" (nor does it highlight as white for "in bank").

This recommendation is expecting a "Ardougne teleport" tab to trigger the color change. Although misleading, it is referring to that specific item so technically it is correct. Though, it would be more correct if it encompassed the entire set of items which teleport someone to Ardougne.
Perhaps more ItemCollections could be implemented for teleport locations like this and include a check for all the runes needed for that teleport but at the moment that does not exist.


ReadMe: update example hook config to 1.2.0

Small change to reflect latest version in Read Me

Thanks!

Whoa! That is the fastest PR I've ever opened. 🎉
Happy to help!

I miiiiight take github a little too seriously ;)


feat: define network service interface

Current dependencies on/for this PR:

main

PR #15   👈

This stack of pull requests is managed by Graphite.

Merge activity

Nov 8, 7:51 AM: @richardcase started a stack merge that includes this pull request via Graphite.


Card type in card name

For quick overview in the code base, please consider adding the card type indicator in the card file name or path.

Yes, even though a bit redundant with the frontmatter, it would really help for getting an overview an easily find a certain card.

Renaming cards based on card type would allow us to narrow the Makefile dependencies a bit.
Today, all cards depend on all templates; if the cards were named by type (and thus by template), it would make it easier to have each card depend on only the templates that it uses.


ssh subcommand accepts command line after '--' that runs on the remote server

This pull-request adds support for remote command execution. Command line is passed after '--' argument. For example,
$ hotdog ssh -i ~/.ssh/td2.pem -u ubuntu -t public_ipv4 myworker-staging -- uptime

:+1:


feat(ingest): switch dbt to use auto_stale_entity_removal

Follow up on https://github.com/datahub-project/datahub/pull/7158.

This also resolves a long-standing bug where we would add non-dbt entities to the dbt state object
Adds status aspects for assertions

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Merging through the failures, which are related to glue and fixed by https://github.com/datahub-project/datahub/pull/7185


How to execute MSSQL stored procedure and take the result in GORM

How to execute MSSQL stored procedure and take the result in GORM

List of Objects or Map

Its worked.! Thank you for the support


Word synonyms for binary operators

Cognate looks really cool. The one place I think the literate aspect can be improved is with the binary operators, which are hard to read in a sentence as prefix symbols.
Print * 3 by - 7 2;

If the following looks nice, I will make a pull request to add synonyms like this:
Print Multiply 3 by Subtract 7 from 2;

and so on, + would be Add, Inequal? and Equal? for != and ==, because of the same for While (!= "done" Twin Input)

This is definitely an interesting idea. A long while ago (might be in commit history somewhere) I had all the binary operators as words, although more declarative variants. IE you could write Print the Product of X and Y; instead of Print Multiply X by Y;.
However I felt that was a tad too verbose and made code rather more difficult to scan through, so I added the symbol variants. I think the problem is that mathematical expressions are just very difficult to convey in english.
I'm definitely open to the idea of adding synonyms, but I do worry that it would make the language more difficult to learn and could potentially be overwhelming(?)

One idea I had from this (borrowed form Scheme) is you could allow the user to write something like Let Product be &* -- the & forcing the symbol to be treated like a var even though it is a function (and the definition of * will be pushed to the stack instead of * evaluated), and then when Multiply is looked up, it will see the definition of * as the value of Multiply and voìla. Although if Cognate is a "Lisp-2" kind of language, this might be hard to implement.

@dragoncoder047: Let Product be &* -- the & forcing the symbol to be treated like a var even though it is a function (and the definition of * will be pushed to the stack instead of * evaluated)

You should already be able to do Def Product (*) right?

You should already be able to do Def Product as (*); right? That's almost as good as is

Yes, but that incurs another layer of stack recursion. My "redirected definition" idea is like inline in C -- inlined functions don't use any extra stack space to call them. It's an optimization. Tail-call optimization may be higher priority than this.

You should already be able to do Def Product as (*); right? That's almost as good as is

Yes, but that incurs another layer of stack recursion. My "redirected definition" idea is like inline in C -- inlined functions don't use any extra stack space to call them. It's an optimization. Tail-call optimization may be higher priority than this.

The compiler will already inline this when defined as (*) btw

The compiler will already inline this when defined as (*) btw

Good, I didn't know that.
Maybe all that is needed is to add these things to the standard library.

The compiler will already inline this when defined as (*) btw

Good, I didn't know that.
Maybe all that is needed is to add these things to the standard library.

Yes, I think that was catb0t's original intention.


Added pin cluster list

Fixes https://github.com/rancher/dashboard/issues/9587
Allow the user to pin a cluster by clicking it
Store this configuration of the saved clusters in the same format as we get it here
==== On hover =====

==== Close =====

==== Open =====

in addition, cluster-badge-logo has a padding-top: 2px which makes the acronym not vertically centred


Converting of labels

in V2, labels must sometimes  be converted to functions.
does this means that we should start this function with global?
example: Process example 3 ( almost working)
https://www.autohotkey.com/docs/commands/Process.htm
#z:: ; Win+Z hotkey
WinGet, active_pid, PID, A
WinGetTitle, active_title, A
Gui, 5:Add, Text,, Press ESCAPE to cancel, or double-click a new`npriority level for the following window:`n%active_title%
Gui, 5:Add, ListBox, vMyListBox gMyListBox r5, Normal|High|Low|BelowNormal|AboveNormal
Gui, 5:Add, Button, default, OK
Gui, 5:Show,, Set Priority
return

5GuiEscape:
5GuiClose:
Gui, Destroy
return

MyListBox:
if (A_GuiEvent != "DoubleClick")
    return
; else fall through to the next label:
5ButtonOK:
GuiControlGet, MyListBox
Gui, Destroy
Process, Priority, %active_pid%, %MyListBox%
if ErrorLevel
    MsgBox Success: Its priority was changed to "%MyListBox%".
else
    MsgBox Error: Its priority could not be changed to "%MyListBox%".
return

=>
#z:: ; Win+Z hotkey
{ ; V1toV2: Added bracket
; add global here ???
active_pid := WinGetPID("A")
active_title := WinGetTitle("A")
oGui5 := Gui()
oGui5.OnEvent("Close", _5GuiEscape)
oGui5.OnEvent("Escape", _5GuiEscape)
oGui5.Add("Text", , "Press ESCAPE to cancel, or double-click a new`npriority level for the following window:`n" . active_title)
ogcMyListBox := oGui5.Add("ListBox", "vMyListBox  r5", ["Normal", "High", "Low", "BelowNormal", "AboveNormal"])
ogcMyListBox.OnEvent("DoubleClick", MyListBox)
ogcButtonOK := oGui5.Add("Button", "default", "OK")
ogcButtonOK.OnEvent("Click", _5ButtonOK)
oGui5.Title := "Set Priority"
oGui5.Show()
return
} ; Added bracket before function

_5GuiEscape(*)
{ ; V1toV2: Added bracket
; add global here ???
_5GuiClose:
oGui5.Destroy()
return
} ; V1toV2: Added Bracket before label

MyListBox(*)
{ ; V1toV2: Added bracket
; add global here ???
if (A_GuiEvent != "DoubleClick")
    return
; this is wrongly converting, I know, but it is hard to follow the code flow, maybe add an option to not close the brackets if the return is unclear, or add a sentense that will give an error and tell the user to verify the code here indicate an unclear conversion?
} ; V1toV2: Added Bracket before label
; else fall through to the next label:
_5ButtonOK(*)
{ ; V1toV2: Added bracket
; add global here ???
MyListBox := ogcMyListBox.Text
oGui5.Destroy()
ErrorLevel := ProcessSetPriority(MyListBox, active_pid)
if ErrorLevel
    MsgBox("Success: Its priority was changed to `"" MyListBox "`".")
else
    MsgBox("Error: Its priority could not be changed to `"" MyListBox "`".")
return
} ; V1toV2: Added bracket in the end

yes labels are global scope in v1, so i think you should def make the converted funcs global

Is there any reason this hasn't been added yet? I've made a patch that add this and none of the tests seems to be broken by this (so I'll finish and commit these changes)
We'd also need to do the same with hotkeys, for same reasons listed above.


working scenarios of kata containers

Fixes #15
The working scenarios are discussed in kata-containers/runtime#31 as part of the design requirement of Kata Containers.
Please consider reviewing this after #14 is reviewed and merged.

Some of the mentions of runv/clearcontainers aren't necessary imo, as this should just be about the kata-containers project (superfluous at best, confusing at worst)

agree

@jodh-intel thanks for the suggestion, will update later. I'd like to collect more comments before changing pictures. And do you have any idea with the much simpler #14 ?

@egernst sorry I missed this PR, let me have a look if it has been covered by other docs

close it, and file new PR if we need it.


Document "get/set-app-data" macros.

Documenting the macros removes 14 undocumented items.
Merge the two SSL exdata/appdata manpages into one.
Rename BIO exdata page to be consistent.
This should backport trivially.

find-doc-nits complains, but weirdly:
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_CTX_set_app_data is not public
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_get_app_data is not public
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_SESSION_get_app_data is not public
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_CTX_get_app_data is not public
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_SESSION_set_app_data is not public
doc/man3/SSL_CTX_set_ex_data.pod:1: SSL_set_app_data is not public

NOT that they're out of order :) but why didn't it complain about the other appdata additions?

It didn't complain because those functions were listed EXPLICITLY, and not in a "for openssl generic" manpage.  I think find-doc-nits scans the synopsis, not the NAME section.  Oh well, at least I know why.  New commit pushed.

There is a check of SYNOPSIS to see if what's in there matches what's given in the NAME section.

Merged.
d318389eff0fb80d4a88c7af1cc314f185ba94e1 Document "get/set-app-data" macros.


Timing

The code is currently about 20x slower than the Cython version.
Points where to look:

Julia code needs to be type-stable (check with @code_warntype function(inputs))
Julia runs single-threaded, Cython has 8 cores / 16 threads

Quick test of the package ParallelStencil.jl:

kernel code can be nearly identical
30% speedup on CPU (similar to Cython)
2x speedup on GPU (~10x compared to Cython CPU)
only tested with tgv_update_eta, 500 iterations, rest was commented out

speedup

it seems fine to only do calculation for voxels inside the mask
in st version: if CENTER

new version using ParallelStencil.jl timing
1000 iterations
Cython: 320s
julia CPU stencil: 180s
julia GPU stencil: 20s
create rectangular mask and only compute inside
This is a data specific improvement, in this test case 55% of the image was cut away
julia CPU stencil+mask: 80s
julia GPU stencil+mask: 10s

That's so cool!


Cupertino portuguese translations

Description
Cupertino translations to Portuguese
Related Issues
####13452

Need Cupertino Translations
https://github.com/flutter/flutter/issues/13452

I signed it!

I signed it! Again...

googlebot check it again.

@xster, What should I do to correct this Pull Request?

Make sure the commits you added were with the same email as what you registered with.  The first couple commits look like your author email were not the same as the email you CLA'd with.  Your best bet may be to close this PR and open a new one with the correct commit history.

Ok, i will do it again.


Publish to npm

clean up repo
correct file structure (js/, css/, bin/, src/ etc.
write package.json

Installing via npm install npm install biojs-vis-bonestagram gives
$ npm install biojs-vis-bonestagram

><EMAIL_ADDRESS>install /home/chdallago/git/test/node_modules/biojs-vis-bonestagram
> undefined && npm run css

sh: 1: undefined: not found
npm WARN enoent ENOENT: no such file or directory, open '/home/chdallago/git/test/package.json'
npm WARN test No description
npm WARN test No repository field.
npm WARN test No README data
npm WARN test No license field.
npm ERR! Linux 3.16.0-77-generic
npm ERR! argv "/home/chdallago/node/bin/node" "/home/chdallago/node/bin/npm" "install" "biojs-vis-bonestagram"
npm ERR! node v6.2.2
npm ERR! npm  v3.9.5
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn

npm ERR<EMAIL_ADDRESS>install: `undefined && npm run css`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'undefined && npm run css'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the biojs-vis-bonestagram package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     undefined && npm run css
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs biojs-vis-bonestagram
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls biojs-vis-bonestagram
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/chdallago/git/test/npm-debug.log

@sacdallago
Hmm.. That line of script "undefined && npm run css" was auto-generated by biojs-slush. What should it be instead?

Nothing! :)
It is a script that is run when installing the package. There is though no action to be performed on the machine when installing the package, you just need to "download" the package from npm. Thus I suggest you either delete it or (better) write something like "echo 'Read documentation to know how to use'"


Feature: use public RPCs for suggested wallet configs

What it solves
Resolves #2869
How this PR fixes it
Uses the new config field.
How to test it

Delete previous wallet configs.
Switch to an L2 network, accept suggested config
Make sure it's a public RPC

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 3 (33.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0002%) to 32.341%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/config/index.ts
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.0002%

Covered Lines:
3083

Relevant Lines:
8480

💛  - Coveralls


added unit testing for node

https://github.com/aurelia/skeleton-navigation/issues/767
README.md

[ ] recommend adding jasmine config path as env var. export JASMINE_CONFIG_PATH=./jasmine.json
https://jasmine.github.io/2.5/node.html#section-18
[ ] install jasmine globally

[ ] add dist files to .gitignore

[ ] list spec files individually in jasmine.json, for ordered test runs: https://github.com/lmj0011/sae-spa-skeleton/blob/1e59969320df457b674ae1b4e1a22f8cd5dc9d09/skeleton-esnext/jasmine.json#L4

[ ] recommend adding jasmine config path as env var. export JASMINE_CONFIG_PATH=./jasmine.json
https://jasmine.github.io/2.5/node.html#section-18

[ ] install jasmine globally and locally

@lmj0011 would you mind giving a justification for why this should be added?
I'm not against adding it, but I want to make sure that this is something that is truly needed for the skeleton.

I think it would be better to explore simply switching unit testing to be node-based-only, as is in the #714 which uses jest and the new aurelia-pal-nodejs. The only caveat is that the pal-nodejs might fail with unit tests that handle SVG, as that is not supported under jsdom. That way we'd only keep the e2e tests browser-based, as they need to be such, and all the other tests would run much faster, not having to spawn a browser to be able to run.
If that's not an option, I think this is a fairly good solution. But before we merge, we'd need to have this incorporated into the corresponding TypeScript skeleton.

before we merge, we'd need to have this incorporated into the corresponding TypeScript skeleton.

I'll try to work on that sometime this week

Closing this per the suggestion of @niieani which I think would be an awesome approach.

It's been shipped via #714! In the webpack skeletons we now have:

Karma for in-browser testing
Jest for node-based testing
Protractor for e2e testing


Add riscv vector extension in cpu feature

This patch parse /proc/cpuinfo isa string in linux/android platform to check the support of riscv vector extension.

HWCAP works on latest qemu and linux kernel. Drop this PR and use HWCAP to get riscv vector extension on new PR https://github.com/openxla/iree/pull/15306.


Step detrend fails: Error of overlapping depth > array size

Good day dear Alexey Pechnikov,
I run step unwrapping with the parameters as in the screenshot. However when I run the step detrend, I get an error of overlapping depth > array size as indicated in the screenshot.
I am finding it difficult to understand how to tackle this. What adjustments do I need in parameters to be able to run detrending step.
Thanks a bunch. Looking forward to hear from you

Is your gaussian wavelength larger than your area?

Thanks for your reply, you mean the wavelength I specified (300000) is too large for the area 3616 x 4138? I am trying this from a notebook where area is much smaller and this wavelength is applied but over there it went without error. So I wanted to check how it works for me, but it gives this error.  I will try more shorter wavelengths. What do you suggest for  3616 x 4138 area ?
tqdm_dask(detrend := (unwrap.phase - sbas.gaussian(unwrap.phase, wavelength=300000)).persist(),
desc='Detrending')

THis is what I get with 30,000

Thanks..... As we increase the Gaussian wavelength, it gets better and better (until we exceed the size of our area where it gives error). I am closing this issue.

Gaussian detrending is not the only detrending tool in PyGMTSAR. It is easy to use but not precise and has its limitations. Use precise tidal correction together with linear regression on the complete area or in chunks, and possibly pixel-wise residual topography correction for better results.

Thanks a lot for your insights dear Alexey Pechinikov. Sure, I will try those methods too...

By the way, there is a parameter to define the filter window size: Stack.gaussian(..., truncate=3.0). By using truncate=2.0, the filter size can be reduced by 1.5x, allowing for the use of a 1.5x larger wavelength on the same raster. However, it’s important to carefully evaluate the accuracy of your results. Gaussian filtering does not inherently guarantee that the output will be valid, as it may filter out real signals.


Download of the Stage_I dataset

In the first stage, the paper mentions the use of a 200GB dataset, but why does the actual code involve downloading a 2.3TB dataset?

We use Laion-aesthetic from the LAION-5B dataset for stage 1, which amounts to approximately 200GB for the first 302 tar files.


QA Review Updates

Updating things based on Gerard's review. He wanted a couple commands and to not see warnings/error at startup.
Adding:

less command
hexdump command (hd short command)
dd command (needed by urandom)
hostname command (and setting the hostname to "Kubos" instead of the default "buildroot")

Updating:

rcS/rcK scripts to ignore errors from ls command. This was getting thrown when the '/home/system/etc/init.d' directory was empty because there weren't any user scripts yet.
Upgrade partition size. Want to be able to store at least three *.itb files (current, previous, base)

Removing:

RTC options - In theory there is a real-time timer on the AT91SAM9G20 processor which can be used as an RTC. However, it has not be fully implemented (and, more importantly, tested), so I am removing the unused/unneeded commands and configuration info, rather than add in what is missing.

 Linux additions: tail, less, ascii editor, hex viewer and/or editor

 Try to fix or remove urandom and bin/hostname errors during linux init


Maybe something like "The minimum level Clue Casket tier to warrant a notification": ["Beginner", "Easy", "Medium", "Hard", "Elite", "Master"] where "Beginner" is the default (i.e. notify for all tier caskets)
There's a chance this setting is too extravagant, since minimum loot value threshold might be enough for people.
Not a request from me, but it came up briefly at @Supinic's stream, so I thought I'd get people's opinions here.

Ye I've been thinking about this since we added min value for screenshot, should be the same drop-down menu as diaries, as you've described.

It's now possible to configure this option with the "Min Tier" option under the "Clue Scrolls" category


[Bug] replace-ingress-hosts fails to mutate elements when fetching value from ConfigMap

Kyverno Version
1.10.x
Kubernetes Version
1.25.x
Kubernetes Platform
EKS
Description
The sample replace-ingress-hosts policy works when using static values, however we would like to use a value provided in a ConfigMap to provide the replacement domain in the policy to allow us to dynamically update the policy and deploy the policy to multiple clusters without customising it. We do this by defining a context to the rules that points to the ConfigMap that has the replacement domain in it like below:
context:
# A unique name for the context variable under which the below contents will later be accessible
- name: dictionary
  configMap:
    # Name of the ConfigMap which will be looked up
    name: cluster-domain
    # Namespace in which this ConfigMap is stored
    namespace: kyverno

We then set the replacement domain to fetch the value from the ConfigMap by setting it to the below in the 3 patching sections:
value: {{replace_all('{{element.host}}', '.old.com', '.{{ dictionary.data.domain }}')}}

When doing this and trying to create an ingress object the object fails to create with the below error:
failed to create rancher-demo/rancher-demo networking.k8s.io/v1, Kind=Ingress for acef03a8-4acb-4390-9817-8f48fe4e6dd4: admission webhook "mutate.kyverno.svc-fail" denied the request: mutation policy replace-ingress-hosts error: failed to apply policy replace-ingress-hosts rules [replace-old-with-new: failed to mutate elements]

This issue seems somehow related to the foreach loops. When commenting out the TLS and SecretName patches in the policy so only the host patching is applied the policy mutates successfully.
Steps to reproduce

Create ConfigMap with a domain value
Add a context into the policy rule to define the ConfigMap that was created
Set the replacement domain field to fetch the value from the ConfigMap

Expected behavior
Value from ConfigMap gets added and the policy mutates an ingress object successfully.

[X] I have searched other issues in this repository and mine is not recorded.

This was a known issue and should be fixed on main branch and will be included in the 1.10.1 patch release. Please try again with the latest code as outlined here.

Thanks @chipzoller, I have tested the policy against the latest code and the mutation is working as expected! Do you by any chance have a rough timeline as to when the 1.10.1 patch is going to be released?

The first release candidate for 1.10.1 is available now. You can try with that to confirm on a pre-release.


Update Step 6 Legal aspects data owner question in DAMAP and export templates

Changes

The last question in the Legal Aspects section is "who is the owner of the data and who controls access to tthe data?"
Fix: change the wording to say "List who will have the rights to control access over which dataset(s)."

Currently the answer above does not appear in the templates
Fix: add this statement “The following individual(s) hold rights and control access to the project data:”  and insert the answer from the above question to section 4b (Science Europe), 6.2 (Horizon Europe) and V.1 (FWF).

Currently, if no answer to the question is provided, the phrase "There are no legal restrictions on the processing and disclosure of our data." appears
Fix: change the phrase to "“info regarding rights and control of access to data has yet to be identified”

Adjust the verbiage for "Intellectual property rights and ownership" sections in templates
Fix:  change the name of the section to "Intellectual property rights and rights of use" in 4b (Science Europe), 6.2 (Horizon Europe) and V.1 (FWF).

@ChristianeStork please confirm I've captured the changes from our discussion.

3.: Make the phrase a full sentence: "Information ... identified."
The rest is fine!


Add option to capture GPS metadata on captures.

It would be great if there was at least an option to allow GPS meta data to be captured when taking a photo or video.

I will look into this in the future for possible enhancements. I do not currently have plans on implementing it


Copyright Metadata Proposal: 1st Draft

This is an attempt do open up #1 for peer review and feedback.

Thanks for the first draft! I agree with the problem, scope and overall approach. My main question is how we resolve conflicts between what is onchain and what is offchain? What happens if they differ?

A few thoughts here.

Would simply adding a rights field to NFT metadata JSON spec be a good first step to cover most use cases going forwards? I'm not a lawyer so not sure how legally binding that is but Objkt does that on their platform.
If trying to put this on-chain, it seems like an EIP extending the NFT standards would be appropriate, similar to ERC-2981. And then it would be possible to create a registry for backwards compatibility, similar to what Manifold has done with the Royalty Registry.
Having an api might seem good on the surface but as @edowling mentioned, how do you resolve conflicts on-chain and off-chain? This would also be an issue for NFTs with schemas specified in the metadata spec. I think you almost have to choose between off-chain and on-chain in a way so that conflicts aren't an issue.

Anyways, definitely want to keep this conversation going!

Hi @mpeyfuss!
Responses:

A singular field would be better than nothing, especially if it was CC0. I think in situations where it's a bit more complicated (e.g. "Attribution 3.0 United States"), it would need the ability to specify addition fields for attribution. Or if it was a non-commercial license, a pointer to where inquiries could be made. But yes... in the spirit of the 80/20 rule, just having a singular field would get most people 95% of the way there. I just want to not overlook the next to extend.
Glad you mentioned ERC-2981! This was inspired by a conversation with them where they shared their work on that. The question remains whether the data should initiative within tokenURI as a sane default with a global registry as a larger umbrella. But first, I want to get to an agreement on the metadata structure + components before I tackle that (and it relates to the 3rd bullet).
On vs off-chain and precedence. I think this is where I need to get more input from legal/lawyers. I would bet this acts in many ways like a will, where the last version is the one (however, I think this has to be balanced with something not being able to go backwards from public domain back to all-rights reserved). So if it was CC0 once, it's CC0 forever (on or offchain). And if it's something else, then we look at blockheight.

Love the feedback! Keep it coming if something I said sparked and idea or pushback.


[BUG] Flex box issue

Describe the bug
The input fields aren't aligned into the div
To Reproduce
Make your browser use half of your screen(split screen)
Expected behavior
Input fields to coincide the box.
Screenshots

Additional context
None

Hey @zelfroster Could you look into the issue.

Yes, I can fix it. I will work on it now, assign it to me.


Is circle softmax equal to original softmax?

Hi,
In Base-stringerbaseline.yml:
MODEL.HEADS.CLS_LAYER: "CircleSoftmax"
MODEL.LOSSED.NAME: ("CrossEntrpyLoss", "TripletLoss")
my question is:

The difference between circle softmax and softmax?
The total loss = CrossEntrpyLoss(with CircleSoftmax) + TripletLoss, is there any reason why using this combination.(what kinds of experience on this you have done, can you share ? )
In CVPR 2018 Bag of tricks paper, the triplet loss is applied before bn layer, now seems applied after bn layer, any explainable experience can share?

Thanks a lot!

Circle softmax is just like arcface or cosface, you can name it margin-based softmax. The difference between softmax is the margin.

We call circle softmax "ID/classification loss", triplet loss "metric loss", these two type loss combination can boost performance.

Just through experiments, we found features after the bn layer can get better results when using SBS configuration.


test: remove skipped tests

I don't think it's a good idea to have skipped tests on master, so I've removed them. I looked at fixing them, but the Transfer throws an error about a missing backgroundColor when mounted in enzyme, so it should probably be fixed in ui. I was hoping that a ui update would fix it, but it didn't. We looked at this in the past, I'll create an issue for this if it doesn't already exist.
See also the removed comment:
        // At the time of writing these tests have a problem relating to the error
        // ReferenceError: backgroundColor is not defined
        // seems to be a problem in<EMAIL_ADDRESS>
I've also removed the abstraction in the aggregate data component. There's no need to be DRY in tests in my opinion. It only makes them harder to follow and couples them unnecessarily.

Not sure which merge strategy is being used in this repo, but with these changes, I think it should be either standard or rebase merge, not a sqush merge.

You mean because there's an update and some changes to the tests in this PR? I'll clean them up a bit and then rebase merge.


Create issues from todos in the code

Goal
There are no more todos in the code. It's more consistent to have them here on GitHub.
Motivation: see the bigger picture more clearly
Tasks

[ ] implement easy todos
[ ] create issues from all todos in the code or remove them

Closed because completion on time is not realistic.


fwupd: 1.2.8 -> 1.2.10

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/fwupd/versions.
meta.description for fwupd is: '""'.
meta.homepage for fwupd is: '"https://fwupd.org/"

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.2.10 with grep in /nix/store/0i3bxrrfblasxcjkcshwxjr153vb8wwv-fwupd-1.2.10

directory tree listing: https://gist.github.com/e3ed8754b4d6cbf6e6f323a61eaab37b

du listing: https://gist.github.com/8bb0f712ada169c7ff43c3cf922893cd

Rebuild report (if merged into master) (click to expand)

11 total rebuild path(s)
4 package rebuild(s)
4 x86_64-linux rebuild(s)
4 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
3 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
discover
fwupd
gnome3.gnome-software
plasma5.discover

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/0i3bxrrfblasxcjkcshwxjr153vb8wwv-fwupd-1.2.10 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
Or, build yourself:
nix-build -A fwupd https://github.com/r-ryantm/nixpkgs/archive/e7bc99490d95dcd9c2c6dafd3a9e39026577d0e1.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/0i3bxrrfblasxcjkcshwxjr153vb8wwv-fwupd-1.2.10
ls -la /nix/store/0i3bxrrfblasxcjkcshwxjr153vb8wwv-fwupd-1.2.10/bin

@GrahamcOfBorg build fwupd


Managed windows

I noticed lots of code-duplication w.r.t. IWorkspace.Windows. I created a new property called "Managed Windows" to cut down on the repetition.
Not sure if it's the best name, but it was the first decent name I could come up with. Maybe you have a better suggestion?

This PR probably has merge conflicts with this PR.
From my point of view, it will probably be easier to fix conflicts, if you handle the other PR first.

No actual changes to the PR itself, but I just rebased it to be based on current master-branch.

This PR probably has merge conflicts with this PR.
Currently this PR fixes errors, and the other does not, so it probably makes most sense to merge this first, and then I can fix up the other later.


[docs] Document overlay ports/triplets in vcpkg-configuration.json

Describe the pull request

What does your PR fix?
Fixes docs to reflect changes to overlays

Which triplets are supported/not supported? Have you updated the CI baseline?

n/a

Does your PR follow the maintainer guide?

Yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

n/a
If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Dropping reviewed because this is already requires:vcpkg-tool-release.

Thanks!


postgresqlPackages.postgis: 3.4.1 -> 3.4.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/postgis/versions.
meta.description for postgresqlJitPackages.postgis is: Geographic Objects for PostgreSQL
meta.homepage for postgresqlJitPackages.postgis is: https://postgis.net/
meta.changelog for postgresqlJitPackages.postgis is: https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.4.2/NEWS
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 3.4.2 with grep in /nix/store/j6l6ckbp2yi68akfgrgs0h1kk908gs8q-postgis-3.4.2
found 3.4.2 in filename of file in /nix/store/j6l6ckbp2yi68akfgrgs0h1kk908gs8q-postgis-3.4.2

Rebuild report (if merged into master) (click to expand)

12 total rebuild path(s)

12 package rebuild(s)

First fifty rebuilds by attrpath
postgresql12JitPackages.postgis
postgresql12Packages.postgis
postgresql13JitPackages.postgis
postgresql13Packages.postgis
postgresql14JitPackages.postgis
postgresql14Packages.postgis
postgresql15JitPackages.postgis
postgresql15Packages.postgis
postgresql16JitPackages.postgis
postgresql16Packages.postgis
postgresqlJitPackages.postgis
postgresqlPackages.postgis

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/j6l6ckbp2yi68akfgrgs0h1kk908gs8q-postgis-3.4.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A postgresqlJitPackages.postgis https://github.com/r-ryantm/nixpkgs/archive/1b42752173d115f4101e68e240dac64fc31d2ff0.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1b42752173d115f4101e68e240dac64fc31d2ff0#postgresqlJitPackages.postgis

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/j6l6ckbp2yi68akfgrgs0h1kk908gs8q-postgis-3.4.2
ls -la /nix/store/j6l6ckbp2yi68akfgrgs0h1kk908gs8q-postgis-3.4.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

10 packages built:

postgresql12JitPackages.postgis
postgresql12Packages.postgis
postgresql13JitPackages.postgis
postgresql13Packages.postgis
postgresql14JitPackages.postgis
postgresql14Packages.postgis
postgresqlJitPackages.postgis (postgresql15JitPackages.postgis)
postgresql15Packages.postgis
postgresql16JitPackages.postgis
postgresql16Packages.postgis

Maintainer pings
cc @das-g @imincik @nh2 @nialov @r-burns @sikmir @willcohen @MarcWeber for testing.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/week-in-geospatial-team/37035/7


TEP-0142: Surface step results via sidecar logs

Prior to this, we enabled surfacing Step Results via termination-message. This PR does the same thing for sidecar-logs. It would ensure that we can use StepResults when results-from: sidecar-logs feature flag is enabled.
This PR is part of issue https://github.com/tektoncd/pipeline/issues/7259.
Changes

Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
[x] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[x] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
Surface step results via sidecar logs

/kind feature

/lgtm

/lgtm


sourcemaps.rewriteSources doesn’t apply new source value

Environment

Sentry Vite plugin, 2.16.1
Self hosted Sentry, 22.8.0

Steps to Reproduce

Use Sentry Vite plugin
Add option sourcemaps.rewriteSources: (source) => './' + source.replaceAll('../', '')

Expected Result
Source from source map should be translated to value defined in rewriteSources hook, e.g. ../ should be stripped and ./ should be prepended to source path.
Actual Result
Default value is used which is relative path from process.cwd(), but I’m not sure if that’s valid - I’ve tried to change code directly inside default hook but changes are not applied.
I’m also using RewriteFrames integration, but I haven’t seen any changes if it’s removed.
Is this maybe related to self-hosted Sentry? For upload to work I had to use release.uploadLegacySourcemaps option so maybe these changes don’t get applied?

Hey @niksy thanks for writing in!
To debug this, would you mind sharing your vite plugin config?
It could be well-related to self-hosted and uploadLegacySourcemaps. Which makes this extra hard to debug 😅
are you able to update to the latest self-hosted version of Sentry? If so, I think the simpler, debug-id based source map upload apporach should work (tagging @lforst to confirm).

To debug this, would you mind sharing your vite plugin config?

Sure, no problem, here it is:
sentryVitePlugin({
  url: "",
  org: "",
  project: "",
  authToken: "",
  sourcemaps: {
    rewriteSources: (source) => "./" + source.replace("../", ""),
  },
  release: {
    name: commitSha,
    uploadLegacySourcemaps: path.resolve(cwd, "ssr-dist"),
  },
});

are you able to update to the latest self-hosted version of Sentry?

I’ll see what I can do, it would be great if this is fixed just with version bump, it looks like our self-hosted instance version is almost 2 years old 😄

Unfortunately, we’re currently unable to easily upgrade our Sentry instance 😞

One question: Did you look at the sources field of the uploaded artifact (in Sentry) or the local file? sourcemaps.rewriteSources only affects the uploaded artifacts.

@niksy okay thank you! I will take a look.

@niksy Hey, I just took another look. I realized you were using uploadLegacySourcemaps to upload the source maps. The upload process that is kicked off when using that option does not consider any options in the sourcemaps field. If you want to transform sourcemaps when using uploadLegacySourcemaps, I recommend looking into the specific options instead.
I think we can do a better job documenting this. Sorry about that.

Okay, thank you for a fast response!


Push updates to TOC to live

Docs Build status updates of commit c036003:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

BingMaps/articles/geospatial-endpoint-service.md
:white_check_mark:Succeeded
View

BingMaps/getting-started/bing-maps-dev-center-help/understanding-bing-maps-transactions.md
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/Google-Maps-to-Bing-Maps-Migration-Guide.md
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/hosted-data.md
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/key-features-in-bing-maps.md
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image1.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image10.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image11.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image12.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image13.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image14.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image15.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image16.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image17.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image18.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image19.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image20.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image21.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image22.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image23.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image24.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image25.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image26.png
:white_check_mark:Succeeded
View

BingMaps/getting-started/google-maps-to-bing-maps-migration-guide/media/image27.png
:white_check_mark:Succeeded
View

This comment lists only the first 25 files in the pull request.
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Remove preview header for Traffic API

Announcement:
https://developer.github.com/changes/2016-12-28-end-traffic-api-preview/

Please assign this to me, I am almost done with integration test issues.


improved the home page info div

added logo for website tab
modified the homepage info tab and adjustment
add style for adjustment

@iriteshmishra will this do?

There is a problem in search feature Its not working. Kindly look into this.

@iriteshmishra sure!

Issue #73

@iriteshmishra does script.js working properly, it is showing all data into webpage?

can you create a screen recording after your added feat how the website is looking. @Khushalsarode

Because when I am running the website it is looking something like this


add kata TL sig config + release TL images weekly

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Is the mariner_v2_kata_gen2_tl_sig_version.json file going to be updated manually, for a particular release?

Is the mariner_v2_kata_gen2_tl_sig_version.json file going to be updated manually, for a particular release?

from next week, we will build kata TL image weekly, I will delete this file then


feat(back matter): Adjust resource anchor links

This changes resource data to include their uuid in their anchor link.

@kylelaker  would you prefer that these links by just the uuid? I currently just have them written as a subset of back-matter/resources/{uuid}, similar to how the controls are written as a subset of groupings.

would you prefer that these fragments be just the uuid?

Yes


Sign out button should go inside menu in mobile view, profile image hidden or out of the way

Complete with #304


DEP Update minimum composer versions

Issue https://github.com/silverstripe/.github/issues/306

CI failures unrelated - see https://github.com/silverstripe/silverstripe-framework/actions/runs/12228337036


EXC_BAD_ACCESS in Simulator::Call in custom engine

I have built a custom engine which can run kernel output (JIT) in iphone device (not simulator). But there is a EXC_BAD_ACCESS Error when calling Simulator::Call in dart vm. What's wrong with it ? How can I make it work in iphone device.
It's strange that the same kernel output can work in simulator and profile mode in iphone simulator, but it can not work in debug mode and release mode in iphone device.

I run a demo created by flutter create demo using my custom engine.
I click the plus icon. When I click the plus icon twice, it will crash.

meets the same problem...any updates?

I'll pass this on to the engine team, although I think we may not have the bandwidth to support custom engine builds.

Closing as this is not a supported workflow.


Created product_steps.py file for behave testing

IBM Cloud toolchain: Delivery Pipeline deployed products to dev, including commit 3f8c9b4b0881cac367a290edbeb43fe5e5fa4bdd

IBM Cloud toolchain: Delivery Pipeline deployed products to prod, including commit 3f8c9b4b0881cac367a290edbeb43fe5e5fa4bdd


Partially updated view navigating from browsing community to "All of DSpace"

Describe the bug
When navigating from browsing items in a community by issue date, by author, etc to the corresponding "All of DSpace" menu option, the address bar and items shown reflect the navigation but the page otherwise appears the same, as if still browsing items within the community. This only occurs when the "All of DSpace" option matches the currently displayed community browse option.
Observed with dspace-angular 7.6.1 in Chrome 121 and Edge 121 on Windows; reproduced on https://demo.dspace.org/.
To Reproduce

Open the community list eg https://demo.dspace.org/community-list.
Click any community.
Click By Issue Date, or By Author, etc.
Click All of DSpace -> same option as step 3.

The list of items is updated correctly, but the rest of the page is not, eg breadcrumbs are unchanged and the community name and browse controls are still visible.
Expected behavior
When using "All of DSpace" menu options while browsing a community, the resulting page should always look the same as using those options from the home page or direct links.

@ghadf: This has been fixed on dspace 8.0 see this this ticket: #2425

Sorry for the waste of time, obviously I missed that one. Closing since this is a duplicate and https://github.com/DSpace/dspace-angular/issues/2425#issuecomment-1942445729 implies "won't fix" for 7.6.


Update wasm endpoint for non-classic chain cosmwasm chain

Current pisco-1 testnet hive is using the old Terra wasm endpoint /terra/wasm/v1beta1/ causing wasm query to fail and return Not Implemented error. The non-classic chain should use the direct cosmwasm endpoint /cosmwasm/wasm/v1/.
This query on testnet hive will fail with such error.
{
  wasm {
    codeInfo(codeID: 12) {
      code_creator
    }
  }
}

{
  "errors": [
    {
      "message": "[Not Implemented] error",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "wasm",
        "codeInfo"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "exception": {
          "status": 501,
          "name": "LCDClientError",
          "message": "[Not Implemented] error",
          "stacktrace": [
            "LCDClientError: [Not Implemented] error",
            "    at WasmService.codeInfo (/app/dist/wasm/wasm.service.js:36:19)",
            "    at runMicrotasks (<anonymous>)",
            "    at processTicksAndRejections (internal/process/task_queues.js:95:5)",
            "    at async target (/app/node_modules/@nestjs/core/helpers/external-context-creator.js:77:28)"
          ]
        }
      }
    }
  ],
  "data": null
}

@y-pakorn It's been fixed by #18 and deployed to pisco-hive.terra.dev

{
  wasm {
    codeInfo(codeID: 12) {
      code_creator
    }
  }
}

Now returns,
{
  "data": {
    "wasm": {
      "codeInfo": {
        "code_creator": "terra1em2sanwzpv5226dxlp3rwf765r7x5gvrqfdk7p"
      }
    }
  }
}

As expected.


Show different unit options in compare view

Description:
Users currently set global unit settings and cannot be able to  compare different available units in compare view.

Let's add options to list to compare:
Temperature (°C)
Temperature (°F)
Temperature (K)
Humidity (relative, %)
Humidity (absolute, g/m3)
Humidity (dew point, °)
Pressure (pascal, Pa)
Pressure (hectopascal, hPa)
Pressure (inch of mercury, inHg)
Pressure (millimetre of mercury, mmHg)

Please don't hardcode these in the app, add to language file instead.  Dewpoint is also incorrect it should be "dew point"

@io53 there are few issues with this.

CSV/XLXS export doesn't give anything for new measurement selections.

The language strings are still hardcoded I believe, for example "accelerationX" is shown as title for Acceleration X and I cannot find it in the localisation.

@io53 one simple fix required, I cannot figure out which string this is in localisation

Dew point is one unit selection under Humidity, so logically it should say
Humidity (Dew point (°C))


Questions: How should I setup my VSTS Builds for a solution which has dotnet core and non-core dependencies

It's a question not an issue - hope that's ok.
We have a ASP.NET Core API project which depends on some non-core C# project in the same solution.
When I came to setup the CI build I setup:
GitVersion Task
NuGet Restore
DotNet Restore
Build
It fails in the DotNet Restore as the depend projects are not yet built. I'm about to create two new solution files to split the core and non-core builds and add an additional build step so it looks like this
GitVersion Task
NuGetRestore
Build Non-Core SLN
DotNet Restore
Build Core SLN
....
Does seems reasonable ? Have I missed something with dotnet restore ? I looks at the command options and nothing jumped out at me to build dependant projects or such like.

I'm still stuck with this issue, I can't find a combination of
dotnet restore
& 'C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\MSBuild.exe' <SFSolution Name> /t:Package /p:platform="x64" /p:configuration="Release"

@zjrunner, would your team own the dotnet restore scenario?  Thanks.

We don't own a dotnet restore task today if that is the question.  We already have on our backlog general dotnet restore support for auth (dotnet doesn't currently support plugin credential providers or encrypted creds so we're waiting/pushing/working toward that first).
This sounds like an issue to be resolved first with the dotnet-cli or msbuild spaces first.  If it comes down to tasks around packaging that don't support the commands needed to get this rolling then that is probably with me, but the above sounds like confusion around even how the individual tools should be sequenced (regardless of build/task infra)

Hi @johnkattenhorn.  Sorry for the delay.  Did you find a solution, or is this still an issue for you?

This is still a problem for us but it turned out not to be anything to do with the restore.
The build steps fail regardless of the restore, I've got another issue logged here:
https://github.com/Azure/service-fabric-issues/issues/66
PS. There seems to be a lot of people with this issue in dotnet core and plenty of workarounds but none I've seen so far work for us.

Thanks, John.  I'll close this issue since it's tracked by the other one you referenced.  Sorry for the trouble you're seeing and I hope we can resolve the other issue quickly.


Some missing links key mappings

Hello folks,
First of all, thank you for your work. I use dbt_vault and the regularly published examples on projects and you can't imagine how it simplifies my daily work :)
This morning, I wanted to transcribe the metadata into an Excel file in order to centralize and regenerate the models. I noticed a little oversight or maybe it's wanted!
In the LNK_INVENTORY_ALLOCATION Link.
The primary key of the link is 'INVENTORY_ALLOCATION_PK' and the foreign keys are "PART_PK", "SUPPLIER_PK", "LINEITEM_PK"
In the "v_stg_orders" staging view, you have defined the key with three source columns :
INVENTORY_ALLOCATION_PK:
  - 'LINENUMBER'
  - 'PARTKEY'
  - 'SUPPLIERKEY'

While,
PART_PK: 'PARTKEY'
SUPPLIER_PK: 'SUPPLIERKEY'
LINEITEM_PK:
  -  'ORDERKEY'
  -  'LINENUMBER'

I think ORDERKEY is missing in the hash calculation of the primary key of the link
I thank you a lot.

Thank you for your feedback, we're glad you're finding the package useful!
As for the mapping, I think this is correct, as the ORDERKEY is not part of the relationship. This relationship between ORDER and LINEITEM is modelled in the LINK_ORDER_LINEITEM.
I will double check this, however.

As a newbie trying to explore this, and much Appreciate sharing your thoughts and experience if any of you ever encountered the error below from 'dbtvault-snowflakeDemo'.

Compilation Error
Model 'model.dbtvault_snowflake_demo.raw_transactions' (models/raw_stage/raw_transactions.sql) depends on a source named 'tpch_sample.ORDERS' which was not found


Update mdoc, sbt-mdoc to 2.5.3

About this PR
📦 Updates

org.scalameta:mdoc
org.scalameta:sbt-mdoc

from 2.5.2 to 2.5.3
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (2.5.2).
You might want to review and update them manually.
project/plugins.sbt
zio-aws-codegen/project/plugins.sbt

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #1315.


Add missing word to our styles config to fix vale

I've added the word at the wrong place 🤦 .
Follow up of c27118f25f5a449c0c9c58ce552a1f0980be2581.

Don't we need this on 5.2 as well?

Don't we need this on 5.2 as well?

I will include it directly in the related issue backport.


Uncaught TypeError: ref.is is not a function

[Enter steps to reproduce:]

...
...

Atom: 1.27.2 x64
Electron: 1.7.15
OS: Ubuntu 18.04
Thrown From: 'tree-view-open-files-updated' package vundefined
Stack Trace
Uncaught TypeError: ref.is is not a function
At /home/florian/.atom/packages/tree-view-open-files-updated/lib/tree-view-open-files.coffee:27

TypeError: ref.is is not a function
    at /packages/tree-view-open-files-updated/lib/tree-view-open-files.coffee:27:27)
    at CommandRegistry.handleCommandEvent (/usr/share/atom/resources/app/src/command-registry.js:384:49)
    at CommandRegistry.dispatch (/usr/share/atom/resources/app/src/command-registry.js:273:23)
    at AtomEnvironment.dispatchApplicationMenuCommand (/usr/share/atom/resources/app/src/atom-environment.js:1347:25)
    at EventEmitter.outerCallback (/usr/share/atom/resources/app/src/application-delegate.js:339:53)
    at emitThree (events.js:116:13)
    at EventEmitter.emit (events.js:197:7)

Commands
     -1:54.9.0 tree-view:toggle (div.tool-panel.tree-view)
     -0:48.9.0 core:confirm (input.hidden-input)

Non-Core Packages
atom-ide-ui 0.12.0
atom-monokai 0.10.9
autocomplete-python 1.10.5
busy-signal 1.4.3
django-templates 0.5.0
file-icons 2.1.21
git-diff-details 1.4.0
git-plus 7.10.2
git-time-machine 2.1.0
goto-definition 1.3.4
highlight-selected 0.13.1
ide-python 1.0.0
intentions 1.1.5
language-django 0.1.1
linter 2.2.0
linter-flake8 2.3.0
linter-pydocstyle 0.4.7
linter-python 3.1.2
linter-ui-default 1.7.1
MagicPython 1.0.12
minimap 4.29.8
minimap-cursorline 0.2.0
minimap-find-and-replace 4.5.2
minimap-highlight-selected 4.6.1
monokai 0.24.0
monokai-seti 0.9.0
python-autopep8 0.1.3
python-indent 1.1.5
python-tools 0.6.9
seti-ui 1.10.0
split-diff 1.5.2
todo-show 2.3.0

Thanks for the report @florianRichy.
Can you confirm a few things for us?

What were you doing at the time of the error?
Is the error is reproducible?
If reproducible, do you see the error in safe mode (atom --safe)?

Thanks for contributing!
It appears that this is being caused by the tree-view-open-files-updated package, not Atom itself. It may be that there is still a bug in Atom. If so, we'll need the maintainer of the package that is causing the problem to help track that down. You should file this issue on their repository so they can either fix the problem or tell us where the problem is coming from. The Atom FAQ has information on how to contact the maintainers of any Atom community package or theme.