Adapt the Ouroboros Praos implementation to Isabelle2022

This resolves #20.

It seems a bit strange to me that such changes should be necessary. In the past, I had an experience where many of my simplifier invocations broke after an Isabelle update. The problem was, if I remember correctly, that the most fundamental theory of my development (probably Transition_Systems-Foundations) imported Eisbach before Main. This can lead to problems with configurations, like the one of the simplifier. As you perhaps know, some things in Isabelle are designed with linear processing of code in mind, which creates issues when a theory imports several other theories: in particular, configurations have to be merged and in some cases this leads to suboptimal results.
The bottom line back then was that you should never import certain low-level theories of Isabelle/HOL without having imported Main first: Main is the official entry point for any Isabelle/HOL development. If you don’t respect this rule, you might face breakage in some versions in Isabelle, which you might not see in others. I’m not completely sure about the details, though; I guess the rule is that all theories of the HOL session that come before Main as well as some other sessions like Eisbach shouldn’t be imported directly, while you can rely on the HOL sessions that come after Main and the sessions of, for example, HOL-Library taking care to import Main first.
The theory Ouroboros_Praos_Implementation doesn’t explicitly import Main. I checked the chain of theories imported first and found that it is Ouroboros_Praos_Implementation → Finite_Map_Extras → Finite_Map → FSet → Main; so Main actually is imported first (except if you have a different local version of Finite_Map_Extras perhaps; I’m a bit puzzled about you being able to import it without qualifying with a session name). Therefore, it seems that not importing Main first isn’t the problem here.

At the moment, the theory Ouroboros_Praos_Implementation is not mentioned in the ROOT file. If I add it and run make qnd afterwards, I get the following error messages:
*** Cannot load theory file "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Finite_Map_Extras.thy"
*** The error(s) above occurred for theory "Ouroboros.Finite_Map_Extras"
*** (required by "Ouroboros.Ouroboros_Praos_Implementation") (line 5 of "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Ouroboros_Praos_Implementation.thy")
*** Cannot load theory "HOL-Library.BNF_Corec"
*** The error(s) above occurred for theory "HOL-Library.BNF_Corec"
*** (required by "Ouroboros.Ouroboros_Praos_Implementation") (line 6 of "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Ouroboros_Praos_Implementation.thy")
*** Cannot load theory "HOL-Library.Sublist"
*** The error(s) above occurred for theory "HOL-Library.Sublist"
*** (required by "Ouroboros.Ouroboros_Praos_Implementation") (line 7 of "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Ouroboros_Praos_Implementation.thy")
*** Cannot load theory "Chi_Calculus.Typed_Basic_Transition_System"
*** The error(s) above occurred for theory "Chi_Calculus.Typed_Basic_Transition_System"
*** (required by "Ouroboros.Ouroboros_Praos_Implementation") (line 8 of "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Ouroboros_Praos_Implementation.thy")
*** Cannot load theory file "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Finite_Map_Extras.thy"
*** Bad import of theory "HOL-Library.BNF_Corec": need to include sessions "HOL-Library" in ROOT
*** Bad import of theory "HOL-Library.Sublist": need to include sessions "HOL-Library" in ROOT
*** Bad import of theory "Chi_Calculus.Typed_Basic_Transition_System": need to include sessions "Chi_Calculus" in ROOT
*** No such file: "/home/wolfgang/Dokumente/Beruf/IOG/ouroboros-high-assurance/src/Finite_Map_Extras.thy"
*** No such file: "HOL-Library.BNF_Corec"
*** No such file: "HOL-Library.Sublist"
*** No such file: "Chi_Calculus.Typed_Basic_Transition_System"

I guess this has partly to do with lack of porting to the Þ-calculus and partly with some more additions to the ROOT file missing. I’ll accept this pull request nevertheless, but we must fix these issues.


[BUG] use wrapt success in .py, but failed in .pyd

from wrapt import decorator

@decorator
def d1(wrapped, instance, args, kwargs):
    print(f'd1: {args}, {kwargs}')
    return wrapped(*args, **kwargs)

def d2(*argsT, **kwargsT):
    @decorator
    def d3(wrapped, instance, args, kwargs):
        print(f'd3: {argsT}, {kwargsT}, {args}, {kwargs}')
        return wrapped(*args, **kwargs)
    return d3

@d1
@d2(a=int, b=str)
def hello():
    print('hello')

Save above code as hello.py, use another module, import hello and call hello.hello(), all success.
import Cython.Build
import distutils.core

def py2c(file):
    cpy = Cython.Build.cythonize(file)
    distutils.core.setup(
	    name = 'test',
	    version = "1.0",
	    ext_modules= cpy,
	    author = "test",
<EMAIL_ADDRESS>	)

if __name__ == '__main__':
    file = "hello.py"
    py2c(file)

Save above code as py2c.py, run "python py2c.py build_ext --inplace" ,it generate hello.pyd, import again, raise TypeError.
Expect it run success and print "hello".

OS: Windows 7
Python version 3.6.8
Cython version 0.29.22

def d2(*argsT, **kwargsT):
    @decorator
    def d3(wrapped, instance, args, kwargs, extra_arg=None):
        print(wrapped, instance)
        print(f'd3: {argsT}, {kwargsT}, {args}, {kwargs} {extra_arg}')
        return wrapped(*args, **kwargs)
    return d3

@d2(a=int, b=str)
def hello():
    print('hello')

For the line print(wrapped, instance) it prints
<modulename.__pyx_scope_struct__d2 object at 0x7f64a8584df0> <cyfunction hello at 0x7f64a8394040>

i.e. it's pulled the internal closure out of d3, which is stored as __self__ in d3 and is then passing it to d3 as the first argument (which pushes all the other arguments along one).
I think this is probably wrapt trying to be too clever and picking apart Cython objects in a way that doesn't really make sense. But I'm not completely sure.

I'm not hugely convinced that CyFunction should have a __self__ attribute (that just points to the closure). I think FusedFunction might need to (and CyFunction probably has it just because they share some implementation) but I think maybe it should be removed from CyFunction.
With the stray self attribute gone wrapt would probably work.

I'm not hugely convinced that CyFunction should have a __self__ attribute (that just points to the closure). I think FusedFunction might need to (and CyFunction probably has it just because they share some implementation) but I think maybe it should be removed from CyFunction.
With the stray self attribute gone wrapt would probably work.

It's too hard to me.I have abandoned the plan, and use a simple decorator like d1.
Thank you.

The __self__ attribute has a special purpose in Python for methods of classes and is an indication that binding has occurred. If cython is using the __self__ attribute to mean something entirely different to what it means in the Python object model that could cause problems for packages which expect it to have the meaning it does in the context of the Python object model.
In other words, if cython is using the __self__ attribute for something else, it will break wrapt, which needs to be able to know in certain contexts when binding of functions has occurred. So if __self__ in cython has a completely different purpose, it may be better to use a different name for the attribute in cython.

@GrahamDumpleton Yes I agree - I think it's currently being misused in Cython (and thus it's reasonable for wrapt to fail on it). I'm going try to fix the bug in Cython when I have time. I think it's easily removed for most Cython functions but it's possible it may have to remain for "fused functions". Those are a fairly obscure edge-case though, that we may have to live with for now.

@da-woods why is this only relevant for fused functions and not for regular (bound) methods?

@da-woods why is this only relevant for fused functions and not for regular (bound) methods?

