[Mainnet] Playground: Huge number of requests on initialization

Description
huge number of fetch requests most of them to the same endpoint with different page number
Screencast from 07 نوف, 2023 EET 10:49:34 ص.webm
Steps to reproduce
go to https://playground.grid.tf/#/
Log in and check the network tab

try to force reload if it is not reproducible.

Currently, retrieving offline nodes involves multiple requests and loops, causing inefficient use of resources and impacting performance. This issue is currently blocked on tfgrid-sdk-go issue #423. Once resolved, it will enable a more streamlined approach to handling offline nodes.
Current Behavior:

Multiple Requests: The system requests the grid proxy for offline nodes, which returns paginated results. If there are many offline nodes (e.g., 1000), this results in numerous requests (e.g., 20~100 requests) due to pagination.

Array Comparison: Alternatively, the system loops through node IDs and user contracts to check if the contract's node ID exists in the node IDs array.

Proposed Solution:
Once tfgrid-sdk-go issue #423 is resolved, the system can optimize performance by:

Making a single request with an array of specific node IDs (e.g., [1, 2, 3, 4, 5]) representing the offline nodes.
Receiving an array of node objects directly related to the requested node IDs, eliminating the need for multiple requests and loops.

This optimized approach significantly improves performance and reduces unnecessary resource consumption.

verified
env used : devnet
version : 7f4d8ea

@khaledyoussef24
Please keep in mind that this issue needs to be re-verified on mainnet.

also verified on mainnet only two requests were made


[ODS-4488] Fix broken composite features reported by the postman tests

reopening as these changes are required


Reading unicode from command line.

@freerdp-bot test

@freerdp-bot ok, test again

LGTM,
and we have an happy client. Let's merge that.


fix: the email input box style issue of contact us section.

Title and Issue number

Title : Fixed the email input box style issue of contact us section.
Issue No. : #1060
Code Stack : CSS
Close #1060

Description

Fixed the email input box style issue of contact us section.
Now, all the 3 input boxes have same style.

Video/Screenshots (mandatory)

Type of PR

[x] Bug fix
[ ] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Checklist:

[x] I have performed a self-review of my code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have gone through the  contributing.md file before contributing

Additional context:

##Are you contributing under any Open-source programme?

yes GSSoC'24

[x] I am contributing under GSSOC'24
[ ] I am contributing under VSOC'24

@apu52 , @itsekta Please review & merge this pr under GSSoC'24


Velocity is already loaded/l.velocity is not defined :|

Slightly annoying going in circles, following dead-end comments # trying to load jquery from a cdn (which succeeds but chokes in use in a @Component. Does anybody have the current solution?

including the below in my webpack config produces the above
new ProvidePlugin({
jQuery: 'jquery',
$: 'jquery',
jquery: 'jquery'
})

[SOLVED]
The above can be indicative of multiple loads of jQuery.
My app in progress is actually targeted as a 'plugin' of a larger app built on a different stack, and logically I wanted to leverage the cached Materialize/jQuery already used by the parent app.
Therein, I'd cloned the  tags for the plugin index, loaded in iFrame but not omitted Materialize and jQuery from the webpack builds. The following solves this cross-loading technique.
WebPack Config
        plugins: [
          ...
            // Make $, jQuery Hammer, etc available in every module without writing require("jquery")
            new ProvidePlugin({
                jQuery: 'jquery',
                $: 'jquery',
                'window.$': 'jquery',
                'window.jquery': 'jquery',
                Hammer: "hammerjs/hammer"
            }),
        ],

        // let WebPack know we've already got these resources in the browser
        externals: [{
            'materialize-css': 'Materialize',
            jquery: 'jQuery',
        }],

https://github.com/Dogfalo/materialize/issues/1229


Any plan about caching on disk to speed up the loading upon initialization?

Hi all,
I've read some issues related to caching but it is still not implemented in rust-analyzer. I wonder would it be a potential feature to be implemented? Or caching the previous states on disk does not conform to the designing philosophy of rust-analyzer? (If so I may implement it for myself to use, lol:D)
Thanks!

This was discussed a bit in https://github.com/rust-analyzer/rust-analyzer/issues/1650. TL;DR persisting the analysis data would be really nice, but it's hard to implement and doesn't help when opening a project for the first time. So it kind of makes sense to optimize what we have before adding persistence, because then we'll be less likely to go back and work on it.

There's also #4712, of which I think we can count this as a duplicate.


Make each .treeview mandatorily overflow with scroll

Fixes #764

that should be fixed now. please reopen the PR if not.


Integrate from Memgraph new C++ API

Description
Please briefly explain the changes you made here.
Pull request type

[ ] Bugfix
[ ] Algorithm/Module
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Related issues
Delete if this PR doesn't resolve any issues. Link the issue if it does.
######################################
Reviewer checklist (the reviewer checks this part)
Module/Algorithm

[ ] Core algorithm/module implementation
[ ] Query module implementation
[ ] Unit tests
[ ] End-to-end tests
[ ] Code documentation
[ ] README short description
[ ] Documentation on memgraph/docs

######################################

@antoniofilipovic shouldn't this be completely closed because we put the C++ API under the memgraph repo? CC @antepusic

Since multiple files have to be copied now, do we put (submodule or download) the memgraph inside mage and reference those files (it makes more sense not to copy them)? This is a pure software maintenance type of question... CC @jbajic

I am not sure what is the best solution, but copying definitely seems like an improper solution. I can investigate since this PR is blocked until a new Memgraph is released.

Since multiple files have to be copied now, do we put (submodule or download) the memgraph inside mage and reference those files (it makes more sense not to copy them)? This is a pure software maintenance type of question... CC @jbajic

I am not sure what is the best solution, but copying definitely seems like an improper solution. I can investigate since this PR is blocked until a new Memgraph is released.

My suggestion would be to have memgraph as a submodule since it is easier to just bump up the submodule commit and keep up with the newest changes. then to c/p same files

Since multiple files have to be copied now, do we put (submodule or download) the memgraph inside mage and reference those files (it makes more sense not to copy them)? This is a pure software maintenance type of question... CC @jbajic

I am not sure what is the best solution, but copying definitely seems like an improper solution. I can investigate since this PR is blocked until a new Memgraph is released.

My suggestion would be to have memgraph as a submodule since it is easier to just bump up the submodule commit and keep up with the newest changes. then to c/p same files

Okay, I will investigate

Closing this PR as we continued development on other one.


Use is version instead of |version_compare

Using tests as filters is deprecated and version_compare was renamed
to version in Ansible 2.5.

version_compare was renamed
to version in Ansible 2.5.

Fortunately Ansible 2.4 was just EOL'd (https://access.redhat.com/support/policy/updates/ansible-engine)

[citest]

[citest bad]


New IAF implementation with inverse operation

This pull request contains a new IAF implementation that uses a slightly different formula (also from the IAF paper). This matches the TF implementation and should improve performance I believe on the DMM example. The old version of IAF is moved to class InverseAutoregressiveFlowStable.
Explicit inverses are calculated for both InverseAutoregressiveFlow and InverseAutoregressiveFlowStable when required.
I've added in MaskedAutoregressiveFlow and NeuralAutoregressiveFlow. For these, the numerical gradient doesn't seem to match the analytical one, but I don't think it's due to an incorrect formula. I think it's caused by limitations in the method used to calculate the numerical gradient. I think that the gradient calculation for MAF could work if I use dx/dy rather than dy/dx (which has to be calculated by inverting the operation). I'm not sure about NAF...
I've separated out the tests for autoregressive flows from those for autoregressive networks.

Codecov Report

Merging #1352 into dev will increase coverage by 0.04%.
The diff coverage is 97.26%.

@@            Coverage Diff             @@
##              dev    #1352      +/-   ##
==========================================
+ Coverage   95.68%   95.72%   +0.04%
==========================================
  Files         123      123
  Lines        6442     6501      +59
==========================================
+ Hits         6164     6223      +59
  Misses        278      278

Impacted Files
Coverage Δ

pyro/distributions/__init__.py
100% <100%> (ø)
:arrow_up:

pyro/contrib/autoguide/__init__.py
99.29% <100%> (ø)
:arrow_down:

pyro/distributions/iaf.py
97.98% <97.14%> (+3.11%)
:arrow_up:

Continue to review full report at Codecov.

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

@stefanwebb thanks! can you please split this into at least two PRs? maybe peeling off the NeuralAutoregressive* bits? it's difficult to review 700 lines of code in one go

Let me have another go at submitting this PR and the FlipFlow one tomorrow. I'll break this one into three and remove the IAF stuff from the FlipFlow one so they're all independent

great, thanks. maybe while you're at it rename flipflow to something like PermutedDistribution? doesn't something like that seem a better fit?

Yeah I agree
On Mon, 3 Sep 2018 at 22:08, martinjankowiak<EMAIL_ADDRESS>wrote:

great, thanks. maybe while you're at it rename flipflow to something like
PermutedDistribution? doesn't something like that seem a better fit?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/uber/pyro/pull/1352#issuecomment-418193147, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEsrXqLBY_F2vj1UhLzRtB56tFSaypAuks5uXZpVgaJpZM4WWUUY
.

@stefanwebb what's the status of this PR? No hurry, I just want to make sure you're unblocked.

Nothing is blocking me at the moment, except an important conference deadline tomorrow. I look forward to getting back on this on Friday though

Hey,
I see you closed this issue. However, I was quite fond of it. Any updates
on how this is going?
Cheers,
T.
On Tue, Oct 23, 2018 at 1:49 PM Stefan Webb<EMAIL_ADDRESS>wrote:

Closed #1352 https://github.com/uber/pyro/pull/1352.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/uber/pyro/pull/1352#event-1921696228, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABVhL-YfdugSd9NPc7BLkaaOI8dp1kSwks5un4C9gaJpZM4WWUUY
.

Ah sorry, yes I'm breaking it up into several pull requests, which I'll do in sequence

About to do the first one...

P.s. I'm glad you liked it!


Migrate Spaces to new instance

Description
Currently there is no way of migrating one OCIS installation (with all Spaces included) to another, with a different backend (POSIX -> S3NG, or vice versa).
User Stories

