Survival function for Cox Time Varying model

I've written a method for getting the survival function until timestep $t$ where $0<t<\tau$. It will not show $S(t)$ for all the way to time of failure $\tau$, as you do not know the covariates at that moment. Adding this function supports with calculation of $\int_0^t S(t)$, needed for determining the optimal replacement time.

Neat, thanks @rvdinter! Are you comfortable writing a test for this too? If so, it would go in test_estimation.py under the TestCoxTimeVaryingFitter class.

@CamDavidsonPilon definitely! I will work on it.

@CamDavidsonPilon just added the tests, let me know if I need to change anything!

@CamDavidsonPilon could you review the PR?


forceOriginalQueryStringEncoding should be true by default

Having upgraded from spring-cloud-netflix-core:1.3.0.RELEASE to spring-cloud-netflix-zuul:2.1.0.M3, I found a regression issue where a query parameter query=%2Btest (that's a URL encoded +) was getting decoded to a + in SimpleHostRoutingFilter, and hence, the target service was receiving a space instead of the intended +.  After several hours of debugging, I found the flag forceOriginalQueryStringEncoding, which is also documented here. However, the flag is set to false by default, which means the URL encoding is going to be invariably messed up unless I set it to true. This seems backward to me, since there's no reason for Zuul to not preserve the URL encoding, as its purpose in life is to forward the request to the target service. The decision to set this obscure flag to false by default is causing hard-to-find bugs in places least expected.
Please consider setting forceOriginalQueryStringEncoding to true by default, or otherwise explain in the docs why that's not a good idea.

@spencergibb I couldn't find a tag for RC2 (the latest is Greenwich.M1) on GitHub, but ZuulProperties.forceOriginalQueryStringEncoding is still false. Why do you think upgrading will fix this issue, unless, of course, the flag has been flipped and I can't find the code.

Need to fix that erroneous tag. 2.1.0.RC3 is the latest.


replace filesystem access with writable fs.FS

This replaces lots of different fs.FS and implementations at various levels with a single "Full FS", i.e. an fs.FS implementation for full read-write capability, plus handling things that some filesystems might not, like chmod, chown, mknod, etc.
There are 2 implementations of it. One is memfs, the other is based on a disk directory.
The disk one keeps a copy of all of the files and directories - but not the contents - in memory, which means that once you exit the program, the contents of the FS cannot be recreated fully. However, we pretty much delete all of these things right away anyways, so that should be fine. An alternative implementation could be plugged in, one that would use "special files" on disk to store that information.
The important parts here are:

we no longer put everything in memory when merging filesystems
we no longer create different filesystems and then merge them; instead, it is all done in a single FS
BuildImage returns that filesystem, which, in turn, can be used at any point. We no longer have to make a tarball layer in order to get at all of the additional information, which should help solve this PR
This all is a lot cleaner; we just work with an FS like it is a normal fully-powered Linux filesystem as root, even if we are not

The build is failing when trying to build wolfi-base. Here is why it is failing, but I am not sure how to fix it. Two packages are trying to modify /lib64: one is trying to make it a symlink to /lib, the other is trying to make it a directory.
The build file is (simplified):
contents:
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
  repositories:
    - https://packages.wolfi.dev/os
  packages:
    - ca-certificates-bundle
    - wolfi-base

I went through those packages as follows:

download the index https://packages.wolfi.dev/os/x86_64/APKINDEX.tar.gz
Look at the dependencies of each package, eventually building a dependency tree
Look at the contents of each

ca-certificates-bundle does not affect that dir or have any dependencies.
The relevant dependency treeis:
wolfi-base
    apk-tools
        so:libc.so.6 (provided by glibc)
            wolfi-baselayout

wolfi-base -> apk-tools -> glibc -> wolfi-baselayout
glibc includes the following in its apk file (simplified):
drwxr-xr-x  0 root   root        0 Jan  1  1970 lib64

wolfi-baselayout includes the following:
drwxr-xr-x  0 root   root        0 Jan  1  1970 lib
lrwxrwxrwx  0 root   root        0 Jan  1  1970 lib64 -> lib

This causes the failure. By the time glibc installs, it tries to mkdir /lib64, but it fails because a symlink already exists. It wouldn't help if it ran in the other direction either.
In theory, we could have it do, "if I try to mkdir, and it already exists as symlink to a directory, then treat it like it already succeeded," but that is messy. I wonder if we got something wrong with the conflict between glibc and wolfi-base/wolfi-baselayout, or conversely if I just misunderstood how to resolve these.
@kaniini or @jdolitsky any ideas?

this is intentional: LSB requires the stupid lib64 directory, but we don't want it.  but every build system on the planet wants to use it.
wolfi-baselayout installs first, and creates the symlink, and apk-tools just follows the symlink.  it is an intentional feature of apk that we can do this :)

Hopefully this will catch it. If it encounters a need to install a directory, and that target name already is a symlink pointing to a directory, it will accept it.
I had to implement all sorts of symlink resolution stuff, because the underlying memfs does not, but it looks good.


sh make.sh cffi version mismatch

