enhanceskip follow cooldown once failed to do follow cooldown

Proposed changes
Issue Number: close #xxx
Once the tablet failed to do follow cooldown, it means the cooldown replica may be slow to upload it's rowset meta file. It would be wasteful if we keeping trying to do follow cooldown, we'd better skip follow cooldown for an interval.
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Compatibility for MySQL

@sgoley
sure, thank you for your answer!!
Database: MySql Community Edition
ODBC Driver: MySql ODBC 8.0 Unicode Driver
DataType Field: Int
Visual: Table
Decsription: when i drag the int column it is ok (but it is sum aggregated by deafult), but when i check the "dont summerize" in power bi i get that error.
i cant see anything that is not aggregated.
Originally posted by @dr0rRvali in https://github.com/sgoley/DirectQuery-for-ODBC-in-PowerBI/issues/1#issuecomment-487554360

Closing as duplicate of #5


Check cssRules before css variables are read from stylesheet (again)

References

Fixes #2450

Description
check stylesheets in the dom before reading the css variables from them. If some error occurs reading the stylesheet cssRules (see the issue, f.e. it is some cross-origin stylesheet from some plugin which is not-readable) the exception is catched and the css variable not extracted from the stylesheet.
Instructions for Reviewers
see https://github.com/DSpace/dspace-angular/issues/2450 and https://github.com/DSpace/dspace-angular/issues/2557  and the previous PR https://github.com/DSpace/dspace-angular/pull/2454 for an overview over the discussion, especially the exception and the difference to the previous PR.
Include guidance for how to test or review your PR.
See the issue for details how to reproduce the bug with specific browser addons that inject stylesheets into the DOM.
Also login into the system (e.g. dspace sandbox) and see the admin sidebar if everything works (https://github.com/DSpace/dspace-angular/issues/2557) , especially by controlling the browser console for unexpected errors.
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[ ] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[ ] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[ ] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[ ] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[ ] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

Thanks @floriangantner for the follow-up work!  I'll give this a test myself in the next few days to verify it works & solves the issues that we previously ran into with #2454


RedisNodes ping results check optimization

if some node ping result not true, just break foreach!

Thanks for contribution!


Added e:getPlayerColor() and e:getWeaponColor()

getWeaponColor was rejected in #1340.

In that case, I hope it gets added this time.

Could probably be added because who cares what gets added to it at this point.

just went ahead and looked this up in case there was a doubt that this wasn't just something you could just do with e:color()
these functions are meant to return the colors players set as their playermodels/physgun color, which normally can't be returned from an entity.
only question is, why tho?


fix: capturing deep composites

try fixing https://github.com/EmbarkStudios/rust-gpu/issues/873 . context is this https://github.com/EmbarkStudios/rust-gpu/pull/690#pullrequestreview-719958024 .
The tests I added still errors, but a different one compared to what I am trying to fix.
But the wired thing is, if I compile the tests using my own setup in my own repo, it compiles successfully, but in the tests it fails with a different error. Also this change fixes my original problem (in my own repo).

LGTM modulo comments, but I am a bit confused: is it actually possible for us to end up with OpCompositeInserts with multiple indices? Do we have a pass that generates those? (I'm asking because AFAIK, rustc_codegen_ssa sure doesn't have the ability to emit anything similar, at most it does single-level and usually only for ScalarPair anyway)

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

That's true at the type level, but is there something that generates the equivalent of .field.subfield extracts/inserts in a single SPIR-V instruction? (as opposed to what rustc_codegen_ssa might generate for such independent operations, of one instruction for .field and one for .subfield - tho it usually only does pointer offsets, not even by-value extract/insert)

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

That's true at the type level, but is there something that generates the equivalent of .field.subfield extracts/inserts in a single SPIR-V instruction? (as opposed to what rustc_codegen_ssa might generate for such independent operations, of one instruction for .field and one for .subfield - tho it usually only does pointer offsets, not even by-value extract/insert)

it seems when I simplify my reproduction the error is gone, but my original shader does have multi index CompositeInsert. So the testcase isn't correct. Will try to get a new testcase if possible


Replace libpython3.8/3.10 dependency with libpython3-all-dev

There is no clear reason as to why there is an explicit dependency on libpython3.8 or libpython3.10, and having this dependency breaks installation on Debian.
This would resolve #2524 & #2646

This looks like a reasonable fix so this will work on Debian @volfco -- did you build and install the .deb from this branch?


Allow taxonomic units to record additional information about specimens

There is a clear difference between a specifier that points to a scientific name and one that points to a specimen that has been identified to a scientific name.
We would like to extend this to document all the information included about the specimen in the paper, such as scientific name, GenBank identifiers to particular genes, locality information and so on. Note that we can use an external identifier to identify a specimen when the specimen is the taxonomic unit, but in some cases, we will want to use a URI to clarify which specimens are included in a taxonomic unit circumscribed by a taxon concept or taxonomic name.
Also add support for specimens that are included solely on the basis of a genetic sequence, i.e. make sure we can include a sequence itself if necessary. This might be useful in environmental genetic surveys or bacterial phylogenies.

I don't think we need this any more -- most phyloreferences use a phrasing like "the type specimen of [species name]" rather than a specimen identifier, and we haven't seen any references to GenBank IDs or locality information in a clade definition yet. Once we get to environmental genetic surveys or bacterial phylogenies, we can consider other forms of specifiers than taxa and specimens or the storing of additional information in the Curation Tool. But for now, I'm going to close this until we have a clear use-case for developing this.

I'd suggest that closing an issue be kept to have relatively clear and simple semantics. Usually this means "it's done", either in the sense of work having been done that addresses the issue sufficiently well, or a conclusion having been made that it is not necessary to address it, or that it is poorly scoped (needing either to be split into, or to be combined with other issues).
I would argue that deferring work is different from that, in the sense that for work that's deferred we assume we will come back to it in the future, only when in the future hasn't been decided yet (and may not be decided for a while). I.e., deferred work is work that we continue to find worth doing. In contrast, closed issues shouldn't need to be revisited other than perhaps for the purposes of annual reporting, because they're done.
Your explanation for closing sounds to be like an argument for deferring. Perhaps I misread that, but if that's indeed what you meant, let's not close this but instead use labels (and/or possibly a pseudo-milestone) to mark deferred issues.

Sounds good! I'd classify it as "deferred indefinitely" -- i.e. after thinking this through, I can't imagine that it will ever be in scope for the Curation Tool. But it definitely doesn't meet your criteria of "it's done" (and I could be wrong!), so I'll reopen it and tag it as "wontfix" instead. Will that work, or should we have a new tag specifically for "deferred indefinitely"?


Rename the extrinsic .submit_encoded_xrpl_transaction to .transact

This is to make it inline with ethereum.transact and doughnut.transact which are all self-contained calls
PR checklist

[ ] Describe the added/changed/fixed/removed behaviour
[ ] Tag related issue(s)
[ ] Add appropriate unit tests and/or integration tests to the integration test repository

let me know if I miss anything else @zees-dev

let me know if I miss anything else @zees-dev

The tests are pretty extensive, they would let us know 😆


Improve:  memory leak

Improve:  memory leak - need free object Timer

Thanks! Have you submitted this fix to the official WACEF repo?

Unfortunately no :-(


Fixed mailing issue in redmine 4.0.0

This solves #67
Disclaimer: not a ruby developer ;)

No this fix is so complicated.
A better one could be to replace app/models/mention_mailer.rb:9 from
Mailer.default_url_options
to
::Mailer.default_url_options
Then it's working ^^
The reason is Mailer is an already existing class and on this line it doesn't resolve with the right Mailer class.

No this fix is so complicated.
A better one could be to replace app/models/mention_mailer.rb:9
# from:
Mailer.default_url_options
# to:
::Mailer.default_url_options

Then it's working ^^
The reason is Mailer is an already existing class and on this line it doesn't resolve with the right Mailer class.

Thanks, man! its working

No this fix is so complicated.
A better one could be to replace app/models/mention_mailer.rb:9
from:
Mailer.default_url_options
to:
::Mailer.default_url_options
Then it's working ^^
The reason is Mailer is an already existing class and on this line it doesn't resolve with the right Mailer class.
Yes it works for me too.

::

No this fix is so complicated.
A better one could be to replace app/models/mention_mailer.rb:9
# from:
Mailer.default_url_options
# to:
::Mailer.default_url_options

Then it's working ^^
The reason is Mailer is an already existing class and on this line it doesn't resolve with the right Mailer class.

Maybe you should add this as merge request. This fix works for us too.


fix: use sql-migrate instead of soda

What kind of change does this PR introduce?

Use sql-migrate instead of soda for gotrue migrations. The main benefit for this change is that sql-migrate allows for running DDL migrations outside of a transaction during the migration up process. We can now update indices concurrently with this change as shown here.
Migrations will now be stored in the migrations table rather than the schema_migrations table
Migrate cmd will handle moving any existing migrations in schema_migrations to migrations to ensure that they are not ran again by sql-migrate

Thanks for the PR-- looks good to me! In the spirit of considering reasons why we should not do things before we do things I was wondering if there are any potential disadvantages to introducing sql-migrate.
It's fine if none come to mind though

these are some of the disadvantages that i considered:

potentially breaking existing projects if i've missed out an edge case while migrating the migrations
if some user has triggers on the schema_migrations table (i don't really think there's any valid use cases around this anyway)
ability to run migrations outside of a transaction (debatable)

in terms of advantages

ability to run migrations outside of a transaction (debatable)
much better support & better docs

Cool, thanks for the overview. I'm okay with merging if support in soda might potentially be a long term issue -- better to switch now when there's less complexity.
While not optimal, I think we can merge and rollback in 2 weeks/1 month if there's an uptick in issues I guess.
Let's also let @darora and @inian take a look to see if they're okay with it before we merge.


Check Delta Max As Working

First of all - Thank you!
Second - Works flawlessly with a Delta Max so feel free to add a check mark next to that as working:

Thanks for your help with the test.
Just to make sure, did you find any entities with incorrect units? (For example, the value needs to be 1/10, etc.)
Please check with particular care for entities in the diagnostic category.

Everything looked good to me, but here you go to see for yourself:

You'll probably be fine.
I will mark it as tested.


fix: Make ADC + human account work with firebase-admin

This PR is intended to fix a current bug in firebase-admin.
Google Cloud recommends utilizing [Application Default Credentials (ADC)] (https://cloud.google.com/docs/authentication/application-default-credentials), however this feature does not fully work with the firebase-admin-node library when you want to utilize a human account<EMAIL_ADDRESS>instead of a service account.
Some GCP APIs require you to specify the quota project associated to the request, however, the current implementation of the firebase-admin-node library does not provide the project ID when making requests to GCP APIs, even if you set them through gcloud auth application-default set-quota-project YOUR_PROJECT, because the code that handles the requests never adds the project ID to the request. And you get errors like this:
Your application is authenticating by using local Application Default Credentials. The identitytoolkit.googleapis.com API requires a quota project, which is not set by default. To learn how to set your quota project, see https://cloud.google.com/docs/authentication/adc-troubleshooting/user-creds .

Therefore, this pull request aims to fix this issue by checking if a projectId was provided when calling the initializeApp() function and adds it to the x-goog-user-project header of requests made to GCP APIs, just like the documentation states it should be set.
This implementation is similar to how the (working) google-auth-library library handles ADC authentication (src/auth/authclient.ts:270):
    /**
     * Append additional headers, e.g., x-goog-user-project, shared across the
     * classes inheriting AuthClient. This method should be used by any method
     * that overrides getRequestMetadataAsync(), which is a shared helper for
     * setting request information in both gRPC and HTTP API calls.
     *
     * @param headers object to append additional headers to.
     */
    addSharedMetadataHeaders(headers) {
        // quota_project_id, stored in application_default_credentials.json, is set in
        // the x-goog-user-project header, to indicate an alternate account for
        // billing and quota:
        if (!headers['x-goog-user-project'] && // don't override a value the user sets.
            this.quotaProjectId) {
            headers['x-goog-user-project'] = this.quotaProjectId;
        }
        return headers;
    }

This should also solve some problems described in #1377

Hi @foxrafa could you please take a look at the lint errors in the failing CIs? Thanks!

@lahirumaramba fixed it.

Oh, all of the test cases are not expecting the x-goog-user-project header. Can I change them @lahirumaramba ?

@lahirumaramba fixed it.

Thanks! We also need to update the unit tests :)

@lahirumaramba fixed it.

Thanks! We also need to update the unit tests :)

