Change hawkular client usage to work with partial endpoints

Creating the aggregated client does a health check against all endpoints.
The Hawkular deployed in OpenShift does not include some of those endpoints (e.g inventory)

@miq-bot add_label providers/containers, bug

@lucasponce @cben @simon3z could you please review?

@josejulio @cfcosta Please could you also review this PR ?
@moolitayer is using the hawkular ruby client for the datawarehouse provider and he commented some potential problems with the validation of non existing endpoints in the backend.
OpenShift deployments only uses Metrics/Alerting endpoint.

@cfcosta Thanks for the review
@cfcosta @josejulio please take a look

@cben Please review

I still dislike the boolean because "alerts false" here doesn't mean "the opposite or alerts" or "don't fetch alerts", it means "the other unrelated thing out of two"...
LGTM on the PR, it fixes a bug and the code is no worse than before.
P.S. if the options hash grows any new parameters in the future, it's easy for the bug to re-appear.
In theory the Right Thing is memoizing on @clients[canonicalized_options.freeze] where canonicalized_options currently means ensuring :alerts is either true or false.  Not worth the complexity I suppose, if you think that's a concern just add a comment.
P.P.S. AFAIK a Hawkular::Client currently constructs new RestClient for every request, and a RestClient currently opens new http connection for every request.  So the memoization is not really helping, just dropping it is also an option.

@cben +1 to dropping memoization, on a stylistic level it makes the code weird to read, and as you said it does not exactly do anything.
In case we're doing lots of that kind of memoization, we can start using Memoist, which is a nice, elegant way of doing memoization.
And as of Ruby 2.1 (I guess) something like this is possible:
memoize def foo; end

And it would be equivalent to do:
def foo; end
memoize :foo

Outside the scope of this pr:

changing memoization mechanism
should we do memoization?

I have my thoughts about both of these, but they are both out of scope of this PR
in the scope of this pr:

should we pass a boolean or symbol to self.raw_connect if I understand correctly
The both have good reasons

The difference as I see it is;
option a;
class.raw_connect(..., false) # or nil or nothing
class.raw_connect(..., true)

def self.raw_connect(..., alerts=false)
  client_klass = alerts ? ...
  ...

option b;
class.raw_connect(..., :alerts)
class.raw_connect(..., :events)

def self.raw_connect(..., type=:alerts)
  client_klass = case type
    when :alerts
      ...
    when :event
      ..
    else
      ..

I prefer option a here

@cben @cfcosta @josejulio please review

I prefer option b, because its not default behaviour OR other behaviour, but two different kinds of behaviour being switched by a flag. Going even further, I prefer something like this:
def self.client_for(type)
  case type
  when :metrics
   ::Hawkular::Metrics::Client
  when :alerts
    ::Hawkular::Alerts::AlertsClient
  else
    raise ArgumentError, "Client not found for #{type}"
  end
end

def self.raw_connect(..., type = :alerts)
  client_for(type).new(...)
end

I prefer option b, because its not default behaviour OR other behaviour, but two different kinds of behaviour being switched by a flag. Going even further, I prefer something like this:
...

@cben @josejulio are you happy with this suggestion?

@cben @josejulio sorry for nagging but I have a ton of other stuff dependant on this

@cfcosta suggestion is good

P.P.S. AFAIK a Hawkular::Client currently constructs new RestClient for every request, and a RestClient currently opens new http connection for every request. So the memoization is not really helping(?), just dropping it is also an option.

That's right, but some clients (e.g. metrics) do check the version to know if use legacy API or not.
alerts doesn't do that.
I guess the whole Hawkular client could benefit from checking it lazily (I suppose this PR wouldn't exist if it was like that).

Thanks @josejulio
@cben are you fine with that?

Love @cfcosta's suggestion.

@cben @josejulio @cfcosta please review

LGTM

@miq-bot assign moolitayer

@miq-bot assign @simon3z
please review

@simon3z can we merge this?

@simon3z please review

LGTM :+1:
cc @chessbyte
@miq-bot assign blomquisg


Always builds a native-image event when explicitly disabled

I have a Spring Boot App with Gradle and Kotlin including id("org.graalvm.buildtools.native") version "0.9.26" and a META-INF/native-image folder in Resources. When running bootBuildImage with paketo base builder, it builds a native image. This is fine for prod uses. For some debugging I want to build a java based image, not a native image. When I now set BP_NATIVE_IMAGE=false, still a native image is build. I did try to exclude the plugin and also to exclude the META-INF folder, but regardless of what I try, the builder always builds a native image with liberica nik.
Expected Behavior
When setting BP_NATIVE_IMAGE=false I would expect to not build a native-image but rather a normal jvm based image.
Current Behavior
The builder builds a native image, regardless of which variables I set.
Possible Solution

Steps to Reproduce
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    val kotlinVersion = "1.9.10"
    kotlin("jvm") version kotlinVersion
    kotlin("plugin.spring") version kotlinVersion
    id("org.springframework.boot") version "3.1.3"
    id("io.spring.dependency-management") version "1.1.3"
    id("org.graalvm.buildtools.native") version "0.9.26"

    application
    id("org.flywaydb.flyway") version "9.22.0"
}

group = "com.example"

kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(17))
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation(platform("org.springframework.cloud:spring-cloud-dependencies:2022.0.4"))
    implementation("org.springframework.boot:spring-boot-starter-actuator")
    implementation("org.springframework.boot:spring-boot-starter-data-r2dbc")
    implementation("org.springframework.boot:spring-boot-starter-security")
    implementation("org.springframework.boot:spring-boot-starter-thymeleaf")
    implementation("org.springframework.boot:spring-boot-starter-validation")
    implementation("org.springframework.boot:spring-boot-starter-webflux")
    implementation("org.springframework.cloud:spring-cloud-starter-gateway")
    implementation("org.thymeleaf.extras:thymeleaf-extras-springsecurity6")
    runtimeOnly("io.r2dbc:r2dbc-h2")
    runtimeOnly("com.h2database:h2")
    runtimeOnly(kotlin("reflect"))

    // Kotlin
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core")
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-reactive")
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-reactor")
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")

    // Flyway
    implementation("org.flywaydb:flyway-core")
}

tasks {
    bootBuildImage {
        builder.set("paketobuildpacks/builder:base")
        environment.set(
            mapOf(
                "BP_JVM_VERSION" to "17",
                "BP_NATIVE_IMAGE" to "false",
                "BPE_SPRING_PROFILES_ACTIVE" to "prod",
                "BP_SPRING_CLOUD_BINDINGS_DISABLED" to "true",
                "BPE_APPEND_JAVA_TOOL_OPTIONS" to "-XX:+ExtensiveErrorReports",
                "BPE_DELIM_JAVA_TOOL_OPTIONS" to " ",
            ),
        )
        imageName.set("registry.gitlab.com/etalytics/infrastructure/eta-central")
        tags.set(listOf("${project.version}"))
    }
}

tasks.withType<KotlinCompile>().configureEach {
    kotlinOptions {
        javaParameters = true
        freeCompilerArgs = listOf("-Xjsr305=strict", "-Xemit-jvm-type-annotations", "-Xjvm-default=all", "-Xcontext-receivers")
    }
}

tasks.test {
    useJUnitPlatform()
}

graalvmNative {
    agent {
        defaultMode.set("standard")
    }
    toolchainDetection.set(false)
    binaries {
        all {
            resources.autodetect()
            buildArgs("--enable-monitoring=heapdump", "-march=native", "--initialize-at-build-time=org.slf4j.LoggerFactory,ch.qos.logback,org.apache.logging")
        }
        named("main") {
            when {
                project.hasProperty("static") -> buildArgs("--static", "--libc=musl")
                else -> buildArgs("-H:+StaticExecutableWithDynamicLibC")
            }
        }
    }
    metadataRepository {
        enabled.set(true)
    }
}

Motivations

You are correct that the behavior here is a bit odd. The buildpack doesn't actually look at the value, just if it's present or not.
If you simply remove it instead of setting it to false, you'll get the desired behavior.
We can look at changing this, but it would be a behavior/breaking change, so we'd be limited in terms of when we could introduce the change. I'll leave this as a bug request, but it could be a while before we can change this.

The reason why I did set it in the first place, was that without setting it, the builder always builds a native image.
So when using this one:
mapOf(
    "BP_JVM_VERSION" to "17",
    "BPE_SPRING_PROFILES_ACTIVE" to "prod",
    "BP_SPRING_CLOUD_BINDINGS_DISABLED" to "true",
    "BPE_APPEND_JAVA_TOOL_OPTIONS" to "-XX:+ExtensiveErrorReports",
    "BPE_DELIM_JAVA_TOOL_OPTIONS" to " ",
)

I still see the builder build a native image with liberika NIK

I'm not seeing that. The builder should include both the paketo-buildpacks/java and paketo-buildpacks/java-native-image so it should be capable of building a standard Java app as well as a Java native image app.
Also, paketobuildpacks/builder:base is the older Bionic base image set. It shouldn't be used anymore as Ubuntu Bionic is no longer supported by Canonical. The current builder is paketobuildpacks/builder-jammy-tiny. That's based on Jammy.

Check that your builder has both of those buildpacks. Run pack builder inspect <builder>.
Use the Jammy builder.
If that doesn't help, include your build log so I can see what is happening in the build.