I believe that bound CyFunction get wrapped up with PyMethod_New (https://github.com/cython/cython/blob/0ec9be57f5770869cb2fbe36e00bbde405b3b855/Cython/Utility/CythonFunction.c#L921) and so the method object provides the __self__ attribute. Therefore CyFunction doesn't have to.
For fused functions, a bound fused function remains a fused function (so [] indexing still works). Therefore, they do need a __self__ attribute.

The current status is that Cython returns the closure as __self__ which I don't think is ever right.


operators elastic-cloud-eck (2.2.0)

Updates ECK Elasticsearch operator to the latest version 2.2.0

@naemono please check channels.

@J0zi The only change to channels is https://github.com/k8s-operatorhub/community-operators/pull/1181/files#diff-535e8ce84461ae24edda7b79f702f631a3dacccfa1d1ea7f551be7f79a668d60, and the naming of the CSV is staying consistent across versions.
Am I missing something?  Thanks for any pointers you can provide.

@naemono i found it. Somehow package.yaml file is not changed while we are rebasing your branch to our main. Will you be so kind to rebase to current main? Thank you very much

@mvalarh git did an auto-merge, instead of a rebase.  Hope that's ok.  Thanks for your help with this.

It seams to me that it didn't help. Very strange. Our pipeline is doing
git clone https://github.com/naemono/community-operators
cd community-operators
git checkout origin/2.2.0

And at this stage we have elastic-cloud-eck.v2.2.0 which is correct
$ cat operators/elastic-cloud-eck/elastic-cloud-eck.package.yaml
channels:
- currentCSV: elastic-cloud-eck.v2.2.0
  name: stable
defaultChannel: stable

Then we do
git remote add upstream https://github.com/k8s-operatorhub/community-operators
git pull --rebase -Xours upstream main

and package file is old one. Very strange for me
$ cat operators/elastic-cloud-eck/elastic-cloud-eck.package.yaml
channels:
- currentCSV: elastic-cloud-eck.v2.1.0
  name: stable
defaultChannel: stable
packageName: elastic-cloud-eck

Can you test it locally please? If it will not work. Can you make new PR?

/merge possible

/merge possible

/merge possible


Salted concat instead of XOR

Apologies for the late-game addition! I did a revision pass before publishing the skip ratchet paper. The major change is that while XOR is probably fine for a lot of use cases, its nice algebraic properties have some leaky edge cases that are sometimes hard to spot in the moment. The binary inverse also has some potential for leaking if the hash is later weakened, and a concatenated salt is likely better.
TL;DR using salted hashes is probably safer in some situations. This basically comes down to any operations that used to use a binary inverse or XOR now use a salted hash.

Every SR gets a unique, randomly generated salt in its state
Generating next smallest zero (epoch):

Was: hash(inverse(parent))
Now: hash(salt <> parent)

Flatten / derive key:

Was: xor(big, xor(med, small))
Now: hash(big ⋈ med ⋈ small)

(Where ⋈ is any combining operation, including concat or the existing XOR)

DO NOT IMPLEMENT THE ABOVE


Adds reading and writing of gAMA (gamma) and cHRM (primary chromaticities).

I've included tests for gamma (passing) based on the PngSuite images.
I've used the modified library in my personal project and found it to work fine.
cHRM code is pulled from kettle11's fork which didn't include tests. I have also not tested it, but will do so in the future.

Thanks! This is going to be in 0.17. No fixed ETA on a release as we're going to first go through #213 and ensure that at least the interface is prepared and SemVer compatible.

In the meantime you've gotten an invitation to collaborators team to ease further contributions if you plan on doing any in the future :)
More information:
Contributing
Code of Conduct

I much appreciate your help and attention to detail.
When I wish for further changes, I won't hesitate to contribute here.
Thanks for feeling welcome :)

@ivovanderlans Thanks for finishing up this work!
I had no idea anyone even noticed my fork until now when I stumbled across this, but I'm very pleasantly surprised!

So was I when our changes were integrated in main. Keep up the good work! There are always people who see the beauty :)


Page Not Found on Clicking Spiritual Therapy in Footer

Description
How Regenerate the ISSUE

Go to Footer
Click Spiritual Therapy
Now you can see the error

Screenshots

Additional information
No response

Hi,
I am interested in being assigned to this issue. I am confident that I can resolve this issue.
Please let me know if you have any questions or if there is anything else that I can do to help.
Thanks,
GrandmasterGogo

Hi,
I am interested in being assigned to this issue.i have experience to solve this type of issues
thanks,
Yadav97


textured output

how to get textured output with the ply

Hi, Our method does not estimate texture information. But you can use the pixel intensity as the texture information and then write it to a ply file.


removed tsconfig from libraries

Description
There seems to be a repetition of the tsconfig.json file when using frameworks. I have removed ...tsconfig from the libraries array to avoid repetition because all projects already contain a package.json (tsconfig is already nested under it).
Linked Issues
This seems to have occurred in the following issues: https://github.com/antfu/vscode-file-nesting-config/issues/135 and https://github.com/antfu/vscode-file-nesting-config/issues/94

Actually, this is made on purpose as for now most of the frameworks will read tsconfig.json are part of their configure. Maybe instead we could exclude it from package.json.

Yeah, I think that would be good too, may I make this change?

Sure, you can directly update the PR

Hope I did it right

For some projects the tsconfig.json file does not get nested under any other files, for those files do not exist. Is it possible to have it so precedence is given to library's configs—to keep current behaviour—, but if none are found, then have it nest under package.json?


soc: intel_adsp: ipc: check for pending ack

This patch extends the driver API with a function to check if we are waiting for an ACK from the host.
This change will allow to solve the problem that occurs during the power state transitions. Occasionally, the Application decides to enter the power gating state after sending an IPC message, before receiving an ACK from the HOST. This results in broken IPC communication when coming back to Idle state.

@dnikodem fyi

Update: instead of adding a new function, I change the operation of the existing one.


background location in Android 9-10

Hi,
The background location is working smoothly in Android 8, however, it breaks down after Android 9.
I have tried using "subscribeToLocationUpdates" and "getLatestLocation" but had no luck...
Any suggestions / solutions ?
Thanks

:wave @amirmatin
Can you provide some examples of what you expect to happen and what's happening instead?

Hi Matt,
Sure, so in Android 8 when I use the"subscribeToLocationUpdates" method, while the app goes to the background, it is still able to recieve the correct geolocation info as the location changes so I can use them for turn-by-turn navgation so this is the expected behaviour..
However, on Android 9-10, once the app is minimed, there are no callbacks made upon the user location change. I have tried it on Samsung phone and the Pixel phone running Android 9 and 10 respectivly.
So I tried a different approach where using a background worker library in RN , I enforce the new location fetch via the "getLatestLocation" comamnd every 3 seconds however it also returns null values.
Hope this can shine some light over the issue..
Many thanks

Thanks for the information! This is due to new security policies in Android. This library is also not really designed for background location as, in my opinion, most apps don't really need it.
If you do need it, then I recommend you use this library which supports it really well:
https://github.com/transistorsoft/react-native-background-geolocation


Analyzer that pulls ROSE valuations, API that exposes them

The frontend currently pulls ROSE valuations from CoinGecko directly, but sooner or later we'll hit their rate limits.
Instead, the indexer should pull from CoinGecko (or other similar service) using a new analyzer, store the result in a new table, and serve the timeline of valuations in a new endpoint.
Bonus: Alter the DB wiping method (DANGER__WIPE_STORAGE_ON_STARTUP) so it does not erase historic valuations. Publicly accessible historical valuations usually only have daily granularity, whereas we can pull and store with much higher frequency (e.g. once every 5 minutes, or even every minute).
Suggested available output granularities: 5 min and 1 day (like /tx_volume endpoint).

It was decided that it is more suitable to fetch this from frontend.


Adding v2 BulkMutation