when I tried sh make.sh,
it showed that there is a version mismatch of cffi
However, as I tried to pip install cffi==1.5.2
it is not supported anymore.
Is the real reason for the error really because the version of cffi==1.11.5 isn't suitable for this implementation,
or maybe there are other problems that i forget

this is my error log

[
error.txt
](url)

pip install cffi==1.6 works for me.

wait...by looking at your error.txt...
It seems you have two cffi in your system and it causes this problem.

Yes, I used a virtualenv to create a cleaner environment
But I did activate it
Could it be the problem of virtualenv?

Do you faced with the problem?
cffi.ffiplatform.VerificationError: CompileError: command 'x86_64-linux-gnu-gcc' failed with exit status 1

@irislin1006 One quick fix should be upgrading your system cffi to match with some pip's cffi. For example, apt-get python-cffi to 1.7 and pip again should work.

@FrankYoungchen Is that python3?


S390 support for k8s storage performance tool.

Problem Description:
The storage performance tool is not running successfully on S390 cluster.
This came up while working on this customer issue.
Reproducibility: Consistent
Type of Environment: Pre-existing and/or Embed
S390
Steps to reproduce:

Install the per-requisites as mentioned here https://github.com/IBM/k8s-storage-perf
Run the playbook
Tool is timed out for S390 clusters

Actual result:

Expected result:
Tool should be successful.
Additional info or Screenshots: (log files, diagnostics, system/env information etc, use the tool mentioned below)
For questions pertaining to this template, please contact<EMAIL_ADDRESS>or<EMAIL_ADDRESS>
Information on assigning Severity: here
Information on Cluster Serviceability & Troubleshooting tool: here
Diagnostics and logs files for all pods can be fetched by: ./icp4d_tools.sh --collect=smart
Also, here is the logs from the failed pods.

A stop-gap recommendation received directly from this tool owners is to use dd command instead; sample command and expected output to meet the acceptable storage perf criteria below:
Disk latency test
dd if=/dev/zero of=/PVC_mount_path/testfile bs=4096 count=1000 oflag=dsync

The value must be comparable to or better than: 2.5 MB/s.
Disk throughput test
dd if=/dev/zero of=/PVC_mount_path/testfile bs=1G count=1 oflag=dsync

The value must be comparable to or better than: 209 MB/s.

Thanks for the feedback. Will look into adding the dd command as an alternative for running the performance tests.


DataTable: openable rows

New feature to <DataTable />: openable rows.

refactors DataTable element structure a bit
adds renderOpenRow prop

the style for the opened row content is completely customisable

keeps internal state about opened row
can be controlled by setting openRowId prop

Could add openRowIdprop in the future to make it controlled.

example of opened row:

example of opened row with sections:

I think the opened looks visually too much like the column headers and section separators. I think it would make sense to add some inner shadow to the opened row content to make it appear like it's deeper in than the normal rows. I.e. the opened row content is something that's revealed underneath the table when two rows are pulled apart and those two rows cast a shadow to the content which is deeper in.

It's confusing that we now have DataTable with collapsibility feature and also CollapsibleDataTable. I know the collapsibility of those is different, but it's nevertheless confusing to anyone who doesn't know. Would it make sense to implement the CollapsibleDataTable case into DataTable as well?

I think it would make sense if you could have multiple rows open at the same time. For example, in the Specials page's table, we would render some analytics graphs in the opened row, and the user would want to compare the graphs of multiple rows.

I didn't consider this, but is a very good point. I will make it openRowIds instead!

I think the opened row content is visually difficult to distinguish from the table header and table section headers.

Would it make sense to add some inner shadow to the opened row content to make it appear like it's deeper in than the normal rows? I.e. in terms of skeuomorphism, the opened row content is something that's revealed underneath the table when two rows are pulled apart and those two rows cast a shadow to the content which is deeper in.

The content of the opened row is completely customisable by the renderOpenRow, DataTable doesn't define even the bg color. I would keep it this way, because it is more flexible than the solution you suggested. If, in the future, we see a pattern that repeats again and again, we could consider adding it as a default style or something.

It's confusing that we now have DataTable with collapsibility feature and also CollapsibleDataTable. I know the collapsibility of those is different, but it's nevertheless confusing to anyone who doesn't know. Would it make sense to implement the CollapsibleDataTable case into DataTable as well?

Yeah, it is a bit confusing, but not a big problem. It would be super hard to integrate those two, so I would rather not. A better name could be invented for CollapsibleDataTable, however...

👍

Fixes done


Can't Manage extension settings

I've installed Code Cracker as an extension for Visual Studio 2015, but there appears to be no way to manage which diagnostics are on and what levels they are on at. I've found the analyzers node of References in solution explorer. While I can make changes there they don't seem to save as the new set the next time I open the solution or project. Even if they did, this is installed for my entire VS2015, so I'd like to manage it at that level rather than have to make changes to every project I open.

You can do it in VS. See this comment: https://github.com/code-cracker/code-cracker/issues/47#issuecomment-63705397

The link provides a way to set it per project, meaning for every project I open I have to go set the ruleset.

You can share the ruleset file with all the projects. Just move it to the root folder where the solution lives. This is what we are doing at CodeCracker, check the repo.


Add --allow-unpinned-python