Thanks

Okay it seems like it is dependent up on the MANIFEST.MF attribute Spring-Boot-Native-Processed = true not to any META-INF stuff. When dropping this from the jar, no native image is build, but then the app does not know it has to start as aot processed as well

Oh, I see. Yes, you're right. There were some changes not too far back to auto-detect when there's a Spring Boot app that is capable of being built with native image. I think the thought was that if you were doing this then you'd likely want to have a native image app image, so we defaulted to it.
A couple of thoughts:

I believe the intent was that you could opt-out of this by setting BP_NATIVE_IMAGE=false so it sounds like this is not working as it should.
I don't believe that we documented this new criteria to auto-detect Spring Boot native. As I look at the README, it doesn't mention this. We should get that updated too.

That said, I didn't make these changes so I'm going to defer to @anthonydahanne who introduced them. He would know best the intended behavior. Hopefully he can chime in soon on this issue.

Hello 👋!
Sorry for the late reply 🥲
If I understand correctly, this issue, which I could reproduce using the demo.zip from you @cmdjulian (thanks for the well formulated bug report btw 🙏) is only happening with the Spring Boot Gradle plugin.
With Spring Boot and Native Image buildpacks, we need to consider 4 scenarios possible:

Maven and Gradle Spring Boot plugins -> they each build the jar before calling the buildpacks; and
pack CLI with either Maven or Gradle source code -> the buildpacks are just given the source code; up to them to wire the Gradle or Maven buildpacks to build the jar

Let's look at each of them in detail

if you build a gradle project, which relies on the native plugin, with ./gradlew bootBuildImage no matter what you do with BP_NATIVE_IMAGE -> native build ❌

Like you discovered, the mere presence of manifest.Get("Spring-Boot-Native-Processed") will make the Spring Boot buildpack plans it's a native build.
Since the Spring Boot Gradle plugin automatically (because of the native plugin I believe) set BP_NATIVE_IMAGE to true, the Native Image buildpack will happily comply.
=> what are the ways to fix this?

either the Gradle Spring Boot plugin stop setting BP_NATIVE_IMAGE=true; the consequence being that... the users will need to set BP_NATIVE_IMAGE=true themselves... not ideal...

or the Spring Boot buildpack checks the BP_NATIVE_IMAGE variable before setting the plan to native, the issue being... that the Spring Boot buildpack becomes aware of non strictly Spring Boot things 😖 ... which we really avoid doing

if you build a maven project, which relies on the AOT plugin, with ./mvnw spring-boot:build-image but not the native profile -> no native ✅ BUT no AOT goodness either ❌

The Maven BOM has a native profile, that will, when activated, not only make sure AOT plugin is enabled, but also set BP_NATIVE_IMAGE=true.
Great for native; but if you just want AOT then probably the suer can set a profile, not named native that will enable the AOT plugin, without setting BP_NATIVE_IMAGE

if you use pack with gradle ✅

pack build test --env BP_JVM_VERSION=21  -B paketocommunity/builder-jammy-java-tiny

Well, the Gradle buildpack will gradle assemble which will do the AOT if you have the native-plugin in your gradle.kts
If you want native, of course, set --env BP_NATIVE_IMAGE=true

if you use pack with maven✅

pack build test --env BP_JVM_VERSION=21  -B paketocommunity/builder-jammy-java-tiny

Well, the Maven buildpack will mvn package which will do the AOT if you have the native-maven-plugin in your pom.xml and an execution configured:
			<plugin>
				<groupId>org.graalvm.buildtools</groupId>
				<artifactId>native-maven-plugin</artifactId>
			</plugin>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
				<executions>
					<execution>
						<id>process-aot</id>
						<goals>
							<goal>process-aot</goal>
						</goals>
					</execution>
				</executions>
                       </plugin>

If you want native, of course, set --env BP_NATIVE_IMAGE=true as well, or more simply, just set  BP_MAVEN_ADDITIONAL_BUILD_ARGUMENTS=-Pnative
Well, I did not expect to write such a long comment...
But I think this is where we are: native builds are very easy to get automatically, no matter how you build your app; AOT jars, not so much, because it was assumed the user must want native if they do AOT.
I will check with Spring boot team if it would be possible to have a specific profile, or signal, to hint the buildpacks what to do; because unless we start mixing concerns between the spring-boot and native-image BPs, I don't think there's a way to guess.

I've played a bit around with it and even if we remove setting the BP_NATIVE_IMAGE variable (https://github.com/spring-projects/spring-boot/issues/32884), things don't work for Gradle.
That's because when we detect that the NBT (native-build-tools) plugin is applied, we set the Spring-Boot-Native-Processed manifest entry. The Spring Boot buildpack acts on that and provides native-image-application, which the Native Image buildpack happily complies and then a native image is built.

Yes, thanks for raising it @mhalbritter I'm also facing the same issue. Are there any workarounds or solution for this with gradle? cc @anthonydahanne @dmikusa @cmdjulian


Add AssetManager

API | Common | Forge | Vanilla | Gradle | plugin-meta
This PR adds the AssetManager class to Sponge. It allows for easy retrieval of plugin resources as well as adds a assets plugin meta attribute to allow developers to declare a custom asset directory.
Signed-off-by: Walker Crouse<EMAIL_ADDRESS>

Wow, a six-repo pull request! Never seen that before :smile:

@JBYoshi you jinxed it :sad:

@kinggoesgaming It was merged :P


Improve article 1505.00444

Exact location of issue
Equation 3 of https://ar5iv.org/html/1505.00444#S2.E3
Problem details
The original LaTeX source code (generated by LyX) \left\Vert ... \right\Vert has been replaced by \left| ... \right| in the ar5iv version, which then displays only the "filler" ... between the | ... |.
Example:
None.
Expected behavior
The original LaTeX source code (generated by LyX) \left\Vert ... \right\Vert should generate || ... ||, which is a double vertical line at the left and right of the bracketed expression
Desktop (please complete the following information)

OS = MacOS
Browser = Safari

Thanks for the report @luttrell !
The PDF has equation 3 rendered as:

And ar5iv today has it as (on Firefox):

Is this good enough to close the issue?
Also, there is a separate fidelity problem in Chrome, where the parentheses are stretched out to be too large, which is pending a resolution in mathml-core#103.
But if the original problem is now remediated, we can close here.

I reported this several years ago, and I have only a vague recollection of the original details.
I do not recall exactly what was incorrectly rendered before, nor can I find it using a search based on the details in your email’s subject line, though the rendering quoted in your email looks correct to me.
Could you point me to whatever it was that I originally reported?
Stephen Luttrell
West Malvern, UK
@.***

On 18 Jan 2023, at 14:01, Deyan Ginev @.***> wrote:
Thanks for the report @luttrell https://github.com/luttrell !
The PDF has equation 3 rendered as:
https://user-images.githubusercontent.com/348975/213190474-30cf26a3-004a-4fcc-b511-ccc29a8ab55c.png
And ar5iv today has it as (on Firefox):
https://user-images.githubusercontent.com/348975/213190635-d8fb69a0-62cb-479a-becf-eab18717bc61.png
Is this good enough to close the issue?
Also, there is a separate fidelity problem in Chrome, where the parentheses are stretched out to be too large, which is pending a resolution in mathml-core#103 https://github.com/w3c/mathml-core/issues/103.
But if the original problem is now remediated, we can close here.
—
Reply to this email directly, view it on GitHub https://github.com/dginev/ar5iv/issues/20#issuecomment-1387121438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVWJMA6YUWYDNB6N6FSV7LWS7ZU3ANCNFSM5NI72ILA.
You are receiving this because you were mentioned.

Hi @luttrell ,
My apologies, this may be confusing if you are interacting with my comment via email. The original comment was written in Github's issue interface, which you can find here:
https://github.com/dginev/ar5iv/issues/20
The issue has a link to the original article, to your detailed remarks (thank you again!), and to a couple of screenshots I added for today's rendering of the specific equation in question.

Oh! That was only a year ago, but it seemed like much longer ago to me.
I drilled down to check the LaTeX in https://ar5iv.org/html/1505.00444#S2.E3 https://ar5iv.org/html/1505.00444#S2.E3 which is now \left| . . . \right|, and this renders the equation correctly.
The issue now appears to have been fixed. Thank you.
Stephen Luttrell
West Malvern, UK
@.***

On 18 Jan 2023, at 14:23, Deyan Ginev @.***> wrote:
Hi @luttrell https://github.com/luttrell ,
My apologies, this may be confusing if you are interacting with my comment via email. The original comment was written in Github's issue interface, which you can find here:
#20 https://github.com/dginev/ar5iv/issues/20
The issue has a link to the original article, to your detailed remarks (thank you again!), and to a couple of screenshots I added for today's rendering of the specific equation in question.
—
Reply to this email directly, view it on GitHub https://github.com/dginev/ar5iv/issues/20#issuecomment-1387156221, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVWJMHVG43FAZBOKTBFM6DWS74GPANCNFSM5NI72ILA.
You are receiving this because you were mentioned.

Great to hear, and thank you for the quick response!
Time flies around here too. You're always welcome to report more ar5iv issues when you encounter them, even if you just happen to remember by chance years from today.


TIP-19 Dust Protection Based on Byte Costs