As a sys-admin, I want to be able to copy spaces verbatim, so that I can migrate data to other storage backends.

Value

Ease migration between storage backends

Behavior before: Copy data-directory, recreate all spaces, rclone two different space ids
Behavior after: Copy data-directory, rclone with same space id on both sides

Retain Space-Ids

env SPACEID=00000000-0000-0000-0000-000000000000 bash -c 'rclone ocis-source:${SPACEID} ocis-target:${SPACEID}'

Acceptance Criteria

XCopyable data-directory
Copying over data from OCIS migration source to OCIS migration target using RClone with Space IDs retained
Spaces don't need to retain their data

Definition of ready

[ ] Everybody needs to understand the value written in the user story
[ ] Acceptance criteria have to be defined
[ ] All dependencies of the user story need to be identified
[ ] Feature should be seen from an end user perspective
[ ] Story has to be estimated
[ ] Story points need to be less than 20

Definition of done

Functional requirements

[ ] Functionality described in the user story works
[ ] Acceptance criteria are fulfilled

Quality

[ ] Code review happened
[ ] CI is green (that includes new and existing automated tests)
[ ] Critical code received unit tests by the developer

Non-functional requirements

[ ] No sonar cloud issues

Configuration changes

[ ] The next branch of the ocis charts is compatible

But we could build a similar command that migrates blobs from one store to another.

Yes. That is what i meant. But you already did some ground work in reva to export some props to get that done.

Sounds good :+1:
So the action item would be to create a cli command that copies all blobs from one blobstore into another. Using the new List method on the source blobstore should make this a straightforward task. We will not validate anything, just copy the blobs into the new store.

That would be fine by me, and even more premium than the initial option of just keeping the ids and copying data manually.

Updated entry post.
Anything to amend?

@tbsbdr @dragotin we need to squeeze that in.

Added to backlog. Candidate for next sprint.

I am reading this as 'only copy blobs between blobstores' not anything related to metadata, right? The latter would require a Dump and Load mechanism for node metadata.


Why does page.$eval() throw an error if no match found?

Confusing because document.querySelector() just returns null.
I'm using Puppeteer to scrape a utterly horrendous .NET UI. Unfortunately I have a scenario where if one element exists, I'll assign it to version, if not I look for the dropdown's selected value.
Puppeteer 0.12.0 ( MacOS 10.13 )
const getVersion = async () => {
  // this is because if there are multiple versions, .net will create a dropdown
  let single = await resultPage.$eval('#ctl00_ContentPlaceHolder1_lblVersion2', el => el.innerHTML )
  if ( +single ) {
    return single
  } else {
    return await resultPage.$eval('#ctl00_ContentPlaceHolder1_lstVersion2 > option[selected="selected"]', el => el.innerHTML )
  }
}

Great software by the way. Thank you

I solved it by using page.evaluate() with a document.querySelector() inside. Still doesn't answer my question about the design decision to throw an error of page.$eval() doesn't find a match.
const getVersion = async () => {
  // this is because if there are multiple versions, .net will create a dropdown
  return await resultPage.evaluate( () => {
    const single = document.querySelector( '#ctl00_ContentPlaceHolder1_lblVersion2' )
    const dropDown = document.querySelector( '#ctl00_ContentPlaceHolder1_lstVersion2 > option[selected="selected"]' )
    // check if exists
    if ( single ) {
      return single.innerHTML
    } else {
      return dropDown.innerHTML
    }
  } )
}

I think one challenge here is that page.$eval() does more than one thing. It finds the element  and also runs your callback code. If it just returned null, is that b/c the element couldn't be found or the resolve value from the callback?

Fair.
Element could not be found:
Error: Error: failed to find element matching selector "#ctl00_ContentPlaceHolder1_lblVersion2"
It could still find the element and run callback with a null value assigned param, right?


[WIP] Change MV mode if NEAREST isn't NEAREST anymore

Addresses same issue as #532 but without speed penalty. RD penalty to be determined

PSNR
PSNR Cb
PSNR Cr
PSNR HVS
SSIM
MS SSIM
CIEDE 2000

1.8231
1.5903
2.0027
1.8724
1.8174
1.8226
1.7642

Is above awcy results saying rergession?
Otherwise,  just the comparison direction is this patch --> ref, and an improvement?

yes, it's an RD regression wrt to master at speed 1. But it runs 20-25% faster


Configure tracker store in configuration file

Feature request:
Add configuration for tracker store to domain.yml or other configuration file. Something like this:
tacker_store:
  mongo:
     host: http://localhost:27017
     db: rasa
     user: user
     password: pass
     collection: conversations

Then this information can be used to configure tracker store while running Rasa with run.py.

This was already solved long time aga. Thx! Closing. :)


[New Endpoint] EntityCopyEntityMutation

Definition
Message (TypeScript definition)
interface Message {
  type: 'EntityCopyEntityMutation'
  payload: Payload
}

interface Payload {
  entityId: number!,
  userId: number!
}

Output (TypeScript definition)
interface Output {
  entityId: number!
}

Description what happens in the database layer
Creates a new entity with the same properties as the given entity. Also copies possible children.
Necessary checks / possible errors

[ ] Only entities which don't have a parent entity are allowed to be copied.
[ ] Set entity_links for possible children.

(What would this be used for?)

It's a user wish in backlog. There are two use cases. 1. User wants to create a new Entity with similar structure/content. 2. User wants to translate a page.


haskell.packages.ghc942: make it work

Description of changes
Bring up ghc-9.4 enough that I can run hpack and the HLS dev shell, and HLS (with some limited overrides). It's still fairly thoroughly jacked. I copied the definitions from ghc-9.2 as a starting point then started fixing stuff.
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.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Thank you for working on this! This is much needed. I am a bit weary of just carrying forward all those overrides without being sure if they are all needed/desirable. On the other hand this is probably the smart thing to do.

Me too, I'd love to factor them out into a >=9.2 file but i have no idea how to.

Currently you are including a breaking change for callCabal2nixWithOptions in this PR was that maybe a mistake?

Only half a mistake; I needed it for a project and didn't want to deal with another branch. It's not breaking as it's backward compatible: I added callCabal2nixWithOptions' which lets you configure the source filter for cabal files, which is necessary to use hpack include directives, but callCabal2nixWithOptions remains as-is with the same API. If you'd like me to split it into another PR I can do that for you.

If you'd like me to split it into another PR I can do that for you.

Please do, I think it needs separate discussion.
My request would be to remove all overrides that don't actually lead to a working package.

Reverted, going to let my computer crunch on the builds for a while on those reverts.

note to self for later:
error: build of '/nix/store/0b6znjv12cl3kipiwq7b4s7xybwghffc-ghc-source-gen-<IP_ADDRESS>.drv', '/nix/store/0hd4mzb9hr4baihj5f5d3x2577rkvy9r-regex-rure-<IP_ADDRESS>.drv', '/nix/store/0yddwkana0pv7av04bb2paim2shf5d6d-hlint-3.4.1.drv', '/nix/store/48glx2agpmdwca45c6r5b4yk1y7ppafg-servant-docs-0.12.drv', '/nix/store/4qkhwazmgqskvksjvrcyidswrhsfhf7p-servant-auth-server-<IP_ADDRESS>.drv', '/nix/store/4xdlj3cv91x6b3fbs7x5z51bxdq4bmx0-ghc-lib-parser-ex-<IP_ADDRESS>.drv', '/nix/store/6q10wnxz5hbq9yh5pk1pz8gpvc1p1cy8-servant-auth-swagger-<IP_ADDRESS>.drv', '/nix/store/awshsdbxhghwrd50rq759hvrh4az60ns-retrie-<IP_ADDRESS>.drv', '/nix/store/d8xcydixmv2x5m3g8gvynjzz1gyjcyc5-cabal-install-<IP_ADDRESS>.drv', '/nix/store/f5a7wg75f4sj0xgvza43ys2vd1hl54c9-servant-auth-docs-<IP_ADDRESS>.drv', '/nix/store/f984zfznhqlccy4cpm9f9ngh0v6my07c-tomland-<IP_ADDRESS>.drv', '/nix/store/fc8yypsh1xq3npv1hk4jhk0qgdyl32a5-tasty-hedgehog-<IP_ADDRESS>.drv', '/nix/store/fkq40aylz9jy6z2ma4nf3i8al59sw1w0-servant-auth-<IP_ADDRESS>.drv', '/nix/store/hls03ka4lm2lnxjz7a66964l9dcqf7lf-jacinda-<IP_ADDRESS>.drv', '/nix/store/m1m1vimd67s4xim2qpsymg5g30vx2iq9-ormolu-<IP_ADDRESS>.drv', '/nix/store/m7ly3c0j05ji6v9l1qf3yki4nwvs78rf-double-conversion-<IP_ADDRESS>.drv', '/nix/store/md1lfhll1gbc6xbhvc03xc6w2d3xhpn3-ghc-lib-<IP_ADDRESS>20729.drv', '/nix/store/mgp1iz5lcrfy52wqaf90qkd5j4lpbgf5-servant-swagger-1.1.11.drv', '/nix/store/nrlzk5cxfkh1i91k58i0xwsydjjdhv51-hiedb-<IP_ADDRESS>.drv', '/nix/store/nx7pacybizx0xvas9bs2ww2j8b9r5mfk-servant-multipart-0.12.1.drv', '/nix/store/pjvhx5d80pzs7qwknbsqsf5mifp13xfn-hls-fourmolu-plugin-<IP_ADDRESS>.drv', '/nix/store/pk8yi0rp8yv635cdvwkr25vv7wpf4qzs-servant-foreign-0.15.4.drv', '/nix/store/qdn7x08bgcksyg87pih1c513mkrk45mx-implicit-hie-cradle-<IP_ADDRESS>.drv', '/nix/store/sai0kx6issymhsza5kywsbfjaii7jnca-shelly-1.10.0.drv', '/nix/store/sfhqp52p1gjy218ywwhi57spwb2jbshg-hls-ormolu-plugin-<IP_ADDRESS>.drv', '/nix/store/vmlj0lh36297170nfvv2n3i7988vkli7-servant-0.19.drv', '/nix/store/w595libzbvkxjaqfr22abm6j7ka3l4pc-ghc-exactprint-1.5.0.drv', '/nix/store/wclj4pi9j8dhs47pzmx25v5kwk3idsxb-dbus-1.2.26.drv', '/nix/store/wfnzx2dg7g5r1n7d31gqllxk2hrajbl8-fourmolu-<IP_ADDRESS>.drv', '/nix/store/wr6ssw2alp3vh8kzsxjjgdn893ymd5xv-ghc-lib-parser-<IP_ADDRESS>20729.drv', '/nix/store/xb2sgw3jkh13939xa3kqm31x0nrrxdsv-doctest-0.20.0.drv', '/nix/store/zrhnrf6p320nw1dyzw1bx6y1qx1qd49z-aeson-diff-<IP_ADDRESS>.drv' failed

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/how-to-get-ghc-9-4-2-on-nixos/22130/2