Updated BigtableDataClient to reflect the fact that MutateRowsResponse is a streaming response rather than unary.
Copied AsyncExecutor to v2. Updated to v2 return types (for example MutateRowResponse in v2 vs. Empty in v1), and List instead of a single response
Copied BulkMutation to v2. The handleResult() method looks significantly differently with the streaming response.
Copied the tests for AsyncExecutor and BulkMutation with minor changes.

LGTM other than typos


CoE license requirements

Question about licensing requirements. Power Apps canvas/model-driven in CoE of course require Premium license but isn't so that also Power Automate Premium license is required because Flows uses Premium connectors like Dataverse? If so then I think we should state that requirement more clearly on this page like Power Apps per User/App AND Power Automate per User/Flow is needed? Now it is mentioned that 1 of the Power Apps OR Power Automate license is the requirement
Premium licenses are required to use the CoE Starter Kit. Depending on what components you will use, your organization size and the existing licenses available in your organization, you will require either a Power Apps per user or per app or Power Automate per user or per flow license or a combination of these licenses.

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

ID: 3f619bbe-9303-8583-2cb9-a287811cec13
Version Independent ID: 8e256e0c-38fa-f2ca-58db-550bb6e9802a
Content: Set up the CoE Starter Kit - Power Platform
Content Source: power-platform/guidance/coe/setup.md
Service: power-platform
GitHub Login: @manuelap-msft
Microsoft Alias: mapichle

We updated the license requirements pre-reqs!


devcontainer up not working with podman and docker-compose file

With this devcontainer.json, devcontainer cli 0.66.0 and podman the image seems to build fine mostly but then the cli will prepend localhost to the image name and the build fails.
Command executed: devcontainer up --buildkit never --workspace-folder .
CLI version: 0.66.0 (also with 0.59.1)
System: Arch Linux
Podman: 5.1.2
Logs:
[...]
[4/4] STEP 32/32: LABEL "com.docker.compose.image.builder"="classic"
[4/4] COMMIT docker.io/library/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest
--> b93856cae65a
[Warning] one or more build args were not consumed: [_DEV_CONTAINERS_FEATURE_CONTENT_SOURCE]
Successfully tagged docker.io/library/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest
b93856cae65a07925056a02be038297c9959607ad139bf21dd84ed722cfb90ee
Successfully built b93856cae65a
Successfully tagged vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829
STEP 1/9: FROM localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829
Trying to pull localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest...
WARN[0000] Failed, retrying in 2s ... (1/3). Error: initializing source docker://localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
WARN[0002] Failed, retrying in 2s ... (2/3). Error: initializing source docker://localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
WARN[0004] Failed, retrying in 2s ... (3/3). Error: initializing source docker://localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
Error: creating build container: initializing source docker://localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829:latest: pinging container registry localhost: Get "https://localhost/v2/": dial tcp [::1]:443: connect: connection refused
Error: Command failed: docker build -f /tmp/devcontainercli-zenon/updateUID.Dockerfile-0.66.0 -t vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829-uid --platform linux/amd64 --build-arg BASE_IMAGE=localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829 --build-arg REMOTE_USER=vscode --build-arg NEW_UID=1000 --build-arg NEW_GID=1000 --build-arg IMAGE_USER=root /tmp/devcontainercli-zenon/empty-folder
    at utA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:410:3925)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async KtA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:482:3944)
    at async eB (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:482:4886)
    at async hrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:663:200)
    at async lrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:662:13452)
{"outcome":"error","message":"Command failed: docker build -f /tmp/devcontainercli-zenon/updateUID.Dockerfile-0.66.0 -t vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829-uid --platform linux/amd64 --build-arg BASE_IMAGE=localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829 --build-arg REMOTE_USER=vscode --build-arg NEW_UID=1000 --build-arg NEW_GID=1000 --build-arg IMAGE_USER=root /tmp/devcontainercli-zenon/empty-folder","description":"An error occurred setting up the container."}

