Add default CIA args

The CIA default args JSON is incorporated into the PMP shared files to assist the migration to conda-forge.
Files:
share/setup_default_args.py: Copy of writejson.py from CIA. Edit arguments here, then run the script to generate share/DefArgsCIA.json
share/DefArgsCIA.json: The JSON containing the default arguments. This is now included in the PMP installation.
setup.py: Added share/DefArgsCIA.json to data_files. Added commands to regenerate DefArgsCIA.json when setup.py is run.
pcmdi_metrics/driver/pmp_parser.py: Get DefaArgsCIA.json file from PMP installation, not from separate CIA package install.
Testing:
To test this, you should create a new environment without the CIA (so don't use the CDAT nightly install). Then try running the mean climate driver.
conda create -n test1
conda activate test1
conda install -c conda-forge  python=3.6 cdms2 genutil cdutil cdp matplotlib numpy proj4 jupyterlab nb_conda nb_conda_kernels
python setup.py install
conda list (verify no cia)

@lee1043 Thanks for the testing and the flake8 fixes!


[bug] update google maps marker

Requirements
Google Maps is updating from Marker to google.maps.marker.AdvancedMarkerElement We need to upgrade this.

js?callback=__google…places&v=weekly:233 As of February 21st, 2024, google.maps.Marker is deprecated. Please use google.maps.marker.AdvancedMarkerElement instead. At this time, google.maps.Marker is not scheduled to be discontinued, but google.maps.marker.AdvancedMarkerElement is recommended over google.maps.Marker. While google.maps.Marker will continue to receive bug fixes for any major regressions, existing bugs in google.maps.Marker will not be addressed. At least 12 months notice will be given before support is discontinued. Please see https://developers.google.com/maps/deprecations for additional details and https://developers.google.com/maps/documentation/javascript/advanced-markers/migration for the migration guide.

[ ] Follow the directions in the link provided and upgrade it.

Dependencies

None (Add any issue dependencies here)

@theyokohamalife  might be a good one for you?

@ermish  I'll take a look at it!

as part of #468 this error goes away with the custom marker. The custom marker is easier to work with for svgs, and was surprisingly simpler code.


Make "PCAMetric" more like "PCAMetric_f_multithreaded"

Mostly stylish changes to make it easier to compare the source files of "itkPCAMetric" and "PCAMetric_f_multithreaded".

No need to await the CI. "itkPCAMetric.h" and "itkPCAMetric.hxx" are not included with the build, at the main branch.


rebased fix for trace decorator

I have merged this change into my https://github.com/mithro/q/tree/abadger-fix branch and added tests.
Will merge the code upstream shortly.


TypeError: ~ (operator.invert) is only implemented on byte tensors

Hi!
During training I got this error

python train.py --output_directory=outdir --log_directory=logdir
WARNING:tensorflow:
The TensorFlow contrib module will not be included in TensorFlow 2.0.
For more information, please see:

https://github.com/tensorflow/community/blob/master/rfcs/20180907-contrib-sunset.md
https://github.com/tensorflow/addons
https://github.com/tensorflow/io (for I/O related ops)
If you depend on functionality not listed there, please file an issue.

FP16 Run: False
Dynamic Loss Scaling: True
Distributed Run: False
cuDNN Enabled: True
cuDNN Benchmark: False
Epoch: 0
Traceback (most recent call last):
File "train.py", line 290, in
args.warm_start, args.n_gpus, args.rank, args.group_name, hparams)
File "train.py", line 215, in train
y_pred = model(x)
File "/opt/conda/lib/python3.6/site-packages/torch/nn/modules/module.py", line 531, in call
result = self.forward(*input, **kwargs)
File "/tacotron2/model.py", line 508, in forward
encoder_outputs, mels, memory_lengths=text_lengths)
File "/opt/conda/lib/python3.6/site-packages/torch/nn/modules/module.py", line 531, in call
result = self.forward(*input, **kwargs)
File "/tacotron2/model.py", line 402, in forward
memory, mask=~get_mask_from_lengths(memory_lengths))
TypeError: ~ (operator.invert) is only implemented on byte tensors

I ran this in docker container configured with Dockerfile from the repo and installed all libraries from requirements.txt but with small changes due to occuring errors:

matplotlib 2.1.0 ==> matplotlib 3.2.1
numpy 1.13.3 ==> numpy 1.16.0
plus future packet

Does anyone have/had this problem?
Regards
Franek

Which version of pytorch you have?

@ksaidin Good point, I resolve this by installing newer version of pytorch. I will close this issue.


use le ordr

if this ever gets used please use the websocket instead of querying the o!rdr api every 5 seconds to know if the replay finished rendering. see https://ordr.issou.best/docs

@christopher-dG this should be mostly ready. Can you help me with the github ci part, mainly in terms of setting up a proper test.sh file?

@christopher-dG bump

bump? not sure if you're still in charge of osu-bot, but I'd really like to see it make renders again

merging, will fix/change things in the main branch :ok_hand:

should have squashed before merging, oops


fix: support binary type

Maybe we need to increase version dependency for databend-driver

Maybe we need to increase version dependency for databend-driver

The version is databend-driver>=0.12.1, so no need to change it.

But databend-driver dose not support binary until 0.12.3

It will use the newest version of databend-driver when user install sqlalchemy.


[otbn] Clarify what happens on out-of-bounds or unaligned load/store

Allocate an error code for "bad data access" and refer to it in the
docs: this can totally change as we implement the design, but it's
much easier to say something and change it later.
This patch also slightly expands the general notes about what happens
on an error ("We stop and set an error flag": see _index.md). I think
this should be pretty uncontentious. Obviously, there are more details
to add in future!
Closes #3094.

Force-push adds missing comma to the verilog enum: oops!


Server tasks api module tests

[User Story]
Server tasks api module tests

Epic Title
Next Server Integration Tests

T-shirt size: S(mall), M(edium), L(arge)
M

User Story
"As a developer I would like my code tested so it will not break from any changes."

Description
Currently the Tasks API module is sitting at 0% coverage.   This needs to be increased to at least 70% coverage via unit tests or integration tests.  Any changes or modifications are not checked because of this lack of tests.

Acceptance Criteria/Tests
Running ./bin/build -t shows coverage for the module to be greater then 70% or a comment must be made on why it is not testable. (Usually an indication of a need for refactor.)

migrated to new tmobile/sawtooth-next-directory repo


Error "FIND, runtime, no input, s empty" in the Scrabble Score exercise

When trying to test the below code, I get the error "FIND, runtime, no input, s empty". The issue may will be on my end as I'm not used to working with ABAP outside an ABAP-editor with all the language support that provides!
CLASS zcl_scrabble_score DEFINITION PUBLIC .

  PUBLIC SECTION.
    METHODS: score
               IMPORTING input         TYPE string OPTIONAL
               RETURNING VALUE(result) TYPE i.
  PROTECTED SECTION.
  PRIVATE SECTION.
    types: begin of ty_scores,
             letters(10)    type c,
             score          type i,
           end  of ty_scores.
    data: defined_scores type standard table of ty_scores.
    data: def_score  type ty_scores.

ENDCLASS.

CLASS zcl_scrabble_score IMPLEMENTATION.

  METHOD score.
     data: letter(1) type c,
           clen      type i.

     check input is not initial.

     defined_scores = VALUE #( ( letters = 'AEIOULNRST' score = 1 )
                       ( letters = 'DG' score = 2 )
                       ( letters = 'BCMP' score = 3 )
                       ( letters = 'FHVWY' score = 4 )
                       ( letters = 'K' score = 5 )
                       ( letters = 'JX' score = 8 )
                       ( letters = 'QZ' score = 10 ) ).

    "DESCRIBE FIELD input LENGTH DATA(clen) IN CHARACTER MODE.
    clen = strlen( input ).

    Do clen times.
      letter = input+sy-index(1).  "substring( val = input off = sy-index len = 1 ).
      loop at defined_scores INTO data(letterscore).
        FIND letter IN letterscore-letters.
        IF sy-subrc EQ 0.
          result = result + letterscore-score.
          exit.
        ENDIF.
      endloop.
    enddo.

  ENDMETHOD.

ENDCLASS.

thanks, I've reproduced the error as below, bug in transpiler runtime...

https://github.com/exercism/abap/pull/82 will hopefully make it easier to pull the code into a SAP ABAP system
having debugging would be nice too, however its not part of the Exercism platform as such
F1 help: yea, perhaps we can do that somehow 😅

Hi @BaerbelW you can always write it on an SAP system and paste the code here once it's running.
As Lars already pointed out we are attempting to join the Exercism format with abapGit.
Alternatively I've also created a repo https://github.com/pokrakam/exercism-abap-local from which you can also pull the entire set of empty exercises with test classes into one package using abapGit.

Thanks, Lars & Mike!
I plan to use good old copy & paste to recreate the code in one of our sandbox systems - we don't really use ABAPGit (yet). I'll however not have a means to do that over the weekend as our sandbox and development systems are not available then. So, for now, I'm "running blind" (and realize how much I depend on language support for even simple ABAP exercises!).

Something must have changed in the meantime as I no longer get the error mentioned in the OP. I'm now passing 7 and fail 4 tests but can't make heads or tails of why four fail - esp. as the one getting a complete tally for all letters is among the passed tests. How can the logic be correct for the overall number but fail for some others for shorter input? Guess, I'll have to wait until next week and copy the code into a sandbox system to then take a look via debugging to figure out which stupid mistake is still in my code! We sure are spoiled with the tools available in an SAP-system, aren't we?!?