This RFC describes a new dust protection mechanism that prevents bloating of the IOTA ledger database.
Rendered Version
The scripts for byte cost calculations can be found here.

Minimum state rent virtual byte counts are incorrect given that the calculations still work with uint16 for denoting the feature blocks slice length.

Currently the weight for the fields are arbitrarily set to 1.0 and 10.0. In the future these could become fractional values, so we should decide if we want to round min_deposit_of_output up or down and specify this in the RFC.
Rounding down has some advantages with regard to integer conversion.

Rendered Version

the link is changed to https://github.com/muXxer/protocol-rfcs/blob/master/tips/TIP-0019/tip-0019.md


Move Dolphin hook status to status bar.

It reduces the clutter in the GUI by saving several lines of vertical space in the main window.
Bonus: A state icon is now included for each of the four possible states, as well as the game ID of the emulated game when present.

Hmm... I know its traditional to have the status bar on the bottom, but would you consider having an option for the top? I may add it as an option under View.
Functionality tested and the spacing is nice, but there's just something with muscle memory with me wanting the bar up top like this mockup:

In the mockup, the status bar is in a place that is occupied by a label [that is only visible after the first search]: the one that shows number of matches.
I too noticed muscle memory was a thing, but to be fair it went away after just a few minutes.
One option we can consider (I'd love to see mockups) is moving it to the very right in the top menu's bar (at the very right of the Help menu). We might need to reverse the layout direction so that the icon stays at the corner.


find_unused_port needs to return the right value from getsockname() call

In:
    @staticmethod
    def _find_unused_port():
        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
            s.bind(("", 0))
            return s.getsockname()[0]

The tuple returned by getsockname() contains the following:
('<IP_ADDRESS>', 51200)
And so this function should be returning the second element rather than the first.

Good catch, this is fixed now.


Fully specified paths everywhere

To @girving : You missed adding fully qualified paths in a few places, so I finished the job (I hope).

Thanks!


The one time I forgot to use my vac bypass. My acc got vac banned :(

This leads me to believe that Osiris was detected once again.

i dont use vac bypass and my account isn't banned, just use a undetected injector and protected osiris

( Kittenpopo will not even give anyone the source code to help it stay undetected)

VAC doesn't need the source code of anything to make a signature out of it.
so even if this kitten guy/girl released his source code this wouldn't affect shit.
and yeah it's detected what do you expect from a public injector using Load library ?

loadlibrary is a meme for cheats


fix(CMakeLists): add options to select backend

Add options USE_FBDEV, USE_DRM, USE_SDL2 to CMakeLists.txt to select the backend. Also change lv_conf.h to make fbdev the optional default.
Add option USE_THOR to CMakeLists.txt so as to make using thorvg optional.  This way C++ is not required for building. Also change lv_conf.h to make building the internal ThorVG optional.
Mark lvgl as EXCLUDE_FROM_ALL in CMakeLists.txt so it does not get installed on the target when lv_port_linux is installed.
These changes are useful to enable including this package in buildroot (see issue #17).

Hi,
Please check here: https://github.com/lvgl/lv_port_linux/pull/51/files


when a node is both stretch and auto, get the result with width and height "null"

Report
when a node is both cross stretch and margin auto, get the result with width and height "null",i have read the source code and found the following code:
          if (alignItem == YGAlignStretch &&
              YGMarginLeadingValue(child, crossAxis)->unit != YGUnitAuto &&
              YGMarginTrailingValue(child, crossAxis)->unit != YGUnitAuto) {

can someone explain , since the alignItem is already stretch ,auto is meaningless, so why this code exclude the auto ?

It excludes auto, as if you have a margin of auto. The node should not stretch. Margin is "stronger" than align-item.

i write a node with "text" type ,since text has no width&height,so i set a custom measureFunction as:
 YogaNode root = new YogaNode();
 root.setWidth(500);
 root.setHeight(300);

        YogaNode text = new YogaNode();
        text.setMeasureFunction(new YogaMeasureFunction() {
            @Override
            public long measure(YogaNode node, float width, YogaMeasureMode widthMode, float height, YogaMeasureMode heightMode) {
                return new YogaMeasureOutput().make(50,50);
            }
        });
       text.setMarginAuto(YogaEdge.LEFT);
        root.addChildAt(text, 0);

when i run this code ,find the text node return "null" for both height and width, please find what's wrong with it ,thx

It should be a width and height of 50 and left 450 here. I'll reproduce and have a look.

thank you for the hint @Lizz0y , I pushed a fix for this in #645

thx @woehrl01  for fix this problem


ToCells (maybe) doesn't terminate

I'm attempting to polyfill a a 3º×3º box at res0. It doesn't look like this will ever terminate, even with new ContainmentMode::Covers. Here's reproduction code:
use geo::{geometry::GeometryCollection, polygon};
use h3o::{
    geom::{ContainmentMode, PolyfillConfig, Polygon, ToCells},
    CellIndex, Resolution,
};

fn main() {
    let geo_poly = polygon![
        (x: 156.0, y: 6.0),
        (x: 156.0, y: 3.0),
        (x: 159.0, y: 3.0),
        (x: 159.0, y: 6.0),
        (x: 156.0, y: 6.0),
    ];
    let geo_json =
        geojson::FeatureCollection::from(&GeometryCollection::from(vec![geo_poly.clone()]));
    println!("{geo_json}");

    let h3o_poly = Polygon::from_degrees(geo_poly).unwrap();

    let polyfill: Vec<CellIndex> = h3o_poly
        .to_cells(PolyfillConfig::new(Resolution::Zero).containment_mode(ContainmentMode::Covers))
        .collect();

    println!("{polyfill:?}");
}

And a geosjon of the polygon:
{"features":[{"geometry":{"coordinates":[[[156.0,6.0],[156.0,3.0],[159.0,3.0],[159.0,6.0],[156.0,6.0]]],"type":"Polygon"},"properties":{},"type":"Feature"}],"type":"FeatureCollection"}

I know I can workaround this by generating all res0 cells and geometry hit testing them against this rect, but this'll be unfeasible if the caller switches to a higher resolution.

Thanks for the report and the test case.
This trips a debug_assert in debug mode, I look into it.

Fixed in v0.5.1


validate_paths data prefix

If you haven't already, please read through our contributing guidelines before opening your PR
What is the purpose of this PR?
Closes #676.
How did you implement your changes
Check for data prefix first if specified and change default to data_prefix=False. The instances of validate_paths in the notebook use the default which now doesn't require ..\data.
Remaining issues
After this PR is merged I'll check throughout toffy for appropriate behavior using the False default.

Nope! The notebooks just use the default and all the ark functions have data_prefix=False.


RC Test: Masses and Springs 1.0.0-rc.3

@ariel-phet, @arouinfar, Masses And Springs 1.0.0-rc.3 is ready for RC testing. It is @ariel-phet suggestion to test on only a few core platforms and not all of our supported platforms.
Link to Sim
Link to iFrame
Test Matix
Issues to Verify: There are no outstanding issues to verify.
This is the third RC test for M&S. The main focus here is on view layout and alignments as there were refactors done for view components since the last RC test.
Please verify:
stringTest=double (all strings doubled)
stringTest=long (exceptionally long strings)
stringTest=X (short strings)
stringTest=rtl (right-to-left)
stringTest=xss (test passes if sim does not redirect, OK if sim crashes or fails to fully start)
showPointerAreas (touchArea=red, mouseArea=blue)
Full screen test
Screenshot test
If any new issues are found, please note them in https://github.com/phetsims/masses-and-springs/issues and reference this issue.
Tagging @ariel-phet for prioritization.

This isn't a build error. Master was merged into RC.3 and was up to date with the latest master. The bug for #290 was reintroduced via https://github.com/phetsims/masses-and-springs/commit/98951d448882c664d8a37849c69a382307ea4c65.

Since there've been a lot changes stemming from the recent RC cycles, I should probably do a detailed review of rc.3 to make sure everything's still looking good. Self-assigning.

QA is finished.  LOL won't open in OS 10.12 Safari as pointed out in phetsims/special-ops/issues/116.  However, this a problem with LOL and not the sim.

@Denz1994 I found a few small things, documented in the issues above. Everything else is looking great!
Thanks to @KatieWoe and the QA team for a speedy RC. :)


[PE-D][Tester D] [UG Bugs] Update more information about deletei command

The deletei command cannot be done, if there exists uncompleted orders for item.
Please update it in UG for readers.

Labels: severity.Medium type.DocumentationBug
original: myangat0343/ped#5

This can be addressed in the user guide that items with active orders cannot be deleted


chore: bump deps version

What is the goal of this change?
Bump deps version :sparkles:
Is there any issue related?
GitHub security alerts + dependabot PR to update deps versions.
How does the changes address the issue?
N/A

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@eca2051). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             master        #6   +/-   ##
==========================================
  Coverage          ?   100.00%
==========================================
  Files             ?         1
  Lines             ?         7
  Branches          ?         0
==========================================
  Hits              ?         7
  Misses            ?         0
  Partials          ?         0

Flag
Coverage Δ

#unittests
100.00% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

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


fft.tests.test_numpy.test_multiprocess hangs on Python3.8 on macOS

#11822 proposes to add macOS testing on a range of Pythons using Github actions. The 3.8 matrix entry kept hanging on fft.tests.test_numpy. I've since reproduced the error on my local machine. The specific test it's hanging on is fft.tests.test_numpy.test_multiprocess. If I comment out the test everything runs ok.
The reason it's probably failing is that the default context for multiprocessing on macOS for Python 3.8 is 'spawn', it used to be 'fork'.
('fork' is the default for linux, 'spawn' for macOS, 'spawn' for windows)
A check/fix needs to be done for why the test fails with a 'spawn' context.

@andyfaff maybe this?
https://bugs.python.org/issue38501

@larsoner possibly, I'm not sure.

The travisCI matrix has an Ubuntu+3.8 entry, and the test doesn't hang on that.

I tried changing the test code to:
@pytest.mark.parametrize("func", [fft.fft, fft.ifft, fft.rfft, fft.irfft])
def test_multiprocess(func):
    ctx = multiprocessing.get_context('fork')
    # Test that fft still works after fork (gh-10422)
    with ctx.Pool(2) as p:
        res = p.map(func, [np.ones(100) for _ in range(4)])

    expect = func(np.ones(100))
    for x in res:
        assert_allclose(x, expect)

The test run works if the context is 'fork', but not if it's 'spawn'

I hope the core devs are paying attention to that Python issue, its a real pain.

I was running those tests with the normal python runtests.py -s fft.
If I run the specific test from an interpreter then I have no issues. The test may need a knownfail.

@andyfaff does the test still fail  if you replace p.map(func, ...) with p.map(np.array, ...) or something similar. If this isn't the python issue then that should pass.

@peterbell10 it hangs on that as well. The test, as-is, passes in an interpreter.


Get Algolia working

Addresses #58.
Minimal Algolia config, which also gives us automatic nesting of search result headers under their parent pages.
Notes on styles:

Pre-existing styling logic doesn't apply cleanly to the new search component, and I got tired of trying to figure out Infima's intended usage (it's not very well-documented).
Instead, I just updated the search box background to our background color instead of the cool gray it was, and decreased the default border radius, since the oval shape wasn't matched anywhere else.

Would be nice for the future:

De-prioritize results from "Archive"
More intentionally style the search component

FYI @cdanwards I ended up removing a bunch of existing styles and mostly going with the default, but please suggest improvements if you'd like

@cdanwards I didn't have any ideas in particular, just wanted to make sure nothing important was removed!


feature: support Hightlight component

All Submissions:

[x] Have you followed the guidelines stated in CONTRIBUTING.md file?
[x] Have you checked to ensure there aren't any other open Pull Requests for the desired changed?

Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)

New Feature Submission:

[x] Does your submission pass the tests?
[x] Have you linted your code locally prior to submission?

Changes To Core Features:

[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your core changes, as applicable?
[x] Have you successfully ran tests with your changes locally?

After these steps, you're ready to open a pull request.
a. Give a descriptive title to your PR.

support Highlight component.
b. Describe your changes.
support Highlight component and you have to notice styles and style is different prop.  Highlight uses styles.
c. Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such).

close #1048

This code doesn't seem to be working for me can you provide an example?

import pynecone as pc

class State(pc.State):
    """The app state."""

    text: str = "With the Highlight component, you can spotlight, emphasize and accentuate words."
    query=['spotlight', 'emphasize', 'Accentuate']
    styles={ 'px': '2', 'py': '1', 'rounded': 'full', 'bg': 'teal.100' }

def index():
    """The main view."""
    return pc.heading(
        pc.highlight(State.text, query=State.query, styles=State.styles)
    )

app = pc.App(state=State)
app.add_page(index)
app.compile()

This code doesn't seem to be working for me can you provide an example?
Is this example working?

import pynecone as pc

class State(pc.State):
    """The app state."""

    text: str = "With the Highlight component, you can spotlight, emphasize and accentuate words."
    query=['spotlight', 'emphasize', 'Accentuate']
    styles={ 'px': '2', 'py': '1', 'rounded': 'full', 'bg': 'teal.100' }

def index():
    """The main view."""
    return pc.heading(
        pc.highlight(State.text, query=State.query, styles=State.styles)
    )

app = pc.App(state=State)
app.add_page(index)
app.compile()

I think the Highlight component should provide a default styles in case the user didn't provide it.

I think the Highlight component should provide a default styles in case the user didn't provide it.

Yes, you are right.

For this component should we take the stye props and pass them into the style dict similar to how it's done in code block. This would allow code like
class State(pc.State):
    """The app state."""

    text: str = "With the Highlight component, you can spotlight, emphasize and accentuate words."
    query=['spotlight', 'emphasize', 'Accentuate']
    styles={ 'px': '2', 'py': '1', 'rounded': 'full', 'bg': 'teal.100' }

    def add_query(self, query: str):
        """Add a query to the list of queries."""
        self.query.append(query)

def index():
    """The main view."""

    return pc.vstack(
        pc.input(on_blur=State.add_query),
        pc.heading(
            pc.highlight(
                State.text,
                query=State.query,
                bg = "green",
                color = "red",
                px = "2",
                py = "1",
                rounded = "full",

            )
        ),
    )

https://github.com/pynecone-io/pynecone/blob/e9ca1fd03b7d1c3caade682bd9f1f2dca10f268a/pynecone/components/datadisplay/code.py#L52-L75

It's working right now.

For this component should we take the stye props and pass them into the style dict similar to how it's done in code block. This would allow code like
class State(pc.State):
    """The app state."""

    text: str = "With the Highlight component, you can spotlight, emphasize and accentuate words."
    query=['spotlight', 'emphasize', 'Accentuate']
    styles={ 'px': '2', 'py': '1', 'rounded': 'full', 'bg': 'teal.100' }

    def add_query(self, query: str):
        """Add a query to the list of queries."""
        self.query.append(query)

def index():
    """The main view."""

    return pc.vstack(
        pc.input(on_blur=State.add_query),
        pc.heading(
            pc.highlight(
                State.text,
                query=State.query,
                bg = "green",
                color = "red",
                px = "2",
                py = "1",
                rounded = "full",

            )
        ),
    )

https://github.com/pynecone-io/pynecone/blob/e9ca1fd03b7d1c3caade682bd9f1f2dca10f268a/pynecone/components/datadisplay/code.py#L52-L75

It's working right now.


Update for Elm 0.19

The elm-community packages aren't updated for 0.19 yet, so I wasn't able to resolve all the compiler errors (and since I couldn't compile, I wasn't able to build the generated code), but I made as much progress as I could. Hope this is useful! :)

@xtian thank you so much for the PR! That's awesome that you did this! I am also going to rename the package to elm-graphql with the 0.19 migration, so I will have to make those changes in here as well.

@dillonkearns Got everything compiling, but there are test failures now. I can dig into them in a little bit.

@dillonkearns Got the tests passing and the generator building. This is ready for review :)
I had to move the generator code into a separate Elm application as the compiler was interpreting the port module Main code to be a part of the package and so throwing an error.