I think the key line in the log it where it tags vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829 but then tries to pull from localhost/vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829 (I don't have a local registry).
I tried with 0.66.0, 0.65.0, 0.59.1 and all have this issue.
maybe related to https://github.com/microsoft/vscode-remote-release/issues/9748 ? at least one user there had the same issue, but they actually had a custom registry.

Looping in @chrmarti for his thoughts, thanks!

I agree, the fix for https://github.com/microsoft/vscode-remote-release/issues/9748 seems to cause this.
Could you try with v0.58.0 to confirm it works without that fix?
Maybe that fix is only needed when using buildx (seeing that you are disabling it). Does the latest version work when you allow BuildKit? (Or does that not change behavior with Podman?)

I'm seeing the same issue here, but as far as I know I don't have any specific builder options except format docker for buildah (as an envar).
As far as I can tell, the problem is that when I execute podman compose build the images are prepended the docker.io/library registry, whereas if I just do podman build the prepended domain is localhost. I am using dockers compose (not the package podman-compose`), which I think it's a somewhat common set up.
My guess is that docker's compose engine is manually tagging with docker's default registry, hence the fix for podman build breaks podman compose build.

I disable buildkit due it failing otherwise (I think buildkit is not supported in podman, see https://github.com/containers/podman/issues/17836 , but there's conflicting information online on podman and buildkit support).
I tried with 0.58 but that fails due to an unrelated error, which I think was fixed in 0.59. I can try again and post the log but doubt it sheds a light on this issue.
I'm not currently on that machine (still using regular Docker on my work machine) but can give try and post relevant logs later.

Here it is with buildkit:
$ DOCKER_BUILDKIT=1 devcontainer build --workspace-folder .
[...]
[8404 ms] Docker Compose override file for building image:
version: '3.8'

services:
  data_service:
    image: vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829
    build:
      dockerfile: /tmp/devcontainercli-zenon/container-features/0.66.0-1723021184360/Dockerfile-with-features
      context: /tmp/devcontainercli-zenon/empty-folder
      args:
        - BUILDKIT_INLINE_CACHE=1
        - _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label
        - _DEV_CONTAINERS_IMAGE_USER=root
        - _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp
      additional_contexts:
        - dev_containers_feature_content_source=/tmp/devcontainercli-zenon/container-features/0.66.0-1723021184360

[8405 ms] Start: Run: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service
>>>> Executing external compose provider "/usr/bin/docker-compose". Please refer to the documentation for details. <<<<

WARN[0000] /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
WARN[0000] /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
the classic builder doesn't support additional contexts, set DOCKER_BUILDKIT=1 to use BuildKit
Error: executing /usr/bin/docker-compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service: exit status 1
Error: Command failed: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service
    at Km (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:430:525)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async FrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:665:3021)
    at async yrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:664:4994)
{"outcome":"error","message":"Command failed: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service","description":"An error occurred building the Docker Compose images."}

~/DEV/ETH/renku-data-services main 10s
[8404 ms] Docker Compose override file for building image:
version: '3.8'

services:
  data_service:
    image: vsc-renku-data-services-34f67da2ae2e898466e7b938e43785c2322033e1d9fbed1ea7c91813ff9ad829
    build:
      dockerfile: /tmp/devcontainercli-zenon/container-features/0.66.0-1723021184360/Dockerfile-with-features
      context: /tmp/devcontainercli-zenon/empty-folder
      args:
        - BUILDKIT_INLINE_CACHE=1
        - _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label
        - _DEV_CONTAINERS_IMAGE_USER=root
        - _DEV_CONTAINERS_FEATURE_CONTENT_SOURCE=dev_container_feature_content_temp
      additional_contexts:
        - dev_containers_feature_content_source=/tmp/devcontainercli-zenon/container-features/0.66.0-1723021184360

[8405 ms] Start: Run: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service
>>>> Executing external compose provider "/usr/bin/docker-compose". Please refer to the documentation for details. <<<<

WARN[0000] /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
WARN[0000] /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
the classic builder doesn't support additional contexts, set DOCKER_BUILDKIT=1 to use BuildKit
Error: executing /usr/bin/docker-compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service: exit status 1
Error: Command failed: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service
    at Km (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:430:525)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async FrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:665:3021)
    at async yrA (/usr/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:664:4994)
{"outcome":"error","message":"Command failed: docker compose --project-name renku-data-services_devcontainer -f /home/zenon/DEV/ETH/renku-data-services/.devcontainer/docker-compose.yml -f /tmp/devcontainercli-zenon/docker-compose/docker-compose.devcontainer.build-1723021191395.yml build data_service","description":"An error occurred building the Docker Compose images."}

I tried again with 0.58.0 to reproduce the error, but it actually works! :shrug:
Tried with devcontainer up --buildkit never --build-no-cache --workspace-folder ..
So can confirm that 0.58.0 does not have this issue.

I started working with Podman today, and I can confirm that version 0.58.0 works perfectly with my Rails project on macOS, while the latest version 0.70.0 does not.
Here’s the error log when trying to build with version 0.70.0:
[3094 ms] Start: Run: docker compose --project-name example_devcontainer -f ~/Documents/projects/example/.devcontainer/compose.yaml -f /var/folders/vv/m5djvkbs6t1fr96k4l3cp66w0000gn/T/devcontainercli/docker-compose/docker-compose.devcontainer.build-1725915103822.yml build app
the classic builder doesn't support additional contexts, set DOCKER_BUILDKIT=1 to use BuildKit
Error: executing /usr/local/bin/docker-compose --project-name example_devcontainer -f ~/Documents/projects/example/.devcontainer/compose.yaml -f /var/folders/vv/m5djvkbs6t1fr96k4l3cp66w0000gn/T/devcontainercli/docker-compose/docker-compose.devcontainer.build-1725915103822.yml build app: exit status 1
Error: Command failed: docker compose --project-name example_devcontainer -f ~/Documents/projects/example/.devcontainer/compose.yaml -f /var/folders/vv/m5djvkbs6t1fr96k4l3cp66w0000gn/T/devcontainercli/docker-compose/docker-compose.devcontainer.build-1725915103822.yml build app
    at Ym (/opt/homebrew/Cellar/devcontainer/0.70.0/libexec/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:430:525)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async MrA (/opt/homebrew/Cellar/devcontainer/0.70.0/libexec/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:665:3021)
    at async krA (/opt/homebrew/Cellar/devcontainer/0.70.0/libexec/lib/node_modules/@devcontainers/cli/dist/spec-node/devContainersSpecCLI.js:664:4962)
{"outcome":"error","message":"Command failed: docker compose --project-name example_devcontainer -f ~/Documents/projects/example/.devcontainer/compose.yaml -f /var/folders/vv/m5djvkbs6t1fr96k4l3cp66w0000gn/T/devcontainercli/docker-compose/docker-compose.devcontainer.build-1725915103822.yml build app","description":"An error occurred building the Docker Compose images."}

To fix the issue, I uninstalled version 0.70.0 and rolled back to 0.58.0 using the following steps:
devcontainer --version
0.70.0
brew uninstall devcontainer

npm install -g<EMAIL_ADDRESS>devcontainer --version
0.58.0

After downgrading, everything works as expected again.


[PT run] Windows search index is regularly "losing" entries

Microsoft PowerToys version
0.55.2
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
I have some "custom location" within my Windows search index (C:/Data/dev/WinScripts/*) which holds a bunch of small "helper scripts" of mine. Usually PT run & Windows search via the start menu find all the exe files within this path. I've explicitly excluded most of the other files extensions within this folder (*.ahk, *.ico, *.png) as I don't want those files to clutter my PT run search results.
✔ Expected Behavior
All exe files within the above mentioned path C:/Data/dev/WinScripts/* can be found via PT run & the Windows start menu.
❌ Actual Behavior
Sometimes the files get somehow removed from the Windows index and they're not shown anymore when searching for them in PT run or the Windows start menu:

When this happens, I can "restore" the index by using the rebuild button in the Windows search index settings. After the rebuild, everything is back to normal and the files show up again within PT run & the Windows start menu search.
The index being in this "broken state" happens on a rather regular basis. Whilst I have no "hard data" for this, I'd guess that I have to perform the rebuild ~ once every 1 or maybe 2 months.
Whilst I can basically live this "manual rebuild step", it comes with a very awkward side effect which starts to really bug me and degrades overall usability of the PT runs for me:
When rebuilding the index, PT run seems to be losing all "learned scores" and files which appeared on top of my search results before, show up rather late in the list. This means PT run has to "re-learn" my frequently used items and once it's "done", the index "breaks" again and I have to start all over again 😕
I know that there's probably not much you can do as this is most probably a Windows search index issue but I'm hoping that you maybe have heard of such issues before and could maybe give me some tips on how to prevent this from happening or can route me to some place where such a bug report is better placed.
Other Software
Windows 10, Version 20H2 (OS Build 19042.1526)

we leverage the indexer, I'd honestly do a Win+F and report it next time it happens as that would provide diagnostic data to the search team.
I haven't heard of anything like this and honestly doesn't ring a bell in our bug list.

Thanks for the feedback, I wasn't aware of Win+F, and will try it next time.

FYI, just ran into this issue again and submitted a report via the Feedback Hub as suggested.


Support for backends on multiple namespaces

Hello,
I have a service running on namespace A and other isolated service running on namespace B, but they share the same domain, so I'd like to set them as backends of the same ALB, something like this
spec:
  rules:
  - http:
      paths:
      - path: /a
        backend:
          serviceName: "a/app"
          servicePort: 80
      - path: /b
        backend:
          serviceName: "b/app"
          servicePort: 80

Thanks

While there is a lot of interest in this its unfortunately not possible with the current ingress specification since serviceName can not be anything other than just a service name.


llvmPackages_rocm: 4.5.2 -> 5.0.2

hip: 4.5.2 -> 5.0.2
Description of changes
llvmPackages_rocm (including llvm, clang, compiler-rt, and lld) upgraded from ROCm 4.5.2 to 5.0.2.
The hip compiler is also upgraded along the same path as it is coupled with llvmPackages_rocm.clang.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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/)
22.05 Release Notes (or backporting 21.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Hi @InternetUnexplorer, if you have a chance, can you also give this a whirl? This comes in atop your recent change to switch to static linking, and I'd like to be sure this update doesn't set things back (it shouldn't!).

Sure, I'll give it a go as soon as I can (will probably be tomorrow morning) :)

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
Result of nixpkgs-review pr 165362 run on x86_64-linux 1

14 packages built:

hip
llvmPackages_rocm.clang
llvmPackages_rocm.clang-unwrapped
llvmPackages_rocm.clangNoCompilerRt
llvmPackages_rocm.compiler-rt
llvmPackages_rocm.lld
llvmPackages_rocm.llvm
rocclr
rocm-comgr
rocm-device-libs
rocm-opencl-icd
rocm-opencl-runtime
rocm-runtime
rocminfo


Test group middleware

Use the same tests for Global + Group middleware to check for problems/differences

The problem here is that other methods are not matched with the fallback, so the response doesn't get added. Not sure if that's fixable.


Implement without constructors

I like the idea of doing it this way, but we should probably benchmark to ensure it's at least as fast as the original. I no longer have any idea how JS will behave with differences like these. :wink:

I wouldn't be surprised if the delete this.thunk was important somehow.

Maybe, but if we can avoid it it porbably would be better - delete is generally Bad in JS, as it prevents any kind of "hidden class" optimisations. Setting to undefined is better unless hasOwnProperty is being used for the presence test.

The question really is whether using closure scope or object properties are faster.

Perhaps we could do a performance comparison.

I have done this:
performance profile on master: https://github.com/matthewleon/purescript-lazy/tree/profile
performance profile with this change: https://github.com/matthewleon/purescript-lazy/tree/constructorless-profile
The test is a profile of the following two lines:
let longList = L.range 1 1000000
    len = L.length longList

On Chrome 56.0.2924.110 (64-bit):
master version runs in ~1.8s. More than half that time is spent in staggered GC pauses.
constructor-free version runs in ~13s (about 7x as slow):. Seems more than 90% of the time spent in GC pauses.
Don't know enough about V8 garbage collection to understand what, exactly, is happening in either case, given that the forced thunks shouldn't be removed from memory. Perhaps they are being shifted from one GC zone to another? Would love some insight.
Pics:

On further thought, I came to the idea that what makes the GC stutter so much might be that the closure's reference to thunk is leaking. The browser GC probably isn't smart enough to know that the else clause will never be triggered again, and thus retains the reference to thunk even after it has been called.

@garyb this should be closed by #21


Does the secondary replica in the secondary DAG need connectivity to the servers in the Primary DAG?

The article states:
As shown in the following figure, AG 1 is the primary availability group. Its primary replica sends transactions to both the secondary replicas of AG 1 and the primary replica of AG 2. The primary replica of AG 2 is also known as a forwarder. A forwarder is a primary replica in a secondary availability group in a distributed availability group. The forwarder receives transactions from the primary replica in the primary availability group and forwards them to the secondary replicas in its own availability group. The forwarder then keeps the secondary replicas of AG 2 updated
I recently observed something unexpected in my Azure environment. The network connection between the primary and secondary DAGs was down and the secondary replica in the secondary DAG (so not the Forwarder) went yellow in the Always On dashboard.
I did a netstat on that secondary replica and I could see that it was trying to talk to the load-balancer in front of the primary DAG. As soon as the connectivity was restored, the secondary replica went green in the dashboard.
I can't understand why the secondary replica in the secondary DAG was talking to the primary DAGs' load balancer. Surely only the forwarder in the secondary DAG would be doing that?
Thanks

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

ID: 3e0e8cda-edf4-81f6-0941-1ed53558e1e9
Version Independent ID: 09e55110-b604-acd8-9903-bbd4f971170c
Content: What is a distributed availability group - SQL Server Always On
Content Source: docs/database-engine/availability-groups/windows/distributed-availability-groups.md
Product: sql
Technology: availability-groups
GitHub Login: @MashaMSFT
Microsoft Alias: mathoma

@ChrisSommers -- Chris, thank you for your thorough feedback.  Please consider these resources:

SQL Server on Microsoft Q&A
DBA Stack Exchange
Stack Overflow

@MashaMSFT -- Masha, please look into this issue.

@ChrisSommers we haven't been able to find an acceptable answer to what you saw, and since this is the documentation repository, and without the product group being able to give us an answer, my suggestion is to open a support case with Microsoft to figure out what you saw. I know what that entails, so if you don't want to go through the hassle, I'm not sure we can provide much more information at this time.


Handle Rails engine routes

Let iterate all the recognized routes including the ones coming from Rails engines.
As reference, the relevant part of action_dispatch's recognize:
https://github.com/rails/rails/blob/main/actionpack/lib/action_dispatch/routing/route_set.rb#L881-L892
Fixes #37

Failing specs due to a route without a controller (block route in the engine).
            Failure/Error: tags = [route.requirements[:controller].classify]

            NoMethodError:
              undefined method `classify' for nil:NilClass

Should be fixed by #40

To mitigate the risk of this change, I removed changes that are not needed to pass the test case. https://github.com/k0kubun/rspec-openapi/pull/38/commits/81751cb19734dbe686d98aa357843be3e3c3acf1


when list, the list doesnt show in the feed, it keeps just loading

first, awesome product. I just tried it today the problem is that
When list an NFT, the list doesn't show up in the feed nor the selling section. Instead it keeps just loading forever.
I tried to run it with a custom RPC, and the same issue.
it's different then the main website grape.art

Thank you for your feedback
yes that is correct, grape.art uses it's own auction house program, the auction house program in the repo is the default demo auction house with 0% fees for testing and any listings you do there will not show on grape.art but on your own build (do you see the NFT listed for sale on your build?)

i waited up for an hour and nothing, it keeps loading

What rpc endpoint are you using for transactions

it's specified from grapetools. constants.st?
export const FREE_RPC_ENDPOINT = process.env.REACT_APP_API_FREE_RPC_ENDPOINT || '<transaxction RPC??>';
export const GRAPE_RPC_ENDPOINT = process.env.REACT_APP_API_GRAPE_RPC_ENDPOINT || <transaxction RPC??>

Transaction*

in the constants.tsx file:
export const FREE_RPC_ENDPOINT = process.env.REACT_APP_API_FREE_RPC_ENDPOINT || 'https://api.mainnet-beta.solana.com'; export const GRAPE_RPC_ENDPOINT = process.env.REACT_APP_API_GRAPE_RPC_ENDPOINT || 'https://api.mainnet-beta.solana.com';
update only the GRAPE_RPC_ENDPOINT to your own rpc provider, for the FREE_RPC_ENDPOINT do not use an rpc provider unless you are paying for it, they have a high tendency of failing (this is to minimize botting), so you should use either:
https://api.mainnet-beta.solana.com - Solana-hosted api node cluster, backed by a load balancer; rate-limited or
https://solana-api.projectserum.com - Project Serum-hosted api node
(I will rename the FREEto be TX_RPC_ENDPOINT)

Ok, I used a paid version, paid 299 for quick-node. i understand free version doesn't work fine )
but sill the same, will try different a provider

The whole concept is amazing, hope can see it in action. Hope this will be fixed soon and we can view the Feed section

latest version on here now has a new tariable TX_RPC_ENDPOINT just edit that one to use https://solana-api.projectserum.com/ from the constants file
the GRAPE_RPC_ENDPOINT should use your own endpoint (the quick-node one)

thanks so much, that was fast "god speed"


feat(approval): add appeal_statuses filter for list approvals API

Require

https://github.com/odpf/proton/pull/268

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

19 of 19 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 75.327%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
8011

Relevant Lines:
10635

💛  - Coveralls


Any pretension on supporting iOS?

Maybe a Swift version.

Happy to. Would just need so what native options exists first.

Jezz. So we could create a view with a tableView inside holding the options. Like this:

Is that possible?


chore: bump superset-ui to 0.13.27

SUMMARY
This bumps all superset-ui packages that were released in the 0.13.27 batch.
TEST PLAN
CI + Tested locally that all charts work + made sure all resultType and resultFormat variations in the V1 chart data API still work properly (=the only real code change in this PR besides the bump).
@pkdotson @rusackas @suddjian

Codecov Report

Merging #10018 into master will decrease coverage by 11.03%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master   #10018       +/-   ##
===========================================
- Coverage   70.39%   59.36%   -11.04%
===========================================
  Files         585      401      -184
  Lines       31046    12838    -18208
  Branches     3277     3277
===========================================
- Hits        21855     7621    -14234
+ Misses       9080     5036     -4044
- Partials      111      181       +70

Flag
Coverage Δ

#cypress
?

#javascript
59.36% <100.00%> (-0.01%)
:arrow_down:

#python
?

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


Make ldap search for objectClass case-insensitive

I work with an LDAP server which the ObjectClass attribute is in lowercase, i.e., "objectclass".
When Rancher makes the search for objectclass attributes it expects the literal name "objectClass", i.e, it's case-sensitive, which makes the LDAP authentication never work because it won't find any attributes in this case.
To fix this, I changed the search to make it case-insensitive, using EqualFold function.
I also changed the isType check method from ldap_client.go so it can use the new case-insensitive function from ldap package.
I have builded and tested this fix in my environment, and LDAP provider worked just fine.

In order to have this on release 2.4, should I make a PR to release/v2.4 branch or is up to you guys define it after merging to master?

Please create a corresponding issue in rancher/rancher describing the logging/error you receive and with what LDAP server you are working so we know why this change is introduced and we can review it.

@superseb Create the issue like you asked (#28077). If you could check there! Thanks!

@mrajashree @prachidamle Is this going to cause issues?

@superseb this change is fine

@igorcezar Please squash commits and rebase to trigger CI

@superseb done!

What about the others PRs? #26952 #26949
Should I squash them too or those will not be needed?

@igorcezar Can you open a pull request against the release/2.5 branch and close your 2.3 pull request?

@igorcezar Can you open a pull request against the release/2.5 branch and close your 2.3 pull request?
@dramich done!

@igorcezar Can you open a pull request against the release/2.5 branch and close your 2.3 pull request?

@dramich done!
#29488


#672 Make it can work well without any @package and ok<: in codegen sample model

Fixes #672  .
Changes proposed in this pull request:

Add code to fix issue that it can't work without @package setting in https://github.com/anz-bank/sysltemplate/blob/master/simple.sysl
Add code to print out a warning message if model sysl is not ok <: jsonplaceholder.todosResponse, but jsonplaceholder.todosResponse

Now it can work with following new simple.sysl too:
`
import jsonplaceholder.json as jsonplaceholder ~swagger
simple:
/foobar:
GET:
jsonplaceholder <- GET /todos/{id}
return ok <: jsonplaceholder.todosResponse
`
Checklist:

[x] Added related tests
[x] Made corresponding changes to the documentation

@anz-bank/sysl-developers

Please attach an example of a repo so we can see with https://github.com/anz-bank/sysltemplate

Please attach an example of a repo so we can see with https://github.com/anz-bank/sysltemplate

Can I update https://github.com/anz-bank/sysltemplate/blob/master/simple.sysl directly?

Please attach an example of a repo so we can see with https://github.com/anz-bank/sysltemplate

Please attach an example of a repo so we can see with https://github.com/anz-bank/sysltemplate

Can I update https://github.com/anz-bank/sysltemplate/blob/master/simple.sysl directly?

Fixed sample with PR https://github.com/anz-bank/sysltemplate/pulls

The change for adding a warning looks ok, but addEssentialAttr should rather be done in the transform.

@springwiz, the @package issue is when removes @pakcage information in https://github.com/anz-bank/sysltemplate/blob/master/simple.sysl, it can't generates servicehandler.go and serviceinterface.go. And I checked related transform sysl files svc_handler.sysl and svc_interface.sysl. both of them are done this package change when package information is missed in sysl model file in view goFile. So it has to change Go code still to make sure view calculation logic work well which depends on package information.


Clear engine use

Clear Engine uses these changes in derived classes to include additional processing to TextSegments before training and to intercept versification. Making these virtual enhance the re-usability of the framework.

Damien, in this commit, https://github.com/sillsdev/machine/pull/9/commits/bc8f8d513e6a55f5a8d40e4d03166b4338278f7a , I pulled out a change I needed to compile the WPF test app that leaked into another commit. I didn't have time to determine why the change was needed to compile but suspect it may be a nuget dependency version.


trying to get the current location without a web browser

I am trying to get the current location, not the ip address,
IP address will point me to the ISP i am on, however if we use a browser, we are able to pin point to the nearest 20-30 meters
any idea on how to get that would be great, i tried selium and chromium, it does not work well

Anyone??


Additional Holidays

Valentine's Day (02/14), St. Patrick's Day (03/17), Halloween (10/31) and Election Day (First Tues every 4 years ((this year is 11/05)) ). Could you please add these to the US Holiday Calendar?

Thanks for the correction, I'll get a PR to get this fixed ASAP

@KJhellico While the first 3 of the list above aren't official holidays for the US, which category would be the most appropriate here? WORKDAY, OPTIONAL, or some new ones altogether?

I think, if such holidays are to be added, there should be a new category for them (UNOFFICIAL or something like that).

@KJhellico While the first 3 of the list above aren't official holidays for the US, which category would be the most appropriate here? WORKDAY, OPTIONAL, or some new ones altogether?

The category support was started as ad-hoc feature and has been improved recently. I think it still needs some more attention in terms of standardized across entities and proper documentation.
UNOFFICIAL / NON_PUBLIC would do it for now.

I'll use NON_PUBLIC for this case then 👍


Update sbt-scalajs-crossproject to 1.3.1

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

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.portable-scala", artifactId = "sbt-scalajs-crossproject" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.portable-scala", artifactId = "sbt-scalajs-crossproject" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, version-scheme:semver-spec, commit-count:1

Superseded by #118.


Improve Plan status logic

During testing the ns on the source cluster was accidentally removed. The migration picked up the change, but the UI displayed only that the plan is Not Ready. It was hard to notice the migration failed, even knowing it's background.
Here is how it is displayed now:

Migmigration status:
status:
  conditions:
  - category: Critical
    lastTransitionTime: 2019-07-25T14:36:50Z
    message: The referenced `migPlanRef` does not have a `Ready` condition.
    status: "True"
    type: PlanNotReady
  phase: StageRestoreCreated
  startTimestamp: 2019-07-25T14:35:27Z

Migplan status:
status:
  conditions:
  - category: Critical
    lastTransitionTime: 2019-07-25T14:36:50Z
    message: Namespaces [mysql-persistent] not found on the source cluster.
    reason: NotFound
    status: "True"
    type: NamespaceNotFoundOnSourceCluster

Migplan correctly recognized the issue, and it should be displayed in the UI too. Should be related to https://github.com/fusor/mig-ui/issues/291 https://github.com/fusor/mig-ui/issues/355 and https://github.com/fusor/mig-ui/issues/331

Should be fixed by #434


Integrate ComposablePreviewScanner

https://github.com/sergio-sastre/ComposablePreviewScanner requires apps do the integration with the preferred screenshot library
Example https://github.com/sergio-sastre/ComposablePreviewScanner?tab=readme-ov-file#roborazzi
But it could be a great experience if the roborazzi plugin had an option to enable screenshot testing of previews with no extra code or config.
Theoretical developer Steps

Use previews in a gradle project
Add io.github.takahirom.roborazzi plugin to build
Configure via RoborazziExtension

roborazzi {
  automaticPreviewScreenshots = true
}

This would cover maybe 80% of a typical apps screenshots, while promoting routine use of Previews for development, and allowing unit tests for the other 20%.

Thank you for your proposal! I think it is great to have APIs that users can set up easily, while also having basic APIs for advanced usages. For example, we can add dependencies like Robolectric and options like hardware rendering when using the automatic option.

One challenge is automatically adding a test. Here's how I think we can add a test:
      testTaskProvider
        .configureEach { test: AbstractTestTask ->
          val resultsDir = resultDirFileProperty.get().asFile
          if(test is Test) {
            val generateTestsTaskProvider = project.tasks.register("generateTests", GenerateTestsTask::class.java) {
              it.dependsOn("generateTests")
            }
            test.testClassesDirs += project.files(generateTestsTaskProvider.map { it.outputDir })
          }

....

abstract class GeneratePreviewScreenshotTestsTask : DefaultTask() {
    @get:OutputDirectory
    abstract val outputDir: DirectoryProperty

    @TaskAction
    fun generateTests() {
        val testDir = outputDir.get().asFile
        testDir.mkdirs()

        File(testDir, "GeneratedPreviewScreenshotTest.kt").writeText("""
            import org.junit.Test

            class GeneratedPreviewScreenshotTest {
                @Test
                fun testPreviewScreenshot() {
                }
            }
        """.trimIndent())
    }
}

I think we can implement this feature by following these steps:

Add the automaticPreviewScreenshots Gradle extension property.
Add dependencies like Robolectric and ComposablePreviewScanner if automaticPreviewScreenshots exists.
Add the GeneratePreviewScreenshotTestsTask and set it up if automaticPreviewScreenshots exists.

I think it is important to mention that ComposablePreviewScanner is based on ClassGraph which finds the Previews while running the jvm tests (so no code generation or ksp involved), and such tests run at build-time as stated here
Theoretically it should be possible, but I am a little bit unsure how good it works inside a Gradle plugin, and I think the first step would be to try it out and see if it finds some Composables in a very basic gradle plugin that does nothing else but that.
That would be the very first step I’d try.
Regarding the mapping between the Previews and Robolecteic/Roborazzi, I can help with that once I am back from Droidcon Berlin 😊

Thanks. I'm thinking of adding a generated test, which uses ComposablePreviewScanner, to the test Gradle task to generate screenshots instead of loading Previews in the Gradle Plugin. This approach is easier and would allow users to migrate their own customized tests. If you have any opinions on this, please let me know.
Sadly, I don't have time to implement this now, so I added the contributions welcome label. I'll be available in late September.

Oh I see, that should definitely work without troubles

With just adding one hundred lines of code, it seems to have worked 🎉
https://github.com/takahirom/roborazzi/pull/416/files#diff-2ec7175e0bee85fe7e7d1d5d40dbf060b59731fcbd6dac9cc2db230a9ed84876R22
All users have to do is add this.
plugins {
  id("io.github.takahirom.roborazzi")
}

roborazzi {
  automaticPreviewScreenshots {
    enabled = true
    scanPackages = listOf("com.github.takahirom.sample")
  }
}

I have a small issue: I'm not sure how we can access the version catalog during compile time from the plugin.
https://github.com/takahirom/roborazzi/blob/8d68dea6f3a9372d931d73451d75c3a1a5dffd17/include-build/roborazzi-gradle-plugin/src/main/java/io/github/takahirom/roborazzi/PreviewScreenshots.kt#L49-L63

Is naming of multipreviews a follow up? It wasn't clear it's handled.
But amazing, ship it!

Wow! Super fast 🏎
I’ll try to do a code review today in the evening (CET time)

I'm thinking of changing the DSL to make it more flexible.
Current Configuration:
roborazzi {
  automaticPreviewScreenshots {
    enabled = true
    scanPackageTrees = listOf("com.github.takahirom.sample")
  }
}

Proposal:
Minimum setup for preview screenshot tests:
roborazzi {
  androidSetup {
    enable = true
    generatePreviewTests {
      scanPackages = listOf("com.github.takahirom.sample")
    }
  }
}

You can disable or enable all setups:
roborazzi {
  androidSetup {
    enable = true
    generatePreviewTests {
      enable = true // Inherits from setupOptions if not specified
      scanPackages = listOf("com.github.takahirom.sample")
    }
    libraryDependencies {
      enable = true
      robolectricVersion = "1.xxx"
    }
    testConfig {
      enable = false
      includeAndroidResources = true
      roborazziFilePathStrategy = "relativeFromOutputDir"
      robolectricRenderMode = "hardware"
    }
  }
}

These changes allow users to copy and reuse GeneratedPreview tests, disable specific settings like dependencies, and easily set up screenshot tests even if they opt not to use Preview Screenshot tests. We can also introduce new settings with defaults set to false. Additionally, naming the setup as androidSetup leaves room for possible expansion to Kotlin Multiplatform."

I also think It's confusing. I'm thinking additional abstraction layer for users.
roborazzi {
  baseSetupConfig(
    AndroidAutomaticPreviewScreenshots(listOf("com.github.takahirom.sample"))
  )
  advancedAndroidSetup {
    libraryDependencies.junitVersion = "4.13.2"
  }
}

I don't think you should get involved in dependencies at all. I think the pattern from Hilt, Compose and gRPC (IIRC) is to fail the build if they are unmet, with a clear error, and often a way to suppress.
So I'd suggest minimising the changes to the project structure and dependencies, instead executing the code paths you planned and explaining the requirements to the user.

That's a good point. I've been considering what should and shouldn't be included in our scope. For example, I was wondering about the differences between setting dependencies and adding new tasks in the plugin. Adding tasks and properties means they become the single source of configuration, but changing something users can already configure can lead to losing that single source of truth.
I've come up with the following API. This setup checks dependencies and configurations and generates necessary source codes without altering user settings:
roborazzi {
  generateRobolectricPreviewTests {
      enable = true
      pacakges = listOf("com.github.takahirom.sample")
  }
}

Looks good. Typo in packages aside.

Thank you. I have re-implemented the PR based on the feedback.
https://github.com/takahirom/roborazzi/pull/416

That looks great to me.  Keen to try it.

@takahirom
I’ve added support for private previews in ComposablePreviewScanner 0.1.3 in case you also want to let users set that in the plugin

Thank you for letting me know. We don't have versioning in our documents, and there are no errors, so I think it's fine to leave it as is.
I'll close this issue! Thank you for your review and proposal.


403 Bypass script

Description
The aim of the script is to bypass the 403 response code and give out the response code for each retry in colored output to be easy to read.
Fixes #88
Have you read the Contributing Guidelines on Pull Requests?

[x] Yes

Type of change

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update
[x] Documentation Update

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[x] I've edited the README.md and link to my code.
[x] I have created a helpful and easy to understand README.md
[x] My documentation follows Template for README.md
[x] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works.

okay i will fix that


feat: add docs for GoTrue

Attempts to mirror the effort by great @anand2312 on the storage-py library.
A few pointers which need to be addressed:

[x] Get autodoc to properly parse error docstrings

Notes
Sphinx seems to have an unresolved dependency conflict with flake8.
As such, I've left it in a dependency group similar to how it was resolved in this issue

@J0 maybe we can try to use https://github.com/charliermarsh/ruff as a replacement for flake8

Going to merge for now, will do any modifications to add ruff in a follow up PR


[FR]: Support passing args to js_test

What is the current behavior?
A nice pattern for running tests using Node dependencies as binaries looks like:

directory_path(
    name = "vitest_entry_point",
    directory = "//:node_modules/vitest/dir",
    path = "vitest.mjs",
)

js_test(
    name = "tests",
    chdir = package_name(),
    data = [
        "path/to/tests.js"
    ],
    entry_point = ":vitest_entry_point",
)

However, there is no way to pass arguments to this, test e.g. vitest --run.
A current workaround involves writing a wrapper JS file, e.g.:
process.argv.push('--run')
import('vitest/vitest.mjs')

and then setting that file as the entry_point. But, this causes issues with chdir and paths.
Describe the feature
Ideally, js_test would support args so we could write this with:

directory_path(
    name = "vitest_entry_point",
    directory = "//:node_modules/vitest/dir",
    path = "vitest.mjs",
)

js_test(
    name = "tests",
    args = ["--run"],
    chdir = package_name(),
    data = [
        "path/to/tests.js"
    ],
    entry_point = ":vitest_entry_point",
)

args is already supported as it is a built-in attribute to all *_test rules in Bazel: https://bazel.build/reference/be/common-definitions#common-attributes-tests

You're right, my bad - my example code actually works. Thank you.


Help and suggestions

Am not able to get how to extract the single line of handwritten text from the form.please can you help me to figure out how I can do that

Hi,
this repo was more like an exploration and evaluate some options in the market.
Unfortunately, I didn't find any viable solution for my use case. So, I created a new tool which would focus on a specific segmentation method.

Most of our documents were using joined frame. The tool support joined frame only right now, but I'm open to check for others as well. Joined frame was easier to support on unknown document and scanned documents with bad quality..
I thought initially that a could clean the paper-based form and then use Tesseract to extract the text. I got poor results and I didn't feel confident enough to put it in production.
I found a paper which describe a way to detect fields. (https://github.com/doxakis/ICR-detection-in-filled-form/blob/master/papers/ICR Detection in filled form and form removal.pdf)
The idea is use line junctions to compose the field and improve confident if we find enougth adjacent cells.
I created this repo: https://github.com/doxakis/ICR-detection-in-filled-form
I did a lot and experiments (c++, python, c#) and finally, the end result has been moved to https://github.com/OpenFieldReader/OpenFieldReader.
I prepared a linux package which contains the c# code to find the fields. I plan doing a wrapper (python), but I didn't take the time.
I will continue the discussion which will give more details on how to use it in the issue you opened here: https://github.com/OpenFieldReader/OpenFieldReader/issues/1

Hi, I will close the issue for now. Feel free to open it again if you have any question.


Testing framework

This project currently does not have enough tests to ensure the faithfulness of the exported model to the original. A test harness should be written that compares the output of the original predictor against its exported model run through an external PMML execution engine.

See jpmml_test, and examples of using it sklearn-pmml/sklearn_pmml/convert/test/test_decisionTreeClassifierConverter.py.  It runs the original sklearn model against the exported model via JPMML (invoking via mvn) and compares the output.

Oh, very good

Hey all! I just started familiarizing myself with this project today. I'm running on OSX, with Java 1.7.0_78, and Maven 3.3.3. Running py.test results in two failures and one error.
Here's a gist of my py.test output.
https://gist.github.com/ngould/09a236af202e0ab15653
Wondering if you're seeing the same thing, or if I have a problem with my setup. I'm not all that familiar with Java and Maven, so this could be due to ignorance on my part. Any ideas?
Also, are log outputs like this anything to be concerned about?
2015-08-29 19:30:09,884 Unable to convert DOM node output at [UNAVAILABLE] to binding
2015-08-29 19:30:09,885 Unable to convert DOM node x1 at [UNAVAILABLE] to binding
2015-08-29 19:30:09,885 Unable to convert DOM node x2 at [UNAVAILABLE] to binding

I'd love to help contribute to the project. Is there a mailing list, IRC channel, etc?

Hey @ngould!  There isn't currently a mailing list, IRC channel etc... we've just been using github issues/ to communicate, though as it grows we should make something more usable.  Looking at that it seems as if I set the target to be 1.8 for the JPMML integration tests, rather than 1.7 which you are running on.  I'll change the target to be 1.7, since that's all that's required.


Host the updated template on github pages

Configure github pages to host the page setup.

Page has been updated. Here is the link : https://anaeronbaggins.github.io/varunkapoor/


[nu-book/zxing-cpp] update to 1.4.0

Describe the pull request

What does your PR fix?
Fixes #27704

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

Does your PR follow the maintainer guide?

Yes

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

Should we upgrade this port, or make a new port named "zxing-cpp" and deprecate this one?

Thank you!


Bug: string array comparison with toBe()

Using jest 20.0.4.
let arr = [ "hello", "world" ];
expect( arr ).toBe( arr );

FAILS, reporting:
 expect(received).toBe(expected)

 Expected value to be (using ===):
      ["hello", "world"]
    Received:
      ["hello", "world"]

    Difference:

    Compared values have no visual difference.

Sorry, I think I should be using toEqual instead of using toBe, right?

Depends if you need strict equality or not. Your example should work, here's example on repl.it: https://repl.it/JyOW/1


[TS] ListItemProps seems broken

There are typescript errors when passing props of type ListItemProps to ListItem:
const MyListItem = (props: ListItemProps) => <ListItem {...props} />

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔
No errors.
Current Behavior 😯
Type '{ alignItems?: "flex-start" | "center"; button?: boolean; ContainerComponent?: ElementType<HTMLAttributes<HTMLDivElement>>; ContainerProps?: HTMLAttributes<HTMLDivElement>; ... 263 more ...; onTransitionEndCapture?: (event: TransitionEvent<...>) => void; }' is not assignable to type '{ button: true; }'.
  Types of property 'button' are incompatible.
    Type 'boolean' is not assignable to type 'true'

The error disappears when providing button={false} explicitly:
const MyListItem = (props: ListItemProps) => <ListItem {...props} button={false} />

Steps to Reproduce 🕹
Link:

https://codesandbox.io/s/create-react-app-with-typescript-4iubx

Context 🔦
I'm trying to customize ListItem wrapper in the typescript project
Your Environment 🌎

Tech
Version

Material-UI
v4.1.0

React
v16.8.x

Browser

TypeScript
v3.5.1

etc.

Duplicate of #14971


feat: Add maxBatchingDelayMs Option.

Adds support for max batching delay option in Commit requests.
This feature allows users to express how much latency they are willing for spanner to add to attempt to batch their writes. Generally speaking, the more latency they are willing to tolerate, the more efficiently Spanner can serve the writes.

Closing this PR due to no-activity. Please re-open when this is ready for review.


runtime test

Hello. I am using your project for my own purposes, but I encountered the following problem. Why is there such a big time difference between requests (the code is the same)? How to fix it? (Windows OS)

I cannot tell you the exact reason. It is generally caused by business logic, and you need to troubleshoot it yourself. The troubleshooting method is to find suspicious code snippets, record the execution time of the code snippets, and continue until you find the key code. In addition, the first request after the process starts may be slightly slower because it needs to load the code from the disk into memory and initialize the database connection.

May another reason of multiple work processes.
First connection to a worker that have hot code or data loaded, but next request to another worker is not.


libp2p/crypto/minasn1.nim doesn't build on Nim version-2-2/devel

https://github.com/nim-lang/Nim/issues/24125
Not a terribly high-priority bug, but worth documenting here so no one else spends time hunting down the root cause of this.
The specific error one gets is:
nim-libp2p/libp2p/crypto/minasn1.nim(392, 36) Error: type mismatch
Expression: safeConvert[int](b)
  [1] b: byte

Expected one of (first mismatch at [position]):
[2] template safeConvert[T: SomeInteger; S: Ordinal](value: S): T
  missing generic parameter: S

and apparently was an accident it worked at all.

Thanks for reporting it. Could you please explain why it was an accident it worked at all?

Araq in https://github.com/nim-lang/Nim/issues/24125#issuecomment-2354530627 notes:

Partial explicit generic instantations are not in the language spec.

What would you recommend here? I'm not sure this proc is necessary.

template safeConvert*[T: SomeInteger](value: SomeOrdinal): T =
  ## Converts `value` from S to `T` iff `value` is guaranteed to be preserved.
  when int64(T.low) <= int64(typeof(value).low()) and
       uint64(T.high) >= uint64(typeof(value).high):
    T(value)
  else:
    {.error: "Source and target types have an incompatible range low..high".}

for example


You run this terminal in sh mode.

This message shows up in terminal at below , and  i don't know why
:/ # su
:/ # energized
You run this terminal in sh mode.
=> You must run in sh mode.

Energized is only compatible with sh.

fixed

fixed

Indeed, it has been fixed with the last BETA, also the last BETA works for you?