I updated them now.

When will a new version with this change be released?

@lahirumaramba any ETA on when this fix will be generally available?

Thanks for the updating the tests! This issue will also be addressed in the credentials migration work https://github.com/firebase/firebase-admin-node/pull/2466 (which I think is the proper way to address this issue). For now, I am okay with us merging this PR as a stopgap

Thanks @foxrafa ! this change is now included in the v12.2.0 release!

This fixes so much pain, thank you for that.


nswag jsonschema2csclient lack of functionality

I was a little nuisance lately, sorry :)
This day I tried to integrate NSwag into VS more closelly(WPF XAML behavior for automatically generated client from swagger json) and have some progress. I came to the stage when I need to actually generate client from swagger json and I have 2 options:

Create custom msbuild task and generate from code (NSwag.CodeGeneration with several customizations)
Use jsonschema2csclient for this (but i cannot afford such level of customization like in 1 option)

Required customization in my case:

Extend used namespaces. I share my contract types with nuget package (package will contain client code as well). My swagger document contains few vendorExtensions (Type and Namespaces) for every swagger definition, so I collect them and add as additional namespaces.
In my swashbuckle swagger UI I use trick for flagged enumerations - Controller method parameter definition: IEnumerable<FlaggedEnumerationType> scope = null it is transformed to array of strings in contract.
Unfortunately NSwag cannot guess enumeration name and generates Anonymous type by default (actually in NSwagScheme code i saw that it is even not try for arrays of string nameHint always set to null). I fixed this with ParameterNameGenerator and another vendorExtensions["Name"].

Finally question: is it possible to add some additional custom rules(that not in standard) into NSwagScheme to manage cases above? I will describe in details with documents and client generation code examples if you agree to discuss this issue.
BR
PS: When I finish will send u example. Maybe it would be useful.

I think you need to build your own cmd line tool with the nswag libraries to satisfy your needs...

I wrote about sample above... Well, I implement another solution for client code generation using NSwag and roslyn.
Idea is to use MSBuild ability to regenerate(MSBuild Generator) and dynamically include generated code using existen compilable class attributes.
Now to generate any client u just need to include nuget package into project and add special attributes for NSwag generators to any c# class. Tomorrow will upload code to show u results.
I cover Remote/Local swagger document fetch (can be extended with your doc from Assembly). Also implement ability to inject part of path from build, environment and nuget variables to manage easy document discovering from attributes. Leave places for customization (u can set custom Name/Type generators, custom places for document discovering from msbuild)
MSBuild tasks support incremental building and internal caching.
Anyway there is still a lot things to do, but I am afraid that will have lack of time to support this(do my actual work).
It would be great to see this kind of integration in your official releases so I could use 'vanilla' NSwag functionality in our projects.
I could explain u any peace of code by request.
BR

https://github.com/BlackGad/NswagAutoClientsSample smaples with quick documentation


[BUG] Cannot log into migrated VM

Describe the bug
I migrated a VM from Proxmox, now try to log in with root and the password, but it keeps saying Login incorrect, even though I can easily log in to the original VM with the exact same data.
Any idea what is causing that?
Environment

Harvester ISO version: 1.1.2
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Baremetal HPE

Hi @xeruf
Can you give some details about how did you migrate a VM from Proxmox to Harvester?

I extracted and converted a backup:
lzop -d vzdump-qemu-102-2022_07_30-17_29_21.vma.lzo
vma extract vzdump-qemu-102-2022_07_30-17_29_21.vma 102pve
qemu-img convert 102pve/disk-drive-scsi0.raw -O qcow2 102.qcow2

Then uploaded it into Harvester and created a VM with it as disk.
Hostname and everything look fine, it is oddly simply not accepting my login.

Tried again with another user which has a different password, same result.
Maybe something wrong with special files or so?

oops, seems like an old VM version with different password was the issue :sweat_smile:


 Even if the backend is slowish to give responses, having placeholder blocks like YouTube, Facebook, etc do makes a big difference psychologically. Paginated content like on the /find page feels a bit Web 1.0 for me 😅 . Infinite scrolling with virtualized list would be nice, like I implemented on https://zpublish.org/ (code is open-source)

I got 18/100 Chrome lighthouse score for performance (granted my laptop/internet is slowish), but I got 41 for Twitter. Server side rendering would be nice. Seems there isn't a consistent image compression pipeline? Am getting served 2MB images.

6.81s server response for api/zpage/search=&page=6 - seems to happen randomly, other API responses are 800ms

Appreciate you taking the time to listen to this feedback. Hope that it can be useful for identifying fast/easy ways of improving UX :slightly_smiling_face:
Re loading animation; it's a nice touch, the circular/pi animation looks interesting, but loading visuals should serve a function of making a page load seamless and feel as short as possible. Having multiple colours, etc draws attention to the page at the wrong time, which effectively makes the user pay more attention to how long the page takes to load; am not a UX expert, just my thoughts/observation.
Some ideas for it (my subjective opinion :sweat_smile: ):

SSR (eliminate the need to fetch post content for first page load)
Placeholder content Material Design – Launch Screen Placeholder UI

“Additionally, placeholder UIs have a higher perceived response time”

No duplicate loading animations
No opacity (opacity draws attention to the page not accepting interaction yet)