@dillonkearns You're very welcome! I'm a big fan of this library so I'm happy to help :)
This is back in a non-compiling state unfortunately since the package repo got reset. I'm going to wait and see if new versions get released before republishing my forks.
elm-community/json-extra was updated on the alpha repo so it should be released soon. I have a PR open for elm-community/string-extra but I don't know what the status of that project is.

Hey @xtian, I pulled down the code from this PR and was able to get things compiling and the tests passing locally. It looks like it causes a segfault on travis, though, any ideas why?
https://travis-ci.org/dillonkearns/elm-graphql/builds/419360559
https://github.com/dillonkearns/elm-graphql/compare/xtian-elm@0.19?expand=1
Also, I couldn't figure out how to either push commits to this branch directly or make a PR on this PR. Let me know if you have ideas on how to do that, or you could just make these small changes yourself if that's easier.
Also, a couple of things I wanted to discuss:

When I run npm run approve, I get some changes around the exposing for the modules. Is this something that elm-format is doing, or is this in the code generation? https://github.com/dillonkearns/elm-graphql/commit/761eb448e608b7beef2cd54c577f3f0a21510f9f
If it's elm-format doing it, then it's totally fine. If were generating it, I'd prefer to keep it simple (if there are no issues that I'm not considering) and just do module .... exposing (..) to avoid possible bugs.

Can we run the test suite for the generator project from the npm test task (and by extension in the Travis build)?

I'm making progress on the dillonkearns/graphqelm -> dillonkearns/elm-graphql rename (I just published @dillonkearns/elm-graphql, just need to do a little more testing). Then I'll have to do some of those find-and-replaces over to sort out the merge conflicts into this PR, I can take care of all of that. It was tedious but not too bad.
Thanks so much for your help!


Code Improvement : To allow user input than hardcoding

Update https://github.com/codinasion/program/blob/master/program/find-square-root-of-a-number/FindSquareRootOfANumber.cs to accept user input

Code Improvement : To allow user input than hardcoding
Originally posted by @brundabharadwaj in https://github.com/codinasion/program/pull/6845#pullrequestreview-1358007985

!assign


Huzzah32-ESP32 goes offline after connecting Waterproof DS18B20

Describe the bug
as title says, when i connect the Waterproof DS18B20 my feather does not report data and disconnects / reconnects / disconnects  etc from IO.   I have tried many different GPIO pins, check connections etc.
Arduino board
Huzzah32-ESP32 feather
To Reproduce
Steps to reproduce the behavior:

Go to 'Add component'
Click on 'Waterproof DS18B20.'
Pick almost any pin for it
See it disconnect from Adafruit IO

Expected behavior
WAS working for over a few weeks then stopped working and cannot get it to work again
Which components are connected to your device
Which components are set up on the WipperSnapper device page?
AHT20 on I2C and Waterproof DS18B20 on different pins that I have tried
Screenshots
n/a
Desktop (please complete the following information):

OS: Mac OS X
Browser Safari
Version 17.4.1

Additional context
the funny thing is..it worked originally for a few weeks then stopped working and now I cannot get it to work again... I tried A0, A1, A2, D12, D27... maybe a few other pins.  I can leave it connected to the board, just remove it from the configuration then it stays connected.  So I do not think it's an electrical problem.  Also I have erased and refreshed whippersnapper binary a few times... no good

@tyeth  Could you take a look at replicating this sometime this week?

Hey @mennamorato I've connected up what I believe is a similar setup, AHT20 on i2c (component added to device), and then added the DS18b20 (picked waterproof one but all the same), and used standard resolution (12bit) and pin A0 (D26).
Data appears to flow (at least the first data point) and not seen device reset yet.

My wiring has the DS18b20 and AHT20 powered from 3v pin. I have a 4.7k resistor between data and vcc pins of DS18b20, and the vcc pin is connected to 3v as mentioned rather than using parasitic power (and ground pin to ground).
If you haven't tried beta 82 via the IO web installer (new/upgrade device steps) then please do as it will erase your device fully along with installing the latest firmware.
I'll leave this running for a bit and check back tomorrow.

Hi and thanks well… this happened to me yesterday .. i had it working on my bench for a few hours then it started to disconnect / reconnect and now does not work - on that pin.  its like when i move the pin it starts working until it doesn’t…
my wiring is same as yours
i will try beta 82 today
thanks !
Mark

On May 16, 2024, at 8:32 AM, Tyeth Gundry @.***> wrote:
Hey @mennamorato https://github.com/mennamorato I've connected up what I believe is a similar setup, AHT20 on i2c (component added to device), and then added the DS18b20 (picked waterproof one but all the same), and used standard resolution (12bit) and pin A0 (D26).
Data appears to flow (at least the first data point) and not seen device reset yet.
image.png (view on web) https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/assets/6692083/d9efbbd7-eaa3-4d73-a628-e69d8a9fb648
image.png (view on web) https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/assets/6692083/f8d96f36-d736-4f90-9b1e-b8f1606546a7
image.png (view on web) https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/assets/6692083/42d2912d-a4da-4dda-a19d-c1b87e53a923
My wiring has the DS18b20 and AHT20 powered from 3v pin. I have a 4.7k resistor between data and vcc pins of DS18b20, and the vcc pin is connected to 3v as mentioned rather than using parasitic power (and ground pin to ground).
If you haven't tried beta 82 via the IO web installer (new/upgrade device steps) then please do as it will erase your device fully along with installing the latest firmware.
I'll leave this running for a bit and check back tomorrow.
—
Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/issues/586#issuecomment-2115560594, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJOFBSWKBMTWLIHFQCXR6TZCTGQFAVCNFSM6AAAAABHWWHPHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJVGU3DANJZGQ.
You are receiving this because you were mentioned.

I'm curious, how are you physically doing the interconnects? Are you using one of the white plastic breadboards, or are you hard-wiring the pins?
I've found the DS one-wire sensors are extremely picky about intermittent connections, such as if you're using a breadboard and the contacts in a row are slightly worn down.

white plastic breadboards…the Huzzah32 feather has headers installed then plugged into the breadboard BUT i have the waterproof sensor plugged into the header (female on top / male on bottom) right now. I did have it plugged into the breadboard which..could have been a connection intermittent issue? but would not expect the code to fail because of that i would expect no/bad data once in a while. the funny thing is..once it failed on pin A0 (for example) i could never get it to work on A0 again…if i kept moving it around (the data line that is) i would eventually find a pin for it to work
mark

On May 16, 2024, at 11:47 AM, T-Mosher @.***> wrote:
I'm curious, how are you physically doing the interconnects? Are you using one of the white plastic breadboards, or are you hard-wiring the pins?
I've found the DS one-wire sensors are extremely picky about intermittent connections, such as if you're using a breadboard and the contacts in a row are slightly worn down.
—
Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/issues/586#issuecomment-2115963129, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJOFBSRFJYG57QAQXFRYIDZCT5MVAVCNFSM6AAAAABHWWHPHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJVHE3DGMJSHE.
You are receiving this because you were mentioned.

the funny thing is..once it failed on pin A0 (for example) i could never get it to work on A0 again…if i kept moving it around (the data line that is) i would eventually find a pin for it to work
I've seen that behavior too, the drivers for the one-wire interfaces are not at all adaptable in real time. Any time I changed the wiring, I had to cycle the power and restart the code again.
Re: wiring. If you're using the bare part, then pushing the leads into the female header isn't recommended. You're relying on the lead diameter to match the size that the socket expects to receive.
If you're using the waterproof sensor, then it has stranded wire leads, and again pushing those into a socket isn't recommended either.
Adafruit's breadboards aren't the highest quality, and I've worn out several rows by pushing headers into them more than just a few times. Intermittents are very difficult to debug.

Ok cool....I ordered a different temp sensor (board) that is i2c.  I will
waterproof it myself with a thermally conductive electrically
non-conductive material and not use 1-wire which I never liked. Thanks for
the help.  Close this ticket.
On Thu, May 16, 2024, 12:16 PM T-Mosher @.***> wrote:

the funny thing is..once it failed on pin A0 (for example) i could never
get it to work on A0 again…if i kept moving it around (the data line that
is) i would eventually find a pin for it to work
I've seen that behavior too, the drivers for the one-wire interfaces are
not at all adaptable in real time. Any time I changed the wiring, I had to
cycle the power and restart the code again.
Re: wiring. If you're using the bare part, then pushing the leads into the
female header isn't recommended. You're relying on the lead diameter to
match the size that the socket expects to receive.
If you're using the waterproof sensor, then it has stranded wire leads,
and again pushing those into a socket isn't recommended either.
Adafruit's breadboards aren't the highest quality, and I've worn out
several rows by pushing headers into them more than just a few times.
Intermittents are very difficult to debug.
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/issues/586#issuecomment-2116009841,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJOFBQOF6GIUFAMHXHVONDZCUAXNAVCNFSM6AAAAABHWWHPHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJWGAYDSOBUGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks Mark. Good luck and let us know if you have any other problems...


tests: augment the malloc intercept

Add an optional count and symbol name to test_system::invalidate_malloc().
This will cause malloc to fail after the Nth call when the return
address is that of the given string. Note that this will not work
for inlined functions, irrespective of whether inlining is disabled.
Add fpgaOpen() test case that uses the functionality.

pesky tabs


Demonstrate PR 758 caused a regression

DO NOT MERGE
This PR contains the new test added in https://github.com/bblimke/webmock/pull/797 followed by reverse of #758. This demonstrates that the fix done in #758 caused the error I talked about in #797.
Let's keep the discussion in #797 so all comments are in one place ☺

Hmm seems like the Ruby 2.6.0 test matrix failure is also happening in master. Other specs do pass, though:

Ruby 2.3.8 and this PR is green: https://travis-ci.org/bblimke/webmock/jobs/474417154

Ruby 2.3.8 and only the new spec is red: https://travis-ci.org/bblimke/webmock/jobs/474411068


Ensure bucket upload methods return the blob.

Fixes #596.

Coverage remained the same at 100.0% when pulling d3bc6125b36c665894ab90db813a03dff9dfaac0 on tseaver:596-return_blob_from_bucket_upload_file_obj into 9518db72b4d0eefca887304d11e8fc37be17f514 on GoogleCloudPlatform:master.

@tseaver WDYT of having Blob.upload_* methods return nothing (Blob already around) and having the Bucket.upload_ methods return the new objects?

As an aside (outside of this PR), I feel like having a single upload() and a single download() method could be feasible / easy to use? This requires type / interface checking for the objects passed in.
We have (happily, for me) moved away from multi-type behavior for inputs, e.g. datastore.put(entity) fails and only a list is accepted, e.g. datastore.put([entity]).
Somehow I feel like this is slightly different since there is only one action (download) but 3 legitimate places to download to

bytes object (return value)
writable buffer (e.g. BytesIO or something attached to something other than the FS)
buffer pointed to the filesystem

As another aside (outside of this PR), shall we cut a release tomorrow?

Coverage remained the same at 100.0% when pulling dceabc61f65e5145f7fb4075c3cee6b80b0ee40a on tseaver:596-return_blob_from_bucket_upload_file_obj into 9518db72b4d0eefca887304d11e8fc37be17f514 on GoogleCloudPlatform:master.

dceabc6 drops the return self from the Blob.update_* methods.

I'm not sure that a single upload / download would be easier to use in practice, unless we just made the user pass / receive a file-like object everywhere.  E.g.:

    def upload(self, name, file_obj):
        """Upload a blob into this bucket.

        :type name: string
        :param name: name of the blob within the bucket.

        :type file_obj: readable file-like object
        :param blob: an object that can be read like a file.

        :rtype: :class:`Blob`
        :returns: The created / updated Blob object.
        """

    def download(self, name, file_obj):
        """Download a blob from this bucket

        :type name: string
        :param name: name of the blob within the bucket.

        :type file_obj: writeable file-like object
        :param blob: an object that can be written like a file.
        """