tasty-hspec seems to hit a possible Cabal bug:
setupCompilerEnvironmentPhase
Build with /nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2.
unpacking sources
unpacking source archive /nix/store/7qdf9509d4qryj35n97cwrv9n43z5939-tasty-hspec-<IP_ADDRESS>.tar.gz
source root is tasty-hspec-<IP_ADDRESS>
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file tasty-hspec-<IP_ADDRESS>/tasty-hspec.cabal
patching sources
Replace Cabal file with edited version from mirror://hackage/tasty-hspec-<IP_ADDRESS>/revision/1.cabal.
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/tmp.AzzXF5C2Nn/setup-package.conf.d -j4 +RTS -A64M -RTS -threaded -rtsopts
[1 of 2] Compiling Main             ( Setup.hs, /build/tmp.AzzXF5C2Nn/Main.o )
[2 of 2] Linking Setup
configuring
configureFlags: --verbose --prefix=/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS> --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/b5w8r3bc5vwmk4kx5jqfjhd20visrcbz-tasty-hspec-<IP_ADDRESS>-doc/share/doc/tasty-hspec-<IP_ADDRESS> --with-gcc=gcc --package-db=/build/tmp.AzzXF5C2Nn/package.conf.d --ghc-options=-j4 +RTS -A64M -RTS --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --ghc-options=-haddock --extra-lib-dirs=/nix/store/fw7wl6m3jc2zcrj5zq794xcpb281dnh5-ncurses-6.3-p20220507/lib --extra-lib-dirs=/nix/store/3cac527kk6fsgvxgf1x7v0r1mg2j42ng-libffi-3.4.2/lib --extra-lib-dirs=/nix/store/gdrxvhnf6zh41r861a86zvcv0w0cy0rp-gmp-with-cxx-6.2.1/lib --extra-lib-dirs=/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/lib
Using Parsec parser
Configuring tasty-hspec-<IP_ADDRESS>...
Dependency QuickCheck >=2.7 && <2.15: using QuickCheck-2.14.2
Dependency base >=4.9 && <4.18: using base-<IP_ADDRESS>
Dependency hspec >=2.5 && <2.11: using hspec-2.10.6
Dependency hspec-core >=2.5 && <2.11: using hspec-core-2.10.6
Dependency tasty >=0.8 && <0.13 || >=1.0 && <1.5: using tasty-<IP_ADDRESS>
Dependency tasty-quickcheck >=0.3 && <0.9 || >=0.9.1 && <0.11: using
tasty-quickcheck-0.10.2
Dependency tasty-smallcheck >=0.1 && <0.9: using tasty-smallcheck-0.8.2
Source component graph: component lib
Configured component graph:
    component tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        include QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        include base-<IP_ADDRESS>
        include hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        include hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        include tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        include tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        include tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
Linked component graph:
    unit tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        include QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        include base-<IP_ADDRESS>
        include hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        include hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        include tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        include tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        include tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
        Test.Tasty.Hspec=tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm:Test.Tasty.Hspec
Ready component graph:
    definite tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        depends QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        depends base-<IP_ADDRESS>
        depends hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        depends hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        depends tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        depends tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        depends tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
Warning:
    This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
      package hspec (hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4) requires hspec-core-2.10.6-1YaOpTrOnZw95xaaCyezQr
      package tasty-hspec (tasty-hspec-<IP_ADDRESS>) requires hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
Using Cabal-<IP_ADDRESS> compiled by ghc-9.4
Using compiler: ghc-9.4.2
Using install prefix:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>
Executables installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/bin
Libraries installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/lib/ghc-9.4.2/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
Dynamic Libraries installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/lib/ghc-9.4.2/x86_64-linux-ghc-9.4.2
Private executables installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/libexec/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>
Data files installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/share/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>
Documentation installed in:
/nix/store/b5w8r3bc5vwmk4kx5jqfjhd20visrcbz-tasty-hspec-<IP_ADDRESS>-doc/share/doc/tasty-hspec-<IP_ADDRESS>
Configuration files installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/etc
No alex found
Using ar found on system at:
/nix/store/mx37gfqvx3kh8icib3k9jhvw8pv66ryv-binutils-2.39/bin/ar
No c2hs found
No cpphs found
No doctest found
Using gcc version 11.3.0 given by user at:
/nix/store/j061mvdxw70xz20r2r0lr5lk0rcsjf9i-gcc-wrapper-11.3.0/bin/gcc
Using ghc version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/ghc
Using ghc-pkg version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/ghc-pkg-9.4.2
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.27.0 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/haddock-ghc-9.4.2
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.68 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/hpc
Using hsc2hs version 0.68.8 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/hsc2hs
Using hscolour version 1.24 found on system at:
/nix/store/9br4bs74rvsl039lpq65lxqq6v59vmyc-hscolour-1.24.4/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/hk75004j435l09ij4gawlkzg4wfs839w-binutils-wrapper-2.39/bin/ld.gold
No pkg-config found
Using runghc version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/runghc-9.4.2
Using strip version 2.39 found on system at:
/nix/store/j061mvdxw70xz20r2r0lr5lk0rcsjf9i-gcc-wrapper-11.3.0/bin/strip
Using tar found on system at:
/nix/store/gb4zp7iygbkr3bqfv9p38q3ci04m4m5s-gnutar-1.34/bin/tar
No uhc found
*** abort because of serious configure-time warning from Cabal

The additional hspec-core-2.10.6-1YaOpTrOnZw95xaaCyezQr it complains about doesn't seem to actually exist.

tasty-hspec seems to hit a possible Cabal bug:
setupCompilerEnvironmentPhase
Build with /nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2.
unpacking sources
unpacking source archive /nix/store/7qdf9509d4qryj35n97cwrv9n43z5939-tasty-hspec-<IP_ADDRESS>.tar.gz
source root is tasty-hspec-<IP_ADDRESS>
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file tasty-hspec-<IP_ADDRESS>/tasty-hspec.cabal
patching sources
Replace Cabal file with edited version from mirror://hackage/tasty-hspec-<IP_ADDRESS>/revision/1.cabal.
compileBuildDriverPhase
setupCompileFlags: -package-db=/build/tmp.AzzXF5C2Nn/setup-package.conf.d -j4 +RTS -A64M -RTS -threaded -rtsopts
[1 of 2] Compiling Main             ( Setup.hs, /build/tmp.AzzXF5C2Nn/Main.o )
[2 of 2] Linking Setup
configuring
configureFlags: --verbose --prefix=/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS> --libdir=$prefix/lib/$compiler --libsubdir=$abi/$libname --docdir=/nix/store/b5w8r3bc5vwmk4kx5jqfjhd20visrcbz-tasty-hspec-<IP_ADDRESS>-doc/share/doc/tasty-hspec-<IP_ADDRESS> --with-gcc=gcc --package-db=/build/tmp.AzzXF5C2Nn/package.conf.d --ghc-options=-j4 +RTS -A64M -RTS --disable-split-objs --enable-library-profiling --profiling-detail=exported-functions --disable-profiling --enable-shared --disable-coverage --enable-static --disable-executable-dynamic --enable-tests --disable-benchmarks --enable-library-vanilla --disable-library-for-ghci --ghc-option=-split-sections --ghc-options=-haddock --extra-lib-dirs=/nix/store/fw7wl6m3jc2zcrj5zq794xcpb281dnh5-ncurses-6.3-p20220507/lib --extra-lib-dirs=/nix/store/3cac527kk6fsgvxgf1x7v0r1mg2j42ng-libffi-3.4.2/lib --extra-lib-dirs=/nix/store/gdrxvhnf6zh41r861a86zvcv0w0cy0rp-gmp-with-cxx-6.2.1/lib --extra-lib-dirs=/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/lib
Using Parsec parser
Configuring tasty-hspec-<IP_ADDRESS>...
Dependency QuickCheck >=2.7 && <2.15: using QuickCheck-2.14.2
Dependency base >=4.9 && <4.18: using base-<IP_ADDRESS>
Dependency hspec >=2.5 && <2.11: using hspec-2.10.6
Dependency hspec-core >=2.5 && <2.11: using hspec-core-2.10.6
Dependency tasty >=0.8 && <0.13 || >=1.0 && <1.5: using tasty-<IP_ADDRESS>
Dependency tasty-quickcheck >=0.3 && <0.9 || >=0.9.1 && <0.11: using
tasty-quickcheck-0.10.2
Dependency tasty-smallcheck >=0.1 && <0.9: using tasty-smallcheck-0.8.2
Source component graph: component lib
Configured component graph:
    component tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        include QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        include base-<IP_ADDRESS>
        include hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        include hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        include tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        include tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        include tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
Linked component graph:
    unit tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        include QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        include base-<IP_ADDRESS>
        include hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        include hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        include tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        include tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        include tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
        Test.Tasty.Hspec=tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm:Test.Tasty.Hspec
Ready component graph:
    definite tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
        depends QuickCheck-2.14.2-3tClwZe1MDbLIlIgpxfKkC
        depends base-<IP_ADDRESS>
        depends hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4
        depends hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
        depends tasty-<IP_ADDRESS>-KylMI6VfqDu6zatv8M3Rf4
        depends tasty-quickcheck-0.10.2-5d6Mmyqw94Q2ygyHB68mwL
        depends tasty-smallcheck-0.8.2-LOkXEKlXvkjGHGbsJBa02w