In some cases we might want everything else to be pinned to exact versions for reproducibility, but allow the python version itself to be more flexible such as using different python version on CI and developer machines.
I've tested this with:
  - repo: https://github.com/lacop11/pre-commit-pin-dependencies
    rev: 8d360e3388f8e8c9c3838aa5a9ca96e2ee37317e
    hooks:
      - id: poetry-dependencies-pinned
        args: [--allow-unpinned-python]

Also bumped allowed python version from <3.12 to <3.13, it works fine with 3.12 but the constrained prevented me from running it on CI with new python.

I like the idea introduced in this PR. If you have a usecase for this, I'm happy to merge this. However, I'd be interested if we could take this slightly further and maybe introduce a flag --allow-unpinned="<field>" which allows unpinning an arbitary number of dependencies. e.g.
- repo: https://github.com/Harry-Lees/pre-commit-pin-dependencies
  rev: PLACEHOLDER
  hooks:
    - id: poetry-dependencies-pinned
      args:
        - "--allow-unpinned=python"
        - "--allow-unpinned=pandas"

Thanks for the quick response!
I wasn't sure if you would want to have it customizable so I kept it simple. But I agree that --allow-unpinned=dependency is better, updated! Please take another look.

Hey @Harry-Lees , gentle ping -- Can you please take a look at the updated version, and also #6? Thanks!
Would like to get those merged so I could switch CI configs from the fork back to your upstream repo :)


setup: bump invenio-records-rest

@MJedr I am using poetry in the docker container. It should be the correct version.


How we can test daemons?

I have a very simple container with nginx which serves static content. I want to verify that nginx starts with proper virtual host configuration and returns index.html with all headers properly set. Since this PR is merged
With https://github.com/GoogleCloudPlatform/container-structure-test/pull/43 merged entrypoint is empty and my nginx is not started. I was trying to start nginx as a daemon or as a detached process but I can't see how to do it. Seems like all processes started in setup stage are killed?
With this code I see that no nginx is running
- name: "nginx is running and returns index.html page"
  setup: [["apk", "--no-cache", "add", "curl"], ["nginx"]]
  command: "ps"
  args: ["aux"]
  expectedOutput: ["nginx"]

Test result:
    --- FAIL: TestAll/Command_Test:_nginx_is_running_and_returns_index.html_page (3.90s)
        docker_driver.go:85: stdout: PID   USER     TIME   COMMAND
                    1 root       0:00 ps aux
        utils.go:33: Expected string 'nginx' not found in output!

I also tried to run nginx not as daemon but detached ["nginx", "-g", "daemon off", "&"] - test result is the same. If I run nginx in foreground with ["nginx", "-g", "daemon off", "&"] then setup commands is hanging. I think you should fix logic of the setup command to allow it spawn daemons, detached processes or maybe don't wait for it to finish before running main command (for foreground commands).

After thinking about this issue again I believe you should revert #43.  Basically, you change SUT when you override entrypoint - this is just conceptually wrong. Probably you can leave this option to override entrypoint but it should be opt-in, i.e. people can use it if their container are not testable otherwise but I think the general approach should be that people should change their container to make them testable. Like with unit testing for source code, instead of trying to mock dependency somewhere in private property of the class using reflection people should move dependency to the constructor.

I think your case is close to https://github.com/GoogleCloudPlatform/container-structure-test/issues/53#issuecomment-361767823 and you are trying to do integration and not structure test.

@zemanlx Well, from classical point of view it is and integration test. However, if we think about container as a unit then it is more like a unit test. I want to call class method, class here is container and method is that responds on the exposed port.
But it doesn't matter in the end.  We need some generic solution to test application installed inside container.  Before I discovered this project I used https://github.com/sstephenson/bats but it requires me to build a test images based on SUT image with bats installed. Also, tests written in bash aren't that readable that's why I'm very happy with this new tool.

I'm building an image for my project [blockchain2graph]https://github.com/straumat/blockchain2graph) and I need to start a neo4j server in my docker image. I would like to do a neo4j status to check if my deamon is running. From what I understand here, it seems your tool is not made for that ?
Is there a tool I should use to complete your tool or will you add this feature later ? Thanks

Hey @dzavalkinolx, thanks for filing. As @zemanlx mentioned, I would say that what you're trying to do is more in the domain of integration rather than structure tests. However, I understand your use case and am currently trying to figure out how to support it.
I think the main issue here is I want the UX for more "integration" style tests to be more explicit, so I'm working out the best way to do that. I think for now I'll keep #43 in, and maybe work on supporting an option to specify an entrypoint for an image in the the yaml.
That said, I think I know why you're seeing the issue here. The Setup command runs commands and then commits their modified image to be the new base image for the test run, so things like running daemons get ignored. Having a specified entrypoint for the container should fix this.

I know this is quite an old issue... but just wanted to share that we managed to do an "integration test" on a node server by doing the following, which I'd think would work for any daemon process:
commandTests:
  - name: 'server starts'
    command: 'bash'
    args:
      - '-c'
      - |
         /app/src/app > /home/node/output 2>&1 &
         sleep 1
         kill ${pidof node}
         cat /home/node/output
    expectedOutput:
      - '.*Started server on port.*'