A release today seems like a good plan.  Is it just a matter of making a tag, or does somebody need to to PyPI stuff manually?

LGTM.

Yeah I think the single-use upload() / download() may be tricky to do right, but still want to give it a try. I was more curious if you thought it was too inconsistent to "forbid" multi-type signatures in one place and to actively seek them out here.

I will prepare the tag today. Our Travis config deals with PyPI for us, so no issues there. The only effort is put release notes in the tag (which will be copious here).


[Issue] Remove input "type" in Aspire Manifest

Today in Aspire, we say:
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }

The "type": "string" portion is unnecessary. We only support string inputs.
When trying to remove this property, and use azd init, I got an error:
ERROR: unsupported input type:

Can we remove this property from the manifest?
cc @ellismg @vhvb1989 @mitchdenny @davidfowl

Adding it to Preview 5.


Android - Workspace settings - Input fields are not grayed out when made changes offline

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the App and login
Click on Create a New Workspace
Navigate to the General settings page
Disable the internet connection
Change the workspace currency and name
Save the changes

Expected Result:
Input fields should be grayed out when saved changes offline
Actual Result:
Input fields are not grayed out when made changes offline
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
Email or phone of affected tester (no customers): any
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/188506121-f9de9e14-213a-49c5-a80e-b999c56ffe35.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

Not really a blocker. I think this is fine since we'll now allow updating the workspace name optimistically even when offline so this seems normal to me. cc @neil-marcellini as well since you made this change.
I tested on staging and it looks good to me as is.

I agree that this is not a blocker since it's just UI and doesn't prevent the user from using the App. I was also not able to reproduce this locally. Removing the blocker label.

Was cellular data turned off when "going offline"? The offline indicator did not appear. @kbecciv can you please try again and make sure that cellular data is off?

@neil-marcellini Checking with team, will update you shortly.

@luacmartins @neil-marcellini Not able reproduced with build <IP_ADDRESS>
https://user-images.githubusercontent.com/93399543/188639962-54d4c26e-5ede-4ca6-aef4-e824c4f55244.mp4

Cool, thanks for confirming! gonna close this issue!


Command failed with exit code 2 when having nock as dependency

So when I have nock as a dependency and run flow I get the following
node_modules/nock/node_modules/changelog/examples/node.json:2
  2: ==========
        ^^^ Unexpected token ===

Found 1 error
error Command failed with exit code 2.

If I remove nock, everything works fine.

Looks like they ship with a JSON file that has a syntax error in it. I recommend that you use flow-typed for this module, rather than having Flow try to do its best with what is in node_modules:
https://github.com/flowtype/flow-typed


New Control: Notification & Toast

Notification:

Toast:

Consider add a ScaleY animation to Closing animation, it looks way much better.

According to the demo, wo should expose a method for user to easily uninstall the managers.


Add check for Cypress tests that require license

Summary
Add check for Cypress tests that require license.