Image optimization (I don't have much experience re this so take with a grain of salt, just some ideas):

https://web.dev/use-imagemin-to-compress-images/
https://www.npmjs.com/package/imagemin-gifsicle

Re paginated content.

Google seems to be migrating away from it, and the concept doesn't exist in Material Design: https://ux.stackexchange.com/questions/111854/why-is-pagination-not-covered-by-material-design-specs
Opinionated topic - maybe user polling/interviews or A/B testing could be good? If target user base is used to Instagram/Twitter UX then maybe infinite scrolling is better. If people prefer a forum-style experience then paginated?
I find infinite scrolling nicer from a UX perspective (more addictive/satisfying and better engagement).
https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading#selecting-the-best-ux-pattern-for-your-site
Easy improvement: Larger touch target and font size for pagination component for easier use on mobile devices
Preload next page (better UX and faster loading times with paginated)

Lighthouse score

Code splitting is the main thing that would help I think; main JavaScript bundle seems to be around 7.8MB?
Pages whose main resource has cache-control:no-store cannot enter back/forward cache.

https://free2z.com/converse is pretty baller infinite scroll ...


[docs] Add example on querying Paimon table with Trino Iceberg connector

Purpose
Currently Iceberg compatibility document only has examples with Flink and Spark. This PR adds example on querying Paimon table with Trino Iceberg connector.
Tests
No tests.
API and Format
No format changes.
Documentation
No new feature.

+1

+1


API Key Leakage in the BaseLanguageModel

System Info
Langchain:0.0.319
Python:3.11.2
System: macOS 13.5.2 arm64
Who can help?
@hwchase17
@agola11
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[X] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction
I implemented a generic module to handle many types of chat models. I executed the following script after I set OPENAI_API_KEY=xxx in .env file.
from dataclasses import dataclass, field

from langchain.schema.language_model import BaseLanguageModel
from langchain.chat_models import ChatOpenAI
from dotenv import load_dotenv

# Load environment variables
load_dotenv()

@dataclass
class ModelConfig:
    """Model Configuration"""

    model: BaseLanguageModel
    arguments: field(
        default_factory=dict
    )  # This could be any arguments for BaseLanguageModel child class

    def init_model(self) -> BaseLanguageModel:
        return self.model(**self.arguments)

if __name__ == "__main__":
    model = ModelConfig(model=ChatOpenAI, arguments=dict())
    print(model)

And then the output contains a leaked API key!
<class 'openai.api_resources.chat_completion.ChatCompletion'> openai_api_key=xxxx>

Expected behavior
My idea off the top of my head is to use, say,  __str__ directive inside the original class. But this seems just a workaround for ChatOpenAI class. So something more generic feature in BaseLanguageModel would be more decent. Like should have a common property in the base class, which handle API token across any LLM models and this property might be a special class that can hide the value when other class and functions call this.
https://github.com/langchain-ai/langchain/blob/08f5e6b8012f5eda2609103f33676199a3781a15/libs/langchain/langchain/chat_models/openai.py#L181-L238
Similar issue.
#8499

Tracking this issue here: https://github.com/langchain-ai/langchain/issues/12165


Requesting a sync from the internal OpenAPI spec

I know this is relatively fresh, but stream support for runs has been added. It would be great to get this in the public OpenAPI spec.

+1

A sync would be great, especially for the Assistant API Stream Events, however I was able to implement it for my Java library using the official documentation. If you are curious take a look at:
https://github.com/sashirestela/simple-openai/pull/65/files


add signet support

This PR adds the "signet" network type to the list of networks.
See also:

https://github.com/rust-bitcoin/constants/pull/8
https://github.com/rust-bitcoin/rust-bech32-bitcoin/pull/24 (merged)

FWIW, https://github.com/rust-bitcoin/rust-bitcoin/pull/255 removed our dependency on rust-bech32-bitcoin but is blocked on a bech32 PR, but that should land soon.

Getting bitcoin_constants in would make this a lot nicer. It would also solve the problem I have with having to duplicate a lot of code for Elements and Liquid.

@stevenroose Yeah I noticed a lot of duplicate code all over the place. Wasn't sure what that was about but hopefully it can be reduced. :) I am gonna leave the bech32 PR for now, even if it is not going to relate to this repo specifically in the end.

Yeah #255 looks good and should allow us to narrow dependency scope for some projects. I believe we're closing in on rust-bitcoin/rest-bech32#35.

Codecov Report

Merging #291 into master will decrease coverage by 0.25%.
The diff coverage is 28.57%.

@@            Coverage Diff             @@
##           master     #291      +/-   ##
==========================================
- Coverage   82.03%   81.78%   -0.26%
==========================================
  Files          38       38
  Lines        6719     6752      +33
==========================================
+ Hits         5512     5522      +10
- Misses       1207     1230      +23

Impacted Files
Coverage Δ

src/util/bip32.rs
86.36% <0%> (ø)
:arrow_up:

src/blockdata/constants.rs
75.75% <0%> (-5.77%)
:arrow_down:

src/consensus/params.rs
0% <0%> (ø)
:arrow_up:

src/util/key.rs
80.76% <0%> (-0.45%)
:arrow_down:

src/util/address.rs
84.21% <9.09%> (-3.02%)
:arrow_down:

src/network/constants.rs
84.9% <90%> (+1.18%)
: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 caae4b7...ed1fb0a. Read the comment docs.

@kallewoof I'd be happy to review after rebase :relaxed:

@dongcarl I didn't realize it was in need of a rebase until you nudged, thanks. I think I've rebased it and it works, but my account is flagged at Travis right now so I don't think that CI will ever finish..

Kicking Travis!

@stevenroose Would love to, but the "Reopen" button is grayed out for some reason :)

When I hover over the "Reopen" button it says the branch was "force-pushed or recreated". I think it won't let us reopen if the branch changed in the time that it was closed. Frustrating.

I think it won't let us reopen if the branch changed in the time that it was closed. Frustrating.

If you reset the branch to 1c0385002bc89ce0d54e000776372c11bc1ec42a, the tip at the time the PR was closed, github will let you reopen

@ryanofsky Thanks!

Due to https://github.com/bitcoin/bips/pull/900, this PR was changed, and the custom genesis block generation stuff was removed.
The new approach requires a dynamic magic number which is not implemented in this PR; instead the hard-coded result is used as is.

Now will work with electrum (once PR will be accepted): https://github.com/romanz/electrs/pull/239

@dr-orlovsky Nice! I have https://github.com/Blockstream/electrs/pull/12 which is similar, but I'll close that after comparing notes with your version. Btw, is the romanz repository still active? I assumed not, so I made my PR to the ElementsProject fork.

Ouch! It is not! I had to work on Blockstream fork instead, it's >200 commits ahead! Seems all the work have to be re-done...

I do think it's active. the 200 commits ahead is for liquid support AFAIU @shesek @romanz

The main difference between the forks is that electrs started as an light-weight indexer for serving personal Electrum wallet using modest hardware (e.g. a Raspberry Pi), and still works well as such :)
Blockstream fork is more oriented toward a high-perfomant blockchain explorer - serving as a backend for Esplora but it requires better hardware (e.g. larger SSD storage and better CPU).

One thing was forgotten, otherwise seems very good. If my comment gets fixed, I think I can ACK.

@stevenroose good catch! Added Signet case.

I'm not sure what the crate error is indicating, in Travis:
     Running `rustc --crate-name ryu /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/ryu-1.0.5/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=c7e179b45d27fd2b -C extra-filename=-c7e179b45d27fd2b --out-dir /home/travis/build/rust-bitcoin/rust-bitcoin/target/debug/deps -L dependency=/home/travis/build/rust-bitcoin/rust-bitcoin/target/debug/deps --cap-lints allow --cfg integer128`
error: expected identifier, found keyword `crate`
 --> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/ryu-1.0.5/src/buffer/mod.rs:1:5
  |
1 | use crate::raw;
  |     ^^^^^
error: aborting due to previous error
error: Could not compile `ryu`.
Caused by:
  process didn't exit successfully: `rustc --crate-name ryu /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/ryu-1.0.5/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=c7e179b45d27fd2b -C extra-filename=-c7e179b45d27fd2b --out-dir /home/travis/build/rust-bitcoin/rust-bitcoin/target/debug/deps -L dependency=/home/travis/build/rust-bitcoin/rust-bitcoin/target/debug/deps --cap-lints allow --cfg integer128` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed
The command "./contrib/test.sh" exited with 101.

Thanks for the nudge. Rebased and fixed genesis nonce/bits/timestamp.

tACK https://github.com/rust-bitcoin/rust-bitcoin/pull/291/commits/a3d9899cb10796dfea4eac9a07e887abcacc0c37

Not sure however how it match information found in https://github.com/ElementsProject/lightning/pull/2972 about that the new genesis signet nonce is 621297

@dr-orlovsky Yeah, well noted. The nonce and such unfortunately changed when we nudged the POW limit awhile ago. I haven't done a re-request to the lightning project with an update yet.

@kallewoof: c-Lightning version PR with fix: https://github.com/ElementsProject/lightning/pull/4068

Signet got merged into Bitcoin Core master: https://github.com/bitcoin/bitcoin/pull/18267#issuecomment-696357656
Let's merge this PR as well - and unblock downstream Electrs dependency: https://github.com/romanz/electrs/pull/239

Any ideas on how to push this forward? Should I nudge someone, or just sit tight? Who/where if the former?

Thanks, @elichai! I think the bip16_time is only relevant during main net IBD, due to that one offending block, which does not exist in signet, so as long as it's not in the future, it should be fine with any value, I think.


Is this project still alive?

Wondering with no activity for 10 months.

Let's say it's paused. With the covid19, my working conditions changed a little and haven't yet touch lierre since some time, indeed. Unfortunately I can't give yet a date on when I'll continue to update it.


UIKitView goes blank after app restart when using fast user switching

Users of my application have run into this bug while using fast user switching on mac osx lion.  The specific issue occurs when a Chameleon app restarts while the owner is 'switched out' and another user is logged in.  This may seem like an odd case, but this occurs when users of my application are "autoupdated" while their user account is 'switched out'.
I have a mac book pro running osx lion.
This is the simplest way to repro:
I have a mac book pro running osx lion.
1.) Login to your Mac as 'User A'
1.) Create a new user account 'User B', and ensure that 'fast user switching' is enabled.
2.) Build the BigApple example application, and copy it to ~/Applications
3.) run this command from the command line 'sleep 10 ; open ~/Applications/BigApple.app'. The sleep will give you enough time to execute the next step.
4.) quickly 'fast user switch' to 'User B'. This needs to be completed before the BigApple is launched.
5.) wait for 10 seconds until BigApple is running under 'User A'.
6.) fast user switch back to 'User A'
Expected:
You see BigApple running and the screen renders as normal
Actual:
You see a blank screen.
It appears the the UIKitView stops rendering all together. The application seems to be responsive and executing, but no UI is being drawn. I have seen a similar issue when the app is running and the machine switches to using the integrated graphics card from the descrete graphics card.
Any help would be appreciated. Perhaps there is a workaround I could employ in these cases to get the view hierarchy re-initialized.

I would actually like to know a solution for this as well. We've had reports of oddities when fast user switching while Twitterrific is the active app. Upon return to the original user, the app is basically frozen or not rendering correctly. Something weird is going on.
On Dec 6, 2011, at 8:37 PM, raytrodd<EMAIL_ADDRESS>wrote:

Users of my application have run into this bug while using fast user switching on mac osx lion.  The specific issue occurs when a Chameleon app restarts while the owner is 'switched out' and another user is logged in.  This may seem like an odd case, but this occurs when users of my application are "autoupdated" while their user account is 'switched out'.
I have a mac book pro running osx lion.
This is the simplest way to repro:
I have a mac book pro running osx lion.
1.) Login to your Mac as 'User A'
1.) Create a new user account 'User B', and ensure that 'fast user switching' is enabled.
2.) Build the BigApple example application, and copy it to ~/Applications
3.) run this command from the command line 'sleep 10 ; open ~/Applications/BigApple.app'. The sleep will give you enough time to execute the next step.
4.) quickly 'fast user switch' to 'User B'. This needs to be completed before the BigApple is launched.
5.) wait for 10 seconds until BigApple is running under 'User A'.
6.) fast user switch back to 'User A'
Expected:
You see BigApple running and the screen renders as normal
Actual:
You see a blank screen.
It appears the the UIKitView stops rendering all together. The application seems to be responsive and executing, but no UI is being drawn. I have seen a similar issue when the app is running and the machine switches to using the integrated graphics card from the descrete graphics card.
Any help would be appreciated. Perhaps there is a workaround I could employ in these cases to get the view hierarchy re-initialized.

Reply to this email directly or view it on GitHub:
https://github.com/BigZaphod/Chameleon/issues/76

Yes, I have also run into the that issue as well. This also repros with the "BigApple" example app. Simply run big apple, switch to a different user, switch back. Clicking on the button now has no effect.
It appears that the events are still being fired, its just that nothing is actually getting rendered. For that specific issue, I found a fairly hacky workaround, which I am using in my application.
Listen for the NSWorkspaceSessionDidBecomeActiveNotification:

[[[NSWorkspace sharedWorkspace] notificationCenter] addObserver:self
                                                         selector:@selector(switchHandler:)
                                                             name:NSWorkspaceSessionDidBecomeActiveNotification
                                                           object:nil];

In the switch handler, brutally force the view hierarchy to reload:

- (void)switchHandler:(NSNotification*) notification {
    [window setContentView:[window contentView]];
    [chameleonNSView performSelector:@selector(configureLayers)];
}

Unfortunately, this does not solve the issue when the application is actually restarted while switched out. These issues must be related in some way.


[QNT] INT8 quantization feature description

Let me summarize some discussions with @JehandadKhan

(10) This feature is intended for quantized (QNT) inference convolutions only
(20) Bias and scale vectors

(20.10) These should be assosiated with the input and output tensors
(20.20) It is assumed that sizes of bias and scale won't be too big, i.e. these can be stored on the host.
(20.30) [Informative] Taking the above into account, bias and scale vectors could be implemented as an integral parts (attributes) of the tensor descriptor.

(30) What QNT inference convolutions do:

(30.10) They need input bias and scale vectors together with input tensors
(30.20) They compute output bias and scale vectors together with output tensor

(40) The API should provide:

(40.10) Some means to pass input bias and scale to the library and associate them with input tensors
(40.20) Some means to read output bias and scale together with output tensors

(50) So far, the only known application of the bias and scale is inference convolution. However, we anticipate that some other uses of the new attributes will likely appear in the future.

[Attribution] @junliume @johnny-keker https://github.com/ROCmSoftwarePlatform/MIOpen/labels/enhancement https://github.com/ROCmSoftwarePlatform/MIOpen/labels/specification https://github.com/ROCmSoftwarePlatform/MIOpen/labels/urgency_high https://github.com/ROCmSoftwarePlatform/MIOpen/labels/value_high, proposed assignees:

@JehandadKhan
@junliume
@iq136boy
@DrizztDoUrden

Team, everyone is invited to review this spec.

(60) Allocating space for scale and bias in GPU memory
As @jerryyin said at https://github.com/ROCmSoftwarePlatform/MIOpen/pull/1625#issuecomment-1479710288,

Both bias and scale are coming in as host vectors. It may need to be copied to be device tensors passed to the kernel. (As kernel will need and dereference those data at compute time)

I can only add that output scale/bias also need some storage space on GPU. I see three alternatives: (A) allocating space together with tensors, (B) reserving some space in workspace, (C) using dedicated buffers.
Analysis follows below.

(60.10) Using input/output tensor descriptor to exchange data with the library, using tensor buffers to exchange data with GPU
(60.10.10) The new API provides means to store bias and scale arrays (of arbitrary size) in tensor descriptors. Then miopenGetTensorDescriptorSize() can be used (as usual) by the host application to find out tensor size and allocate buffer on GPU. miopenGetTensorDescriptorSize() should take into account the alignment required to properly store bias/scale arrays.
(60.10.20) The convolution descriptor API should be extended with additional convolution attribute, e.g. MIOPEN_CONVOLUTION_ATTRIB_QNT_INFERENCE. The main objective of this is provision for future mentioned in (50). In addition, the new attribute tells the library that QNT inference convolution should be run instead of the "normal" convolution. In other words, it explicitly says how bias/scale should be used. If the attribute is not set, then scale/bias are ignored by the library.

(<IP_ADDRESS>) Please note that the new convolution attribute is not explicitly connected to the bias/scale stored in the tensor descriptors. If bias/scale is set, then miopenGetTensorDescriptorSize() will return bigger size than usual, regardless of the value of the attribute in the convolution descriptor. This is because tensor descriptors are unaware of the convolution descriptor they are intended to be used with.

(60.10.30) However, when QNT inference convolution is being run, the library must check if the bias/scale arrays are of correct size (e.g. for input data tensor, the number of elements must be (>= C) for QNT inference convolution).
(60.10.40) Allocating space in the output tensor descriptor is very similar. In order to avoid unnecessary overhead, API should provide reservation-only functionality (example: https://github.com/ROCmSoftwarePlatform/MIOpen/pull/1625#discussion_r1147905811).
(60.10.50) The downside is overhead required to copy buffers from the host to device, even if output scale/bias can be directly consumed by the next layer. And we copy buffer twice (GPU->CPU->GPU).
(60.10.60) Alternatively, we can only copy the pointers to the host memory. The advantage is that, for example, there is no need to copy output scale/bias data to the input of the next layer, -- we can simply pass the pointers. The disadvantage is the requirement that pointers must remain valid for the lifetime of the tensor descriptors.
(60.10.70) This approach has the best granularity in terms of GPU memory allocation (smallest fragmentation).

(60.20) Using input/output tensor descriptor to exchange data with the library, using workspace to exchange data with GPU
(60.20.10) This is basically the same as (60.10), but bias/scale data reside in the workspace.
(60.20.20) miopenGetTensorDescriptorSize() remains unchanged, but miopenConvolution*GetWorkspaceSize() shall report additional memory for holding bias/scale (including padding for proper alignment).

[Implementation detail] The offsets to the input/output bias/scale sub-buffers can be stored in Solution and used in the Invoker to copy data between sub-buffers and host memory.

(60.20.30) The disadvantage vs (60.10) is slightly worse GPU memory fragmentation.

(60.30) Using dedicated tensors to hold bias and scale.
(60.30.10) The existing tensor API can be used to hold sizes of scale and bias. It is the user's application that is responsible for allocating device memory, initializing it with input bias/scale and reading output. We can use 2D tensors to hold both bias and scale in a single tensor.
(60.30.20) The API extensions should associate input and output bias/scale tensor descriptors with convolution descriptor.
(60.30.30) We'll need to create new API for QNT convolution, because we need to pass three pointers to 2D tensors (or six pointers to 1D ones).
Advantages:

(60.30.40) Flexibility for free. The user app can simply pass device buffers between different primitives.

I do not know if this is important or not, but the same input scale/bias can be used in a series of convolutions at no cost, while both (60.10) and (60.20) involve copying buffers from host to device.

(60.30.50) Unified approach. For example, we already use dedicated tensor for bias in miopenConvolutionForwardBias() primitive.
(60.30.60) No need to invent APIs to pass vectors into/from the tensor descriptors, no need to add a new attribute to convolution API.
(60.30.70) Less host side overhead than (60.10.50) OR no requirement for the user app to keep pointers valid vs. (60.10.60).

Drawbacks:

(60.30.80) New API for QNT convolutions is needed.
(60.30.90) The worst GPU memory fragmentation (we need 3 or 6 relatively small device buffers)

Team, everyone is invited to review this spec.

@JehandadKhan Please consider (60.10) and (60.30). #1625 has the former in mind, while the latter potentially has the smallest host-size overhead.

[Attribution] @junliume @johnny-keker Changes: https://github.com/ROCmSoftwarePlatform/MIOpen/labels/urgency_normal due to https://github.com/ROCmSoftwarePlatform/MIOpen/pull/1625#issuecomment-1492241127


Updated CONTRIBUTORS.md

Added my name to contributors.md

Read the guidelines carefully. make sure you follow and star the repository!

@Ha


convoy-gluster-storagepool stuck in "Initializing"

Version - master 2/11
Steps:

Create two hosts
Create and start Gluster FS
Create and start Convoy Gluster FS (point it to glusterfs-server)

Results:  The storage pools are create but convoy-gluster-storagepool service is stuck in initializing
Expected:  Service to start

can you try again with latest rancher + template?

Version - master 3/7
Verified fixed

Sorry to re-open this but I just deployed Rancher and this still happens to me.


incompatible type windows::Win32::Foundation::HANDLE and std::os::windows::io::RawHandle

windows::Win32::Foundation::HANDLE and std::os::windows::io::RawHandle
are incompatible, how should i use RawHandle in windows-rs?

They have the same memory layout - the std handle types are generally *mut c_void whereas the windows crate uses a struct with a single field of whatever type is defined in metadata but the field is public so you can easily assign/extract/cast it as needed.

so can i just simply transmute it? @kennykerr

so can i just simply transmute it?

Yes.


[$250] Onboarding - Deeplink in concierge chat doesn't navigate to the correct screen within the app

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

Version Number: 9.0.48-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Action Performed:

Go to staging.new.expensify.com
Sign up with a new Gmail account
Select "Manage my team's expenses" on onboarding modal > Select employee amount > Next
Choose any integration > Next > Complete the onboarding
Once logged in navigate to the workspace created > + icon > Submit expense > Manual > Enter any amount > Finish the flow
This will trigger a start of a free trial
Navigate to concierge chat > Click on the hyperlink "#admins" in the "start of a free trial" system message

Expected Result:
The app should generate a link with a staging URL and should redirect to the correct screen within the app
Actual Result:
The app generates a link with a production URL and redirects to production
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/4148cef7-74a6-4d49-94eb-439dc8939e5d
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021844750386942511406
Upwork Job ID:<PHONE_NUMBER>942511406
Last Price Increase: 2024-10-25
Automatic offers:

situchan | Reviewer | 104675132
nkdengineer | Contributor | 104675134

Issue OwnerCurrent Issue Owner: @situchan

Not reproducible in dev.
I don't think this should be a blocker since when the deploy checklist hits production, the deeplink URL in Concierge chat will be correct.

Proposal
Please re-state the problem that we are trying to solve in this issue.
The app generates a link with a production URL and redirects to production
What is the root cause of that problem?
In here, we are checking has the same origin, it mean in staging we can not open link with the origin new.expensify.com
https://github.com/Expensify/App/blob/e4969b22e7dbb1f6a200cc587ced4ab665415c0e/src/libs/actions/Link.ts#L155
https://github.com/Expensify/App/blob/e4969b22e7dbb1f6a200cc587ced4ab665415c0e/src/libs/actions/Link.ts#L174-L181
What changes do you think we should make in order to solve the problem?

We can remove hasSameOrigin in this condition
What alternative solutions did you explore? (Optional)
https://github.com/user-attachments/assets/85f7dbc4-49c8-468b-aa6b-d0098e5fc633

hasSameOrigin check was added on purpose.
@nkdengineer can you please find out PR which added this check and confirm your solution doesn't cause any regression?

Please re-state the problem that we are trying to solve in this issue.)
The Concierge chat message for the 7-days trial contains an internal app link that does not take into account the request https origin.
What is the root cause of that problem?
This is a BE problem, the content of this specific automated message is from the backend where it's constructed with an explicit href for the anchor tag that equals to the production url which is new.expensify.com instead of the staging or the development (It happens on both).
The Front-End apps are just displaying what they're getting (which make sense as these messages should be generated on the backend and displayed as is) and for this message we are getting the production url.
The server is not taking into account the origin of the https request instead it's treating all users as if they're coming from production, maybe even this specific message is fixed for all users.