It works by:

Running the app as a daemon with the output piped to a local file.
Waiting enough time for the background app to run
Killing the app
Reading out the contents of the logfile to stdout


False Positive Style/RedundantSelf when overriding accessor locally

Expected behavior
No warning.
Actual behavior
TLDR: Ruby predefines a reference for var1 when doing var1 = "" if self.var1 so var1 = "" if var1 will evaluate to nil when it comes down to parse/exec time, and since it's a complex accessor, using @var1 is unacceptable.
Rubocop throws a warning Style/RedundantSelf when using complex accessors, with locals of the same name, claiming that the self is redundant, when infact it's not, you cannot use @var1 because self.var1 is complex, and you cannot use var1 because it's been set locally, and Ruby will predefine a reference to var1. The same way it will predefine references later, unless you enter into a separate context, then you have to explicitly define it, this is getting pedantic though.
Steps to reproduce the problem
class MyClass
  attr_writer :var1
  attr_writer :var2

  def initialize(var1: nil, var2: nil)
    @var1 = var1
    @var2 = var2
  end

  def var1
    @var1 ||= begin
      # Complex
      # NilClass
    end
  end

  def var2
    @var2 ||= begin
      # Complex
      # NilClass
    end
  end

  def inspect
    var1 = "blah #{self.var1}" if self.var1
    var2 = "blah #{self.var2}" if self.var2
    "#<#{self.class.name}#{var1}#{var2}"
  end
end

RuboCop version
0.52.1 (using Parser <IP_ADDRESS>, running on ruby 2.5.0 x86_64-darwin17)

I don't actually know if this is still a problem, or if it is... I've not noticed it anymore, this can probably be closed, I'll comment or open another issue if it arises again, but it's not been a problem since that day so I assume this is pretty stale and doesn't really matter tbqf.
@bbatsov

Thanks @envygeeks! 🙇


allow the definition of annotation tasks on subsets of datasets

https://materialdesignicons.com/icon/package-variant-closed
https://materialdesignicons.com/icon/package-variant


Maybe there are some memory on GPU could be freed while start the training

I do not know why, but It need remarkable less memory if I start the trainning with a checkpoint.

How much difference do you experience?

I'm training a model with 8 layers and residue connection, It need 7000+M to build a new model and train it, but 6303M to train from a checkpoint. @guillaumekln

Why is it closed? Did you solve it somehow?

I use part of the code to get another script which build a model and save it, then use train.lua to retrain the saved model. For small model, just train is ok, for big model, this two step will make the job done, and I do not think this is a big problem. @guillaumekln


Why refresh the detail page every single time?

Steps to procedure:

Open the plugin details page and browse some introduction about configurations
Open the configuration file and write/copy some configs
Return to the plugin detail page and hope to continue browsing.

What did I expect to happen:
Don't refresh the page when users just switch back into the extension tab.

Duplicate of #36310


[crate] Make Model Connection as newtype u64

Feature Summary
part: https://github.com/cosmos/ibc-rs/issues/537

Proposal

Similar to channels, modelling connections with a u64 would needlessly restrict the possible connection identifiers. Closing for similar reasons

👌


Waypoint proxy can not enforce Authorization policy source.ipBlocks

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
Given the following Authorization Policy:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: accesspolicy-ratings-9080-ratin-572d748716e55114a4a47e8e657a131
  namespace: bookinfo
spec:
  rules:
  - from:
    - source:
        ipBlocks:
        - <IP_ADDRESS>
        principals:
        - cluster.local/ns/bookinfo/sa/bookinfo-productpage
    to:
    - operation:
        paths:
        - /ratings*
        ports:
        - "9080"
  selector:
    matchLabels:
      istio.io/gateway-name: bookinfo-ratings

That goes through a waypoint for the bookinfo-ratings service, the waypoint always denies any request here because of the sourceIP requirement here. Envoy sees the sourceIP as envoy://internal_client_address/ rather than the actual source pod IP, most likely because of HBONE.
debug	envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:114	checking request: requestedServerName: , sourceIP: envoy://internal_client_address/, directRemoteIP: envoy://internal_client_address/, remoteIP: envoy://internal_client_address/,localAddress: <IP_ADDRESS>:9080, ssl: none, headers: ':authority', 'ratings:9080'
':path', '/ratings/1'
':method', 'GET'
':scheme', 'http'
'user-agent', 'curl/7.83.1-DEV'
'accept', '*/*'
'x-forwarded-proto', 'http'
'x-request-id', 'ff12312f-2d78-47e6-861c-c640722f0ed6'
, dynamicMetadata: 	thread=28
2023-09-13T19:56:14.324057Z	debug	envoy rbac external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:158	enforced denied, matched policy none	thread=28
2023-09-13T19:56:14.324067Z	debug	envoy http external/envoy/source/common/http/filter_manager.cc:953	[Tags: "ConnectionId":"129","StreamId":"9101893357070198794"] Preparing local reply with details rbac_access_denied_matched_policy[none]	thread=28
2023-09-13T19:56:14.324084Z	debug	envoy http external/envoy/source/common/http/filter_manager.cc:995	[Tags: "ConnectionId":"129","StreamId":"9101893357070198794"] Executing sending local reply.	thread=28