yes, I updated the runner earlier today, https://github.com/exercism/abap-test-runner
line letter = input+sy-index(1)., the index starts at 1, but I guess you want to start with the first character?

Thanks, Lars!
I had already changed that statement to use SUBSTR instead, but forgot that the offset for the first letter is 0 and not 1. Once I updated that, all tests were passed.

cool
I also opened https://github.com/abaplint/transpiler/issues/689, as it currently does not throw the correct exception, I think that would have helped identifying the error

closing, running, BaerbelW feel free to reopen if something is missing


chore(cargo.lock): Update deps.

Significantly this removes several no-longer necessary crates which were
previously transitive dependencies by way of gitignore. This includes
rand which was breaking the build on nightly.

Thanks! :+1:
@homu r+

:pushpin: Commit 2ef0ac4 has been approved by kbknapp

:hourglass: Testing commit 2ef0ac4 with merge 5b8dab5...

:sunny: Test successful - status


Update manual tests

Move the manual tests up one directory level.
Fix the testnet config URLs.

bors r+


Cannot convert null to int

Downloading plugin data causes an "cannot convert null to int" error, here the part from the log:
14-01 16:52:46.734|ERROR|SuccessStory#Common:Error on GetGameInfoAndUserProgress()|G:\GitHub\Lacro59\playnite-successstory-plugin\source\Clients\RetroAchievements.cs|822 Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot convert null to 'int' because it is a non-nullable value type    at CallSite.Target(Closure , CallSite , Object )    at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)    at CallSite.Target(Closure , CallSite , Object )    at SuccessStory.Clients.RetroAchievements.GetGameInfoAndUserProgress(Int32 gameID) in G:\GitHub\Lacro59\playnite-successstory-plugin\source\Clients\RetroAchievements.cs:line 822
extensions.log

Can you give me the game that caused this issue?

Can you give me the game that caused this issue?

Sorry for my late reply. I think it is "Fear Effect 2: Retro Helix" based on when the error occurs in the log.


Price history diagram is updated slowly

Not sure if this is related to #1105. The price history diagram is not immediately updated after making a trade. I believe that's a problem for two reasons:

Conflicting information between the two price indicators.

User doesn't immediately see their impact in the graphics.

We can make it faster but it won't be immediate due to subsquid limitations. These should be resolved soon with unfinalised block indexing


App registration secret expiration limit

Earlier we were able to set the limit for expiration of token to never and use it in application without bothering any time limit. But it seems that Microsoft has enforced a limit to set the expiration of client secret to 2 years. This cannot be changed from UI. The document needs to be updated accordingly.

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

ID: c9642c47-826b-017f-eff3-ab3b25e4e454
Version Independent ID: 091f26e7-6543-ef0f-b575-b44519943391
Content: Quickstart: Register an app in the Microsoft identity platform
Content Source: articles/active-directory/develop/quickstart-register-app.md
Service: active-directory
Sub-service: develop
GitHub Login: @mmacy
Microsoft Alias: marsma

@iamguptarishi
Thanks for your feedback! We will investigate and update as appropriate.

@iamguptarishi
Thank you for pointing this out!
It does look like the "Expires" option has changed, with the max selection being 24 months even if you select the "Custom" expiration option.

I'll assign this issue to the author to investigate and update the docs.
Thank you for your time and patience throughout this issue.

@iamguptarishi I've added some clarity to the client secret lifetime limitation of 24 months or less in https://github.com/MicrosoftDocs/azure-docs-pr/pull/160575 (private repo, may 404 for you). We had a sentence on it below the steps for adding a secret, but it weren't very clear and wasn't near the step in which you actually specify the lifetime. Fix should be live sometime on Monday, 31 May 2021.
Was:

Now:


Run | Debug disappears when optional chaining operator is encountered (parsing fails)

I am almost certain this is a bug with the Jest Editor Support library, but I am just letting you know, because it critically affects this extension.
See this issue for more information.

thx for reporting @JonathanWilbur

should be fixed with v0.4.38 if not please re-open


Changed poetry to poetry-core to enable editable installs

This PR changes pyproject.toml file in order to enable editable installs. With presented changes, we can install dasf using pip install -e ..

LGTM


Update tslint.json

Looks like with the rule "variable-name": false, using packages like socket.io-client, it doesn't validate.

Actually, the original error was caused by using the types not the package itself, so the original linting error was legitimate.


How to globally access the JWT token from the request

I'm using a JWT authentication implementation as per the documentation: https://fastapi.tiangolo.com/tutorial/security/oauth2-jwt/
I can easily access the JWT token using DI in all my routers:
@router.get('/something')
async def some_function(token: str = Depends(oauth2_scheme)):
    # Some logic here

I'm trying to use SQLAlchemy's before_compile event to append some logic to all queries:
@event.listens_for(Query, 'before_compile', retval=True)
def sqlalchemy_before_compile(query: Query):
    # From here, how do I access the JWT token?

As a workaround I ended up going with starlette-context + custom plugin.
Just wondering if there's another solution?

Do you mean accessing the JWT that the client sends you in his request?
If so you can add Authorize: AuthJWT = Depends() in your method, and
then you just call Authorize.get_jwt_subject()

Like this you mean?
@event.listens_for(Query, 'before_compile', retval=True)
def sqlalchemy_before_compile(query: Query, authorize=Depends()) -> Query:
    jwt = authorize.get_jwt_subject()

AttributeError: 'Depends' object has no attribute 'get_jwt_subject'
Bare in mind that this is not a FastAPI route, this is a SQLAlchemy event.

I meant in the route like this.
@router.get('/something')
async def some_function(Authorize: AuthJWT = Depends()):
    Authorize.jwt_required()
    what_you_used_to_create_the_token = Authorize.get_jwt_subject()
    function_to_use_that_subject(what_you_used_to_create_the_token)

So this look if there is an access token cookie, if there is one the get_jwt_subject() will decode it back from what was used for the cookie to be made. For example if you have a user register and login you would choose one unique identifier, let's say email and then create a jwt with it, with this "something" route you would take the created cookeis and get the email and then proceed to make database calls. Hope I didn't miss the point or your intent with the jwt.

Hi Valentin, thanks for trying to help but I'm afraid I'm trying to do something a bit unrelated.
I'm not trying to access the raw JWT token in one of my routes. There's a SQLAlchemy event I'm capturing, this event fires before a query compiles internally by sqlalchemy. The handler for this event is not in a request context, I cannot using Depends. I'm yes trying to capture the JWT, but the event handler has nothing to do with routes.
That's fine, as I said, starlette-context provides access to the current request from a global scope.

Thanks for the help here @valentin994 ! :clap: :bow:
Thanks for reporting back and closing the issue @Feijo  :+1:


Add Possibility to Filter Events Older than X

It was proposed that we add an option for source bots, which end up parsing the same source file over and over, where:

you could define a threshold value (in seconds for example).
it would imply that events with a "source time" older than X would not get sent into the pipeline
it would prevent the old events being resent in case there is a change in the feed data format for example and the state file does not "catch" the old events.

The following bots at least would benefit from this option:

[x] abusehelper.bots.openbl.openblbot
[x] abusehelper.bots.phishtank.phishtankbot

I'll add this to FeedBot so most of the bots implement this.

Fixed in debd818


Error: "Cannot read property 'toString' of undefined" in multi().zAdd() execution

    const multi = client.multi();    ...     multi.zAdd(key, score,  code);    ...     await multi.exec();
this code produces next error:
TypeError: Cannot read property 'toString' of undefined     at transformArgumentNumberInfinity ({projectFolder}/node_modules/@node-redis/client/dist/lib/commands/generic-transformers.js:55:24)     at Object.transformArguments ({projectFolder}/node_modules/@node-redis/client/dist/lib/commands/ZADD.js:30:78)     at Commander.commandsExecutor ({projectFolder}/node_modules/@node-redis/client/dist/lib/client/multi-command.js:50:40)     at Commander.zAdd ({projectFolder}/node_modules/@node-redis/client/dist/lib/commander.js:8:29)
Environment:

Node.js Version: 14.17.3
Redis Server Version: 4.0.2
Node Redis Version: 4.0.0
Platform: 18.04.1-Ubuntu

await client.multi()
  .zAdd('key', { score: 1, value: 'value' })
  .zAdd('key', [{ score: 1, value: '1' }, { score: 2, value: '2' }])
  .exec()

I ran into the same problem but spent some hours checking docs.
I think it should be listed on the docs to save other's time.

Where are the docs that explain the interface of zAdd? I can't find anywhere that shows it should contain an object as shown here { score: 1, value: 'value' }

Where are the docs that explain the interface of zAdd? I can't find anywhere that shows it should contain an object as shown here { score: 1, value: 'value' }

Seriously, I found this very annoying.

https://redis.js.org/documentation/client/modules/lib_commands_ZADD.html
https://redis.js.org/documentation/client/

As this was a change from previous versions it should really be called out in the migration docs, or mentioned somewhere, or, at the very least, provide a more succinct error message.  I've spent entirely too much time only to find that the fix is simply a change to the provided arguments.
Are there any other functions that have changed and are not called out in the migration docs?  How many more entirely non-descriptive errors will I need to track down?


cdn.syndication.twimg.com returns 404 page.

Describe the bug
cdn.syndication.twimg.com returns a 404 page now instead of JSON data.
To Reproduce
Steps to reproduce the behavior:

Send a tweet link to the bot.
Bot will reply with "Tweet not found or unavailable."

Expected behavior
Tweet images will be stored and sent to the Telegram channel.
Error output / Logs
Since the unexpected output happens on Twitter's side, no error log output from Nazurin.
Environment (please complete the following information):