cy.hasLicenseForFeature to verify if it has license for a feature
cy.hasLicense to verify in general if server has license (e.g. for test that don't necessarily require a specific licensed feature)

PR for docs - https://github.com/mattermost/mattermost-developer-documentation/pull/552
Ticket Link
none

/update-branch


proposal: crypto/tls: make default minimum version for servers TLS 1.2

Resurrecting stage 2 of #45428, in light of Microsoft recently disabling support for 1.0 and 1.1 by default in Windows (see https://techcommunity.microsoft.com/t5/windows-it-pro-blog/tls-1-0-and-tls-1-1-soon-to-be-disabled-in-windows/ba-p/3887947).
Since #45428 was written SSL Pulse now shows that only <0.1% of surveyed servers only support TLS 1.1 or lower. Given the typically extremely cautious Microsoft seems happy to disable client support for 1.0 and 1.1 by default, it is perhaps reasonable to assume that the number of servers that actually require clients which support these version is rather miniscule.
Note the number of clients which still only support 1.0 or 1.1 is still non-zero though, and this proposal does not propose to completely remove support for these versions, simply not enable it by default. People who still want to support clients which only support 1.0 or 1.1 can still enable this support by setting the Config.MinimumVersion field.
Following the plan suggested in #45428, I propose we pre-announce that we will be changing the default Config.MinimumVersion for servers in 1.22, and in 1.23 we make the change.
cc @FiloSottile @golang/security

Generally speaking, I can't wait to turn off TLS 1.0 and 1.1.
However I want to point out that stage 2 of #45428 is about turning them off by default server side, so what matters are

numbers on how many clients only support TLS 1.0 and 1.1 and would break; and
examples of other servers that turned off TLS 1.0 and 1.1 support by default.

The Microsoft change is both client-side and server-side, but most Schannel users are client-side, and I can't figure out if it applies to e.g. IIS.
From SSL Pulse, the relevant number is not 0.1% servers supporting at most TLS 1.0 (that was relevant to turning off client-side support), but that 32.5% of sites still support TLS 1.1.
Is there anywhere we can get numbers on how many clients still negotiate TLS 1.0 or 1.1? Maybe Cloudflare?

The Microsoft change is both client-side and server-side, but most Schannel users are client-side, and I can't figure out if it applies to e.g. IIS.

I cannot find a specific reference now, but my memory from when I first looked into this was that it was implied this also affect all Microsoft server software shipped with Windows, as well as clients.

Is there anywhere we can get numbers on how many clients still negotiate TLS 1.0 or 1.1? Maybe Cloudflare?

Cloudflare data (assuming that the total includes TLS 1.0 and TLS 1.1 connections, but separated out on the graph) shows ~0.3% 1.0 and 1.1 connections. Internal Google metrics show a similar (ever so slightly lower) number for 1.0 and 1.1.
Given how small a population this appears to be, seems reasonable to disable by default.

Cloudflare data (assuming that the total includes TLS 1.0 and TLS 1.1 connections, but aren't separated out on the graph) shows ~0.3% 1.0 and 1.1 connections. Internal Google metrics show a similar (ever so slightly lower) number for 1.0 and 1.1.

~0.3% is very reassuring, let's do it.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Agreed on the accelerated timeline, I don't see any particularly significant benefit from delaying this (at this point already somewhat overdue) security win.

I agree that having the GODEBUG should mean that we can skip the preannouncement.

Sounds like the proposal is:
In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.1. A new GODEBUG tls11server=1 will re-enable TLS 1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls11server=0 (TLS 1.1 disabled). Older versions will continue to default to tls11server=1, with no change in behavior other than the new metrics counter recording their TLS 1.1 usage.
Do I have that right? In particular, I am assuming it is feasible in the TLS proposal to IncNonDefault only when a client chooses TLS 1.1, not just when the server offers it?

Yes, except it’s TLS 1.0, not TLS 1.1. (The latter is very similar to the former and rarely supported without also supporting TLS 1.2.)

Hmm. The fact that we're removing TLS 1.0 and 1.1 makes this a bit awkward for picking a GODEBUG name.
Should it be tls12server=1 (require 1.2) for the new behavior and tls12server=0 (do not require 1.2) for the old behavior?

I think TLS 1.1 is so insignificant that we can call it tls10server.

OK, so tls10server=1 will enable TLS 1.0/1.1, and tls10server=0 (the new default in a future Go release) will disable it.

Will Config.MinVersion = tls.VersionTLS10 still work?
I also wonder whether it would be better to make the GODEBUG differently, like tlsserverminversion=2, then in future it would be easier to make tls 1.3 the default min version. If we do it the tls10server=1 way, then it some future point there might be a need to add tls13server=1, with the tlsserverminversion, it will only require to bump the number without any new GODEBUG. What do you think?

Not letting GODEBUGs proliferate is appealing, especially as they start interacting in the future, but I still lean towards tls10server=1 because who knows if we will switch off TLS 1.2 for client and server separately, who knows how long from now that will be, and the value of tlsserverminversion is harder to understand. (Is 2 TLS 1.2, or step 2? Does 1 work? Does 3 already work?)

I agree with @FiloSottile. go.dev/doc/godebug talks about retiring entire GODEBUG keys, not just specific values, and the metrics about non-default behavior are also gathered per-key, not per-value.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.0/1.1. A new GODEBUG tls10server=1 will re-enable TLS 1.0/1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls10server=0 (TLS 1.0/1.1 disabled). Older versions will continue to default to tls10server=1, with no change in behavior other than the new metrics counter recording their TLS 1.0/1.1 usage.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.0/1.1. A new GODEBUG tls10server=1 will re-enable TLS 1.0/1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls10server=0 (TLS 1.0/1.1 disabled). Older versions will continue to default to tls10server=1, with no change in behavior other than the new metrics counter recording their TLS 1.0/1.1 usage.


Feature: discard modifications

Give user a choice whether the changes made in the volume should be discarded on unmount or be preserved for the following volume mount

Changed my mind. We will preserve modifications by default, and whenever a user wants to, they can discard modifications by removing the volume explicitly


Dependency type

Hi @Cartus
Thank you very much for your sharing. I would like to ask whether the dependency type information is used or whether only the edge between the nodes is considered and the specific edge type is not considered?

Hi @wt123u,
Yes. The edge type is not considered in this model. In this work, we only make use of the connection information (i.e. which two tokens are connected).
Other GNN models considered the edge types (N-ary Relation Extraction using Graph State LSTM, Song, et al 2018). What they did is basically concatenate the edge embedding to the node embedding during the information propagation process. You can check their code and paper.

Hi @Cartus
Thanks so much for your prompt reply. I will see Graph State LSTM soon.


litestar: 2.12.1 -> 2.13.0

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-reviewd workflow started
Status and logs: https://github.com/Bot-wxt1221/nixpkgs-reviewd/actions/runs/12493799137

nixpkgs-reviewd workflow finished
Status and logs: https://github.com/Bot-wxt1221/nixpkgs-reviewd/actions/runs/12493799137
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

x86_64-darwin

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

aarch64-darwin

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

x86_64-linux

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

nixpkgs-reviewd workflow started
Status and logs: https://github.com/Bot-wxt1221/nixpkgs-reviewd/actions/runs/12499736822

nixpkgs-reviewd workflow finished
Status and logs: https://github.com/Bot-wxt1221/nixpkgs-reviewd/actions/runs/12499736822
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

x86_64-darwin

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

aarch64-darwin

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 368121

x86_64-linux

:fast_forward: 2 packages marked as broken and skipped:

chatgpt-retrieval-plugin
chatgpt-retrieval-plugin.dist

:x: 2 packages failed to build:

python313Packages.weaviate-client
python313Packages.weaviate-client.dist

:white_check_mark: 12 packages built:

litestar
litestar.dist
python312Packages.litestar-htmx
python312Packages.litestar-htmx.dist
python312Packages.polyfactory
python312Packages.polyfactory.dist
python312Packages.weaviate-client
python312Packages.weaviate-client.dist
python313Packages.litestar-htmx
python313Packages.litestar-htmx.dist
python313Packages.polyfactory
python313Packages.polyfactory.dist

python313Packages.weaviate-client failed because of python3.13-authlib


Update Datastore Migration

Executes Postgres and Db2 migration CI workflow
Signed-off-by: Paul Bastide<EMAIL_ADDRESS>

The expanded test coverage looks good.
Now the concern is just the increased build time.  For example, from this last run:
Datastore Migration / migration (db2, previous) (pull_request) Successful in 48m
Datastore Migration / migration (db2, last) (pull_request) Successful in 48m

I saw that we're doing something with caching the db results, but I'm not sure if that is expected to improve this time or not in subsequent runs.

The expanded test coverage looks good.
Now the concern is just the increased build time. For example, from this last run:
Datastore Migration / migration (db2, previous) (pull_request) Successful in 48m
Datastore Migration / migration (db2, last) (pull_request) Successful in 48m

I saw that we're doing something with caching the db results, but I'm not sure if that is expected to improve this time or not in subsequent runs.

Yes - I'm trying to cache it and skip appropriately.

Fetched and merged... if passes, we will merge.


Option to unicode escape <, >, and & in JSON output

An option to unicode escape <, >, & as \u003c, \u003e, \u0026 "to keep some browsers from misinterpreting JSON output as HTML."
https://golang.org/src/encoding/json/encode.go?s=6456:6499#L48
This can be implemented as a middleware layer monkey-patching res.send as below, but it might be nicer to have in core.
const escapeJson = function (json) {
    if (typeof json !== 'string') {
	return json;
    }
    return json.replace(/</g, '\\u003c')
	       .replace(/>/g, '\\u003e')
	       .replace(/&/g, '\\u0026');
};

module.exports = function(req, res, next) {
    var _send = res.send;

    res.send = function (body) {
	if (res.get('Content-Type') === 'application/json') {
	    body = escapeJson(body);
	}
	_send.call(res, body);
    };

    next();
};

Hi @g-k I can certainly see the use-case this would serve. Would like to hear what others think as well, as I'm generally neutral on this right now.

I think it would be useful.

I do not think this is the responsibility of express.  The linked code specifically calls out escaping for use in an html script tag.  I think it is, and should remain, the developer who is inserting the json into the html's job to properly escape the content.
FWIW, I have two modules to for this, one for the server side escaping, and one for the client side unescaping, both using the underlying escape method from lodash:
https://github.com/wesleytodd/recursive-escape
https://github.com/wesleytodd/recursive-unescape

The issue is escaping JSON so it isn't misinterpreted as an HTML page when navigated to directly (for browsers that do mime type sniffing). For example, XSS from a JSON response like:
{"post_id":"81730c8682f1efa5","title":"<img src=x onerror=alert(1)>"}}

X-Content-Type-Options: nosniff should be set as a defense in depth measure too.
Using an escaping library and res.send with a string or buffer would work too, but I'd rather have a safe default that works with res.json and res.send called with an object.
I think the proposed change is a reasonable default or option for users to enable. Providing a hook for encoding (like node-restify formatters) is an option too.

Oh, that is a different context than I got from reading the comments in the go code, which just talked about embedding it in a script tag.  I still think doing it by default is a bad idea, but I could get onboard with an option to turn this escaping on.

Oh yeah, the script context thing is for the line and paragraph separators which express already does for JSONP: http://timelessrepo.com/json-isnt-a-javascript-subset
This does incur a small perf cost and some apps won't care or can guarantee they aren't consumed by older brower clients (e.g. for internal or mobile app apis), so I'd be in favor for having an option to enable this with it off by default.

Just for clarification, this use case is ONLY for browsers directly requesting the json asset and displaying it to a user, not for any ajax or programmatic use?
If the answer to the above is true, I really do think that this should be left to a third party library, as it is too niche of a use case, IMO, to receive built in support.  This could be as simple as:
var myJsonEscaper = require('my-json-escaper')

app.use(function (req, res) {
  res.json(myJsonEscaper({foo: '<bar>'}))
})

this use case is ONLY for browsers directly requesting the json asset and displaying it to a user, not for any ajax or programmatic use?

Yep, at least I can't think of any other use cases at the moment. If an attacker can get someone to visit their site they can programmatically redirect or window.open the JSON page for XSS. Or iframe it if the JSON endpoint is missing X-Frame-Options. There are a couple examples from the wild in: https://blog.qualys.com/securitylabs/2014/09/11/xss-vulnerability-shows-how-security-issues-can-creep-into-popular-software
In general, I'd rather have a safe default to enable than use middleware to monkey patch res.send or manually escape all JSON passed to res.json and res.send.
Escaping is a built-in option in rails and google considers it enough of a best practice to enable by default in the stdlib in go.

According to that post:

By referring to the methods provided in the article, I have confirmed that this vulnerability could be reproduced and exploited with IE8 (Exploited with IE8.0.6001.17184), IE7 and IE6. But I was unable to exploit the vulnerability with IE9 because the response page whose content type is application/json could not be rendered by IE 9.

As much as I totally agree we should have safe defaults, Microsoft dropped support for ie9 almost a year ago, so IMO setting a default behavior that would be a breaking change is not only a bad idea, but mostly pointless from a security perspective.  The real issue is that by escaping the data, something on the other end has to unescape it, thus this being a breaking change.

I'm fine with this being opt-in I'd just like to have the option available.
On Thu, May 4, 2017 at 2:37 PM, Wes Todd<EMAIL_ADDRESS>wrote:

According to that post:
By referring to the methods provided in the article, I have confirmed that
this vulnerability could be reproduced and exploited with IE8 (Exploited
with IE8.0.6001.17184), IE7 and IE6. But I was unable to exploit the
vulnerability with IE9 because the response page whose content type is
application/json could not be rendered by IE 9.
As much as I totally agree we should have safe defaults, Microsoft dropped
support for ie9 almost a year ago, so IMO setting a default behavior that
would be a breaking change is not only a bad idea, but mostly pointless
from a security perspective. The real issue is that by escaping the data,
something on the other end has to unescape it, thus this being a breaking
change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/expressjs/express/issues/3268#issuecomment-299316344,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN1LewTgZTjBxqnpEiibkRYZ2F2m6mhks5r2kUsgaJpZM4M03ea
.

Unless there is a strong objection, I'm proposing that this lands in the 4.16.0 release.

My only objection is that this has weak reasons for inclusion.  IE9 support is a non-reason for me, and I have never worked on, nor heard of an application, where non-developer users are encouraged to directly visit a url that serves a json body.  Also considering how easy it is for a third party library to solve this issue for the people who have it, I believe this is best left to the user space.

It loos like the discusion above has some confusion going on. This is strictly a to prevent a form of XSS attack. For example, the extra encoded chars do not require any extra unescaping on the cliebt side to work; it is just standard JSON escaping. An attacking website can include an iframe (or even a top level redirect) to a JSON endpoint due to no faut of yours. If it is then one of the web browsers who then in turn see the large number of angle brackets and decide that it should be displayed as HTML instead of as text, then whatever HTML was in that response will execute.
An example attack is a comment board where all comments are plain text. User can submit anything and you duefully properly insert it on your page to display. You can load these comments via AJAX over a JSON endpoint, though. Now a user posts a comment with a script tag which doesn't cause XSS because you accounted for properly encoding everything that displays it, but it was unfortunate for a user who visited a sute where the ad network was malicious and included an iframe tag to your comments JSON where they planted that comment. Cookies are send to the attacker.

Effectively this is an issue for all users of Express.

Ok, that is much more clear to me.  Thanks @dougwilson!  This explanation changes my whole position from above.  Do we plan on turning this on by default for 5.x?

Glad it helped :) ideally it could just be default in 4.x especially since it is transparent for all well behaved clients, but the size of the install base makes me iffy on that. We can always turn it on in a later 4.x if warranted or even yell (ugh) at users to make them either opt in or out, not sure. As for 5.x itself I didn't givr too much though besides to follow 4.x, but maybe it should default on in 5 even if it never does in 4.