If I were to remove the sourceIP requirement from the AuthorizationPolicy, the request goes through.
Version
`master`

Additional Information
No response

It has not been implemented, @keithmattix is working on supporting it with TargetRef

Hmm I'm not sure if targetRef fixes this. Because of the internal listener redirection we do for CONNECT, the source IP gets obfuscated to the point where policy doesn't seem to be working

Because of the internal listener redirection we do for CONNECT, the source IP gets obfuscated to the point where policy doesn't seem to be working

That's my take on it too. I'm not familiar enough with the details of how we implemented this to know if we're able to save those details but aren't using them yet or they're actually lost.

I think we can forge source address, we already forge destination address in the internal listener.

Would sandwich help here?  @kyessenov i think you did some prototype on it before?

It was left unimplemented and easy to fix. More important is to design a solution that doesn't require source IP spoofing from ztunnel. That hurts performance because tunnels cannot be shared.


connectivity: improve handling existing cilium-test namespace

The original reason for opening #115 was that I noticed an issue with cilium connectivity check.
When cilium-test namespace exists, srcDeploymentNeeded remains false and the deploy function returns without doing anything else.
https://github.com/cilium/cilium-cli/blob/dff492aeee540d72c27ebc819d3ad522382e6b60/connectivity/check.go#L827-L969
Getting #115 done maybe be a little more involved than I hoped, so a simpler fixes will be needed.

@errordeveloper So you need the ability for the namespace to exist but not the deployments inside?

@tgraf exactly :)

The use-case I have right is for OpenShift, where use of hostNetwork: true is gated by SecurityContextConstraints.
So one alternatively would be to add platform-specific initialisation logic in the connectivity check, which I thought was said to be undesirable. I could take a look and see if a PSP can be used instead of SecurityContextConstraints, in my understanding the API serve the same purpose, if we could use a PSP, we could add it for all platforms.

It sounds like PSP wouldn't be an option for OpenShift.


Let user import css instead

Is your feature request related to a problem? Please describe.
I was hoping to test this out on nextjs but sadly it throws the error:
./node_modules/video.js/dist/video-js.css
Global CSS cannot be imported from within node_modules.
Read more: https://err.sh/next.js/css-npm
Location: node_modules/videojs-react-enhanced/dist/index.es.js

Describe the solution you'd like
In nextjs any global css must be loaded in _app.js so removing the video-js.css import would let me do so.

Thank you for reporting an issue for this library!
I see your point. I will remove the import of css in library, and let users import it themselves. It seems there isn't any reason to do it inside the library, and it will support better compatibility for use case like yours(Next.js).
+) Also will modify sample usage code on documentation
Reference

Next.js Error: CSS Imported by a Dependency
Video.js example with Next.js


[ci:component:github.com/gardener/autoscaler:v1.22.2->v1.23.1]

Release Notes:
Bug stopping autoscaler to run because of architecture incompatibility is fixed

/close
in favor of https://github.com/gardener/gardener/pull/6428


FIX SSViewer::add_themes() to properly prepend

Fixes #7369

Removed a stray newline 😁

OK - I'm happy, but I'll leave merging so others have a chance to review


skill: Add reasoning skill about siblings

This skill was inspired by one of the tests included in mt-bench. It included some questions that the model answered incorrectly. When given the same question manually, I got the following incorrect answer:

Q: David has three sisters. Each of them has one brother. How many
brothers does David have?
A: David has three sisters, and each of them has one brother, so it
must be the same brother in all cases. Therefore, David has 1 brother.

If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

...
...
...

Input given at the prompt

   ...

Response from the original model

  ...

Response from the fine-tuned model

  ...

Contribution checklist

[ ] The contribution was tested with ilab generate
[ ] No errors or warnings were produced by ilab generate
[ ] All commits are signed off (DCO)
[ ] The qna.yaml file contains at least 5 seed_examples
[ ] The qna.yaml file was linted and prettified (yaml-validator can do both)
[ ] An attribution.txt file in the same folder as the qna.yaml file.

@instruct-lab-bot help

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

@instructlab-bot precheck