What changes do you think we should make in order to solve the problem?
The server should take into account the origin of the https request and create the dynamic reference links accordingly.
What alternative solutions did you explore? (Optional)
removing hasSameOrigin check, though opening hrefs that are intended for production on none-production environments doesn't sound correct too, we should open the link exactly as we are getting it from the backend, in order to avoid any edge cases, that's why removing hasSameOrigin is not a great idea too. Actually the current behavior makes sense the most, as the link is for the front end app is an "External link" just like any other external url that is being generated during the chat, a link that does not have the same origin as the application, which should be opened externally in a new tab just as is.
One final note to mention is that after this message, neither the user nor the Concierge chat can regenerate the same href style (Imbedding the url within a text) for example writing "GOOGLE" but enabling a redirection to "www.google.com" when pressing the word.

@situchan I think we should confirm what is expected here, do we want to be redirected to another origin when we click on a link or we only want to do that with staging environments? cc @lakchote

@situchan I think we should confirm what is expected here, do we want to be redirected to another origin when we click on a link or we only want to do that with staging environments? cc @lakchote

We should not introduce staging specific logic.
@nkdengineer could you please answer this question from @situchan:

@nkdengineer can you please find out PR which added this check and confirm your solution doesn't cause any regression?

can you please find out PR which added this check and confirm your solution doesn't cause any regression?

@situchan @lakchote  it is added in this PR and I confirm that it will not cause any regression as expected in the OP of the issue

@nkdengineer no, it's not. That PR just moved logic from here

@situchan It was first added in this PR. please check again

@situchan could you please answer @nkdengineer's comment?

reviewing

@nkdengineer removing hasSameOrigin will cause regression

@situchan @lakchote  as this issue and expected in the OP so we only want to redirect to another origin with staging environment, right?

The functionality we want is:
Given an #admins link in a system message related to a free trial
I'm redirected to the #admins room without opening a new URL (deeplink).
But I'd like to have a solution where no specific staging environment code is written e.g we don't want to check if we're on staging, the solution should abstract that.

No viable solution yet

@lakchote Since the report link in the start free trial is the production link, I have two options with two behavior

If we want to open it in the new tab and log in with the correct account if we're in another environment, we can use openExternalLinkWithToken if internalNewExpensifyPath exists and hasSameOrigin is false

https://github.com/Expensify/App/blob/e4969b22e7dbb1f6a200cc587ced4ab665415c0e/src/libs/actions/Link.ts#L190

If we want to open it without a new tab we should return the URL with the format %baseURL${internalPath} then frontend can replace it with the current environmentURL

https://github.com/Expensify/App/blob/0b547fc290371f80091e79b74ed5caf1120351bd/src/libs/ReportActionsUtils.ts#L752

Since it's a deeplink, redirecting to the correct room without opening a tab is expected.
@situchan what do you think of option #2 from @nkdengineer?

Option 2 sounds good to me

I like option #2 too, @nkdengineer let's go with that.

{
    "actionName": "ADDCOMMENT",
    "actorAccountID": 8392101,
    "avatar": "https://d1wpcgnaa73g0y.cloudfront.net/894b50e60056c966d12216005fbcacec8ce5a2c0.png",
    "created": "2024-10-31 08:32:45.660",
    "lastModified": "2024-10-31 08:32:45.660",
    "message": [
        {
            "type": "COMMENT",
            "html": "
You’ve started a free trial!

Welcome to your free 7-day trial of Expensify <emoji>🎉</emoji> Use it to continue exploring your workspace's benefits, including tracking expenses, reimbursing employees, managing company spend, and more.

If you have any questions, chat with your dedicated Setup Specialist in #admins. Enjoy!",
            "text": "You’ve started a free trial!\n\nWelcome to your free 7-day trial of Expensify 🎉 Use it to continue exploring your workspace's benefits, including tracking expenses, reimbursing employees, managing company spend, and more.\n\nIf you have any questions, chat with your dedicated Setup Specialist in #admins. Enjoy!",
            "isEdited": false,
            "whisperedTo": [],
            "isDeletedParentAction": false,
            "deleted": "",
            "reactions": []
        }
    ],
    "originalMessage": {
        "html": "
You’ve started a free trial!

Welcome to your free 7-day trial of Expensify <emoji>🎉</emoji> Use it to continue exploring your workspace's benefits, including tracking expenses, reimbursing employees, managing company spend, and more.

If you have any questions, chat with your dedicated Setup Specialist in #admins. Enjoy!",
        "isNewDot": true,
        "lastModified": "2024-10-31 08:32:45.660"
    },
    "person": [
        {
            "type": "TEXT",
            "style": "strong",
            "text": "Expensify Concierge"
        }
    ],
    "reportActionID": "4424774399671986900",
    "shouldShow": true,
    "timestamp":<PHONE_NUMBER>,
    "reportActionTimestamp":<PHONE_NUMBER>660,
    "automatic": false,
    "whisperedToAccountIDs": []
}

@lakchote This will require the BE change that will change the https://new.expensify.com in admin room href to %baseURL
When it's done I will create an FE PR to update replaceBaseURLInPolicyChangeLogAction and accept the concierge action because now we're only doing this logic with policyChangeLogAction
https://github.com/Expensify/App/blob/0b547fc290371f80091e79b74ed5caf1120351bd/src/libs/ReportActionsUtils.ts#L737-L740