Warning:
    This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
      package hspec (hspec-2.10.6-Fl3P4tqYSgk4Pft4nVrVI4) requires hspec-core-2.10.6-1YaOpTrOnZw95xaaCyezQr
      package tasty-hspec (tasty-hspec-<IP_ADDRESS>) requires hspec-core-2.10.6-93d1KMsgtAZL9XXcrjnZoK
Using Cabal-<IP_ADDRESS> compiled by ghc-9.4
Using compiler: ghc-9.4.2
Using install prefix:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>
Executables installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/bin
Libraries installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/lib/ghc-9.4.2/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>-EYPyYWfgkHoGHjMrUz3frm
Dynamic Libraries installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/lib/ghc-9.4.2/x86_64-linux-ghc-9.4.2
Private executables installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/libexec/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>
Data files installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/share/x86_64-linux-ghc-9.4.2/tasty-hspec-<IP_ADDRESS>
Documentation installed in:
/nix/store/b5w8r3bc5vwmk4kx5jqfjhd20visrcbz-tasty-hspec-<IP_ADDRESS>-doc/share/doc/tasty-hspec-<IP_ADDRESS>
Configuration files installed in:
/nix/store/kv1cjssrvgli5ks2ym8rgghal588ba82-tasty-hspec-<IP_ADDRESS>/etc
No alex found
Using ar found on system at:
/nix/store/mx37gfqvx3kh8icib3k9jhvw8pv66ryv-binutils-2.39/bin/ar
No c2hs found
No cpphs found
No doctest found
Using gcc version 11.3.0 given by user at:
/nix/store/j061mvdxw70xz20r2r0lr5lk0rcsjf9i-gcc-wrapper-11.3.0/bin/gcc
Using ghc version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/ghc
Using ghc-pkg version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/ghc-pkg-9.4.2
No ghcjs found
No ghcjs-pkg found
No greencard found
Using haddock version 2.27.0 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/haddock-ghc-9.4.2
No happy found
Using haskell-suite found on system at: haskell-suite-dummy-location
Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy-location
No hmake found
Using hpc version 0.68 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/hpc
Using hsc2hs version 0.68.8 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/hsc2hs
Using hscolour version 1.24 found on system at:
/nix/store/9br4bs74rvsl039lpq65lxqq6v59vmyc-hscolour-1.24.4/bin/HsColour
No jhc found
Using ld found on system at:
/nix/store/hk75004j435l09ij4gawlkzg4wfs839w-binutils-wrapper-2.39/bin/ld.gold
No pkg-config found
Using runghc version 9.4.2 found on system at:
/nix/store/8bd87w5v9y7n9b7g3pkzsv344l4zvjwd-ghc-9.4.2/bin/runghc-9.4.2
Using strip version 2.39 found on system at:
/nix/store/j061mvdxw70xz20r2r0lr5lk0rcsjf9i-gcc-wrapper-11.3.0/bin/strip
Using tar found on system at:
/nix/store/gb4zp7iygbkr3bqfv9p38q3ci04m4m5s-gnutar-1.34/bin/tar
No uhc found
*** abort because of serious configure-time warning from Cabal

The additional hspec-core-2.10.6-1YaOpTrOnZw95xaaCyezQr it complains about doesn't seem to actually exist.

I've hit that while hacking on other things. I believe it's caused by doing overrides of the inputs of one package without changing the versions in the rest of the package set.
Maybe it's worth looking at the transitive inputs of that derivation to confirm that this isn't a Nix level mistake.

re: Servant it's a wip pr at present: https://github.com/haskell-servant/servant/pull/1592

hspec-core is overridden globally (and nowhere else it seems) and the alleged hspec-core-2.10.6-1YaOpTrOnZw95xaaCyezQr doesn't show up in the dependency graph printed by Cabal itself which makes this extremely strange. No clue where it could be passed in…
I guess worth looking into the tasty overrides for the normal package set, but I doubt it's a Nix mistake tbh.

Happy to review and merge follow up PRs! Limited binary cache for 9.4.2 packages should also be available soon.


Updated

Updated the dev profile accordingly.

The PR is getting blocked from getting merged due to conflicting files, please sync the repository @KrisJarvis


Issue58

Codecov Report

Merging #60 (5d0df36) into main (3a6924c) will increase coverage by 0.09%.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
+ Coverage   97.85%   97.95%   +0.09%
==========================================
  Files          18       18
  Lines        1026     1025       -1
==========================================
  Hits         1004     1004
+ Misses         22       21       -1

Impacted Files
Coverage Δ

qtgql/codegen/introspection.py
94.73% <100.00%> (-0.06%)
:arrow_down:

qtgql/codegen/py/config.py
100.00% <0.00%> (+3.33%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


fix inconsistent with tikv-lib-java

This change is

Is this still problem? I will close this PR if not.


Upcoming v0.9 release

I want to publish v0.9 within the next 1-2 weeks.
While I originally planned to focus on round-tripping Values in v0.9, instead my focus shifted to improving the format by supporting more Rusty syntax (and serde attributes). As part of these changes, we now have much more tests, higher code coverage, and a pretty good fuzzer that keeps uncovering obscure edge cases (in the future I want to extend it to also support fuzzing serde attributes).
I now want to give the fuzzer and our users some time to find any bugs and for me to fix them. Once we've had e.g. one week without new fuzzer issues, I'll publish v0.9.
Afterwards, I will probably be a bit less active again and only fix bugs for a while, before I then shift focus to improving Value to become closer to an AST that can roundtrip.

[x] Fix the byte literal grammar to include the b' prefix and ' suffix + define ASCII

Just dropping in to say thank you for all your work :heart:
I am very happy that #217 was fixed and can verify that my usecase works with latest main :slightly_smiling_face:

Just dropping in to say thank you for all your work :heart:
I am very happy that #217 was fixed and can verify that my usecase works with latest main :slightly_smiling_face:

Thank you @NiklasEi for your kind message!

I wanted to give a brief update since v0.9 may be delayed by a few more days. #502 has consumed quite some time, since I want to update our fuzzer to cover all tricky serde attributes so that we can at least know what exotic combinations we do not support (see #503 for a start to expanding the restrictions section in the README). I'm almost done with updating the fuzzer, so hopefully it shouldn't take too much longer :)

The 60-commit fuzzer update PR is finally merged. If the fuzzer doesn't find any non-timeout or non-OOM bugs (which are related to huge arrays and which I'm not quite sure yet how to fix), I will now finally publish v0.9 in the coming days, now with limitations of the new serde attribute supper properly investigated.

 :)

Thanks for this wholesome ping :)
The child is doing well but the birth was traumatic and I'm still relearning how to be a functional human. I want to finally get 0.9 released but finding the energy for it hasn't happened yet.
Releasing 0.9 is really only stuck on me trying to find all weird interactions of ron with #[serde(flatten)] attributes that the fuzzer can find. This is unfortunately quite the arduous task since serde flatten is just a bit cursed in all its special cases. Perhaps 0.9 could be released without an exhaustive list which is slowly filled in over patch releases? Almost all bugs the fuzzer found so far were either serde bugs or ones that ron cannot fix until serde supports format-specific Value types for buffering.

how about releasing a 0.9-beta/alpha before you finish #[serde(flatten)] ?
I think it can helps this crate

how about releasing a 0.9-beta/alpha before you finish #[serde(flatten)] ?
I think it can helps this crate

That’s a fantastic idea!

https://docs.rs/ron/0.9.0-alpha.0/ron/index.html is now live


v2.ODataModel.getProperty with bIncludeExpandEntries = false doesn't work

When calling sap.ui.model.odata.v2.ODataModel.getProperty with bIncludeExpandEntries = false the entity is returned "as is" without removing the expanded navigations.
The call to this._removeReferences can never be reached because of
		if (!bIncludeExpandEntries) {
			return oValue;
		}

at the very beginning of the method.
I don't think that this is the desired behavior.
ODataModel.prototype.getProperty = function(sPath, oContext, bIncludeExpandEntries) {
		var oValue = this._getObject(sPath, oContext);

		// same behavior as before
		if (!bIncludeExpandEntries) {
			return oValue;
		}

		// if value is a plain value and not an object we return directly
		if (!jQuery.isPlainObject(oValue)) {
			return oValue;
		}

		// do a value copy or the changes to that value will be modified in the model as well (reference)
		oValue = jQuery.sap.extend(true, {}, oValue);

		if (bIncludeExpandEntries === true) {
			// include expand entries
			return this._restoreReferences(oValue);
		} else {
			// remove expanded references
			return this._removeReferences(oValue);
		}
	};

Hi Frank,
thanks for reporting. Yes, this looks like a bug to me. I will forward this to the responsible developer to have a look. Internal reference is:<PHONE_NUMBER>

Any update on this?


BPMN 2.0 shapes Tasks and Choreographies are black filled

BPMN 2.0 Tasks and Choreographies shapes are black filled (see image)
To reproduce just search and check BPMN 2.0 shapes

draw.io version (In the Help->About menu of the draw.io editor):
draw.io version 15.2.2
Desktop

OS: Windows 10
Browser Google Chrome Version 93.0.4577.63

Please agree to code of conduct when filing issues.
This is fixed in 15.2.4.


Add large message support for SQS integration

Should be fairly straight forward. Likely the only changes necessary will involve the MessageBin registry.

This ticket is being replaced by the following: https://github.com/Axonify/queuebacca/issues/22


PoC filtering content of feed

tag based
multiple tags (or)
add filter
remove items

estimate: 4h

Additional:

Frontpage (Eventteaser) with tags
Tags should be smaller (chips)
Idea:

Fixed bar with tags
Use active vs idle to show filter state

Events/News Detail

Tags right of date


[5.8] Fix issue while committing transaction

As the bug is mention here https://github.com/laravel/framework/issues/29505, i have try to fix code as per need.

@aman00323 it's best that you provide a thorough explanation instead of linking to an issue.

@aman00323 it's best that you provide a thorough explanation instead of linking to an issue.