Delivered as part of the 4.16 release, currently off by default.


feature/terra-testing-results-analysis

best way to run this:

# delete old log
rm state/vrs_anvil.log

# launch in background, send progress bars, etc to /dev/null
export SEQREPO_FD_CACHE_MAXSIZE=25 # 50, 100
nohup vrs_anvil annotate >/dev/null 2>&1  &

# monitor
htop
# or simply
ps -ef | grep annotate

# examine logs and metrics
ls -l state/

# Path to the cache directory, defaults to cache/ (relative to the root of the repository)
cache_directory: "cache/"

# Number of works to use for processing, defaults to 20
num_threads: 40

# Should we create new VCFs with annotations. FOR FUTURE USE
# annotate_vcfs: false

# where to store the state of the application, log files, etc.
state_directory: "state/"

# where to store temporary files, etc.
work_directory: "work/"

# max lines from a vcf file (optional)
#limit: 100000

# The local file paths or URLs to vcf files to be processed
vcf_files:
  - "/home/jupyter/vrs-python-testing/tests/fixtures/1kGP.chr1.1000.vcf"
  - "gs://fc-2ee2ca2a-a140-48a1-b793-e27badb7945d/high_coverage_3202_samples/1kGP_high_coverage_Illumina.chr1.filtered.SNV_INDEL_SV_phased_panel.vcf.gz"

# installation path
seqrepo_directory: "~/seqrepo/latest"

# normalize the VRS ids
normalize: false

# Control if cache is used
cache_enabled: false

# compute reference allele
compute_for_ref: false

Maintain run instuctions, add to documentation, and presentation

The feature/metakb is ready for review see manifest.metakb_directory
# Path to the cache directory, defaults to cache/ (relative to the root of the repository)
cache_directory: "cache/"

# Number of works to use for processing, defaults to 20
num_threads: 10

# Should we create new VCFs with annotations. FOR FUTURE USE
# annotate_vcfs: false

# where to store the state of the application, log files, etc.
state_directory: "state/"

# where to store temporary files, etc.
work_directory: "work/"

# max lines from a vcf file (optional)
limit: 100000

# The local file paths or URLs to vcf files to be processed
vcf_files:
  - "/home/jupyter/vrs-python-testing/tests/fixtures/1kGP.chr1.1000.vcf"
  - "gs://fc-2ee2ca2a-a140-48a1-b793-e27badb7945d/high_coverage_3202_samples/1kGP_high_coverage_Illumina.chr1.filtered.SNV_INDEL_SV_phased_panel.vcf.gz"

# installation path
seqrepo_directory: "~/seqrepo/latest"

# normalize the VRS ids
normalize: false

# Control if cache is used
cache_enabled: false

# compute reference allele
compute_for_ref: false

# required - where we can find CDM files
metakb_directory: "../tests/fixtures/metakb"

tests/fixtures/metakb$ gsutil cp gs://$WORKSPACE_BUCKET/metakb/*.* .
Copying gs://$WORKSPACE_BUCKET/metakb/civic_cdm_20240103.json...
Copying gs://$WORKSPACE_BUCKET/metakb/civic_cdm_20240103.json.zip...
Copying gs://$WORKSPACE_BUCKET/metakb/moa_cdm_20240103.json...
Copying gs://$WORKSPACE_BUCKET/metakb/moa_cdm_20240103.json.zip...
- [4 files][ 19.7 MiB/ 19.7 MiB]
Operation completed over 4 objects/19.7 MiB.```

$ cat manifest.yaml
# Path to the cache directory, defaults to cache/ (relative to the root of the repository)
cache_directory: "cache/"

# Number of works to use for processing, defaults to 20
num_threads: 10

# Should we create new VCFs with annotations. FOR FUTURE USE
# annotate_vcfs: false

# where to store the state of the application, log files, etc.
state_directory: "state/"

# where to store temporary files, etc.
work_directory: "work/"

# max lines from a vcf file (optional)
#limit: 100000

# The local file paths or URLs to vcf files to be processed
vcf_files:
  - "/home/jupyter/vrs-python-testing/tests/fixtures/1kGP.chr1.1000.vcf"
  - "gs://fc-2ee2ca2a-a140-48a1-b793-e27badb7945d/high_coverage_3202_samples/1kGP_high_coverage_Illumina.chr1.filtered.SNV_INDEL_SV_phased_panel.vcf.gz"

# installation path
seqrepo_directory: "~/seqrepo/latest"

# normalize the VRS ids
normalize: false

# Control if cache is used
cache_enabled: false

# compute reference allele
compute_for_ref: false

# required - where we can find CDM files
metakb_directory: "../tests/fixtures/metakb"


Password

I put I password on it but could access the video or anything it didn’t even show a place to put my user and password on the site not sure if I did something wrong please help

First restore normal operation by running the install.sh script again setting user to a blank field.
Which Web server are you using? Apache is the one I do most testing on. It is possible that if you are using a different one then something has changed in how that handles authorisation.

i redid it still not showing up to use a password

I have just done a test on a clean install of Bullseye I first ran install.sh with no user/password, tested OK. Then I reran install.sh with a user/password.. I restarted my browser to make sure it was starting clean then accessed the camera and got a sign in form that needed me to enter user/password to get normal access. That worked fine.
Are you getting any errors when you run the install.sh script? There should be some lines in there saying adding password for user and then updating password.

I removed the cam sub folder that worked I think the sub folder was not working i got it to work :)


Fix ogre 1.x tests

Signed-off-by: Ian Chen<EMAIL_ADDRESS>🦟 Bug fix
Summary
homebrew builds are now running ogre 1.x tests in ign-rendering6, and there are currently a few test failures.
This PR fixes the failing tests.
Checklist

[x] Signed all commits for DCO
[ ] Added tests
[ ] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] codecheck passed (See contributing)
[ ] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge

homebrew build is now :heavy_check_mark:


Confirm Save, MultiDeletion, Text visibility

Adds in mass deletion as well as saving warnings before exiting the current annotation
Fixes #65
Prompts the user to save if they attempt to go to Data (router transfer) or if they decide to close or exit the tab.  There are two different styles because the exiting one relies on browser level dialogs.  I could switch the router one to utilize a similar browser dialog instead of our nicer vuetify one if desired.

Added in a universal visibility toggle for the type list.  That way all types can be turned on/off or shown to be in an intermediate state.  I think future we may want to add something like that for the Tracklist.  Specifically in the tracklist the ability to turn all other tracks off except the current one.
Fixes #350
Adds in deletion for multiple tracks based on checked state in the typelist as well as the track list.  A user is able to delete the visible items and is prompted with a dialog which will confirm the items they are about to delete.  The prompt needed to be changed to support string arrays as well to better handle multi-line text passed to the prompt.  Additionally the removeTrack function was changed to handle arrays of trackIds instead of a single trackId.

Fixes #230  - Added a new option to toggle text visibility on and off per that issue.  I also made the buttons a bit smaller.  They seemed to be fairly large for the number of items that are up at the top bar.  We were using EditAnnotationTypes for the all instances where we wanted the visibility to be displayed.  Initially I justed added a 'text' to all locations, but it makes more sense I believe to have a separate VisbileAnnotationTypes for items that may be calculated or visible but can't be edited.  There may be more of these types in the future.  So that new type was added and implemented.

@subdavis  - The router guard for the vue-router needs to be attached to the view which is now ViewerLoader.vue.  But in order to function needs access to the pendingSaveCount.  There are a few of ways this could be done and I would like your opinion on going forward with this:

Using Template Refs to directly access the data in the component (This is nasty in the composition API plugin and not the same as Vue3 so would require modification on migration).  Also obviously the refs referencing will break the automatic TS and require that we implement it manually.
We could use an emit to try to keep pendingSaveCount in the ViewerLoader in sync.  Just make sure that ViewerLoader knows that there is unsaved data that is referenced.  This doesn't give it access to the save() function required to automatically save the data during route changes.
We could remove the internal router guard for right now, although I like having it there because like I said I've been caught a couple times not saving stuff.
There is probably a more elegant solution I'm not thinking of that you may know which is probably the best option.


[Gally]: master <- dev

Automatically created by Git-Ally

:tada: This PR is included in version 2.10.24 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


HikariConfig#setInitializationFailTimeout javadoc seems wrong.

Environment
HikariCP version: 2.7.8

Problem description
If I understand the behavior correctly, there is an error in the javadoc for HikariConfig.setInitializationFailTimeout(); more specifically, the section describing behavior for negative timeout value:
A value less than zero will not bypass any connection attempt and
validation during startup, and therefore the pool will start immediately.  The
pool will continue to try to obtain connections in the background. This can mean
that callers to {@code DataSource#getConnection()} may encounter exceptions.

It is my understanding that if timeout is less than zero connection initialization and validation during startup will be bypassed, so the not part should be removed.

You are correct.  Will fix.

👍