You can fix this PR with git rebase -i upstream/main and set the commands to:
drop 1966cef feat(synthetic data): Add script to generate synthetic data readme (#650)
pick ad41a8c skill: Add reasoning skill about siblings

Then when you have a merge conflict, you'll want to change it from:
<<<<<<< HEAD
# InstructLab 🐶 Taxonomy

=======
# InstructLab 🥼 Taxonomy
>>>>>>> ad41a8c (skill: Add reasoning skill about siblings)

to:
``
InstructLab 🐶 Taxonomy


Use a more relevant floating point number comparator algorithm

Summary
http://floating-point-gui.de/errors/comparison/ describes a better way of comparing floating point numbers, Double and Float comparators each have a complexCloseEnough method that implements it but they are not yet used.
Let's introduce DoubleComparator or FloatComparator constructors without parameters to follow the new algorithm but keep epsilon with DoubleComparator(epsilon) or FloatComparator(epsilon) in that case we use the existing algorithm assuming users want to set the comparison precision themselves.
Last point is adding tests as in http://floating-point-gui.de/errors/NearlyEqualsTest.java.
Note that this is a breaking change (a small one thought)
Java 8 specific ?

NO  : create Pull Request from the 2.x branch

:+1:
What do you think about doing #637 (another small breaking change related to floating point numbers) in the same release?

already done in d251f2c22ee6aecfb1cf9d81066e0247dc34e47b   :flushed:

Well the algorithm does not work for x, y, epsilon where x=0 and y=epsilon which is a bit too unexpected IMO.
Guava fuzzyCompare may be an option but it is not transitive and then not suitable for use in Object.equals(java.lang.Object) implementations according to Guava authors.
At this point I'm not sure if there is any possible good enough default implementation and it might really be that the only option is to let users come with their own implementation.

I'm closing this issue because there is no obvious solution to compare floats or doubles, this is not an easy topic and if such an algorithm existed it would have implemented already.
Although  http://floating-point-gui.de/errors/comparison/ propose an interesting algorithm, it is not simple for users to decide how to set epsilon.
As a conclusion we leave users implement the float/double comparator algorithm that suits best their own use cases.

I have kept my exploration in better-real-numbers-comparators in case of we want to follow up on the topic.


feat: Add patch property to device configs

Updated device configuration type def to include the patch property for overriding capability presentation values.
https://smartthings.developer.samsung.com/docs/api-ref/st-api.html#operation/createDeviceConfiguration

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


People Tracking Image not Show

Hi  I am using ubuntu 14.04 ,VoxelSDK 0.6.3 and OPT8241 and have run people tracking which shows below output
Who Can help me

Are you running a virtual machine?  If so please try without VM.
-Larry
Sent from my iPhone

On Oct 25, 2016, at 4:30 AM, city0601<EMAIL_ADDRESS>wrote:
Hi I am using ubuntu 14.04 ,VoxelSDK 0.6.3 and OPT8241 and have run people tracking which shows below output
Who Can help me
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi Larry
OK,I will try it .
Thanks.

Hi Larray
Thanks,The issue is close
thank you so much


fix: DefinedRouteCollector.php to use RouteCollectionInterface

Use RouteCollectorInterface rather than RouteCollector to allow for people implementing new RouteCollectors by implementing the interface as intended.
Currently this would generate type errors.
Referenced in <#8204>
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[ ] Unit testing, with >80% coverage
[ ] User guide updated
[ ] Conforms to style guide

If the core team agrees, it would be possible to fix the interface in 4.5 branch.
I personally am in favor of fixing it.
But we do not accept a interface change in develop branch.
See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/workflow.md#if-you-sent-to-the-wrong-branch

How about adding a new interface in 4.5 instead, then using that for the parameter? Slightly less breakage, and as long as the class implements both interfaces (or maybe the new one extends the old?) it shouldn't affect 99% of devs.

I sent another PR  #8911


VSCode ignores display language when opening a new window from within VSCode

VSCode Version: 1.31.0, bb1e228e30ce43ebb361c84fdf2f0d4fb7fda6ce
OS Version: Linux 4.20.3, Solus

Steps to Reproduce:

Display language is set in VSCode to german.
Launch a new window of VSCode from that application with CTRL+SHIFT+N or the menu. A VSCode window shows up with the display language set to english instead of german.

Does this issue occur when all extensions are disabled?: Yes
If this is a Solus Linux related issue that only happens in their OSS package of VSCode, please let me know.

When you call Configure Display Language from the command palette the following json file opens. It tells you to restart VS Code.
{
	// Defines VSCode's display language.
	// See https://go.microsoft.com/fwlink/?LinkId=761051 for a list of supported languages.
	// Changing the value requires to restart VSCode.
	"locale":"en"
}

Did you restart? Your instructions don't say so.

/needsMoreInfo

Yes, I know that. I have that locale configured a long time to german and my VSCode is in german (so yes when I did that I restarted it back then). I just observed that with new update, when I open a new VSCode window within my "german" VSCode 1.31.0 the display language is english instead of my configured language.

I tried to reproduce this with updating to 1.31.1 but was not able to do so. @L0g4n I understand you problem as follows:

after an update to 1.31.0 your display language was English

Is this still the case for you?

@dbaeumer
With Update 1.31.1 i no longer have this problem. So basically it was either an upstream or a downstream issue.


Web: provide a workbench.web.api.d.ts for an embedder to develop against

We provide an API surface for an embedder of our web UI:
https://github.com/microsoft/vscode/blob/7a83e5aa6278d27120c26dabe2b59642dcad9cf2/src/vs/workbench/workbench.web.api.ts#L238-L238
We also require some specific setup to load our web UI pieces as indicated by our yarn web implementation:
https://github.com/microsoft/vscode/blob/c87c95a1a04b01107328fe1987b1865b2eb367a8/src/vs/code/browser/workbench/workbench.html#L42-L42
We should:

investigate to produce a workbench.web.api.d.ts (similar to monaco.d.ts) for the workbench.web.api for an embedder to develop against
consider to extract the loader configuration into something reusable (amdconfig.js?) that an embedder can just point to

Loader piece is done will defer the .d.ts to a later date

I suggest not automatically generating it, and instead have the web api .d.ts checked into VS Code and with manually duplicated types.
The reason is that we have dependency on code and typings for embedders, but it is very easy for team members to not realize that code they're working is exposed in this API and depended upon by the embedder. This may result in breakages, especially if it's something as easy and innocent as an automated refactor for a property rename. Causing a compilation error unless the web .d.ts is manually and explicitly updated would reduce the likelihood of accidental breakages.

I think there are 2 camps: vscode.d.ts is handcrafted but monaco.d.ts for example is not and both have API users.

I suggest not automatically generating the .d.ts, and instead have the web api .d.ts checked into VS Code and with manually duplicated types.

+💯. Creating those types manually is IMO the only way to guarantee awareness of changes in API and to "design" the API explicitly. That's also the different between vscode.d.ts and monaco.d.ts - the latter is a slightly cherry-picked but mostly AS-IS representation of the "internal" API.

I am fine handpicking the API for embedder but I wonder how we could validate the correctness of the API then: we need to ensure we implement the API also in the workbench to get type failures early. In other words, we cannot just hand craft a d.ts file and not validate it with our actual code. I think vscode.d.ts does that.

Yeah, we explicitly implement the API in src/vs/workbench/api/common/extHost.api.impl.ts, we define a type which is of the vscode-module here: https://github.com/microsoft/vscode/blob/527d63162ad6b43a5e106e93ed05c3a299bda947/src/vs/workbench/api/common/extHost.api.impl.ts#L1138

@joaomoreno pointed out this tool which maybe could help: https://api-extractor.com/

@bpasero i'm interested in this, any progress?

I tried using api-extractor by using the new typescript 5.6.0 noCheck option to compile a separate folder of .d.ts for the src folder in hopes stripping out the code causing the error and just using the types would help. But after i did that i ran into a new error Child declaration not found for the specified node, it was happening on pretty much any import from vs/.
Then I tried using https://github.com/timocov/dts-bundle-generator and it worked a charm, I created:
declarations/package.json:
{
  "name": "declaration",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "overrides": {},
  "dependencies": {
    "dts-bundle-generator": "^9.5.1",
    "typescript": "5.6.0-dev.20240723"
  },
  "resolutions": {
    "**/typescript": "5.6.0-dev.20240723"
  },
  "scripts": {
    "build": "dts-bundle-generator -o workbench.d.ts --project tsconfig.json ../src/vs/workbench/browser/web.api.ts"
  }
}

declarations/tsconfig.json:
{
	"compilerOptions": {
		"moduleResolution": "node",
		"baseUrl": "../src",
		"paths": {
			"vs/*": ["../src/vs/*"]
		},
		"target": "es2022",
		"skipLibCheck": true,
		"noCheck": true,
		"lib": ["ES2022", "DOM", "DOM.Iterable", "WebWorker.ImportScripts"]
	},
	"include": [
		"../src/vs/**/*.ts",
		"vscode-dts/vscode.proposed.*.d.ts",
		"vscode-dts/vscode.d.ts"
	]
}

and then run yarn build and i get a nicely compiled workbench.d.ts

Cool, can you attach the resulting file here? Curious how it compares to the one we manually craft.

Btw when I try I get an error:
~/Development/Microsoft/vscode/declarations> yarn build
yarn run v1.22.22
$ dts-bundle-generator -o workbench.d.ts --project tsconfig.json ../src/vs/workbench/browser/web.api.ts
Compiling input files...
error TS5023: Unknown compiler option 'noCheck'.

Error: Error while processing tsconfig compiler options
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
~/Development/Microsoft/vscode/declarations>


client_lb_end2end_test: add OrcaLoadReport into EchoRequest proto

I hate making giant PRs so here's one first small chunk for the load reporter work.

Not exactly sure why yet this isn't building correctly in some cases.

for iOS test failure
/Volumes/BuildData/tmpfs/altsrc/github/grpc/workspace_objc_macos_opt_native/test/cpp/ios/Pods/Headers/Private/RemoteTestCpp/src/proto/grpc/testing/echo_messages.pb.h:34:10: fatal error: 'src/proto/grpc/testing/xds/v3/orca_load_report.pb.h' file not found
#include "src/proto/grpc/testing/xds/v3/orca_load_report.pb.h"

looks like you need to also add the orca_load_report proto to
https://github.com/grpc/grpc/blob/b92f8857569bd78ddd071e883db5edc94ecd594b/test/cpp/ios/RemoteTestClientCpp/RemoteTestCpp.podspec#L36

@dennycd: isn't it what I've done in https://github.com/grpc/grpc/pull/29505/commits/391f3608a0687fdf9447c6eef03e2f830ed6ae2a ?

Ah, I see. It looks like we didn't pick up the generated proto header which is in a subdirectory. @nicolasnoble  can you try
https://github.com/grpc/grpc/blob/2d4f3c56001cd1e1f85734b2f7c5ce5f2797c38a/test/cpp/ios/RemoteTestClientCpp/RemoteTestCpp.podspec#L17
  s.source_files = "src/proto/grpc/testing/**/*.pb.{h,cc}"

I think the original podspec just assumed all generated source are directly under src/proto/grpc/testing. ;  )