@driesvints I have added condition where if the $this->transaction is set to 0 then it will throw error.
The earlier code will be as it is in else like this
$this->transactions` = max(0, $this->transactions - 1);
$this->fireConnectionEvent('committed');

the only else if condition i have added which check $this->transaction is 0 or not, if it is then will throws error.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

@taylorotwell and @driesvints
This pull request has the solution to bug User commit when there is no transaction started
The current code never notify user that transaction is not started and they are trying to commit.
Current 5.8 Code
        if ($this->transactions == 1) {
            $this->getPdo()->commit();
        }
        $this->transactions = max(0, $this->transactions - 1);
        $this->fireConnectionEvent('committed');

As the current code never going to notify user that the transaction was not started so user should notify that transaction they are trying to commit that is not active.
Changes done to code
        if ($this->transactions == 1) {
            $this->getPdo()->commit();
        } elseif ($this->transactions == 0) {
            throw new TransactionException;
        } else {
            $this->transactions = max(0, $this->transactions - 1);
            $this->fireConnectionEvent('committed');
        }

So this code will throw error if the transaction is not started. this code is placed here https://github.com/laravel/framework/blob/5.8/src/Illuminate/Database/Concerns/ManagesTransactions.php#L154-L163

This can't go into 5.8 because it's a breaking change.
People could have unknowingly this behaviour and, while buggy, it would break their application in a minor update.

@mfn yes, it might break their application. But that's a good think!
Think about the current behavior:

An app does some stuff and commits all the changes to the database (by accident too early), even though the processing is not finished yet and there are further update statements to come
One of the following statements after the commit fails
The database is in an inconsistent state (maybe even unrecoverable)

Fixing bugs that prevent serious issues should have a higher priority than keeping BC.
But if you want to postpone this change, at least some log message with level critical must be emitted for the moment.

I agree with @digilist current user might be facing this issue, and they never know what's  happening from laravel side, @taylorotwell please give your review to this issue.

@aman00323 @digilist this is why I said to submit the pr with a thorough explanation (as it says in the pr template). If you give enough info, code examples and reasoning why this is needed then Taylor might reconsider. Feel free to resubmit with a thorough explanation.

@driesvints can you re-open this PR as i have fully described here why this PR is important, with detailed description.


containerservice release

https://github.com/Azure/sdk-release-request/issues/4041

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-arm-containerservice


Remove Publishing#compress_body_threshold

Remove Publishing#compress_body_threshold because there is no need to compress message body on the client-side.

Are related flags like Encoding_GZIP also removed？

Are related flags like Encoding_GZIP also removed？

The proxy may compress the message body, so the flag will be reserved.
@xdkxlk @drpmma


First request took very long?

Expected Behavior
I am testing an API and the procedure is:

get token from POST request A
get json from POST request B with the token returned by POST request A

When I call POST request B, the first trial should perform as similarly as the other trials i.e. second one, third one, ...
Actual Behavior
Below is the history of POST request B I called. Note that the first attempt took 35.6s and the later one were fast. I then stopped calling for a while and restarted, the first attempt took 37s. Later ones were fast. Stopped calling for while and restarted, the first attempt took 35.8s.

At first I thought it must be the API's problem because I have never encountered such problem with Insomina before and the performance of calling POST request A was consistent.
But then I tried using Postman to call POST Request B and found no such issue. I tried to start the POST request B with Postman and then Insomnia and the result is, Postman got the response pretty quick while Insomina stuck in the loading screen and got the response after dozens of seconds just like the behaviour I described above.
Here is one of the Timeline info of the very long POST request B (sensitive information is masked):
* Preparing request to https://xxx
* Current time is 2022-03-19T01:56:38.484Z
* Using libcurl/7.73.0 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.9 zstd/1.4.9 libidn2/2.1.1 libssh2/1.9.0 nghttp2/1.42.0
* Using default HTTP version
* Disable timeout
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 3 cookies
* Too old connection (129 seconds), disconnect it
* Connection 62 seems to be dead!
* Closing connection 62
* TLSv1.2 (OUT), TLS alert, close notify (256):
* Hostname in DNS cache was stale, zapped
*   Trying xxx:443...
* Connected to xxx.com (xxx) port 443 (#63)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /var/folders/d3/k2by8htd2fl9b5bfs0hn46z40000gn/T/insomnia_2021.7.2/ca-certs.pem
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; CN=*.xxx.com
*  start date: Jul  8 04:51:09 2020 GMT
*  expire date: Jul  8 04:51:09 2022 GMT
*  subjectAltName: host "xxx.com" matched cert's "*.xxx.com"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7ffb460b4e00)

> POST /xxx HTTP/2
> Host: xxx.com
> user-agent: insomnia/2021.7.2
> cookie: xxx=yyy
> content-type: application/json
> authorization: Bearer xxx
> accept: */*
> content-length: 39

* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!

| {
| 	"xxx": "yyy"
| }

* We are completely uploaded and fine

< HTTP/2 200
< date: Sat, 19 Mar 2022 01:57:21 GMT
< content-type: application/json; charset=utf-8
< content-length: 452
< cache-control: No-Cache
< pragma: no-cache
< expires: -1
< x-xxx-request-id: yyy

* Replaced cookie xxx="yyy" for domain xxx.com, path /, expire 0

< set-cookie: xxx=yyy;Path=/

* Received 452 B chunk
* Connection #63 to host xxx.com left intact
* Saved 1 cookie

Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2021.7.2
What operating system are you using?
macOS
Operating System Version
Catalina 10.15.6 (19G2021)
Installation method
https://insomnia.rest/download
Last Known Working Insomnia version
No response

@annie-redso I'm going to close this issue in favor of #5010 which has a bit more in-deep details of how to reproduce consistently this problem.
Thank you for reporting this one, and feel free to report any issues you find in the meantime!


Metadata stays unchanged

Hello,
I have an issue with changing meta-data. I changed the description in the _config.yml file to a different text. But when I copy the link to my website and paste it to some messenger, for example, I still get this original text that was there:

Probably this has some easy solution, I am just no very well experienced with this framework.
Thank you.

You need to update the cache of the server where this preview has been generated. The description is updated correctly.
You can see it here: https://www.opengraph.xyz/url/https%3A%2F%2Fzemanpeter.github.io


Update http4s-core, http4s-dsl to 0.21.25

Updates

org.http4s:http4s-core
org.http4s:http4s-dsl

from 0.21.14 to 0.21.25.
GitHub Release Notes - Version Diff
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!

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

labels: library-update, semver-patch

Superseded by #276.


Bug in blog yashwant dubey's blog, keyboard-shortcuts-and-tricks-that-will-make...........

Different date-time in markdown file and blog itself. Date-time in markdown 2021-08-03T21:37:00.000Z and Date in blog *4 August 2021, it should be 3 August 2021

@bitakshat this issue is faced in which blog?


Unconditioned noise of LoRA

Hi,
I'm trying to learn your implementation of VSD loss and have a question. To get the noise with CFG, one should compute both conditioned and unconditioned noise. So why do you use
encoder_hidden_states=torch.cat([image_camera_embeddings] * 2, dim=0),  in the following two links?
shouldn't it be something like
encoder_hidden_states=torch.cat(                         [                             image_camera_embeddings,                             torch.zeros_like(image_camera_embeddings),                         ],                         dim=0,                     ), ?
https://github.com/threestudio-project/threestudio/blob/8a51c37317b6f7cd74bb3cb24c975b56d0a96703/threestudio/models/guidance/stable_diffusion_vsd_guidance.py#L492C6-L492C6
https://github.com/threestudio-project/threestudio/blob/8a51c37317b6f7cd74bb3cb24c975b56d0a96703/threestudio/models/guidance/zero123_unified_guidance.py#L435C24-L435C24
Thank you very much!

In LoRA training, we only drop the camera condition (which is fed into the network by class_labels):
https://github.com/threestudio-project/threestudio/blob/8a51c37317b6f7cd74bb3cb24c975b56d0a96703/threestudio/models/guidance/stable_diffusion_vsd_guidance.py#L570-L571
So in inference, we do the same and only apply CFG on the camera condition.


remove "add topic" button

Is your feature request related to a problem? Please describe.
Users proved to be bad topic creators. We need to write the topics our self.
Describe the solution you'd like
The "add topic" button is removed.
Topics are added directly to the database.

Done. Visible at the staging instance


[RFC] - Support GeoJson Point type format in GeoPoint and XYPoint field

The purpose of this RFC (request for comments) is to gather community feedback on a new proposal to support GeoJson Point type format in GeoPoint and XYPoint field.
Related issue https://github.com/opensearch-project/OpenSearch/issues/3775
GeoJson Point Type
Point type in GeoJson is one of GeoJson type which is used to represent a single position. Point coordinates are in x, y order (easting, northing for projected coordinates, longitude, and latitude for geographic coordinates):
{
   "type": "Point",
   "coordinates": [41.12, -71.34]
}

Indexing
Below is an example of indexing GeoPoint and XYPoint field using GeoJson Point type format
GeoPoint
Point expressed as a GeoJson Point object.
PUT indexing_geopoint
{
  "mappings": {
    "properties": {
      "point": {
        "type": "geo_point"
      }
    }
  }
}

PUT indexing_geopoint/_doc/1
{
  "text": "Point as an object using GeoJSON format",
  "point": {
    "type": "Point",
    "coordinates": [41.12, -71.34]
  }
}

XYPoint
Point expressed as a GeoJson Point object.
PUT indexing_xypoint
{
  "mappings": {
    "properties": {
      "geometry": {
        "type": "xy_point"
      }
    }
  }
}

PUT indexing_xypoint/_doc/1
{
  "text": "Point as an object using GeoJSON format",
  "geometry": {
    "type": "Point",
    "coordinates": [41.12, -71.34]
  }
}

Implementation
Current
XYPointFieldType and GeoPointFieldType has PointParser. When generating PointParser instance, it passes function parameter using a static method in XYPointParser and GeoUtils respectively. PointParser has parsing logic to handle the outer part of contents and the static method in XYPointParser and GeoUtils has parsing logic of each format for a point. The static methods in GeoUtils and XYPointParser have duplicated logic in them.

Proposal
We will introduce a PointUtils which will have a parsing method for each types which are common for both GeoPoint and XYPoint: Object, GeoJson, and Array. GeoUtils and XYPointParser will have the top level parsing logic and calls PointUtils to handle final data format.
This will remove code duplication between GeoUtils and XYPointParser. This approach also minimize the code change required compared to the other alternatives.
Red box in the following diagram indicate either modified or newly created classes.

Alternatives
1. Adds common point parser class
We will introduce a new CommonPointParser class. CommonPointParser will have the top level parsing logic which is generic to any point type. The CommonPointParser will delegate all type specific tasks to methods of which GeoPointParser and XYPointParser will override.
This change will reduce duplicated code in XYPoint type parser and GeoPoint type parser. However, one of the comments that I received is that GeoUtils having dependency on GeoPointParser doesn’t look right. Also, during implementation, this approach makes the code more complex than the proposed option without gaining much in reducing code duplication.
Red box in the following diagram represent either modified or newly created classes.

2. Adds GeoJson Point type parsing logic in both GeoUtils and XYPointParser
We can just modify existing parsing method in each of GeoUtils and XYPointParser to parse GeoJson point type. Even if the logic of parsing GeoJson is simple, it takes same mount of code change as proposed approach to embed the logic in existing parsing logic.

3. Use existing GeoJson or GeoJsonParser
We could reuse existing GeoJson class or GeoJsonParser class to parse GeoJson point type. However, Current implementation in GeoJson class and GeoJsonParser class parse any type of GeoJson format. Therefore, we cannot fail fast when the data is not GeoJson Point type which is the only GeoJson type we are going to support. There is no separate method only to parse GeoJson Point type in those classes as well. Also, the code duplication issue will remain same as before because other parsing logics will stay in GeoUtils and XYPointParser.

A couple of comments

I don't think GeoJSON fits within XYPoint.

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.

https://www.rfc-editor.org/rfc/rfc7946#section-4
Isn't the point of XYPoint to capture arbitrary x,y coordinate systems (e.g. non-spherical) that aren't bound within (-180.0000, -90.0000, 180.0000, 90.0000)? That shouldn't be happening with GeoJSON objects.

GeoJSON has an optional elevation/altitude element.

Altitude or elevation MAY be included as an optional third element.

https://www.rfc-editor.org/rfc/rfc7946#section-3
How will this third element be handled? Will an exception be thrown, will the "z" element just be dropped, or should GeoPoint be changed to accept a "z" element?

@aucoindan Thanks for your valuable comments. Here are my answers.
1. I don't think GeoJSON fits within XYPoint.
You are correct if we are going to represent XYPoint in GeoJson format. However here, we are going to allow customer to use GeoJson format to insert XYPoint data. In other words, converting xy point to geo point is invalid but converting geo point to xy point is valid.
2. GeoJSON has an optional elevation/altitude element.
This is true for Array format as well. There is an option during index creation if you want to ignore or throw error when there is the third element in the data. This option will apply to GeoJson data as well.


Boolean logic DAG dependencies

Hello,
According to Argo documentation, boolean logic operators are available for setting dependencies between tasks in a DAG. I was wondering if this can be done with hera. For example I have tasks A,B,C,D and I would like to execute to do the following logic in the dag
[A,(B or C)] >> D

Hello @alejoGT1202! Thanks for the question! You have access to the depends fields on Task, so you can set up whatever custom logic is necessary for your use case. However, I think it would be very nice for Hera to have this type of enhanced logic available :) I will mark this as an enhancement in addition to a question

Hey @alejoGT1202! See #518 :)


feature request: add background on image type conversion

It would be useful to extend the current backgroundoption so that it also works when converting from a format that has an alpha channel to one that does not, e.g. from png to jpg.

Found out you can already do it using flatten and background together.


optimization doesn't appear to run currently

I've forked pygsp and started implementing the tikhonov optimization on my branch, but it appears that

The current implementation of optimization.prox_tv does not work because
pyunlocbox does not yet support the non-tight frame problem.
Regardless, I think I've fixed prox_tv up to this error with pyunlocbox.  Once I get prox_tik done/documented, i'll switch over to pyunlocbox and see what I can do about the non-tight frame case.

Hi stanlejys,
Thanks for contributing to the pygsp. I have implemented the tikonov case in this branch
https://github.com/epfl-lts2/pygsp/tree/semi-supervised-learning
For the Tikonov case, it not worth using proximal splitting optimization. It is better to directly compute the solution.
For the TV case, the best would be to use a primal dual scheme with the gradient operator and not directly the prox_tv. I have a matlab implementation using the unlocbox in case you want to implement it for the pygsp.

ah, ok - I was just going based on the matlab/gspbox implementation of prox_tik which uses prox when a forward operator is supplied.  Of course, when the forward operator is identity the Chebyshev approximation is often faster.
Where is your matlab prox_tv implementation?

It is there:
https://github.com/epfl-lts2/gspbox/blob/master/graph_ml/gsp_regression_tv.m
The MATLAB unlocbox does not have the most intuitive design and it is mostly my fault. Sorry for that.
I see 3 different ways to implement the TV version

Using the prox_tv is probably the easiest way to implement it. However, it results in an algorithm with two levels of iterations.
Using the solver mlfbf of the pyunlocbox with the norm_l1 of the pyunlocbox. This will result in an algorithm that has only one iteration. However, mlfbf is not the best solver for that problem.
Implementing Chambolle-Pock algorithm in the pyunlocbox and using it with the norm_l1. Probably the best way, but also require more work... (https://hal.archives-ouvertes.fr/hal-00490826/document)

Maybe you should rebase the semi-supervised-learning branch and start from there. @mdeff  what do you think?
Good luck


Scrolls to wrong position if scroll width/height updates while animating

A container is scrolled to the wrong position if it's scrollWidth or scrollHeight updates while animating.
There are lots of occasions this is an issue; the most common is when you attempt to scroll the page to an element (on document ready) while the page is still loading and growing in height.
I use scrollTo almost exclusively as part of our client-side URL hash routing. It works fine when the hash route changes after page load, but if you use a route for a fresh load you get scrolled to random parts of the document.
To see this happening in a real situation:

Visit http://allnewmazdamx5.com.au/#/section/skyactiv-technology. If you are on an average internet connection, you will probably be scrolled to an incorrect location on the page.
Press enter in the URL bar to trigger the hash again, without reloading the page. It should take you to the exact position intended.

The solution is to store original scrollHeight of the container being scrolled at the start of the animation. For every animation frame check if the scrollHeight is still the same (not as expensive as it sounds). If it is not, cancel the current animation and calculate a fresh one to cover the new distance. In the same way you will need to handle the x-axis using scrollWidth.
I used to use this solution effectively in my own custom scrollTo plugin.

In the mean time, here is a way around the problem:
function scrollPageTo($target) {
  var scrollHeight = document.body.scrollHeight;
  $(window).stop(true).scrollTo($target, {
    duration: 600,
    progress: function() {
      // If the page scroll height changes, scroll afresh to the shifted target
      if (scrollHeight !== document.body.scrollHeight) scrollPageTo($target);
    }
  });
}

// Document ready
$(function() {
    scrollPageTo($('#id-of-element'));
});

Hi @jaydenseric,
This is a shared problem among all the uses of $().animate(), rather than solving it within the plugin for the 1000th time, I prefer if people either use a custom solution or maybe come out with a plugin that solves all at once. Else we're all solving the same problems.
Regards


chore: bump tarpulin version in CI

Description and Motivation
Updates tarpulin to 0.24.0, CI will indicate if theres any compatibility issues.

Related Issues

Checklist:

[X] I have read Migaloo's contribution guidelines.
[X] My pull request has a sound title and description (not something vague like Update index.md)
[X] All existing and new tests are passing.
[ ] I updated/added relevant documentation.
[X] The code is formatted properly cargo fmt --all --.
[X] Clippy doesn't report any issues cargo clippy -- -D warnings.
[X] I have regenerated the schemas if needed cargo schema.

Looks like the release binaries changed between 0.15 and 0.24. We might have to not use<EMAIL_ADDRESS>and install it ourself to run the binary.

the tarpaulin github action has not been updated in 3 years. The tarpaulin version they use is 0.15, so changing the version to 0.24 would naturally fail. I see other repos using a tarpaulin docker image and then running the command themselves. or just using the action with version 0.15.
Looking at Tarpaulin's changelog I don't see anything critical being implemented from v0.15 to v0.25. https://github.com/xd009642/tarpaulin/blob/develop/CHANGELOG.md
I don't see why we need to do this at this point.
If we wanted to do it, it seems like the way to do it is the following:
https://github.com/DA0-DA0/dao-contracts/blob/main/.github/workflows/codecov.yml


Can this be implemented as a Good stream ?

What the advantage of having an independent Hapi plugin and not relying on Good ?
Having pino as a Good compatible stream have a few clear advantages (like getting filtering and any other Good preprocessors  to work out of the box). There might be some performance implications but I can assume that for a very basic pipeline it should be negligible.
It would be great if the benchmark code that used to compare this to good-console be published and we could test it vs a good-pino version.

This is what I have been using https://github.com/pinojs/hapi-pino/blob/master/example-good.js. Redirecting it to /dev/null, and launching an http load test with autocannon or wrk.
My initial assessment on all those filters is that their impact is far from negligible. Streams pipelines, specifically, introduce serious overhead.
As anything performance-related, we will be super happy if good (and hapi) becames faster, and we will be happy to fold hapi-pino into good-pino if there are zero performance slowdowns.
My experience dealing with loggers is that it has too many features and extensibility to be fast. I might be wrong, so report your numbers.
In the whole line of pino integrations, our goal is to provide the fastest way to log data. We have seen that a lot of integrations for other logging libraries are not written with performance as a first level concern.
(I have nothing against streams, I maintain them)

I've created a very simple implementation of hapi-pino as good stream https://github.com/pinojs/hapi-pino/pull/12
I'm not sure if all the events data is properly logged but this is enough for benchmarks.
since the results were really close I ran autocannon -c 50 -d 30 localhost:3000 twice without restarting the example server and got the following results -
#good-pino
Running 30s test @ http://localhost:3000
50 connections

Stat         Avg       Stdev   Max
Latency (ms) 45.14     10.58   292
Req/Sec      1093.07   92.62   1160
Bytes/Sec    241.94 kB 19.9 kB 262.14 kB

33k requests in 30s, 7.25 MB read

Running 30s test @ http://localhost:3000
50 connections

Stat         Avg       Stdev    Max
Latency (ms) 46.51     7.71     126
Req/Sec      1061.67   75.92    1139
Bytes/Sec    234.84 kB 17.06 kB 253.95 kB

32k requests in 30s, 7.04 MB read

#hapi-pino
Running 30s test @ http://localhost:3000
50 connections

Stat         Avg      Stdev    Max
Latency (ms) 47.96    25.71    648
Req/Sec      1030.2   158.07   1182
Bytes/Sec    227.4 kB 35.21 kB 262.14 kB

31k requests in 30s, 6.83 MB read

Running 30s test @ http://localhost:3000
50 connections

Stat         Avg       Stdev    Max
Latency (ms) 47.83     8.84     134
Req/Sec      1032.8    79.94    1111
Bytes/Sec    228.56 kB 17.39 kB 245.76 kB

31k requests in 30s, 6.85 MB read

#good-console
Running 30s test @ http://localhost:3000
50 connections

Stat         Avg       Stdev    Max
Latency (ms) 45.68     10.91    269
Req/Sec      1080.94   101.75   1164
Bytes/Sec    238.32 kB 22.98 kB 262.14 kB

32k requests in 30s, 7.17 MB read

Running 30s test @ http://localhost:3000
50 connections

Stat         Avg       Stdev    Max
Latency (ms) 49.23     10.88    201
Req/Sec      1003.97   111.71   1101
Bytes/Sec    222.28 kB 24.35 kB 245.76 kB

30k requests in 30s, 6.66 MB read

good-pino results seem to be a bit better but I'm not sure if there is any significant improvement even when compared with good-console.

Closing as we will not be pursuing this direction (see the discussion in #12).


allow more recent update-checker

is there any reason why you have hardcoded 0.11? usually this is bad practice, and rtv seems to be working fine with 0.12 as well.

It's only hard coded in the requirements.txt file. If you install through pip or python setup.py install, you'll get the latest version (see setup.cfg). My understanding is that everything in requirements.txt should be pinned so you can maintain a reproducible dev environment.

hmm. i only ever noticed this because rtv does not start for me on my archlinux. here's some info:
yunake@x230:~$ yaourt -Qi python-update_checker rtv | grep -iE '^(name|version)'
Name            : python-update_checker
Version         : 0.12-1
Name            : rtv
Version         : 1.12.0-0
yunake@x230:~$ rtv
Traceback (most recent call last):
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 659, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 967, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 858, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (update-checker 0.12 (/usr/lib/python3.5/site-packages), Requirement.parse('update_checker==0.11'), {'praw'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/rtv", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3008, in <module>
    @_call_aside
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2994, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 3021, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 661, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 674, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 853, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'update_checker==0.11' distribution was not found and is required by praw

You are right though, setup.cfg should definitely take precedence for setuptools.

Yea it looks like you're not the only one having this problem :(
https://github.com/michael-lazar/rtv/issues/258


Devs

Create a dev branch, where we could implement new things properly without breaking master

Added a development branch


Use Git for revision control

There were plans already for this. Let it happen in pynote 1.1!

Is already in v2.0.0 branch


[#4245] Allowing password to nil

#4245

@lucasmazza Let me know your comments on this fix.

@lucasmazza I tweaked some test cases. Now build is passing. Let me know your comments.

@lucasmazza @sivagollapalli Any news?

@tegon Made changes. Could you please check?

@sivagollapalli Thanks! Sorry again for taking so long.


Release 5.4.1 lacework-agent Helm Charts

Updating the lacework-agent chart with release version 5.4.1.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Production build fails for nextjs client

API Platform version(s) affected: 3.2.16
Description
With a fresh installation, I was able to run the generator for the default Greeting entity. The app works in dev mode. When I try to build the app in production mode with http only, it fails with the following message:
9.052    Creating an optimized production build ...
38.73  ✓ Compiled successfully
38.73    Collecting page data ...
39.13 TypeError: Failed to parse URL from undefined/greetings
39.13     at node:internal/deps/undici/undici:12345:11
39.13     at async c (/srv/app/.next/server/pages/greetings/page/[page].js:1:7873)
39.13     at async c (/srv/app/.next/server/pages/greetings/page/[page].js:1:7119)
39.13     at async buildStaticPaths (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:786:33)
39.13     at async /srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1215:110
39.13     at async Span.traceAsyncFn (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/trace/trace.js:151:20) {
39.13   [cause]: TypeError: Invalid URL
39.13       at new URL (node:internal/url:775:36)
39.13       at new Request (node:internal/deps/undici/undici:5853:25)
39.13       at fetch (node:internal/deps/undici/undici:10123:25)
39.13       at Object.fetch (node:internal/deps/undici/undici:12344:10)
39.13       at fetch (node:internal/process/pre_execution:336:27)
39.13       at c (/srv/app/.next/server/pages/greetings/page/[page].js:1:7892)
39.13       at c (/srv/app/.next/server/pages/greetings/page/[page].js:1:7133)
39.13       at buildStaticPaths (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:786:39)
39.13       at /srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1215:116
39.13       at async Span.traceAsyncFn (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/trace/trace.js:151:20) {
39.13     code: 'ERR_INVALID_URL',
39.13     input: 'undefined/greetings'
39.13   }
39.13 }
39.13 TypeError: Failed to parse URL from undefined/greetings
39.13     at node:internal/deps/undici/undici:12345:11
39.13     at async o (/srv/app/.next/server/pages/greetings/[id].js:1:5312)
39.13     at async y (/srv/app/.next/server/pages/greetings/[id].js:1:4222)
39.13     at async buildStaticPaths (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:786:33)
39.13     at async /srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1215:110
39.13     at async Span.traceAsyncFn (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/trace/trace.js:151:20) {
39.13   [cause]: TypeError: Invalid URL
39.13       at new URL (node:internal/url:775:36)
39.13       at new Request (node:internal/deps/undici/undici:5853:25)
39.13       at fetch (node:internal/deps/undici/undici:10123:25)
39.13       at Object.fetch (node:internal/deps/undici/undici:12344:10)
39.13       at fetch (node:internal/process/pre_execution:336:27)
39.13       at o (/srv/app/.next/server/pages/greetings/[id].js:1:5331)
39.13       at y (/srv/app/.next/server/pages/greetings/[id].js:1:4236)
39.13       at buildStaticPaths (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:786:39)
39.13       at /srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1215:116
39.13       at async Span.traceAsyncFn (/srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/trace/trace.js:151:20) {
39.13     code: 'ERR_INVALID_URL',
39.13     input: 'undefined/greetings'
39.13   }
39.13 }
39.13
39.13 > Build error occurred
39.13 Error: Failed to collect page data for /greetings/page/[page]
39.13     at /srv/app/node_modules/.pnpm/next@14.1.2_@babel+core@7.24.0_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1258:15 {
39.13   type: 'Error'
39.13 }
39.15  ELIFECYCLE  Command failed with exit code 1.
------
failed to solve: process "/bin/sh -c pnpm install --frozen-lockfile --offline --prod && \tpnpm run build" did not complete successfully: exit code: 1

How to reproduce

Download the 3.2.16 distribution
docker compose build --no-cache
docker compose up --wait
docker compose exec pwa pnpm create @api-platform/client --resource greeting -g next
go to localhost/greetings to verify that the greetings page works
docker compose down
SERVER_NAME=:80 APP_SECRET=ChangeMe CADDY_MERCURE_JWT_SECRET=ChangeThisMercureHubJWTSecretKey docker compose -f compose.yaml -f compose.prod.yaml up --build
TypeError: Failed to parse URL from undefined/greetings

Hello @JDruery,
Thank you for reporting this issue. The problem you're encountering during the production build appears to be related to the Next.js client's inability to access the API, which is essential for server-side generation (SSG) during the build process. Here's how to resolve it:
Step 1: Set the API Endpoint in the .env file
First, we need to ensure that the Next.js client knows where to find the API. Create a .env file in the pwa directory and add the following line:
NEXT_PUBLIC_ENTRYPOINT=http://php

This environment variable (NEXT_PUBLIC_ENTRYPOINT) tells the Next.js client the base URL of your API, enabling it to make requests during the build and runtime.
Step 2: Configure Docker Compose for Network Access
In the compose.prod.yaml file, we'll adjust the pwa service to ensure it can communicate with the php service during the build. Here's the modification:
pwa:
  depends_on:
    - php
  build:
    context: ./pwa
    network: host
    extra_hosts:
      - "php=<IP_ADDRESS>"
    target: prod

These changes allow the pwa build process to access the php service by mapping the php hostname to the local machine, facilitating SSG.
Step 3: Build and start the php service
Let's start the php service to make it accessible:
SERVER_NAME=:80 APP_SECRET=!ChangeMe! CADDY_MERCURE_JWT_SECRET=ChangeThisMercureHubJWTSecretKey NEXT_PUBLIC_ENTRYPOINT=http://php POSTGRES_PASSWORD=!ChangeMe! docker com
pose -f compose.yaml -f compose.prod.yaml up -d --build --wait php

Step 4: Build the pwa service:
docker compose -f compose.yaml -f compose.prod.yaml build pwa

Step 5: Bring up the full project:
SERVER_NAME=:80 APP_SECRET=!ChangeMe! CADDY_MERCURE_JWT_SECRET=ChangeThisMercureHubJWTSecretKey NEXT_PUBLIC_ENTRYPOINT=http://php POSTGRES_PASSWORD=!ChangeMe! docker com
pose -f compose.yaml -f compose.prod.yaml up -d --wait

With these adjustments, your production build should succeed, and the Next.js client will be able to access the API during the build process and at runtime.

I've updated my previous message since there other problems have appeared at runtime.
The TRUSTED_HOSTS and MERCURE_PUBLIC_URL environment variable needs to be updated in the compose.yaml file for the API and Mercure to run correctly without https.


Revised Metric: Event Demographics changes

Issues solved:
Description included Attendee, Speaker, and Volunteer
4th point in the Objectives is redundant
Check out the spreadsheet remark
Added Last Reviewed date
Issue: #432

Thanks for these @TejasMate - we will take a look at that in this week's DEI meeting

@ElizabethN - what do you think about merging this and then you could make a second PR with your suggested changes?

@germonprez I can do that - no worries. Thanks for the PR @TejasMate! Merging now. 🙌


fix(conditions): add foreach property on conditions

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feature

What is the current behavior? (You can also link to an open issue here)
a foreach step cannot have skip conditions that run on itself, only on its generated children

What is the new behavior (if this is a feature change)?
a foreach step can now have skip conditions that run on itself, not only on its generated children

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
no, the new flag on the conditions is optional and defaults on the current behavior

Other information:
invalid template testing is enhanced a bit

CDS Report test#1757.0 ✘

tests and lint

golangci-lint ✘
unit-test and integration-tests ✔


New sample to add fields to content types

Hey @ahamedfazil another awesome sample, thank you! This will be live shortly 🎉😁

Thank you @pkbullock :heart_eyes:


IP/CIDR improved

Improved support for IP/CIDR target
Currently if IP/CIDR doesn't resolve any host by reverse dns lookup, it doesn't do anything. The improvements will be:

If ip/cidr rev dns resolves in domain/subdomain works on it and the IP.
If ip/cidr rev dns doesn't resolve any domain, it will skip the subdomains part, but it will try to detect websites on the IP and continue as usual.

a9f9ed7b9d8dba797dfd9e5e356a48f9da4c8ee6


nixos/xrdp: allow to specify a listen string as port

Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Since I am not using the module myself and the change is seemingly getting more complicated, I am going to close this PR.


RFC: preserving startCursor / endCursor in cases of empty pagination results

Summary
When using relay style cursor pagination to fetch the latest result
connectionField(first: 10)

We get a result that looks like this:
pageInfo: { startCursor: 'ABC', endCursor: 'DEF' }
nodes: [{ ... }, { ... }, { ... }, ...]

If we want to poll for items earlier newer than startCursor, we might want to query for something like:
connectionField(last: 10, before $startCursor)

The issue is that when there is an empty result set:
pageInfo: { startCursor: null, endCursor: null }
nodes: []

The relayPagination will then merge in & return the null cursor values for this latest result set. Ideally we'd like to keep the latest known startCursor so we can continue to re-issue the query for items before the startCursor.
Proposed Solution
Add a new option, maybe named something like skipEmpty or excludeEmpty, which would skip over results that don't have any nodes/edges while looping through the pages in the relayPagination helper, so as to not clobber the cursors for the existing paginated list.
if (params.excludeEmpty && (page.edges.length === 0 && page.nodes.length === 0 && typename)) {
  continue
}

Hm, I'd go as far as to say this is a bug since it's unexpected behaviour as per the intention of the relay spec 🤔


Fix default

What kind of change does this PR introduce?
bugfix/feature
Did you add tests for your changes?
Yes
Does this PR introduce a breaking change?
Yes, but it is under experiments
What needs to be documented once your changes are merged?
Yes

/cc @hardfist
I want to make a change, the reason is performance. If you want to use modules you must use the file name or set  css/module, in other cases users usually have a regular/pure CSS, so wasting time at the parsing stage (extra checks and extra parsing) simply does not make sense, this is how our css-loader works

LGTM, explicit is better than implicit!
But I want to raise a question, even experiments is meant to introduce breaking change in non-major version,
will it be better only release experiments breaking change in minor version other than patch version( that's what we are doing in Rspack, cause experiments is still widely used and it's hard for users to track experiments breaking in patch version)

@hardfist Yeah, I agree, let's use minor


Docs fix

The tables in the service architecture document produced by make docs was not formatted correctly - fix that and fix the missing arrows in the service architecture diagram.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "docs-fix" git@github.com:docker/notary.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "docs-fix" git@github.com:docker/notary.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

[Current coverage][cc-pull] is 58.84%

Merging [#705][cc-pull] into [master][cc-base-branch] will decrease coverage by -19.86%

@@             master       #705   diff @@
==========================================
  Files            84         56     -28
  Lines         10667       8146   -2521
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           8395       4793   -3602
- Misses         2241       2759    +518
- Partials         31        594    +563

2 files (not in diff) in utils were modified. more

Misses +148
Partials +3
Hits -151

4 files (not in diff) in tuf/utils were modified. more

Misses +68
Hits -68

5 files (not in diff) in tuf/store were modified. more

Misses +119
Partials +23
Hits -142

5 files (not in diff) in tuf/signed were modified. more

Misses +125
Partials +26
Hits -151

9 files (not in diff) in tuf/data were modified. more

Misses +211
Partials +69
Hits -280

4 files (not in diff) in tuf were modified. more

Misses +262
Partials +119
Hits -381

2 files (not in diff) in trustpinning were modified. more

Misses +74
Partials +22
Hits -96

6 files (not in diff) in trustmanager were modified. more

Misses +72
Partials +68
Hits -140

3 files (not in diff) in cryptoservice were modified. more

Misses +60
Partials +31
Hits -91

4 files (not in diff) in cmd/notary were modified. more

Misses +18
Partials +89
Hits -107

Powered by Codecov. Last updated by 5b4694e
[cc-base-branch]: https://codecov.io/gh/docker/notary/branch/master?src=pr
[cc-pull]: https://codecov.io/gh/docker/notary/pull/705?src=pr

LGTM.  Just built docs locally -- tables are fixed and look great!

And the arrows are back!

LGTM


sys_init: Fix missing initializer

When compiling in c++ with strict warnings, the missing initializer to dev throws an error.
Fixes #67396

Is this needed after https://github.com/zephyrproject-rtos/zephyr/pull/68125?

Fixed in #68125


Moved all source and project—related files into src/ directory.

I think this cleans up the root directory, and adopts a more standard project directory structure. Admittedly this isn't a Unix-based project, but I think it's a nice convention anyway. FYI everything gets built into bin/ in root. If you don't like it, no worries!
Remaining things to do (these're notes for me ~ F.)

[x] Check bin placement more closely — seems to be okay
[x] Fix unit testing script — not required, it already works
[x] Fix nuspec
[x] Fix publishing script — not required

First of all, I approve the idea overall. It seems like a nice project layout: put main build files and general documentation (readme, license) into the root folder, sources to src/, docs to docs/ etc.
Although I have some small nitpicks about the implementation. I'll mention them in a review section.
Also I can see that you haven't changed the test and publication scripts; that's okay, you don't need to address these. I'll take care of them myself in this branch after we settle other issues.

Regarding the placement of the sln file, that makes sense to me; let's move it to the root directory.
If you could sort out the test and publication scripts (and modify the AppVeyor spec too, if needed), then that would be great, since I'm not very familiar with how they work.

Thanks for the pull request.


Change the mass-publish API endpoint filter

Pre-Flight checklist

[ ] Testing

[ ] Code is tested
[ ] Changes have been manually tested

What are the relevant tickets?
Closes #1222
What's this PR do?
Changes the filter for the mass-publish API endpoint to exclude sites based null live/draft publish date, regardless of source.
How should this be manually tested?

Pick a site and set both publish_date and draft_publish_date to any date.
Verify that the site is included in the output of both http://localhost:8043/api/publish/?version=live and http://localhost:8043/api/publish/?version=draft
Change publish_date to None.  The site should be included in the output of http://localhost:8043/api/publish/?version=draft but not http://localhost:8043/api/publish/?version=live
Change draft_publish_date to None.  The site should not be included in the output of http://localhost:8043/api/publish/?version=draft or http://localhost:8043/api/publish/?version=live

Codecov Report

Merging #1229 (7287274) into master (d1a640e) will increase coverage by 3.83%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1229      +/-   ##
==========================================
+ Coverage   90.74%   94.58%   +3.83%
==========================================
  Files         212      100     -112
  Lines        8839     3027    -5812
  Branches     1634      727     -907
==========================================
- Hits         8021     2863    -5158
+ Misses        709      162     -547
+ Partials      109        2     -107

Impacted Files
Coverage Δ

websites/views.py

videos/api.py

news/urls.py

content_sync/backends/base.py

main/celery.py

content_sync/admin.py

gdrive_sync/tasks.py

gdrive_sync/admin.py

gdrive_sync/signals.py

websites/serializers.py

... and 103 more

Continue to review full report at Codecov.

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


Allow running tasks without forking.

I'm using the plugin in my pom.xml and it works but many tasks are executed twice. I think that the plugin fork the lifecycle, but I found no way to disable forking.
I've posted a question here. There is my pom.xml if you want to check it.
Maybe I'm using the plugin wrong, maybe it's an issue, let me know!

Did you plan a release of these changes ?


Polars Dataframe, ndarray and charming dataframe

Hi,
What are the differences between rust polars dataframe/ndarray and charming dataframe ? The polars and charming dataframe are both created with df! macro. Can I use polars/ndarray instead of charming dataframe ? If not, how to convert them to charming dataframe ?

Bumped with similar question.

They are completly seperate from another, they just have the same name. I don't think there is a general way to convert between them and it is up to you to do it.
If you are trying to plot from polars you can also try plotlars


Improve the provider image

The image used on the provider concept page should match the style of other images.

:grimacing:

Borrowed the one that Pete made


Add fms calculation

FMS implementation for comparing two runs of Pf2 with the same rank

@aarmey Is my calculation off for FMS? I wanted to check if I got a value of 1 (defined as the same components between 2 runs) for running Pf2 by only changing random state, but currently getting a value of .05

This isn't right because two runs of Pf2 can differ in the ordering of the components and/or scaling and still have the same results. Our "ordering" isn't good enough because a lot of components don't have condition-specific effects, so they are equivalent as far as the Gini. The FMS with this corrected is implemented for you in TensorLy-viz. Additionally, I'd try it ignoring the conditions factors (skip_mode=0), to see if that ends up with a very different number.


Added check for zstandard before compilation when onefile

I have closed PR #2002 by error. In this pull request i have made the changes that @kayhayen suggested in that PR.

Thanks, I think the autoformat wants to do stuff still, but I can take it from here. Honestly, I am surprised how easy it is in the end. Going to add a comment to why it's called and maybe something that will avoid the duplicate

hah, you pushed while I was typing... :)