I've discussed about the issue internally.
Given that's an automated message in concierge for a free trial, it'd really only affect applause and internal employees (even then it'd be an edge case),
We've decided to not fix that because it only affects staging. Though you should be compensated for the work done so far @nkdengineer @situchan, that's why I'm proposing a $50 payment for each of you.
Assigning a BZ member to issue payment, and then I'll close the issue.

@trjExpensify please see my comment just above, thanks!

Cool, payment summary as follows:

$50 to @situchan
$50 to @nkdengineer

Let me know when you have accepted the pending offers that have already been sent. Then I'll adjust and settle.

@situchan, paid. @nkdengineer, waiting for you to accept the offer.

@situchan, paid. @nkdengineer, waiting for you to accept the offer.

^ @nkdengineer did you accept the offer?

@lakchote I just did, thanks

Paid, closing!


[FEATURE] Get started | Add Alert info in the Get started pop-up

Is your feature request related to a problem?
Alert info is missing in Get started popup
What solution would you like?
Add info about Alerts in the Get started popup
Step title: View security alerts
Description:
After detectors are created, you can view alerts triggered by findings.
Buttons:  View alerts
Do you have any additional context?
Add alerts info as a third step, current Get started screenshot

Get started with Alerts info added.

How about updating the Get Started text to the following?
Security analytics generates critical security insights from existing security event logs. [Learn more][eui-popout icon]
(The learn more link should open a new tab to: https://opensearch.org/docs/latest/security-analytics/ )

Create security detector Identify security findings and threats from your log datas with detection rules. Additionally, you can set up alerts based on rule conditions.
Discover security findings After detectors are created, you can view insights and analyze security findings.
View security alerts View alerts based on conditions you have specified from your detectors.
Create custom rules for detectors Create rule or fine tune existing rules that can be added to detectors. (Step 4 should have two buttons - Create rule and Manage rules. Create rule should be a primary button)

@jimishs Additional thoughts?

@kamingleung What about buttons for the first three steps? Leave them as they are?

@jovancacvetkovic
Sorry, there's a typo in step 1, log datas should be log data
For buttons, the screenshot you provided looks good to me:

@kamingleung @amsiglan All reviews are resolved per this comment https://github.com/opensearch-project/security-analytics-dashboards-plugin/issues/129#issuecomment-1322627758

@kamingleung datas text updated to data

Resolved with PR #148


feat - support specifying models from file path

currently only pretrained models can be used, allow users to specify their own

closed by #4


NotificationInterval does not work with short intervals in iOS

I am currently creating a notification with a delay and every time I run the application, the simulator crashes whenever the notification is created.
await AwesomeNotifications().createNotification(
          content: NotificationContent(
              id: _id,
              channelKey: "example_channel",
              title:
                  "Example title",
              body:
                  "Example body",
              notificationLayout: NotificationLayout.Default
              ),
          actionButtons: [
            NotificationActionButton(
              key: "complete_survey",
              label: "Complete Survey",
            )
          ]
          schedule: NotificationInterval(
            interval: 5,
           timeZone: localTimeZone,
             repeats: true,
           )
          );

When removing this section, everything works fine:
schedule: NotificationInterval(
            interval: 5,
           timeZone: localTimeZone,
             repeats: true,
           )
          );

Issue is present in both Flutter 2.2.3 and 2.5.3.

[0.6.14]

Added validation to prevent scheduling with repeating intervals smaller than 60 seconds (iOS restriction)
Added crontab schedule to allow complex schedules based on initial and expiration date, a list of precise dates, or a crontab expression, and all four options can be combined together (only for Android)
Defined the final standard to replace negative IDs by random values
Minimum Android requirements increased to SDK 23 (Android 6.0 Marshmallow) due to new cancellation methods with unsecure procedures on API prior 23

Now this issue will not happen again. Thank you so much for your help.


Run the bot 24/7 on a small server.

I already have the server, it just needs to run memberberrybot 24/7. Will be done asap.

Done!


Update for Pint 0.20.0

Description
This PR includes updates for compatibility with Pint 0.20.0
Todos
Notable points that this PR has either accomplished or will accomplish.

[x] Re-exports Quantity, Measurement, and Unit mirrored from new locations in the Pint API
[x] Removes the speed alias, which is now forbidden for reasons I don't follow

Questions

[ ] How can I make Quantity etc. generic classes again? Mypy was complaining about this.
[x] Will version 0.20.1 include other changes? We'll see https://github.com/hgrecco/pint/pull/1633/files#diff-22042b3f9bd2818e47c2e60327e7b830b0989ecd80cef90047e5246bfa23c07a

Status

[x] Ready to go

Codecov Report

Merging #51 (2f567c4) into main (0b50def) will decrease coverage by 45.25%.
The diff coverage is 100.00%.

Additional details and impacted files

Mypy is unhappy but this is, so far, doing everything I want it to.

Thanks!


Deployment challenges in PTU scenarios

In situations where a customer has acquired throughput units for their Azure OpenAI instance, the deployed models are linked to the provisioned throughput units (PTUs). In such instances, the script should offer the choice to utilize the already-existing Azure OpenAI endpoints, along with the model's name, rather than attempting to generate these resources.
This can be accomplished by parameterizing the values of the endpoints to be used and employing a conditional flag for the deployment of Azure OpenAI resources and models.

Thanks for your suggestion, @punitkshah! For my understanding, would a customer with provisioned deployments (PTU) not deploy this via infra as code already? My belief would be that a customer would adapt this repository to their needs, and add their current deployment in the infra code, instead of deploying both separately.
If the deployment is already present, it won't recreate the OpenAI model deployment.

@iMicknl - I was thinking of an approach that involves parameterizing the endpoint and model name. However, for the incorporation of existing resources, users would be required to modify the repository by updating specific details in the main.bicep and ai.bicep files, such as the model name and capacity.
In the case of most PTU deployments, which I anticipate will be common in scenarios where this proxy is utilized, the models are expected to have already been deployed with the required capacity.
While it is not a significant obstacle, based on recent deployment, it appears that users find it more convenient to specify values in just one parameter file rather than updating multiple bicep files.


Documentation improvements

Fixes incorrect/outdated code samples, grammar, and formatting issues in documentation across the project.

Thanks for the PR! Wanted to let you know I'm out today but I will review
tomorrow.
On Thu, Jun 22, 2023, 9:29 AM Dennis Tsar @.***> wrote:

@.**** commented on this pull request.
On
frontend/compose-html-ext/src/jsMain/kotlin/com/varabyte/kobweb/compose/http/HttpFetcher.kt
https://github.com/varabyte/kobweb/pull/256#discussion_r1238773884:
The then syntax wasn't valid since the functions don't return a Promise ,
but it can be replaced withe let to better show off nullability instead
of just being removed.
—
Reply to this email directly, view it on GitHub
https://github.com/varabyte/kobweb/pull/256#pullrequestreview-1493605475,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKNONATZ7UGYHOAM2HOSAD3XMRXH5ANCNFSM6AAAAAAZQONAZU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Focus on function declaration in Edit Function dialog

When using the "Edit Function" action on a function, the focus of the dialog is on the name of the function, not the function declaration. Usually, if I only want to change the name of the function, I use the "Rename Function" action, and I use "Edit Function" mainly to alter the function signature.
Therefore, I would consider it more practical if the keyboard focus was on the function signature edit field by default when opening a new "Edit Function" dialog.

Sounds like a good enhancement.  I also noticed that the signature text component does not have undo/redo support.


Https error 404

Source information
Anime pahe
Source language
English
Steps to reproduce
1.open animepahe
2.search kill la kill
3.trying to the episode
Expected behavior
The video is working
Actual behavior

Aniyomi version
App version: <IP_ADDRESS>-7809
Android version
Motorola
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

I have tested the extension and it is working fine.

@Delmarcop52 have you updated the app and the extension?

Also aniplay is still not working

aniplay has not been fixed yet, I hope to fix it soon :D

Also aniplay is still not working


Implement SQL CLI deploy

I'm closing this ticket since we broke this work into smaller tickets.
These are the detailed tickets on the SQL CLI deployment and split the remaining work with the team for us to accomplish the milestone 0.3
◦ https://github.com/astronomer/astro-sdk/issues/1473 - Review
◦ https://github.com/astronomer/astro-sdk/issues/1517 - Review
◦ https://github.com/astronomer/astro-sdk/issues/1520 - Review
◦ https://github.com/astronomer/astro-sdk/issues/1528 - In Progress (Draft)
◦ https://github.com/astronomer/astro-sdk/issues/1529 - Done
◦ https://github.com/astronomer/astro-sdk/issues/1582 - Pankaj to pair up with Daniel on this.
◦ https://github.com/astronomer/astro-sdk/issues/1601 - Review
◦ https://github.com/astronomer/astro-sdk/issues/1602 - Review
I also created future tickets related to deployment, currently assigned to milestone 0.4 (to be reviewed)
◦ https://github.com/astronomer/astro-sdk/issues/1522
◦ https://github.com/astronomer/astro-sdk/issues/1523
◦ https://github.com/astronomer/astro-sdk/issues/1524
◦ https://github.com/astronomer/astro-sdk/issues/1525
◦ https://github.com/astronomer/astro-sdk/issues/1526
◦ https://github.com/astronomer/astro-sdk/issues/1527

This is a duplicate of #1520


Hopefully address noisy job output about logs

Closes: 🔥
What's Changed

https://github.com/nautobot/nautobot/actions/runs/5283696835/jobs/9560341817?pr=3922#step:7:119
https://github.com/nautobot/nautobot/actions/runs/5284269391/jobs/9562829677?pr=3873#step:7:22845

TODO

[ ] Explanation of Change(s)
[ ] Added change log fragment(s) (for more information see the documentation)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[ ] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

superseded by #3933.


Enable and disable quests command

Hi,
Please, can you add simple command to enable and disable each quest ?
Thanks in advance :)

Unfortunately there are no plans to add this. Either remove the quest or set an obscenely high requirement (9999 diamonds).


[SPARK-27872][K8s][2.4] Fix executor service account inconsistency

What changes were proposed in this pull request?
Similar patch to https://github.com/apache/spark/pull/24748 but applied to the branch-2.4.
Backporting the fix to releases 2.4.x.
Please let me know if I missed some step; I haven't contributed to spark in a long time.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@erikerlandson  , could you help review this, when you get a chance?

ok to test

Test build #129079 has started for PR 29844 at commit 853e1c7.

Test build #129079 has finished for PR 29844 at commit 853e1c7.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129079/
Test FAILed.

Is there a test for executor SA that is different than the driver SA?

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33700/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33700/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33700/
Test PASSed.

Test build #129085 has started for PR 29844 at commit 1e6c509.

Test build #129085 has finished for PR 29844 at commit 1e6c509.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129085/
Test FAILed.

Merged build finished. Test FAILed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33706/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33706/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33706/
Test PASSed.

Thanks @dongjoon-hyun and @erikerlandson for the review. Let me know if you have more comments that I can address.

Test build #129091 has started for PR 29844 at commit 9cb5851.

Test build #129091 has finished for PR 29844 at commit 9cb5851.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129091/
Test FAILed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33712/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33712/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33712/
Test PASSed.

@nssalian this LGTM - it looks like you exceeded 100 character line length in a few places and that needs to be fixed to pass the build checks.  Once it passes the linting and testing I can merge

Test build #129093 has started for PR 29844 at commit cfed34c.

Test build #129093 has finished for PR 29844 at commit cfed34c.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129093/
Test FAILed.

Test build #129094 has started for PR 29844 at commit 46bcdff.

Test build #129094 has finished for PR 29844 at commit 46bcdff.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129094/
Test FAILed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33714/

Test build #129096 has started for PR 29844 at commit 0a47a8e.

Test build #129096 has finished for PR 29844 at commit 0a47a8e.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129096/
Test FAILed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33715/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33714/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33714/
Test PASSed.

Test build #129097 has started for PR 29844 at commit 81205a5.

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33715/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33715/
Test PASSed.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33717/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33718/