Oooh, I see. Yep, trying this now. Thanks!

Alright, at this point all the tests are passing properly, and the copybara test is just getting confused about the internal import state. A manual cherry pick seems to confirm internal tests are okay too. Merging this one.


Implemented POSIX path to support Mkdocs v1.4.0 in Windows

Implemented POSIX path to support Mkdocs v1.4.0 and above under Windows.
See https://www.mkdocs.org/about/release-notes/#replace-filesrc_path-to-not-deal-with-backslashes-2930
Fixed a broken link in README.md

Looks great, thanks for fixing this!


[9.0-preview3] WorksWithOpenTelemetryTracing tests disabled after update to preview 3

Both WorksWithOpenTelemetryTracing tests in Redis had to be disabled given they started to hit the following issue when updating transitive dependencies to preview 3:
Microsoft.DotNet.RemoteExecutor.RemoteExecutionException : Exit code was -532462766 but it should have been 42

Is this still disabled?


Theme

It would be nice to separate the styles, i.e. create a default style (minimal appearance) and a separate "theme" file that changes the appearance of the input field and ul, something like highlightjs-themes

I think I made my decision rashly;)
I will set the basic styles so that the plugin displays well.
Get rid of:

box-shadow
border-radius for input and ul
shadow on focus fo input
...