OS: Windows Server 2012 R2
Python Version: 3.10.7

Additional context
Since it should be a problem on Twitter's side, using another data source might be helpful (ex. nitter.it).

Thanks for your report, this issue should be fixed in the latest release, please upgrade and see if the problem persists.

Thanks for your report, this issue should be fixed in the latest release, please upgrade and see if the problem persists.

Problem solved. Thanks!


Doesn't work with kibana 7.2.0

Here is the error log:

{"type":"log","@timestamp":"2019-08-12T03:22:20Z","tags":["fatal","root"],"pid":1,"message":"{ Error: custom client factory is already set, unable to replace the current one\n    at ScopedSavedObjectsClientProvider.setClientFactory (/usr/share/kibana/src/legacy/server/saved_objects/service/lib/scoped_client_provider.js:30:13)\n    at Object.setScopedSavedObjectsClientFactory (/usr/share/kibana/src/legacy/server/saved_objects/saved_objects_mixin.js:145:63)\n    at setScopedSavedObjectsClientFactory (/usr/share/kibana/plugins/keycloak-kibana/server/services/SecureClusterFacade.js:36:16)\n    at Plugin.init [as externalInit] (/usr/share/kibana/plugins/keycloak-kibana/index.js:209:7)\n    at process._tickCallback (internal/process/next_tick.js:68:7)\n  isBoom: true,\n  isServer: true,\n  data: null,\n  output:\n   { statusCode: 500,\n     payload:\n      { statusCode: 500,\n        error: 'Internal Server Error',\n        message: 'An internal server error occurred' },\n     headers: {} },\n  reformat: [Function],\n  [Symbol(SavedObjectsClientErrorCode)]: 'SavedObjectsClient/generalError' }"}

We using this plugin with Kibana 7.2.0 and its works fine. Can you provide more info about this error? When does it occur?

Closed due to inactivity. Feel free to reopen.


more tests

Added more tests.
All data sets now return sqdist and points.
One issue: circle graph does not work as it should. Is it needed?
metricize2 passes all tests and gives the same results as metricize3. But maybe just for me.

I'm still getting weird results with metricize2

Can you try running tools.py as the main script? You should get some test results.

On Mar 24, 2016, at 9:04 PM, micah541<EMAIL_ADDRESS>wrote:
I'm still getting weird results with metricize2
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/micah541/Ricci/pull/13#issuecomment-201127183

I'll try that, but regardless of what that shows me, when I got and
change metricize = metricize3 to metricize = metricize2 and run
localricci, the results go from what I expect to bad.
On 3/24/2016 9:05 PM, Bartek Siudeja wrote:

Can you try running tools.py as the main script? You should get some
test results.

On Mar 24, 2016, at 9:04 PM, micah541<EMAIL_ADDRESS>wrote:
I'm still getting weird results with metricize2
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/micah541/Ricci/pull/13#issuecomment-201127183

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/micah541/Ricci/pull/13#issuecomment-201127289

It could be different Anaconda version. Or maybe the tests will run ok, meaning they are not good enough.

On Mar 24, 2016, at 9:08 PM, micah541<EMAIL_ADDRESS>wrote:
I'll try that, but regardless of what that shows me, when I got and
change metricize = metricize3 to metricize = metricize2 and run
localricci, the results go from what I expect to bad.
On 3/24/2016 9:05 PM, Bartek Siudeja wrote:

Can you try running tools.py as the main script? You should get some
test results.

On Mar 24, 2016, at 9:04 PM, micah541<EMAIL_ADDRESS>wrote:
I'm still getting weird results with metricize2
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/micah541/Ricci/pull/13#issuecomment-201127183

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/micah541/Ricci/pull/13#issuecomment-201127289

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub https://github.com/micah541/Ricci/pull/13#issuecomment-201127995

I just tried running localricci with metricize2 and the moons where recognized.
I have updated my Anaconda to 2.5 recently.


attempt to improve t2t shuffle situation plus small fixes

@VahidooX could you please review - test if convergence plot isn't affected by this shuffling scheme

do not merge this yet.


Consistent names

unifying all cubes to refer to item as item is important for automatically the items as in the return forms. Also time to clean up the names now we understand their usage better before they get used a lot and we break more things by changing them later.
@longhotsummer FYI

Let's take this chance to fill in some of the other placeholders, too.

This is so freaking tedious and repetitive. Only reason I haven't templated this is because this shouldn't need a lot of changes once it's properly released


fix: avoid auth errors during javadoc publish step

PR summary
This PR is trying to fix the script used to publish javadocs to gh-pages.
Fixes: https://github.ibm.com/arf/planning-sdk-squad/issues/1541
PR Checklist
Please make sure that your PR fulfills the following requirements:

[ ] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[x] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

:tada: This PR is included in version 0.1.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Correctly interface the download button to the csv export route for Public Cloud [New UI]

Describe the issue
Once the api route is created and confirmed to be working correctly, we can then connect it to the front end of the application.
Rational/Why
There may be some error handling to deal with, for example we don't want to download a csv if there are currently no projects displayed.
Tests
Test that the correct csv is being downloaded, and that errors are being handled properly. (No projects displayed = error cannot download 0 projects)
Definition of done/Acceptance Criteria

[x] - Confirm that the button is downloading the correct csv data for Public cloud
[x] - Error is being displayed gracefully when there are zero projects being displayed and the users attempts to download a csv

Clicking Export on Public Cloud page leads to a public-cloud url and shows error if no projects are available.


JI-3673 Cleanup for packages and replaced deprecated packages

Got this warning about Vue when building. Similar to the other library that uses Vue, I don't think upgrading to Vue 3 should be part of this issue.
WARNING in ./app.js 76:22-25
export 'default' (imported as 'Vue') was not found in 'vue' (possible exports: BaseTransition, Comment, EffectScope, Fragment, KeepAlive, ReactiveEffect, Static, Suspense, Teleport, Text, Transition, TransitionGroup, VueElement, callWithAsyncErrorHandling, callWithErrorHandling, camelize, capitalize, cloneVNode, compatUtils, computed, createApp, createBlock, createCommentVNode, createElementBlock, createElementVNode, createHydrationRenderer, createPropsRestProxy, createRenderer, createSSRApp, createSlots, createStaticVNode, createTextVNode, createVNode, customRef, defineAsyncComponent, defineComponent, defineCustomElement, defineEmits, defineExpose, defineProps, defineSSRCustomElement, devtools, effect, effectScope, getCurrentInstance, getCurrentScope, getTransitionRawChildren, guardReactiveProps, h, handleError, hydrate, initCustomFormatter, initDirectivesForSSR, inject, isMemoSame, isProxy, isReactive, isReadonly, isRef, isRuntimeOnly, isShallow, isVNode, markRaw, mergeDefaults, mergeProps, nextTick, normalizeClass, normalizeProps, normalizeStyle, onActivated, onBeforeMount, onBeforeUnmount, onBeforeUpdate, onDeactivated, onErrorCaptured, onMounted, onRenderTracked, onRenderTriggered, onScopeDispose, onServerPrefetch, onUnmounted, onUpdated, openBlock, popScopeId, provide, proxyRefs, pushScopeId, queuePostFlushCb, reactive, readonly, ref, registerRuntimeCompiler, render, renderList, renderSlot, resolveComponent, resolveDirective, resolveDynamicComponent, resolveFilter, resolveTransitionHooks, setBlockTracking, setDevtoolsHook, setTransitionHooks, shallowReactive, shallowReadonly, shallowRef, ssrContextKey, ssrUtils, stop, toDisplayString, toHandlerKey, toHandlers, toRaw, toRef, toRefs, transformVNodeArgs, triggerRef, unref, useAttrs, useCssModule, useCssVars, useSSRContext, useSlots, useTransitionState, vModelCheckbox, vModelDynamic, vModelRadio, vModelSelect, vModelText, vShow, version, warn, watch, watchEffect, watchPostEffect, watchSyncEffect, withAsyncContext, withCtx, withDefaults, withDirectives, withKeys, withMemo, withModifiers, withScopeId)
 @ ./entries/dist.js

webpack 5.73.0 compiled with 1 warning in 3394 ms


PLAT-616: fix test TestVirtual_Constructor_PulseChangedWhileOutgoing

wait for message to be send before asserting counter
test case expected execution to be finished and only after that
VStateRequest should be send into the system

bors r+


Unable to achieve Distributed runs in RFT step of TFS on-premise

Environment

Server - TFS on-premises
Version : 14.102.25423.0

Agent - Private

OS of the Machine running agent : Windows NT
Agent Version : 1.95.3

Issue Description
I'm seeing 2 issues while trying to do concurrent runs/parallel runs in TFS 2015 on-premise

When pool of machines are given to a particular build definition with 1 test assembly, CodedUI tests
inside that assembly are not divided among the pool of machines.

I queued 2 build definitions which have the RFT step enabled with same pool of machines. Instead of
executing each of those builds on separate machines available in pool,One build definition RFT step is
aborting the other build definition.

I searched online & i see that the only way we can achieve this is by having multiple test assemblies. But i wanted to know if we have any option other than this.
It would be really helpful if someone can let me know, if there is a way to achieve concurrent runs of
codedUI tests in TFS on-premise 2015.
If its not supported in 2015, what would be the version i should update TFS to for getting this done?
Thanks,
Ajay

Can you clarify what you mean by "RFT step"?

@bryanmacfarlane RFT is Run functional test task.