Test build #129097 has finished for PR 29844 at commit 81205a5.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/129097/
Test PASSed.

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33717/

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33717/
Test PASSed.

@erikerlandson, tests passed. Thanks for your review.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/33718/

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33718/
Test FAILed.

@nssalian merged to branch-2.4, thanks for the patch!

@erikerlandson Does this conf exist in Apache Spark 3.0.1?

This merge silently creates a future regression because Apache Spark 3.0 doesn't have this conf.
~s:master $ git grep KUBERNETES_AUTH_EXECUTOR_CONF_PREFIX.serviceAccountName
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/deploy/k8s/Config.scala:    ConfigBuilder(s"$KUBERNETES_AUTH_EXECUTOR_CONF_PREFIX.serviceAccountName")

~s:branch-3.0 $ git grep KUBERNETES_AUTH_EXECUTOR_CONF_PREFIX.serviceAccountName

~s:branch-2.4 $ git grep KUBERNETES_AUTH_EXECUTOR_CONF_PREFIX.serviceAccountName
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/deploy/k8s/Config.scala:    ConfigBuilder(s"$KUBERNETES_AUTH_EXECUTOR_CONF_PREFIX.serviceAccountName")

Sorry guys, @erikerlandson and @nssalian . I'll revert this first.
@nssalian . You can make a correct PR if you want SPARK-27872. Please don't piggy-backing all the other improvements silently. It breaks Apache Spark release policy.

cc @viirya , too.

@dongjoon-hyun wasn't aware of the PR you mentioned. I can correct this.

@dongjoon-hyun @erikerlandson  I added another PR to fix these changes, easier than a revert. -> #29876

Thanks for swift replying, @nssalian . However, your addition PR isn't not better than a clean revert in the perspective of downstreams. We had better have a clean and correct commit after reverting.

Since @erikerlandson seems to be busy, I'll revert the problematic commit first.

the changes backported correspond to https://github.com/apache/spark/pull/24748, and SPARK-27872 was tagged as a bug fix (although a credible argument could be made it was a new feature).

Yep. It looks like that. I understand the situation, @erikerlandson . The committers had better be more careful because the contributors make this kind of mistakes sometime. BTW, I'm not against SPARK-27872. I'm against for SPARK-30122 based on the PR content.


Abuse of function arguments to trigger update

This is just a suggestion regarding how the size recalculation is triggered in this line:
$: if (mounted) recomputeSizes(0, height, width, stickyIndices); // call scroll.reset;

At first glance this looks like a mistake because the function only accepts one argument.
I would instead write it like this:
$: {
  height, width, stickyIndices;
  if (mounted) recomputeSizes(0); // call scroll.reset;
}

REPL example of this approach

Indeed, this is much cleaner!


Factor out authenticated protocol object to a test fixture

Many of the tests share the same setup of a pre-authenticated Zino1ServerProtocol instance with a mocked transport object with a readable output buffer.  In order to avoid all the redundant test code, this factors out this type of protocol object as a re-usable test fixture.
Depends on #104 to be merged first.

#104 is merged now. Rebased to master and taken out of draft mode.


Update README.md for fixing ignite flag

What is this PR for?
While Apache Ignite version in Zeppelin was bumped up by #916, but ignite build flag in README.md is outdated so far. So I just changed 1.1.0-incubating -> 1.6.0.
What type of PR is it?
Hot Fix
Todos
What is the Jira issue?
How should this be tested?
Just see here.
Screenshots (if appropriate)
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

LGTM

LGTM

LGTM!


[fix][test]Fix flaky test DispatcherBlockConsumerTest.testBrokerSubscriptionRecovery

Fixes #17011
Motivation

In this test, make a batch of messages is acked, and make the remaining messages are redelivered, then try to receive the redelivered messages again. However, the sequence num is used for cmd-ack. But if the order of the messages changes, the acked messages will not be the expected messages, which makes the test unstable.

There is a bug that caused repeated consumption, PR https://github.com/apache/pulsar/pull/18227 has fixed it.

Changes
Use the message content to determine whether the message should ack.
Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository:

https://github.com/poorbarcode/pulsar/pull/33

Codecov Report

Merging #18228 (7c325f6) into master (6c65ca0) will increase coverage by 35.87%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #18228       +/-   ##
=============================================
+ Coverage     34.91%   70.79%   +35.87%
+ Complexity     5707      438     -5269
=============================================
  Files           607       26      -581
  Lines         53396     2246    -51150
  Branches       5712      245     -5467
=============================================
- Hits          18644     1590    -17054
+ Misses        32119      483    -31636
+ Partials       2633      173     -2460

Flag
Coverage Δ

unittests
70.79% <ø> (+35.87%)
:arrow_up:

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

Impacted Files
Coverage Δ

...pache/pulsar/proxy/server/ProxyServiceStarter.java
60.66% <0.00%> (-1.34%)
:arrow_down:

...apache/pulsar/proxy/server/DirectProxyHandler.java
63.63% <0.00%> (ø)

...apache/pulsar/proxy/server/ParserProxyHandler.java
91.86% <0.00%> (ø)

...ache/pulsar/proxy/server/BrokerProxyValidator.java
89.15% <0.00%> (ø)

...sar/proxy/server/TargetAddressDeniedException.java
100.00% <0.00%> (ø)

...in/java/org/apache/pulsar/PulsarBrokerStarter.java

.../org/apache/pulsar/PulsarClusterMetadataSetup.java

...g/apache/pulsar/PulsarClusterMetadataTeardown.java

...org/apache/pulsar/PulsarInitialNamespaceSetup.java

...pache/pulsar/broker/admin/impl/NamespacesBase.java

... and 577 more


GWAS.gwas.prs plink2 does not produce .profile with chr:pos:a1:a2 snp format

Describe the bug
"Warning: 6201014 --score file entries were skipped due to missing variant IDs." thrown when running with snps list chr:pos:a1:a2 in plink2. works just fine with plink1.9
To Reproduce
python run_gwas_pipeline.py using snp list like: chr:pos:a1:a2
Expected behavior
snps read by --score and produce .profile
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
google colab
Additional context
this is definitely a plink2 issue. will submit a bug report on plink side but we need a temp workaround here

updated to new plink2 version


Application Context loading fail with Mongock 3.2.8 and Spring Boot 2.3.1.RELEASE

I'm trying to upgrade my project to Spring Boot 2.3.1.RELEASE and Mongock 3.2.8.
When application start, I've got this error:
***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    com.github.cloudyrock.mongock.SpringMongockBuilderBase.createMongoTemplateProxy(SpringMongockBuilderBase.java:130)

The following method did not exist:

    'org.springframework.data.mongodb.MongoDbFactory org.springframework.data.mongodb.core.MongoTemplate.getMongoDbFactory()'

The method's class, org.springframework.data.mongodb.core.MongoTemplate, is available from the following locations:

    jar:file:/home/xxxxxxxx/.m2/repository/org/springframework/data/spring-data-mongodb/3.0.1.RELEASE/spring-data-mongodb-3.0.1.RELEASE.jar!/org/springframework/data/mongodb/core/MongoTemplate.class

The class hierarchy was loaded from the following locations:

    org.springframework.data.mongodb.core.MongoTemplate: file:/home/xxxxxxxx/.m2/repository/org/springframework/data/spring-data-mongodb/3.0.1.RELEASE/spring-data-mongodb-3.0.1.RELEASE.jar

Action:

Correct the classpath of your application so that it contains a single, compatible version of org.springframework.data.mongodb.core.MongoTemplate

I've checked that the MongoTemplate class contains the method getMongoDbFactory() and it is ok.
Here is my bean mongock:
@Configuration
public class MongockConfig {
    @Bean
    public SpringBootMongock mongock(MongoTemplate mongoTemplate, ApplicationContext springContext) {
	    return new SpringBootMongockBuilder(mongoTemplate, "com.foo.myapp.config.changelogs")
					    .setApplicationContext(springContext)
					    .setLockQuickConfig()
					    .build();
    }
}

What's wrong ?

In Spring Data Mongodb 3.0.1, the getMongoDbFactory() returns new object MongoDatabaseFactory.

Hello @joelroyer ,
if you want to use Spring data 3, you should be using Mongock 4.X. It's still in beta, but it's stable. Although we haven't still released official documentation, please follow this issue
, which explains how to use it


[PROPOSAL]: Changes to support for multiple index types

Problem Statement
Code changes required to support multiple index types like bloom filter index and partition elimination index.
Background and Motivation
Why limit to covering indexes? Let's expand hyperspace to make it flexible for more index types.
Proposed Solution
Make changes to the existing design to allow for flexibility in adding more index types.
Design
Changes to Action classes

New Classes for updating the rules

Rules end to end workflow utilizing these classes

PartitionEliminationIndex Design
Extending the new index config defined in this design doc: https://github.com/microsoft/hyperspace/issues/341
we can define the PartitionElimination non-covering index as below:
case class PartitionEliminationIndexConfig (
    indexName: String,
    indexedColumns: Seq[String]) extends NonCoveringIndexConfig

Using PartitionElimination Index
PartitionEliminationIndex is a reverse index from index columns and the data files which contain these values. These could be useful especially for point lookups and range queries.
Implementation
Refactoring Tasks
Tasks:

trait: CreateIndex
Class: CreateBFIndex: def op()
Class: CreatePEIndex: def op()
Class: CreateCoveringIndex: def op()
Class: Ranker: def rankIndexes(indexes, rule): Seq[IndexLogEntry]) >>> Needs resolution on how to rank multiple indexes.
trait: IndexTypeHandler:
def udpatePlan(plan: LogicalPlan, index): LogicalPlan => call the right handler based on type.
Class: BFHandler: def udpatePlan(plan: LogicalPlan, index): LogicalPlan
Class: CIHandler: def udpatePlan(plan: LogicalPlan, index): LogicalPlan
Class: PEHandler: def udpatePlan(plan: LogicalPlan, index): LogicalPlan