Cleaning styles #88


Fixes Interactive errors with the profile 2017-03-09-profile-preview

Interactive mode will skip over imports that aren't supposed to be loaded for profiling

fixes #3467
This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[x] The PR has modified HISTORY.rst with an appropriate description of the change (see Modifying change log).

Command Guidelines

[x] Each command and parameter has a meaningful description.
[x] Each new command has a test.

(see Authoring Command Modules)

Codecov Report

Merging #3587 into master will decrease coverage by 0.02%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3587      +/-   ##
==========================================
- Coverage   71.53%   71.51%   -0.03%
==========================================
  Files         420      420
  Lines       26138    26147       +9
  Branches     3958     3959       +1
==========================================
  Hits        18698    18698
- Misses       6278     6287       +9
  Partials     1162     1162

Impacted Files
Coverage Δ

...azure-cli-interactive/azclishell/_dump_commands.py
17.3% <0%> (-1.64%)
:arrow_down:

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 18153e6...1ac6764. Read the comment docs.

@derekbekoe can you take another look?


Terminator terminal

Big fan of Terminator, if anyone is interested (and it's interesting for the project mantainers), I can do a PR to provide support for this.

@mjswensen Hey! Got a few hours to kill this weekend, would love to revisit this one

Sounds great, @kinduff ! I recently added a CONTRIBUTING.md file with some docs and shell scripts that hopefully make the process of setting up a new template package quicker/easier. Fee free to reach out with any questions, too.


analysis: taxonomy is dropped after BIOM processing

While analysing closed-ref BIOM, taxonomy information gets dropped from the file after each step (e.g. after rarefaction). As a result, it's impossible to generate taxa-summary on any processed/filtered BIOM.
It's a QIIME2 problem, but can be easily fixed on the Qiita side.

Fixed here: https://github.com/qiita-spots/qp-qiime2/pull/19


Questions about segment fetch behaviour which may return 404

I've been asked by our content infrastructure team to provide some insight on Shaka's behaviour when fetching segments for a live stream. They tell me that they're seeing an unusual number of requests which return 404, under the following circumstances:

Content is being requested by the client that is in the future (content does not exist on the origin server yet)
Content is being requested by the client that is in the past and outside of the availability window (this is why I was asking about #999)
Content is being requested that is in between two valid segments (content that does not align with segment boundaries defined in the manifest)

At the moment I don't have a reproducible test case, or network logs showing the requests. As our investigation progresses I may be able to provide this. I'm hoping you can provide some insight into whether Shaka could or would make any of the above requests for segments.
We're also following up with ExoPlayer, since the issue is seen with DASH content generally. Let me know if I can provide any more information. Thanks!

Content is being requested by the client that is in the future (content does not exist on the origin server yet)

Some DASH manifests can specify all future segments, so we don't have to wait for a manifest update to know the times and URLs for the media segments.  This means that we could request a segment before the server generated it.  This can happen if there are clock sync problems or if the server is slowing down.
This shouldn't cause a problem since we will wait a few seconds and retry the request.

Content is being requested by the client that is in the past and outside of the availability window (this is why I was asking about #999)

This can be caused by encoder drift or clock sync issues where we choose an incorrect start time.  Those may be fixed by #999.

Content is being requested that is in between two valid segments (content that does not align with segment boundaries defined in the manifest)

This is definitely a bug, I don't even know how this could happen.  If you have a repro, please file a bug for this.

Thanks for the info. Regarding (3), we have an open ticket internally which alleges that you can reproduce the problem in VOD (or perhaps restarted live content) by doing a lot of scrubbing. The ticket was filed by one of our client architects who believes this is the cause of cache misses at the CDN. I've never reproduced this myself.

@chrisfillmore, have we answered your question?  Is there anything else we can do for you on this?

Thanks @joeyparrish, I think I have the answers I need. I'll reopen if I have to follow up again.