@AjayPrasad Thanks for reaching out. RFT does not parallelize at assembly level. You need to split your tests in multiple assemblies if you wish to run these tests in parallel. There have been a lot of changes since TFS 2015 and we no longer recommend using RFT task starting TFS 2018.
TFS 2018 introduced different batching options and VsTest task V2 can now be used in place of RFT.
For your second issue, do you mean the test agent pool?

Thanks @prawalagarwal for the info.
yes, on the second issue i meant Agent pool.

@AjayPrasad Please use different pools with different set of machines. Using different pools with same machines and same pool may cause aborts. Please reopen if you have further queries.

@prawalagarwal Can you suggest me best way to achieve Concurrent runs in TFS 2015 along with documentation if you have.

@AjayPrasad RFT is the only way for TFS 2015.

@prawalagarwal What are the options do i have if i upgrade TFS to latest versions?
My requirement is to execute builds in parallel on the machines i have in my lab. These builds should automatically pick the idle machine from the pool and start executing tests on it.

@AjayPrasad  Here is a blog for your reference. You can reach out to us at devops_tools[AT]microsoft[DOT]com for more details.

Thanks @prawalagarwal


On-Open Validator broken for TSV7 files

The "on open" validation was intended to be a fast check of certain features to prevent it from being used, since it would likely crash tc-create. Those checks are:
Does it have the correct header?
Does every row have the correct number of columns? If not report whether too few or too many.
Are all ID values unique? Report all duplicates and their row numbers.
It may check for:
empty rows (which would be also be a too few columns issue, but perhaps a different root cause worth reporting)
For TSV 7 files, this is broken and the app crashes when the header is bad. It does not report duplicate IDs.

Looks good in translationCore Create - v1.8 build 197-7a6b5de.
On-Open CV reports errors when master/target file has a bad header or duplicate id.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[v1.5.x] Handle fix_gamma in tensorrt subgraph conversion correctly

Description
the current nnvm->onnx->tensorrt conversion is ignoring the fix_gamma field for batch norm layer. This commit tries to solve this particular issue by providing a way to massage params map before convert nnvm to onnx.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ x ] Changes are complete (i.e. I finished coding on this PR)
[ x ] All changes have test coverage:

the unit test failed before and succeeded after

 a: array([[[[4.9751253]]]], dtype=float32)
 b: array([[[[0.]]]], dtype=float32)
-------------------- >> begin captured stdout << ---------------------
[[[[4.9751253]]]]
[[[[0.]]]]
--------------------- >> end captured stdout << ----------------------
----------------------------------------------------------------------
Ran 1 test in 5.820s
FAILED (failures=1)

.
----------------------------------------------------------------------
Ran 1 test in 5.513s
OK

[ x ] Code is well-documented:
[ x ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ x ] Add "Preprocess" step in nnvm->onnx conversion where allow modifying param map

Comments
This is a bug fix for tensor rt subgraph conversion

Thank you @KellenSunderland. Merging now.


Revert "Revert "ROAD-287 make SQL code to add transaction tables to hive meta…"

Reverts Altiscale/hive#7

I tested the change, and it seems to be working as expected. Pulling it back in


Portfolio:  contact form section

[ ] Added a contact form in the footer section.
[ ] Added a submit button.
[ ] Getting started in the readme has been set properly.
[ ] fixed misalignment bags in the footer section.
[ ] Corrected the form action link.
[ ] Added a max length of 500 to the textarea.
[ ] Added a name attribute to the inputs and textarea.

The mobile version of the portfolio project is comlete.

I want to thank all reviewers for great reviews youv'e given to this project.


add EventManager

Would be cool if we can throw events and have systems that listen to them.
That way we might decide that the level is failed or succeeded without adding to much logic to the code

Good idea I like it


Updating expectation_native_contacts