PartitionEliminationIndex specific tasks
FilterIndexRule Handler which uses PEI

Get the source plan
Get the index (these steps would be done in the rule and not the handler)
Run a spark query on index data with the query on the index columns.
Collect a list of data file paths which satisfy the index.
Return a new logical plan which reads data from these filtered source data files.

Creating PEIndex

Exactly as creating a covering index. Just skip the included columns and add the filename column by default.

Refreshing PEIndex

Exactly as refreshing a covering index. Just skip the included columns and add the file name column by default.

Performance Implications (if applicable)
None
Alternate Design Options

Have separate rule sets for every index types. (Today) This will require us to add rules to the optimizer in some hard-coded way as below example:

extraOptimizations += CoveringFilterRule :: BloomFilterFilterRule :: PartitionEliminationFilterRule :: Nil

We will have to hardcode some rule order. This is up for discussion. (e.g. for a filter rule, to choose one type of index over other)

Seems IndexTypeHandler is not necessary as we should create new rules for Non-covering index / bloom filter index.

Seems IndexTypeHandler is not necessary as we should create new rules for Non-covering index / bloom filter index.

thanks @sezruby , it still is a good choice, for e.g. filterindexrule can directly use bloom filter and non-covering index. It's generally a better abstraction I think to separate out index type logic from rules from now on moving forward.

thanks @sezruby , it still is a good choice, for e.g. filterindexrule can directly use bloom filter and non-covering index. It's generally a better abstraction I think to separate out index type logic from rules from now on moving forward.

Ok these are my points:

we need to keep Rules simple and clear.
each index type might have all different conditions and getCandidateIndexes and rank algorithms will be incompatible. Having index type condition for the functions might not be clear.
I also have some refactoring plan of rules for whyNot API. I'll refactor the rules as series of "Checks" to filter the candidate indexes. We might be able to reuse some "Check" between rules.
Hybrid Scan for bf or non covering indexes incurs some complexity

And lastly how can we apply both a covering index and a BF index using one Filter Rule?

Ok these are my points:

we need to keep Rules simple and clear.
each index type might have all different conditions and getCandidateIndexes and rank algorithms will be incompatible. Having index type condition for the functions might not be clear.
I also have some refactoring plan of rules for whyNot API. I'll refactor the rules as series of "Checks" to filter the candidate indexes. We might be able to reuse some "Check" between rules.
Hybrid Scan for bf or non covering indexes incurs some complexity

And lastly how can we apply both a covering index and a BF index using one Filter Rule?

+1 to what @sezruby is saying. I'm in favor of separating out the rules per index type since the logic might be totally different. Ideally, we would have:

Covering index comes with a collection of rules e.g., FilterIndexRule, JoinIndexRule and later AggIndexRule
Non-covering indexes (like fine-grained partition elimination and bloom filter index) will come with their own set of rules e.g., FilterRule to begin with. Also, note that the join optimizations through fine-grained partition elimination (index intersection) and bloom filter indexes (bloom filter gets pushed to one side of the join) are totally different and I do not see any reusability.

The important thing we should consider is ensuring the duplication is minimum to the extent possible.
@apoorvedave1 @thugsatbay What are your thoughts on this?

Ok these are the points:

we need to keep Rules simple and clear.
yeah so if we do this design, i think rules will become simpler and clearer. I am not saying to not write new rules. I am saying if rules can be reused, we don't need to duplicate it if possible. One example is Filter rule. If join rule requires a different logic, we can write a new join rule. but filter rule doesn't require duplication.

each index type might have all different conditions and getCandidateIndexes and rank algorithms will be incompatible. Having index type condition for the functions might not be clear.

I also have some refactoring plan of rules for whyNot API. I'll refactor the rules as series of "Checks" to filter the candidate indexes. We might be able to reuse some "Check" between rules.
Hybrid Scan for bf or non covering indexes incurs some complexity

hybrid scan logic gets extracted out of the filter rule into the index type handler. CoveringIndexHandler knows how to handle hybrid scan for covering index. Same for BF, NC

And lastly how can we apply both a covering index and a BF index using one Filter Rule?
If you take a look at the design, what I have done is added an IndexTypeHandler for exactly this question. Given multiple index types, a ranker decides which index to pick. if it is a covering index, covering handler will update the plan. if it's a bf index, bf handler will update the plan.

Here's the bottom line. Given a data source and two types of indexes which are eligible. E.g. a covering index, which was not updated for long, and a bf index, which is most recently updated. How do we decide which index to choose from?
Option 1: Use a ranker for the rule type. Filter index rule can use a ranker to choose the bf or covering index and pick one.
Option 2: Use two rules. FilterRuleForCovering, FilterRuleForBF. Now the quesiton is, how do we decide (today) which rule to prioritize? Remember, the Covering index could be outdated or the BF index could be outdated so i think we should not hardcode it to prioritize one over the other.

If we look at FilterIndexRule or JoinIndexRule. We are trying to find if there is a filter or join condition. Once it is done, we are trying to figure can we use covering index. And if they are multiple index we rank them.
The question is are we ever going to compare two different type of index. If no, then how we figure out which we prefer more based on type, staleness .. it becomes complex. If yes, then we need to do inside the rule (what metrics to use to compare for 2 different type of indexses is debatable) ?
What I believe is that changing the getCandidateIndex method/function/utility to find the best index should be the right approach.
For each Rule we would already know what type of index we can apply. Going through each eligible index and applying on the rule would give us a new item [Rule, Index] to look at. Once we have collected all these items we can figure out which would work best based on our internal heuristics (metrics to discuss). Once done we return the index back. This is where the handlers come into play as they will take the rule and create an item and help compare which one is the best through rankers.
For future cost optimization problem (as discussed with @apoorvedave1) which rule+index combination to chose first. Each Rule should expose an internal API telling which index it supports (). Also each rule should expose an internal API allowing to give preference order of selection of index.

This is a great proposal. I would suggest to have an Epic for it where to include the work that needs to happen. From the top of my head it will require:

Change in the public API
Refactoring the core part of Hyperspace
Each type of index has its own particularities and needs to be understand

How it is created
How it gets updated
How to manage it
Hybrid scans over each one
Joins between datasets with different indexes

Performance testing

I'm sure I lost a lot of other work needed for this.

@andrei-ionescu Yep! We have an epic tracking this work #157 (we are using ZenHub so we can see all the linked issues).
The goal is to add a few index types so we can flesh up all the generality and change the design abstractions as needed. What I've requested @apoorvedave1 to do was to update this issue with a detailed break-down of all the steps. He will most likely get to this early next week.

@rapoth, @apoorvedave1: For file skipping indexing please have a look on the XSkipper built by IBM.

Closing old issues. Further discussions can continue in #441.


Include DAV in protocols supported by gfal

Another PR's of supreme brevity: gfal2 supports the WebDAV protocol (reference).

Hi, thanks but please make the change to the main-dev branch. Then I will merge it with master.


Documentation issue https://js.langchain.com/docs/expression_language/get_started

The documentation here: https://js.langchain.com/docs/expression_language/get_started says to run pnpm add @langchain/openai @langchain/community but it's missing: @langchain/core/prompts and @langchain/core/output_parsers. Installing @langchain/core seems to help.

@langchain/core is installed as a result of installing the other packages - what is erroring for you?

It's right here:
https://github.com/langchain-ai/langchainjs/blob/7e16af24dd4ee28e8536e30e9db7ffab0e26a69b/langchain/package.json#L1212
It seemed to work when I tried it with pnpm?


mms data preparation doesn't work with latest nightly torchaudio build

I used this tutorial: https://github.com/facebookresearch/fairseq/tree/main/examples/mms/data_prep
To setup a forced alignment system with mms, however, when I reinstalled my conda environment today, (10th of July 2023), it didn't run anymore, as the torchaudio nightly build is incompatible with the code in the example. The nightly build requires an extra dimension for the emissions variable (probably a batch dimension).
Reverting the code to 27th of Juny 2023 (using pip install --pre torchaudio==2.1.0.dev20230627+cu118 --index-url https://download.pytorch.org/whl/nightly/cu118 instead of pip install --pre torchaudio --index-url https://download.pytorch.org/whl/nightly/cu118 ) fixed the issue for me. But would be nice if the tutorial and code could be updated to work with the new batch in the nightly build.
def get_alignments(
    audio_waveform,
    tokens,
    model,
    dictionary,
    use_star,
    sample_rate
):
    # Generate emissions
    # emissions, stride = generate_emissions(model, audio_file)
    emissions, stride =  generate_emissions_waveform(model, audio_waveform, sample_rate)
    T, N = emissions.size()
    if use_star:
        emissions = torch.cat([emissions, torch.zeros(T, 1).to(DEVICE)], dim=1)

    # Force Alignment
    if tokens:
        token_indices = [dictionary[c] for c in " ".join(tokens).split(" ") if c in dictionary]
    else:
        print(f"Empty transcript!!!!! for audio file {audio_waveform}")
        token_indices = []

    blank = dictionary["<blank>"]

    targets = torch.tensor(token_indices, dtype=torch.int32).to(DEVICE)
    input_lengths = torch.tensor(emissions.shape[0])
    target_lengths = torch.tensor(targets.shape[0])

    path, scores = F.forced_align(
        emissions, targets, input_lengths, target_lengths, blank=blank
    )
    path = path.to("cpu").tolist()
    segments, scores_segments = merge_repeats_scores(path, scores, {v: k for k, v in dictionary.items()})
    return segments, stride, scores_segments
    ```

Great you managed to get it to run. I run it on a Windows desktop with 12GB VRAM. I noticed it uses about 5-7 GB of VRAM.

We fixed this issue now. Thanks to @yaya-sy for sending the PR.

How this issue was fixed ? I can't see any merged of the PR.

Ah! looks like the change was commited to your local branch.
Fixed in https://github.com/facebookresearch/fairseq/pull/5317 now.