Description
Updated the expectation native contacts function to use MDTraj for the distance calculations (entire trajectory at once rather than one pair at a time). The inputs are updated so that we can use the existing fraction_native_contacts() function within it.
The new method matches the old expectation native contacts output, but precision on the distances are reduced because we are reading from pdb files instead of the .nc files. (see #69 )
Fixed an error with the array_folded_states reshaping. It was being reshaped frame by frame rather than by replica before, so the past free energy curve was wrong (though the shape still looks the same).

Codecov Report

Merging #70 into free_energy_calc will decrease coverage by 0.09%.
The diff coverage is 100.00%.

@mrshirts could you check that I've redone the expectation native contact fraction correctly?

Ok I think this is better now - I made the fraction_native_contacts calculation separate from the expectation, and have a list of trajectory files as input instead of a single mdtraj trajectory object.
I also added dcd writers to rep_exch.py. We can load them into mdtraj for contact fraction analysis but need a topology to go along with them or it won't work. There is a built-in function to convert openmm topology to mdtraj topology which I've used.
I can make a similar update in analyze_foldamers for higher precision coordinates.

Made a bunch of updates to the native contacts and free energy of folding examples. The files aren't included with the examples (and still some cleaning to do in the native contacts example folder), but there are small files included with the tests which are passing.
There are a few different scenarios for using the native contacts code:

Use the discontinuous state trajectories to compute native contact fraction (Q) vs. T (standard method with standard error)
Use the continuous replica trajectories and energies in .nc file to compute Q_expectation vs. T (with pymbar uncertainties - much smoother curve)
Use continuous replica trajectories to compute regular Q vs. T, and then compute array_folded_states(frames,replicas) to use for the free energy of folding calculation.

@mrshirts I remember we talked about using the Q_expectation for the free energy calculation too. Could you reiterate how we would do that calculation?

@mrshirts I remember we talked about using the Q_expectation for the free energy calculation too. Could you reiterate how we would do that calculation?

Hmm, I'm not quite sure what the context is here?  Remind me a bit more?

I mean if we have the expectation of native contact fraction for each replica and the uncertainty from pymbar (including at intermediate unsampled temperatures), rather than the fraction native contacts for the individual frames for each replica, is there a way to compute the free energy of folding?
I suppose it doesn't really matter since we will always need to first compute Q for all frames to get Q_expectation.

A few more things added:

Function for plotting Q vs. simulation time for each replica
get_native_contacts() now also returns a dictionary containing the types of native contacts (i.e., bb-bb, bb-sc, sc-sc) and amounts of each type

I think this is good to merge now, and also merging free_energy_calc into master, as these have become pretty huge. The results from the regular and expectation native contact fraction are in agreement (to within the noise of the non-expectation one), so that's added confirmation that the expectation calculation is correct (at least as far as that we are using the right arrays). There is very noticeable improvement in the native contact fraction curves for the expectation version when the native contact cutoff is small - for example:
nccut_2_5_Q_expect_vs_T.pdf
nccut_2_5_Q_vs_T.pdf


add bf.load to support bloom filter aofrewrite.

this pr is for #8  https://github.com/valkey-io/valkey-bloom/issues/8.
design proposal
I use serde  and bincode to  deserialize and deserialize BloomFilterType. add data version in first element.
bf.load not support override old key.

@KarthikSubbarao Please help review this PR.

@KarthikSubbarao The review comments have been modified and replied. Please review them again.

@KarthikSubbarao
I think another purpose of BF.DUMP is for migration scenarios. When tools like redisshake perform data migration between two Redis instances, the valkey-bloom type keys can be replayed using BF.LOAD and BF.DUMP.
If you believe this command is ultimately unnecessary, please let me know, and I will remove it. (About BF.DUMP review can't reply, so i add a new comment to reply it.)

@KarthikSubbarao  The review comments have been modified and replied. Please review them again, thank you.

Quick note: When you get the latest changes your changes will cause the tests in test_bloom_metrics.py to fail, due to the new size of BloomFilterType, to fix this you can update this file and line to be DEFAULT_BLOOM_FILTER_SIZE = 179961.

The PR is close. Just have few comments on fixing the validation logic of bloom filters restored from BF.LOAD. We can merged it in after this

Thank you, @wuranxx . Can you update the PR Description? It currently references BF.DUMP. We can update it to reference BF.LOAD and I will merge the PR after that

Thank you, @wuranxx . Can you update the PR Description? It currently references BF.DUMP. We can update it to reference BF.LOAD and I will merge the PR after that

updated.

Thank you for helping with AOF Rewrite support, @wuranxx !


Proposal to re-enable ALU mode

If I correctly understand, #78 disables ALU mode 8 (CUPCDN), since it has the same LUT4 bits as mode 1 (SUB) and therefore can't be correctly identified by gowin_unpack. An alternative option was mentioned, namely defaulting to SUB. I would like to propose setting the 4 unused bits (8 through 11) in CUPCDN to some value in gowin_pack so that gowin_unpack can then recover this mode if produced with that tool, and only defaulting to SUB if the usual value is found.
I would like your opinion on the matter before sending any changes. I would also like your opinion on adding an extra mode implementing the functionality described at the end of this page, which could complement mode 9 for implementing a multiplier.

If I understand correctly, this is how nextpnr wires the ALU:
add(0)<PHONE_NUMBER>001100  A:-  B:I1 C:1 D:I0
sub(1)<PHONE_NUMBER>011010  A:I0 B:-  C:1 D:I1
addsub(2)<PHONE_NUMBER>011010  A:I0 B:I1 C:1 D:I3
ne(3)<PHONE_NUMBER>011111  A:I0 B:I1 C:1 D:-
ge(4)<PHONE_NUMBER>011010  A:I0 B:I1 C:1 D:-
le(5)     N/A
cup(6)<PHONE_NUMBER>100000  A:I0 B:I1 C:1 D:-
cdn(7)<PHONE_NUMBER>011111  A:I0 B:I1 C:1 D:-
cupcdn(8) N/A
mul(9)<PHONE_NUMBER>001000  A:I0 B:I1 C:1 D:I3

So, that answers my second question; the MUL mode is already doing what the page describes.

As mentioned in the other issue I don't have particularly strong feelings about the modes yosys isn't using. As long as CI is green and users are happy I'm happy. So I'd happily take a pr that reenables this mode.
Iirc there is some unde the hood reshuffling of ports so as a user it's not as mixed up as in the primitives

@pepijndevos I see AND ports are swapped here. You mean more swapping is done elsewhere, for SUB and MUL? Is that done in yosys, nextpnr itself or gowin_pack?

I think that might be it


I modify the transparency of the images

Hello how are you? I have seen that the images of the programming logos do not have the same format, some are .png and others .jpg.
I think that if they are all placed in the same format and are transparent, it would be compatible with any background. For example, in Github it has two backgrounds, one white and the other black, if all logos have transparent backgrounds they would look better with the visual environment.
I have changed the white background to transparent and all the images in .png format.
It would only be necessary to modify the links of the .jpg images by .png in the readme.md and you will be able to visualize the change. For example
Line 28 | 5. C # [C Sharp] | ! [CSharp logo] (https://github.com/aryashah2k/Printing-Pattern-Programs/blob/main/assets/CSharp Logo.jpg) |
For
| 5. C # [C Sharp] | ! [CSharp logo] (https://github.com/aryashah2k/Printing-Pattern-Programs/blob/main/assets/CSharp Logo.png) |
Greetings and very project !!!

Hey there @lgmontero , thanks for having interest in contributing to my repository. It will help a lot if the images background are changed in one single format. You can always feel free to open an issue if you wish to contribute more in any way to this repository. Merging this PR for now!
Thanks and Regards,
Arya.


WIP: Staged Generator

New Staged Generator
Tracking PR for the generator rewrite. The new generator is being developed in parallel in branch feature/generator-v2. See referenced PRs and commit messages for more information.

Original Post:
This is a "proof of concept" staged generator like I described in https://github.com/gircore/gir.core/issues/100#issuecomment-721087887. It only generates a subset of the current generated code to focus on the overall architecture instead.
This is a complete rewrite - The git diff isn't too helpful for understanding what's going on here. The source can be found on the branch feature/generator-v2 in the Generator/ and Repository/ folders. Note the build tool doesn't compile, so CI will fail.
To try out, run the generator project as an executable, using Generator/ as your working directory. Some dependencies like GModule-2.0.gir are not satisfied, so those need to be manually copied into gir-files for the time being. The generator output is currently directed to Generator/output/* to avoid clashing with the Libs/ folder. See Tool.cs for a good starting point. An example run might look something like:
$ cd Generator
$ dotnet run -- ../gir-files/Gst-1.0.gir

Architecture
The generator is divided into two projects:

Repository contains loading, parsing, and type dictionary/resolution code. It functions similarly to libgirepository and creates a database-style reference of all symbols in the project.
Generator meanwhile builds upon Repository to create a streamlined code-generation tool.

This separation allows for significantly cleaner generator code, specifically:

Using strong references between types, rather than string-based references (See TypeReference). This makes renaming and processing far more straightforward.
Separate from file format (works around limitations of XmlSerializer), which then enables:

Using enums instead of strings for attributes like Direction/Transfer/CalleeAllocates/etc
Control over mutability (I use the new init accessor extensively to decide what can/cannot be modified during processing).

Stages
Repository
 1. Loader (includes Graph, Serialisation/Parsing, resolves dependencies)
 2. Type Resolution (resolves string-based references into strong references, accounting for namespacing and internal/external types).
---------------------------------------------------------------------
Generator
 3. Processing/Analysis (transforming data, renaming, reparenting, aliasing, etc)
 4. Services (Small non-mutable/static helper objects which do generation logic)
 5. Writer (Asynchronously outputs source files)

All five stages are namespaced and reasonably separate.
A short description of each stage:

Loader takes in a list of "top-level" projects. It serialises the GIR introspection data and resolves any dependent library GIR files (e.g. Gtk depends on Gdk, Cairo, Pango). Finally, using a very simple graph algorithm (located in Repository/Graph), it orders dependencies such that symbols will always be defined before they are used. This is necessary for shared dependencies.
Type Resolution includes a type dictionary ("Symbol Dictionary") that stores symbols and their names/namespaces. We iterate over all 'String References' and resolve them using the symbol dictionary. This not only ensures the GIR file is valid (all symbols are defined) but allows for renaming by simply changing the property of one single struct instance.
Processing allows us to transform a subset of data ahead of generation. Prefixing and PascalCase conversions will happen here, as well as "reparenting" (which simply changes the managed name of a type to include the parent class name at the front).
Services contains small, maintainable non-mutable (so they can be used asynchronously) utility classes which implement the generation logic, so as to decouple it from the template backend (e.g. Scriban will only organise the code into source files, the actual generation logic will be handled by the generator using the data from the Analysis stage).
Writer is a simple Asynchronous wrapper around Scriban which allows source files to be written concurrently (as the introspection data is already finalised in the processing/analysis stage).

Features
Repository Features:

Loading GIR files and their dependencies automatically (recursive load)
Serialising GIR files into a raw structure
Parsing the raw structure into a nice, readable processed structure (e.g. enums over strings, etc)
Directed acyclic graph for ordering logic/avoiding circular dependencies
TypeDict (Symbols and Aliases)
Resolves strings into strong references, done from the perspective of the current namespace

Generator Features:

Printing basic delegate signatures
Interface renaming
Object reparenting
Folder names based on type and version

@badcel @na2axl

Great work! :heart: This is quite impressive and like you promised quite a great leap forward.
I just stepped through your code one time (meaning I have only limited overview). I like the general concept of the interpretaton of the GIR data and the split into new structures with the ManagedName / NativeName.
Just from my "feeling" I think how the code is intertwined is not optimal at the moment. Perhaps it is just some small adjustments, perhaps a little more refactor or even some dependency injection. I need go deep to answer this question. But this will take a bit of time (perhaps even some weeks).
But we should probably work on the general architecture before adding more features. We could try to add architectural improvements via pull requests into your branch.  What do you think?

Great work! :heart: This is quite impressive and like you promised quite a great leap forward.
I just stepped through your code one time (meaning I have only limited overview). I like the general concept of the interpretaton of the GIR data and the split into new structures with the ManagedName / NativeName.
Just from my "feeling" I think how the code is intertwined is not optimal at the moment. Perhaps it is just some small adjustments, perhaps a little more refactor or even some dependency injection. I need go deep to answer this question. But this will take a bit of time (perhaps even some weeks).
But we should probably work on the general architecture before adding more features. We could try to add architectural improvements via pull requests into your branch.  What do you think?

Just from my "feeling" I think how the code is intertwined is not optimal at the moment. Perhaps it is just some small adjustments, perhaps a little more refactor or even some dependency injection. I need go deep to answer this question. But this will take a bit of time (perhaps even some weeks). A possible solution to this is working on it together step by step.

I agree. The generator I've written here is more of a "Look, you can write a generator with this!" than an actual generator. It was more to figure out the needed features and constraints for the repository side of things.

But we should probably work on the general architecture before adding more features. We could try to add architectural improvements via pull requests into your branch. I would try to make more smaller PRs to give more frequent feedback and not do s.th. like "V2" after a long time. In this way we can discuss the changes step by step. What do you think?

Yeah, this sounds like a good idea. I think Repository is in a good state to iterate on. I don't mind what happens with Generator since it's really just bits and pieces of the last generator copy/pasted over. My preference would be to make this a parallel branch alongside develop and spend the next few months making small PRs into it until we're ready to merge.

Just from my "feeling" I think how the code is intertwined is not optimal at the moment. Perhaps it is just some small adjustments, perhaps a little more refactor or even some dependency injection. I need go deep to answer this question. But this will take a bit of time (perhaps even some weeks). A possible solution to this is working on it together step by step.

I agree. The generator I've written here is more of a "Look, you can write a generator with this!" than an actual generator. It was more to figure out the needed features and constraints for the repository side of things.

But we should probably work on the general architecture before adding more features. We could try to add architectural improvements via pull requests into your branch. I would try to make more smaller PRs to give more frequent feedback and not do s.th. like "V2" after a long time. In this way we can discuss the changes step by step. What do you think?

Yeah, this sounds like a good idea. I think Repository is in a good state to iterate on. I don't mind what happens with Generator since it's really just bits and pieces of the last generator copy/pasted over. My preference would be to make this a parallel branch alongside develop and spend the next few months making small PRs into it until we're ready to merge.

Closed in favour of #274


Facebook Channel status error

When I 1st setup the Facebook Channel the status is show running but since I couldn't get any respond from the bot in the facebook messenger.  I uncheck the "Enable this bot on Facebook Messenger " and check its again.  After it the Facebook Channel keep showing error "Object reference not set to an instance of an object"
I deauthorize the facebook channeland redo it, still the same error, please help

I just pushed a new version of the facebook connector, can you try again?

Thanks Tom but I still got the same error after I deauthorize the facebook channel and redo it.  Somehow it seems something has been cashed no matter I deauthorize or check/uncheck "Enable this bot on Facebook Messenger"

May I know anyone has the sema issue and waht is the work around?  I dont want to re-register my bot as I've skybot setup etc.  Appreciate if someone can help me out?


[improve][broker] Improve Gzip compression, allow excluding specific paths or disabling it

Motivation

improve Gzip compression support added in #21667
extend Gzip compression to cover also Pulsar Proxy endpoints

Modifications

use a shared GzipHandler instance
add configuration key "httpServerGzipCompressionExcludedPaths" for excluding specific paths or disabling compression

Documentation

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

Some changes were moved from the original draft PR to #22463 and #22464


API client generator (TypeScript and Python)

Description

Based on my work exploring this concept in https://git.sr.ht/~sara/openverse-api-client.
Differences from that version are mostly around using the OpenAPI schema to generate the types, rather than hand writing the types.
Otherwise, the interface for the frontend client is virtually unchanged. The Python clients have more significant differences due to that I removed the HTTP method from the front of the client method names. In all other cases, the principle is nearly identical.
I've already demonstrated the value of the JavaScript client for even our own frontend. The Python client, on the other hand, would be more useful for things like the Openverse Slack Reaction app (which isn't part of the project yet).
To briefly document the approach:

There are two new packages, a JavaScript @openverse/api-client package and a Python package openverse-api-client, which contains both the openverse_api_client distributable package and a second support package openverse_api_client_generator.
openverse_api_client_generator is responsible for parsing the Open API schema, translating it into Python data models of Property, Model, and Route, and then templating TypeScript and Python files based on that data model.
For the TypeScript side, the generator generates the type definitions for the models as well as type definitions (and runtime metadata) for the actual API routes.
For the Python side, the generator generates the TypedDict definitions for the models, and two separate client classes. The client classes share the same template. This is possible because HTTPx's interface is 1-to-1 mirrored between the synchronous and asynchronous versions of its client (and is why I chose HTTPx instead of aiohttp + requests).
The @openverse/api-client package consumes the models and route definitions to create a client generating function. Authentication handshake and such are handled by the client. Essentially all the complexity of the TypeScript package is contained within the OpenverseClient function.
The openverse_api_client package uses the models to create support objects for the two generated client classes. That means there is a bit of circular navigation that happens when working on the Python side (because the Auth refers to the models, and client refers to the Auth). I tried very hard to think of an approach that would avoid this and instead be more like the TypeScript side. But, because Python's type system is much less dynamic than TypeScripts, I was not able to find any solution to this problem. Instead, I decided to acccept that these packages will be tightly coupled regardless.

Originally I had the generator package as a completely separate project from openverse-api-client. That's not necessary, however, because we can instruct pdm's build to only build src/openverse_api_client and exclude the generator files altogether. Colocating the generator and the Python client reduces the sense of circularity in the references, because at least the files are close to each other in the file tree. It is still less linear a flow than with TypeScript, but I couldn't figure out another option. If anyone can think of a way to accomplish this, I'd be stoked!

Ultimately the goal is to have two publishable packages that both pass type checks, correctly manage the Openverse API authentication flow, and are usable in day to day applications. The final step of this, which should happen in a separate PR, is to create and document a process for publishing versions of these packages to npm and pypi. This PR is focused on creating the packages, demonstrating a potential approach for maintaining them based on the OpenAPI schema, and adding basic minimal tests to support that. Of course, more testing and validation should go into this before we start publishing these on a regular basis. For example, we can incorporate the @openverse/api-client into our own frontend, or use openverse-api-client for some integration-level tests of the local (or production) API in test suites similar to that proposed for the frontend in #4706.
Testing Instructions

Review the documentation for the package (and the information above) to understand the goals and approach. Then review the code. I recommend starting with the generation code in packages/python/api-client/src/openverse_api_client_generator. The entrypoint is __main__.py, through which you should follow the parsing of the OpenAPI schema into the different pieces, and map those onto the Jinja2 templates for generating the requisite Python and TypeScript code. You can run the generator using the command documented in the Python package's documentation page: ov just pdm api-client run generate.
After reviewing the generation code, review the client code itself, in particular the authentication flow. This is in the auth.py for the Python package and in client.ts for the JS client. The JS client currently has good tests demonstrating how it should work, which pass. Similar tests need to be written for the Python package to validate the HTTPx Auth implementation.
Finally, review the JS code for making requests, and review the generated Python client code. Review the types too, if you'd like.
I'd also recommend trying out the clients in the unit tests for each package and seeing what you think of the way the APIs work for each one. Nothing here is really set in stone, so if there are problems with the ergonomics, we can improve and iterate on those over time.
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[x] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[N/A] I ran the DAG documentation generator (./ov just catalog/generate-docs for catalog
PRs) or the media properties generator (./ov just catalog/generate-docs media-props
for the catalog or ./ov just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

I also want to discuss the use of the LGPL license because, while I agree with the choice, the reasons for it need to be documented somewhere

Totally! I'd forgotten I kept the LGPL from my original work. It's been a long overdue conversation for us to talk about when/if we'd go in line with WP foundation's GPL usage.
We can keep this MIT in the meantime for flexibility, though.
That's a good conversation for us to consider for the meetup, potentially (depending on how the maintainers all feel about it).

Sorry for accidentally closing this PR.

I wondered about an API like that as well, Olga. Cloudflare's Python client library has a similar API to that (and types), however they handle versioning fundamentally differently (and indeed require specifying the version every time). For what it's worth, the JS client's API was heavily inspired by GitHub's client's request function. Their documentation does a great job of highlighting how the string parameter with method and route correspond directly to the OpenAPI documentation.
Leaving aside the inspirations or the approaches others have taken, I disagree with the approach you suggested for the JS client for the following reasons:

The Openverse API does not have a versioning policy, but even if we did, I wouldn't expect it to have a static version supporting all endpoints. If we bumped a particular route to v2, for example, I don't think we would bump other routes if they didn't also change. A major change in the image search API is completely separate from the auth token endpoints (both versioned). Using a static version for the client (or even adding a default and facilitating overrides for individual calls) would: potentially imply that versioning does work that, make it non-obvious that a single client instance can support multiple different versions, complicate the code to enable the support to override versions for an individual call (and then select types conditional on the version). We shouldn't try to support a single version per client instance either, because then we'd have to share state between client instances for authentication, a complicated situation already, made even worse if we tried to coordinate multiple clients that for some reason operate on different versions of the authentication API... which would by definition operate differently!
From a typing perspective, it's untenable or at the very least much more complicated than the current approach. Grant that we would need to support overriding the version of a particular call at the call site. That means the return type, which currently merely maps the type out of the Routes type using the string the client function is called with, would need to also map that based on the version. Ignoring how the route is determined, it would look like this: client.search_images({ version: 2 }) and the return type mapped based on the version, either inline or in some super-type like the current Routes type.
From a maintainability perspective, it's far more code to write, and it would either be exceedingly verbose (generate every single endpoint as individually nested JavaScript objects and functions, which somehow share state for auth) or highly abstract (some kind of proxy object that builds the route based on the dotted path, and which is typed separately from the code itself that runs the proxy).
Finally, it doesn't translate well to any API that would be easy to generate and maintain for the Python clients (this is a minor concern, but a nice-to-have if they roughly align in some way).

Generally (for both the JS and Python client) I disagree that we should optimise for conciseness of calls. The difference in the number of characters required to call openverse.images.search() and openverse("GET /v1/images/") is effectively 3 characters (ignoring the quotes and the dot in each, which are just syntax). If we used images.search for search and images.get for the single result, then they are pretty easy to confuse either way, especially if you're reading the REST API's documentation. Using the routes, there is no possibility of confusion of which route you are working with, and translating the REST API documentation to a client call is one-to-one: openverse("GET /v1/images/") and openverse("GET /v1/images/{identifier}/", { identifier: "..." }).
From a discoverability perspective, TypeScript's language server is perfectly capable of autocompleting these strings and giving you all the options as you type, even if you type fragments.

For documentation, there is an easy improvement to make here I only thought of due to this discussion! We can export delcare function Client(...) with overloads for each route and docstrings on each endpoint.
I am writing on a flight and will continue writing the rest of my thoughts later. Thanks for the thoughtful suggestion!

One more thing regarding the alignment between the REST API documentation and the JS client's API. If you're not using TypeScript, then the REST API's documentation should be copy/paste-able to create the calls you need. That avoids us needing to write double documentation for each of the nested objects and functions like .images.get and so forth, to make the library discoverable without relying on TypeScript's language server.
I think that's pretty valuable.
I will admit, however, that the Python API is rather ugly. The method names are long and admittedly a bit rough to read. At one point I tried to implement the same string-literal based approach in Python, but the language server I was using does not automatically cast strings to Literal[...], so a set of overloads of a single request function where the return type corresponds to the first string parameter as a literal value wasn't working very well. I think mypy would support it (maybe even without the casts) and I'm not sure what Pylance or Pycharm do (I use Jedi's language server).
However, while writing this, I remembered trying something along these lines and never really gave it a full try:
from openverse_api_client import Openverse, routes
openverse = Openverse()

openverse.request(routes.v1_images(q="...", source="..."))

In this version, the request method is overloaded like this:
class Openverse:
    @overload def request(r: routes.v1_images) -> routes.v1_images.Response
    @overload def request(r: routes.v1_audio) -> routes.v1_audio.Response
    def request(r: OpenverseRequest) -> OpenverseResponse:
        ...

I did try something like this, and ran into some kind of problem, I just cannot remember what. I may have gotten frustrated at the need for individual overloads instead of being able to map the generic type? And then forgotten to go back and try this again after I realised we would need to write a method signature for every individual route anyway?
Of course the benefit of this is that it removes the need for individual implementations of each method, the single request method just works over the OpenverseRequest instance. That would make the generated code (and really the template) a bit easier to comprehend and would remove the need to duplicate every single route method's implementation in the async and sync clients.
I would also be possible to eventually add back in overloads for individual routes, so that routes.v1_images could be defined like this (never mind the complexity of generating this from the OpenAPI schema, it's a bit of just dreaming at this point, the OpenAPI schema doesn't currently describe the true discriminated-union nature of the search endpoints):
class v1_images(OpenverseRequest):
    class Response:
        ...

    @overload def __init__(self, q: str) -> Response
    @overload def __init__(self, collection: Literal["tag"], tag: str) -> Response
    @overload def __init__(self, collection: Literal["source"], source: str) -> Response
    @overload def __init__(self, collection: Literal["creator"], source: str, creator: str) -> Response

Of course, there's the same literal-string casting problem again. I guess the other option is:
class v1_images(OpenverseRequest):
    class Response:
        ...

    @overload def __init__(q: str) -> Response
    @overload def __init__(tag_collection: str) -> Response
    @overload def __init__(source_collection: str) -> Response
    @overload def __init__(creator_collection: str, source: str) -> Response

But that's deviating far from the REST API's documentation, and not even using the same parameter names anymore. Tag is easy, I suppose, because the tag parameter is used exclusively for the tag collection. Source can be used on its own and creator+source can be used without the collection parameter (I've just learned this, I'm not sure what this code is doing different from if you add collection=creator, but I haven't looked yet).
Another idea is to abuse the TypedDicts indexer types, and have the clients inherit from a generic TypedDict where the keys are the GET /v1/images/ style route names, with the value being a corresponding Procotol with __call__ (and presumably async def __call__) defined with the args and return type for the route. Last I checked Jedi wasn't capable of auto-completing strings inside the indexer brackets for TypedDicts, but if other LSPs support that now (or soon), maybe that's the way to go. Then the APIs would align essentially 1-to-1.
class v1_images(Protocol):
    class Response:
        ...

    def __call__(self, q: str, ...) -> Response:
        ...

class OpenverseRoutes(TypedDict, total=False):
    "GET /v1/images/": v1_images

class Openverse(OpenverseRoutes):
    def _request(self, route: v1_images | ...) -> ...:
        ...

    def __getitem__(self, key: str):
        # this is made up code ... maybe something like this is possible?
        return self._request(OpenverseRoutes.__annotations__.get())

Anyway, there is a lot of room to explore here. If anything though, I'd like to aim to get the Python client as close to the JS client as possible, in terms of how 1-to-1 the relationship is to the REST API documentation itself.

I will take more time reading through your replies and the code, thank you for giving all the details and context. I understand the reasons, although I'm still not the biggest fun of the string-based approach :)

That's fair! We could start with this, it's much simpler overall to program, and then create an alias layer over top it, similar to the GitHub library's API. The scope for this PR definitely needs to be defined somehow, a "low-level" version (as you called it) sets a foundation and lets us ignore more complex questions about what to name aliases and such.

For reviewers: I plan to make at least one change, which is to add the various overloaded definitions of the TS client function type so that documentation for each route shows up in the function call (currently does not do that).
I will experiment with the Python client and the idea of using individual classes to construct a request for a particular route, and overloaded definitions to transform the response type accordingly.
I was also wondering, because this is such a large PR to review (and there aren't really good ways of splitting it up), maybe we can review it together at the maintainers' meetup next month? Otherwise, we could do that over a video chat earlier. Just if that would help get this reviewed. It certainly should be given some careful thought, but we aren't committing to anything in particular here other than the methodology. These packages won't be published yet (and the versions that are published are marked alpha anyway) so we can feel free to make any changes we want to align with our goals.

After trying Pyright again (after much time not using it, and only using mypy instead), it turns out Pyright will implicitly cast a literal string passed to a function with overloads of Literal["whatever"] and find the right overload. And in fact, mypy will do so as well. So I don't know why I thought it wouldn't. Anyway, I'll get changes up as soon as possible to make the Python clients align with the "low-level" API of the JS client.

Okay, I got something like what I wanted, but not quite. Annoyingly, whilst mypy and Pyright will both select the correct override when the endpoint is the single argument, they will not do so when there are additional positional or key-word arguments. Instead, client.endpoint takes the endpoint string and returns a class whose constructor signature has the path, query, and body parameters, and you pass the instance of that class to client.request.
search_result = client.request(
    client.endpoint("GET /v1/images/")(q="dogs", source="flickr", page=2),
    headers={"User-Agent": "CustomApp/1.0"},
)

I don't really like this. At all. I can't remember if I tried overloads on request with the parameters, so you wouldn't need to do the awkward call off the result of endpoint() with the request parameters. Maybe it would be cleaner if endpoints was just a TypedDict and the syntax was client.endpoints["GET /v1/images/"](q="dogs", ...)? It at least feels more normal, and is effectively the same, perhaps even simpler because endpoint as a method requires a list of overloads, but as a TypedDict, that wouldn't be required. I'll try that in the next commit.

I'm converting this back to a draft. I want to refocus this PR a bit by making it explicitly interested solely in implementing the "low-level" version, and facilitating a higher-level API built upon it. To me, that means making the following changes:

Go back to a dedicated request method on the Python client, and implement an explicit function named request on the JavaScript client. The latter will include converting the JS client to a class, rather than this weird pseudo-constructor function I for some reason used. Using a class with a request method will make it easier to implement any kinds of higher-level APIs over top that request method within the context of the class, just as we can do with the Python client.
Explore splitting the method and route into separate strings, and in Python, use StrEnums for both (http.HTTPMethod for the method, of course).
Clean up the OpenAPI schema parsing code to use new NamedTuples for each OpenAPI schema type rather than Python types. This should make following the code a lot simpler. I tried using https://pypi.org/project/openapi-type/ for this, but it didn't immediately work, and required some potentially significant changes to support 3.0.3 and even some features of OpenAPI that we use which are technically optional, and therefore unimplemented in openapi-type. I forked it and briefly tried to make some of these changes, but the complexity of that library (it uses typeit to parse the schema) felt over-the-top for just handling the current OpenAPI schema features that the Openverse REST API uses. We don't need to implement a general OpenAPI schema parser, just the subset of one that will handle the Openverse REST API.

Sounds good, thanks for the review @zackkrida! I'll add exporting the paths.

@zackkrida paths export added in https://github.com/WordPress/openverse/pull/4538/commits/9da282d5a17c0a1a4245f77fc4c6ea24e7b69e76


Fix no-sm2

Fix ecdsatest to not run the SM2 test if SM2 has been disabled.

I marked it "urgent", since I imagine that a run-checker build fails.

Pushed. Thanks.


Error when using torch.html() with newlines in the HTML

To reproduce
Open a notebook and type into a cell:
itorch.html('hello\nworld')

It produces the error shown below.
The following works fine, however, with the \n removed:
itorch.html('hello world')

Error message shown in cell
Javascript error adding output!
SyntaxError: Unexpected token ILLEGAL
See your browser Javascript console for more details.

itorch html has to be double-escaped. it's basically first a javascript string that then gets pushed into a div tag with $(id).html(str).
In your case itorch.html('hello\nworld') will work.
I can fix this in two ways. I can add a warning in the documentation of this subtlety, or I have to write a patch to escape the string manually before sending it to the browser.

Ah, thanks, that wasn't clear to me from a quick skim in the developer's console. Perhaps escaping the string within itorch.html gives the user the least surprises.

Thanks, that's a good call. Fixed now in trunk via commit https://github.com/facebook/iTorch/commit/b38bec0a61f81ddd86110b2aa21be1194cd9ba59


Update ReceiveSharingIntentHelper when intent is null

Has a try catch error on Android when i maximize my app without a intent shared (intent null)
[Error: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.String.toString()' on a null object reference]
With this validation the error will not be appears anymore <3

The one liner is the simplest solution I've seen since multiple discussions on the issue, e.g. #96 and  #110.
Thanks! @JeanEXE


Dreamcast VMU

Two things I've noticed about using this emulator:

the 'vmu' rom folder in roms has to be manually created.  Most rom folders already exist except this one.
The emulation theme for VMU doesn't have an image and the text is just simple "Sega Dreamcas..."

This has been accommodated as part of today's online update.

This has been accommodated as part of today's online update.

Thanks!

Thanks!


[ISSUE #5918]Fix MessageStoreConfig some typo

Make sure set the target branch to develop
What is the purpose of the change
close #5918
close #5882
Brief changelog
XX
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Codecov Report

Merging #5919 (fab208e) into develop (a961a9b) will increase coverage by 0.00%.
The diff coverage is 41.66%.

@@            Coverage Diff             @@
##             develop    #5919   +/-   ##
==========================================
  Coverage      43.36%   43.37%
+ Complexity      8810     8806    -4
==========================================
  Files           1090     1090
  Lines          76407    76407
  Branches        9981     9981
==========================================
+ Hits           33135    33138    +3
+ Misses         39126    39121    -5
- Partials        4146     4148    +2

Impacted Files
Coverage Δ

...ache/rocketmq/store/AllocateMappedFileService.java
41.66% <0.00%> (ø)

...main/java/org/apache/rocketmq/store/CommitLog.java
64.93% <0.00%> (-0.21%)
:arrow_down:

...ache/rocketmq/store/config/MessageStoreConfig.java
58.68% <44.44%> (ø)

...org/apache/rocketmq/store/DefaultMessageStore.java
52.91% <100.00%> (ø)

.../org/apache/rocketmq/store/ha/DefaultHAClient.java
58.46% <0.00%> (-3.08%)
:arrow_down:

...he/rocketmq/client/trace/AsyncTraceDispatcher.java
82.21% <0.00%> (-2.41%)
:arrow_down:

...mq/client/impl/consumer/RebalanceLitePullImpl.java
69.86% <0.00%> (-1.37%)
:arrow_down:

.../apache/rocketmq/store/ha/DefaultHAConnection.java
65.86% <0.00%> (-1.21%)
:arrow_down:

...cketmq/store/ha/autoswitch/AutoSwitchHAClient.java
76.17% <0.00%> (-0.37%)
:arrow_down:

...e/rocketmq/namesrv/routeinfo/RouteInfoManager.java
63.43% <0.00%> (-0.33%)
:arrow_down:

... and 12 more

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

@Oliverwqcwrw  PLS check

Hi @HScarb  PTAL~

@caigy  PTAL~ thanks


Building Abseil 20230802.0 with MinGW-w64 fails

Describe the issue
Building Abseil 20230802.0 with MinGW-w64 fails when building with -DBUILD_SHARED_LIBS:BOOL=ON
[213/236] Linking CXX shared library bin\libabsl_synchronization.dll
FAILED: bin/libabsl_synchronization.dll absl/synchronization/libabsl_synchronization.dll.a
cmd.exe /C "cd . && D:\Prog\winlibs64-13.1.0msvcrt\mingw64\bin\x86_64-w64-mingw32-g++.exe -std=c++17 -O3 -DNDEBUG   -shared -o bin\libabsl_synchronization.dll -Wl,--out-implib,absl\synchronization\libabsl_synchronization.dll.a -Wl,--major-image-version,0,--minor-image-version,0 absl/synchronization/CMakeFiles/synchronization.dir/barrier.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/blocking_counter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/create_thread_identity.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/futex_waiter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/pthread_waiter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/sem_waiter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/stdcpp_waiter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/waiter_base.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/internal/win32_waiter.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/notification.cc.obj absl/synchronization/CMakeFiles/synchronization.dir/mutex.cc.obj  absl/synchronization/libabsl_graphcycles_internal.dll.a  absl/synchronization/libabsl_kernel_timeout_internal.dll.a  absl/debugging/libabsl_stacktrace.dll.a  absl/debugging/libabsl_symbolize.dll.a  absl/time/libabsl_time.dll.a  absl/time/libabsl_civil_time.dll.a  absl/time/libabsl_time_zone.dll.a  absl/base/libabsl_malloc_internal.dll.a  absl/debugging/libabsl_debugging_internal.dll.a  absl/debugging/libabsl_demangle_internal.dll.a  absl/strings/libabsl_strings.dll.a  absl/numeric/libabsl_int128.dll.a  absl/strings/libabsl_string_view.dll.a  absl/strings/libabsl_strings_internal.dll.a  absl/base/libabsl_base.dll.a  -lpthread  absl/base/libabsl_spinlock_wait.dll.a  absl/base/libabsl_throw_delegate.dll.a  absl/base/libabsl_raw_logging_internal.dll.a  absl/base/libabsl_log_severity.dll.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -pthread && cd ."
D:/Prog/winlibs64-13.1.0msvcrt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj:per_thread_sem:(.text+0x14b): undefined reference to `absl::lts_20230802::synchronization_internal::Win32Waiter::Wait(absl::lts_20230802::synchronization_internal::KernelTimeout)'
D:/Prog/winlibs64-13.1.0msvcrt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj:per_thread_sem:(.text+0xb5): undefined reference to `absl::lts_20230802::synchronization_internal::Win32Waiter::Poke()'
D:/Prog/winlibs64-13.1.0msvcrt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj:per_thread_sem:(.text+0xc5): undefined reference to `absl::lts_20230802::synchronization_internal::Win32Waiter::Win32Waiter()'
D:/Prog/winlibs64-13.1.0msvcrt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj:per_thread_sem:(.text+0xd5): undefined reference to `absl::lts_20230802::synchronization_internal::Win32Waiter::Post()'
D:/Prog/winlibs64-13.1.0msvcrt/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: absl/synchronization/CMakeFiles/synchronization.dir/internal/per_thread_sem.cc.obj:per_thread_sem:(.text+0xe5): undefined reference to `absl::lts_20230802::synchronization_internal::Win32Waiter::Poke()'
collect2.exe: error: ld returned 1 exit status
[214/236] Building CXX object absl/strings/CMakeFiles/cord.dir/cord.cc.obj
ninja: build stopped: subcommand failed.

Steps to reproduce the problem
cmake.exe -GNinja -DCMAKE_BUILD_TYPE:STRING=Release -DBUILD_SHARED_LIBS:BOOL=ON -DABSL_USE_GOOGLETEST_HEAD:BOOL=OFF -DABSL_RUN_TESTS:BOOL=OFF -DCMAKE_CXX_FLAGS:STRING="-std=c++17" -S. -Bbuild_shared
ninja -Cbuild_shared

What version of Abseil are you using?
20230802.0
What operating system and version are you using?
Windows 11
What compiler and version are you using?
Tried with GCC 12.2.0 and 13.1.0
What build system are you using?
CMake 3.27.1 + Ninja 1.11.1
Additional context
Builds fine with -DBUILD_SHARED_LIBS:BOOL=OFF

This happens for me as well, but disabling building shared libs did not help on my system.
Forcing a specific implementation of abseil waiter with cxxflag -DABSL_FORCE_WAITER_MODE=4 (4 for stdcpp) seems to be a work-around for the build errors related to Waiter. I found this option in waiter.h.

For me adding -DABSL_FORCE_WAITER_MODE=4 (4 = ABSL_WAITER_MODE_STDCPP) to CMake flag CMAKE_CXX_FLAGS also fixes the build.
But I think it would be cleaner to actually fix the native method (3 = ABSL_WAITER_MODE_WIN32).

I tried this on Linux using mingw32 as a cross compiler and saw what @flxzt mentioned. I think it is a different issue from @brechtsanders original report.
As far as I can tell, the native implementation requires at least Windows Vista. When I tried mingw32 as a cross compiler, it seems to by default target an earlier version of Windows, which is why the build fails. Maybe there is some flag to specify the minimum Windows version to target? At head we now fallback to StdcppWaiter, which fixes this issue.
The original report from @brechtsanders seems to be trying to use the native implementation. I haven't tried to figure out why it is failing yet, but it does appear to fail in a different way.

I have opened a PR where I made abseil-cpp use pthread_waiter instead of win32_waiter.
Please take a look at #1538


Make purple portal surface visible.

Please make the nether_portal block visible (configurable in options), so there will be no more lighting issues (nether portal blocks make light.) and nether will be less visible making also latency less visible!

If I’m not mistaken the config has a setting for that:
hide-portal-blocks: false

Oh sorry GorgeousOne! D:


remove managed_cluster/local_policy history tables

Note:

remove the history.managed_cluster and history.local_plicies from history schema.
Add the trigger only update the deleted_at and updated_at when deleting row from the status.managed_cluster and local_spec.policies.
Make sure the deleted records(deleted_at IS NOT NULL) won't updated when the bundle does not contain the obj.

/retest

/test test-unit

/test test-unit

/test test-unit

/cc @clyang82 @ldpliu


Remove trailing slash in Gemfile gem source

Removes trailing slash in the source for acts_as_versioned in this line:
gem("mo_acts_as_versioned", ">= 0.6.6",
    git: "https://github.com/MushroomObserver/acts_as_versioned/")

I hope this fixes errors in Dependabot PRs. Which complain
You have changed in the Gemfile:
* mo_acts_as_versioned from
`https://github.com/MushroomObserver/acts_as_versioned` to
`https://github.com/MushroomObserver/acts_as_versioned/`

Ex: https://github.com/MushroomObserver/mushroom-observer/actions/runs/10458112849/job/28959191755?pr=2321

coverage: 93.484%. remained the same
when pulling afa6e98e8ddb46dc954255e93dcd85797f4c6d9a on jdc-dependabot-trailing-slash
into 8bb66ae7804227a21df8b225e18028c52cb084e7 on main.


🐛 BUG(miniflare): Diacritics in IP geolocation headers causing problems

Which Cloudflare product(s) does this pertain to?
Miniflare
What versions are you using?
wrangler 3.99.0
What operating system and version are you using?
any os
Please provide a link to a minimal reproduction
No response
Describe the Bug
I tried to deploy my Next.js app to Cloudflare Workers, and I followed this tutorial. The build completes successfully, but when I try to preview or deploy it, I encounter the following error:
Invalid header name or value: "Žilina". Per the Fetch specification, the Headers class may only accept header names and values which contain 8-bit characters. That is, they must not contain any Unicode code points greater than 0xFF. As a quirk, we are encoding this string in UTF-8 in the header, but in a browser this would result in a TypeError exception. Consider encoding this string in ASCII for compatibility with browser implementations of the Fetch specification.

Žilina is a city in Slovakia, and I assume that somewhere, a header with this value is being sent. I was able to find the cause, and it throws an error in Miniflare here. I guess the diacritics are causing the problem.

Please provide any relevant error logs
No response

Hi @Joozty,
Could you let us know which version of @opennextjs/cloudflare you are using? Also, can you check if upgrading to the latest version resolves the issue?
cc: @vicb

@edmundhung @vicb  I use latest version 0.3.3. I will open the issie in the opennextjs repo. Thx


Make BrowserCrypto generate UUID v7 by default

Make BrowserCrypto generate UUID v7 by default.

What changed w.r.t the sequential logic? Are we implementing this in part and still expecting the storage gains?

We drop maintenance of the monotonic sequence (reset every ms) in UUID suffix. However, timestamp-based prefix stays in place, providing storage size/perf gains.