Euclidean distance never exceeds 1.0?

Hi.
On the demo website (bbt_face_similarity), I can't find an example where the distance exceeds one.
I may have my math wrong but would like to understand better.  As I understand it, this means the sum of the squares of the individual distances (presumably many) never exceeds 1.0, otherwise, the sqrt would be >=1 also.
I'm probably missing something obvious?  Is it just a fluke, or is there something in the math or the data guaranteeing a euclidean difference < 1.0

Hi,
That might be due to the fact, that each value of a descriptor is usually a small value -1.0 < x < 1.0 (not sure about the exact boundaries here). Thus the distance usually does not exceed 1.0.
I wouldn't guarantee however, that this is always the case as I understood, the values just happen to lie in that range.


WIP - Common Lisp support for Apache Thrift

The current state of work. Brief summary:

Patched the head of Apache Thrift with the de.setf code.
Fixed errors and warnings. Got it working with SBCL. This involves:

The IDL -> CL generator.
The CL library.

Created the cross-test code and integrated it so it builds together with the rest of cross-tests. Mostly everything is implemented, with the exception of exceptions (pun unintended) on the client side - apparently receiving an exception as a response is broken right now.

My mistake. This wasn't meant for upstream. Please ignore this.


QVBV

Key
Value

View
https://database.shabados.com/sources/3/page/40/line/141

Source
Vaaran Bhai Gurdas Ji

Page
40

ID
QVBV

Line
shs isAwxy sY purs; shs isAwxp lieAw n jweI [

Closed in https://github.com/ShabadOS/database/commit/3a9bcb4bc6c41ff06f903666526057a8a0bfc468


Question about worldborder extention

Hey,
Would the new mansions from 1.11 show up if I'd extend the worldborder? Or is a world reset required?
Thanks in advance.

Offhand, I don't know. This is the first I've actually heard of mansions being added. If the mansion can in fact show up in newly generated chunks in an old world, then the answer is yes. But it may instead require a new world for the new world features.
Whatever the case, it's not really anything to do with WorldBorder.

Well, the reason I link this to worldborder, is because as far as I know due to the worldborder, chunks outside of it won't be generated.
So, if I'd extend the worldborder and new chunks are being generated, I wonder if new structes from minecraft versions would show up, or that it still needs a world reset.
Thanks for your reply btw :)

Well yes, those chunks are of course not generated until somebody moves out close enough for them to generate, or until you run a Fill or similar routine that generates chunks.
Whether the mansions will even generate in an older world is the question, and I don't have that answer.


cannot be called on 'Map<dynamic, dynamic>?' because it is potentially null

Describe the bug
When building my app with this package, I get the error "cannot be called on 'Map<dynamic, dynamic>?' because it is potentially null."  We were able to resolve the issue by changing this._socket.io.options['extraHeaders'] = to this._socket.io.options!['extraHeaders'].
I have attached a screenshot of the error and a screenshot of the fix.  Can you implement this fix or a fix you deem necessary to resolve the issue?
To Reproduce
Build app with package.
Expected behavior
Build successfully.
Screenshots

Hi @palmtown
Thanks this.
It'll be nice to make a PR.
Can you ?

There is a PR available that fixes this issue. Can you merge it and release a new version?


What about a wrapper of the game sdk?

Discord Rich Presence is deprecated and was replaced with the game sdk. Would it not be an easy to to the same with that in the way you did it here with Discord Rich Presence sdk.

This was something I already considered once, however there are two reasons why I haven't done this yet.

The rich presence is far from being depricated, it's more of a „light“ game sdk that only covers the rich presence and joining parts.
To get access to the developer resources for the Game SDK, one needs to be a verified game developer and purchase a developer license for the discord store. The codebase is under a protected license, which makes it fairly hard to create public wrappers for.

I hope this explains why I haven't done this yet.
Best regards, Vatuu

thx for the answer


Maximum call stack size exceeded

Let's say I have a GraphQL schema like below:
type ProductCategory {
  parent_category: ProductCategory
}

And this generates mock function like below:
export function createProductCategoryMock(props: Partial<ProductCategory> = {}): ProductCategory {
  return {
    parent_category: createProductCategoryMock({}),
    ...props,
  }
}

And this cause Maximum call stack size exceeded error. Do I just need to change the parent type different name? Any thoughts? Thanks.

Is parent_category field nullable? I had impression that we get nulls for all nullable fields so I expected the function to be more like:
export function createProductCategoryMock(props: Partial<ProductCategory> = {}): ProductCategory {
  return {
    parent_category: null,
    ...props,
  }
}

aw the schema should be like this:
type ProductCategory {
  parent_category: ProductCategory!
}

i would like to talk about the case if the field is non-nullable :p

That's an interesting use case, not sure what would be best here as the schema defines an infinite recursion. So it's impossible to satisfy the type definition, unless perhaps through a circular dependency but that would not make much sense.
How where you intending to test this code @japboy? Having a better understanding of your expectations could help here.
What do you think @ertrzyiks? Perhaps we should raise an error/warning or offer an option to trick TypeScript (for example through some null as any as ProductCategory but it could bite users).

@zhouzi @ertrzyiks thanks for your feedback!
well my use case is actually sort of exceptional. there is a schema which has nullable fields only and i need to generate non-nullable mock functions for the fields. so i wrote a patch with patch-packages which has nullableIgnored option and found the infinite recursion issue.
and i feel like this comment is intuitive for me:
https://github.com/zhouzi/graphql-codegen-factories/issues/59#issuecomment-1266609192
perhaps i can add another option like nullableIgnoredExceptions: ['ProductCategory'] for my use case.

People who actually need non-nullable recursive seem to have some limits in mind on how many levels of nesting they need.

agreed. limitation is maybe passed by variables and its not expressed with types...

perhaps i can add another option like nullableIgnoredExceptions: ['ProductCategory'] for my use case.

I think that would be a great solution as it's not possible to create an object with infinite depth. You would still be able to create nested objects in your code:
createProductCategoryMock({
  parent_category: createProductCategoryMock({
    // you can repeat the process as much as you need
    // or even create a helper
  })
});

With that being said, I agree with @ertrzyiks that this plugin should better inform users in this case. I think ideally it would raise an error when generating the mocks (build time as opposed to runtime). Let's add that 👍


Best way to get depth from aligbed_depth_to_color topic?

Hello! I'm trying to solve a problem using a intel realsense D455. Right now I have a rosbag captured from a car running by a stop-sign. I'm trying to find the stop-sign and the depth from the camera to the sign. I have a node that recognizes the stop sign and gives me the pixels on the screen where the sign is. So my issue now is that I want to take that pixel-data of x and y and from the aligned_depth_to_color image find the depth to that pixel.
So let's say my stop sign is at the positions x and y. When I run this code for example:
depth_image = bridge.imgmsg_to_cv2(ros_image,desired_encoding='passthrough')
depth_array = np.array(depth_image,dtype=np.float32)
print(depth_array[x,y])

The problem is that I get around 2300 printed all the time.
Thanks for any advice you could give me!

Hi @IcookTacos   The link below may provide some useful insights.   It discusses a method of using Python to retrieve depth information from the /aligned_depth_to_colortopic of a bag recorded in ROS.
https://github.com/IntelRealSense/realsense-ros/issues/1312

@MartyG-RealSense Amazing! Thanks for the help. Will look into that thread!

Hi @IcookTacos   Do you still require assistance with this case, please?   Thanks!

No I think I have solved it. Thanks for the help!

Great to hear - thanks for the update!


Migrate from yarn classic to yarn berry.

Closes #6478
References:
yarn classic to berry migration guide
why yarn berry over classic

I at least ran "web" locally and clicked around localhost and things seems fine. Unfortunately I am not having as much luck with native right now (getting errors I don't quite understand). I will have to try to figure that out in next several days but it was before this change so its likely unrelated since its failure is not during yarn install

Are there any other big projects that migrated and are happy with the experience? I never used Berry before

Are there any other big projects that migrated and are happy with the experience? I never used Berry before

I can't speak for other OSS as I am fairly new to contributing but for the repo I implemented it came with some nice benefits. The biggest of course would by yarn PnP mode but that's significantly more complex. I found the investment was better spent eventually moving to pnpm. But this is a nice intermediate step since yarn classic gets no additional support currently fro. yarn time.
Since I have you here I think my blocker is the patch-package versions of several deps. I am not exactly sure what the process is expected here around that. It appears in one case the dependency may not even be used anymore. Is there documentation on how this should be handled? Otherwise I can try to stake a stab at manually updating the latest patch version of the packages then running patch package again.
Thank you for your time.

yeah tbh i don't think we can prioritize big infra changes like this at the moment, and i think we might as well adopt pnpm if we're making a change like this

yeah tbh i don't think we can prioritize big infra changes like this at the moment, and i think we might as well adopt pnpm if we're making a change like this

okay that's reasonable. ill go ahead and close as won't do against considering pnpm. I don't think its easy for you to forecast when such an update will have bandwidth from team so may I can ask sometime later in 2025. take care.


Navigate on modification in the redux store

I'm having a react-natvie application using redux and react-native-router-flux with user authentication and I want to navigate to the main screen when the user is authenticated (no matter how this authentication is made) and to the login screen when the authentication token is invalid (no matter when or how this happens).
My first thought was to make the navigation in the reducer like this:
 case LOGIN_SUCCESS:
      DataManager
            .getInstance()
            .setToken(action.payload.token);
        return {
            ...state,
            token: action.payload.token,
            loading: false
        }`

The problem is that in this case the navigation happens before the state is updated and I get in the situation that I render the main screen but my token from the store is not updated yet.
I can solve the login case by checking the state in my login component but for the logout case wich can happen in any component I don't know how to make something general.
How should I make my app navigation based on modifications in the redux store?

This is a great use case for a side effect library like redux-saga: https://redux-saga.js.org/. Essentially actions that would modify the store like a user set action can also be picked up by the middleware and trigger some other functionality like a navigation change. You can setup a generator function that watches for actions of a certain type to come in, and when they do then go get data from the store and use that data to inform your navigation action, like the presence or absence of a token. You don't necessarily have to use redux-saga, but it fits in nicely with the architecture if you are already using redux.
Example implementation:
`
function * watchForAuthChanges() {
while(true) {
const action = yield take([
UserTypes.LOG_IN,
UserTypes.LOG_OUT
])
const user = yield select(UserSelectors.get)
if (user.token) {
  yield call(Navigation.Actions.Main)
}
yield call(Navigation.Actions.Other)

}
`


Duplicate type kind 'Files' detected

What version of Elysia.JS is running?
0.8.15
What platform is your computer?
Darwin 23.2.0 arm64 arm
What steps can reproduce the bug?
Here is the reproduction repo: elysia-reprod
Steps:

bun i
bun dev
Server not working, error is thrown due to the JWT plugin in index.ts

What is the expected behavior?
JWT plugin works.
What do you see instead?
error: Duplicate type kind 'Files' detected
      at new TypeBoxError (node_modules/@sinclair/typebox/build/import/type/error/error.mjs:4:6)
      at new TypeSystemDuplicateTypeKind (node_modules/@sinclair/typebox/build/import/system/system.mjs:13:8)
      at Type (node_modules/@sinclair/typebox/build/import/system/system.mjs:37:16)
      at module code (node_modules/elysia/dist/bun/index.js:366:5628)
      at node_modules/@elysiajs/jwt/dist/cjs/index.js:5:7

1 | /** The base Error type thrown for all TypeBox exceptions  */
2 | export class TypeBoxError extends Error {
3 |     constructor(message) {
4 |         super(message);
         ^

Additional information
Seems similar to this: https://github.com/denoland/deno/issues/21394
But I am not using deno. I am using bun.

It looks like vinxi assumes that your elysia handler under routes/api/index.ts is some kind of SSR module and therefore tries to load this handler as SSR. Which in turn causes it to be executed twice.
If it is possible, try telling vinxi that this route is not SSR and should be injected as a simple http handler instead. There seems to be a configuration for this (or you have to write your own vinxi-plugin), but it has been updated recently and lacks documentation.
... at least from my perspective (i haven't done anything with vinxi yet)

did you end up finding a fix for this? also facing the same issue

This should work now.
There's a type-registery check beforehand:
https://github.com/elysiajs/elysia/blob/321a7c5539b9503cfd9169f8c313643c351037b0/src/type-system.ts#L221-L223

Resolved as mentioned by bogeychan

This should work now.
There's a type-registery check beforehand:
https://github.com/elysiajs/elysia/blob/321a7c5539b9503cfd9169f8c313643c351037b0/src/type-system.ts#L221-L223


hstr reads bash history in zsh

Using Arch Linux hstr 1.24, on zsh i get bash history selection instead of zsh.
HISTFILE is present in .zshrc.
Could be related to #272 and #166

@deathtrip thank you for the issue submission! I plan to devote the next release to zsh and fix all the bugs. Stay tuned please.

Reproducible on 18c996852cdde4ef53e7bf843c244c86c3e0bdb2

Fix will be released w/ HSTR 2.1


Add SciPy compatible connected_components

This PR adds SciPy compatible connected_components (cupyx.scipy.sparse.csgraph.connected_components) using libcugraph.
I think there are two main ways to use the functionality of cuGraph: 1) using the python APIs of cugraph, or 2) using the C++ APIs of libcugraph.  I understand that you think the former method is better (https://github.com/cupy/cupy/issues/4219#issuecomment-802523683), but cugraph has more dependent modules than libcugraph, so I think the latter is better for many CuPy users (Please see also https://github.com/cupy/cupy/issues/4219#issuecomment-803668963).
As you can see from this PR, if you use libcugraph, you can use the feature of cuGraph via a python bindings to the libcugraph C++ APIs as well as cuTENSOR, NCCL, among others.
Libcugraph can be installed via conda as follows.
conda install -c rapidsai-nightly libcugraph

Current stable version of libcugraph 0.18, which can be installed from the rapidsai channel now, has an issue in the strongly connected components (SCC). It will be fixed in 0.19. So if you want to use the SCC, please install libcugraph 0.19 or above using rapidsai-nightly channel.
To enable libcugraph, set the environment variable CUGRAPH_PATH as below when you built CuPy from source.
CUGRAPH_PATH=/path/to/the/cugraph python setup.py install

This is related to https://github.com/cupy/cupy/pull/4054 and https://github.com/cupy/cupy/issues/4219.

@rlratzel

pfnCI, test this please.

Jenkins CI test (for commit 1b27d46ba83dc1fb7e7d1d474b621cab315751e9, target branch master) succeeded!


score threshold

Why use 0.05 for score_threshold. ??
Other detectors like YOLO uses 0.5.
Can anybody explain?

Actually, you can read the visualize_single_image.py. They will choose the result whose score is larger than 0.5.


Update text-analytics-how-to-entity-linking.md

Removed non-supported TimeZone and NumberRange subtypes

@ashly1yeo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

#sign-off


Push declined due to email privacy restrictions

When performing a commit no error is shown if wrong email is used and "GitHub email privacy restrictions" are applied.
A fix must be done in ZCL_ABAPGIT_TRANSPORT=>RECEIVE_PACK in order to at least show some message

More info:
https://blog.github.com/2017-04-11-private-emails-now-more-private/
https://stackoverflow.com/questions/43378060/meaning-of-the-github-message-push-declined-due-to-email-privacy-restrictions

added a quick and dirty error message, see https://github.com/larshp/abapGit/pull/1369

@rayatus try again, latest version

closing

The documentation page:
https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address


How to change tempo of song midway with lua?

What is your question?
Check title

First of all, there is no need to do this.
And secondly, that would mess with charting since charts rely on bpm and the note placement literally changes with bpm.
So just change the bpm/tempo with the chart editor, it's a lot easier

Ok okay


add complete_abrogation_regulation_* columns

 [TARIFF17] fix typo in regulation FTS table

hey @myxrome, could you please add a link or some info about these columns? where the data comes from?

oh, I see it now in attached screenshot


"c++" "-Iscipy\sparse\sparsetools\_sparsetools.cp39-win_amd64.pyd.p" "-Iscipy\sparse\sparsetools" "-I..\scipy\sparse\sparsetools" "-IC:\Users\ilhan\AppData\Local\Programs\Python\Python39\lib\site-packages\numpy\core\include" "-IC:\Users\ilhan\AppData\Local\Programs\Python\Python39\Include" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-fdiagnostics-color=always" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-Wnon-virtual-dtor" "-std=c++14" "-O2" "-g" "-D__USE_MINGW_ANSI_STDIO=1" "-DMS_WIN64" "-DNPY_NO_DEPRECATED_API=NPY_1_9_API_VERSION" -MD -MQ scipy/sparse/sparsetools/_sparsetools.cp39-win_amd64.pyd.p/bsr.cxx.obj -MF "scipy\sparse\sparsetools\_sparsetools.cp39-win_amd64.pyd.p\bsr.cxx.obj.d" -o scipy/sparse/sparsetools/_sparsetools.cp39-win_amd64.pyd.p/bsr.cxx.obj "-c" ../scipy/sparse/sparsetools/bsr.cxx

cc1plus.exe: out of memory allocating 65536 bytes
ninja: build stopped: interrupted by user.
Traceback (most recent call last):
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\ilhan\AppData\Local\Programs\Python\Python39\Scripts\ninja.exe\__main__.py", line 7, in <module>
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\site-packages\ninja\__init__.py", line 51, in ninja
    raise SystemExit(_program('ninja', sys.argv[1:]))
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\site-packages\ninja\__init__.py", line 47, in _program    return subprocess.call([os.path.join(BIN_DIR, name)] + args)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 351, in call
    return p.wait(timeout=timeout)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 1189, in wait
    return self._wait(timeout=timeout)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 1470, in _wait
    result = _winapi.WaitForSingleObject(self._handle,
KeyboardInterrupt

Aborted.
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]>

So I don't know what else I should be doing

OK got some progress after rebuilding openblas approx. 100 times with different options but anyway numpy built successfully and now I am getting a strange error with pkgconfig even though I am setting it up, it is still looking for a place that indeed doesn't exist. Is it possibly hardcoded somewhere?
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]> $env:CC="gcc";$env:CXX="g++";$env:PKG_CONFIG_PATH="C:\opt\64\lib\pkgconfig";$env:SCIPY_USE_PYTHRAN=0
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]> python .\dev.py build
💻  ninja -C C:\Users\ilhan\Documents\GitHub\scipy\build
ninja: Entering directory `C:\Users\ilhan\Documents\GitHub\scipy\build'
[2/1395] Compiling Fortran object scipy/linalg/_fblas.cp39-win_amd64.pyd.p/..__build_utils_src_wrap_dummy_g77_abi.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[3/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzr_asvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/idzr_asvd.f:77:72:

   77 |      1                  w(ilist),w(iproj),w(icol),w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 'list' at (1); passed COMPLEX(8) to INTEGER(4)
[4/1395] Compiling Fortran object scipy/linalg/_fblas.cp39-win_amd64.pyd.p/meson-generated_..__fblas-f2pywrappers.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[5/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzr_rid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[6/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzp_rsvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/idzp_rsvd.f:157:72:

  157 |      3                    w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 's' at (1); passed COMPLEX(8) to REAL(8)
../scipy/linalg/src/id_dist/src/idzp_rsvd.f:177:72:

  177 |           call idz_reco(ls,w(isi),w(is))
      |                                                                        1
Warning: Type mismatch in argument 'a' at (1); passed COMPLEX(8) to REAL(8)
[7/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzr_aid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[8/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzp_asvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/idzp_asvd.f:122:72:

  122 |      1                    w(iui),w(ivi),w(isi),ier,w(icol),w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 'list' at (1); passed COMPLEX(8) to INTEGER(4)
../scipy/linalg/src/id_dist/src/idzp_asvd.f:142:72:

  142 |           call idz_realcomplex(ls,w(isi),w(is))
      |                                                                        1
Warning: Type mismatch in argument 'a' at (1); passed COMPLEX(8) to REAL(8)
[9/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddp_asvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/iddp_asvd.f:121:72:

  121 |      1                    w(iui),w(ivi),w(isi),ier,w(icol),w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 'list' at (1); passed REAL(8) to INTEGER(4)
[10/1395] Linking target scipy/linalg/_flinalg.cp39-win_amd64.pyd
FAILED: scipy/linalg/_flinalg.cp39-win_amd64.pyd
"gfortran"  -o scipy/linalg/_flinalg.cp39-win_amd64.pyd scipy/linalg/_flinalg.cp39-win_amd64.pyd.p/meson-generated_..__flinalgmodule.c.obj scipy/linalg/_flinalg.cp39-win_amd64.pyd.p/src_det.f.obj scipy/linalg/_flinalg.cp39-win_amd64.pyd.p/src_lu.f.obj "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0" "-LC:/rtools40/ucrt64/lib/gcc/x86_64-w64-mingw32/10.3.0" "-LC:/rtools40/ucrt64/bin/../lib/gcc" "-LC:/rtools40/ucrt64/lib/gcc" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib" "-LC:/rtools40/ucrt64/x86_64-w64-mingw32/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../lib" "-LC:/rtools40/ucrt64/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../.." "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=scipy\linalg\_flinalg.cp39-win_amd64.dll.a" "-lucrt" "-static" "scipy\lib_fortranobject.a" "-defaultlib:advapi32" "C:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/libgfortran.a" "-defaultlib:advapi32" "-Lc:/opt/openblas/if_32/64/lib" "-lopenblas" "C:\Users\ilhan\AppData\Local\Programs\Python\Python39\python39.dll" "-lgfortran" "-lm" "-Wl,--end-group"
C:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopenblas
collect2.exe: error: ld returned 1 exit status
[11/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idzp_rid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[12/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddp_aid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[13/1395] Linking target scipy/linalg/_fblas.cp39-win_amd64.pyd
FAILED: scipy/linalg/_fblas.cp39-win_amd64.pyd
"gfortran"  -o scipy/linalg/_fblas.cp39-win_amd64.pyd scipy/linalg/_fblas.cp39-win_amd64.pyd.p/meson-generated_..__fblasmodule.c.obj scipy/linalg/_fblas.cp39-win_amd64.pyd.p/meson-generated_..__fblas-f2pywrappers.f.obj scipy/linalg/_fblas.cp39-win_amd64.pyd.p/..__build_utils_src_wrap_dummy_g77_abi.f.obj "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0" "-LC:/rtools40/ucrt64/lib/gcc/x86_64-w64-mingw32/10.3.0" "-LC:/rtools40/ucrt64/bin/../lib/gcc" "-LC:/rtools40/ucrt64/lib/gcc" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib" "-LC:/rtools40/ucrt64/x86_64-w64-mingw32/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../lib" "-LC:/rtools40/ucrt64/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib" "-LC:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../.." "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=scipy\linalg\_fblas.cp39-win_amd64.dll.a" "-lucrt" "-static" "scipy\lib_fortranobject.a" "-defaultlib:advapi32" "C:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/libgfortran.a" "-defaultlib:advapi32" "-Lc:/opt/openblas/if_32/64/lib" "-lopenblas" "C:\Users\ilhan\AppData\Local\Programs\Python\Python39\python39.dll" "-lgfortran" "-lm" "-Wl,--end-group"
C:/rtools40/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopenblas
collect2.exe: error: ld returned 1 exit status
[14/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idd_id.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[16/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idd_svd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/idd_svd.f:78:72:

   78 |         call idd_permuter(krank,r,krank,n,r(io+1))
      |                                                                        1
Warning: Type mismatch in argument 'ind' at (1); passed REAL(8) to INTEGER(4)
../scipy/linalg/src/id_dist/src/idd_svd.f:210:72:

  210 |           call idd_permuter(krank,w,krank,n,w(io+1))
      |                                                                        1
Warning: Type mismatch in argument 'ind' at (1); passed REAL(8) to INTEGER(4)
[17/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddr_rsvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/iddr_rsvd.f:109:72:

  109 |      2                  w(ilist),w(iproj),w(icol),w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 'list' at (1); passed REAL(8) to INTEGER(4)
[18/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddr_aid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[19/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddp_rsvd.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/iddp_rsvd.f:155:72:

  155 |      3                    w(iwork))
      |                                                                        1
Warning: Type mismatch in argument 'list' at (1); passed REAL(8) to INTEGER(4)
[20/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idd_snorm.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[21/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_iddp_rid.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[22/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idd_sfft.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
../scipy/linalg/src/id_dist/src/idd_sfft.f:75:37:

   75 |         if(l .eq. 1) call idd_sffti1(ind,n,wsave)
      |                                     1
Warning: Rank mismatch in argument 'ind' at (1) (scalar and rank-1)
../scipy/linalg/src/id_dist/src/idd_sfft.f:233:36:

  233 |         if(l .eq. 1) call idd_sfft1(ind,n,v,wsave)
      |                                    1
Warning: Rank mismatch in argument 'ind' at (1) (scalar and rank-1)
[23/1395] Compiling Fortran object scipy/linalg/_interpolative.cp39-win_amd64.pyd.p/src_id_dist_src_idd_qrpiv.f.obj
f951.exe: Warning: Nonexistent include directory 'c:/opt/openblas/if_32/64/include' [-Wmissing-include-dirs]
[27/1395] Compiling C object scipy/linalg/_flapack.cp39-win_amd64.pyd.p/meson-generated_..__flapackmodule.c.obj
ninja: build stopped: subcommand failed.
Build failed!
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]>

Grrr. it wasn't progress but an earlier error after manually moving everything to the path it was looking for back to nonsense

C:\Users\ilhan\Documents\GitHub\scipy [main ≡]> $env:CC="gcc";$env:CXX="g++";$env:PKG_CONFIG_PATH="C:\opt\openblas\if_32\64\lib\pkgconfig\";$env:SCIPY_USE_PYTHRAN=0
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]> python .\dev.py build
💻  meson setup C:\Users\ilhan\Documents\GitHub\scipy\build --prefix C:\Users\ilhan\Documents\GitHub\scipy\build-install
The Meson build system
Version: 0.63.0
Source dir: C:\Users\ilhan\Documents\GitHub\scipy
Build dir: C:\Users\ilhan\Documents\GitHub\scipy\build
Build type: native build
Project name: SciPy
Project version: 1.10.0.dev0
C compiler for the host machine: gcc (gcc 10.3.0 "gcc (Built by Jeroen for the R-project) 10.3.0")
C linker for the host machine: gcc ld.bfd 2.36.1
C++ compiler for the host machine: g++ (gcc 10.3.0 "g++ (Built by Jeroen for the R-project) 10.3.0")
C++ linker for the host machine: g++ ld.bfd 2.36.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C supports arguments -Wno-unused-but-set-variable: YES
Library m found: YES
Fortran compiler for the host machine: gfortran (gcc 10.3.0 "GNU Fortran (Built by Jeroen for the R-project) 10.3.0")
Fortran linker for the host machine: gfortran ld.bfd 2.36.1
Program cython found: YES (C:\Users\ilhan\AppData\Local\Programs\Python\Python39\Scripts\cython.EXE)
Program pythran found: YES (C:\Users\ilhan\AppData\Local\Programs\Python\Python39\Scripts\pythran.EXE)
Program scipy/_build_utils/copyfiles.py found: YES (C:\Users\ilhan\AppData\Local\Programs\Python\Python39\python.exe C:\Users\ilhan\Documents\GitHub\scipy\scipy/_build_utils/copyfiles.py)
Program python3 found: YES (C:\Users\ilhan\AppData\Local\Programs\Python\Python39\python.exe)
WARNING: You should add the boolean check kwarg to the run_command call.
         It currently defaults to false,
         but it will default to true in future releases of meson.
         See also: https://github.com/mesonbuild/meson/issues/9300
Library npymath found: YES
Library npyrandom found: YES
Found pkg-config: C:\rtools40\ucrt64\bin\pkg-config.EXE (0.29.2)
Run-time dependency openblas found: YES 0.3.18
Dependency openblas found: YES 0.3.18 (cached)
Program _build_utils/cythoner.py found: YES (C:\Users\ilhan\AppData\Local\Programs\Python\Python39\python.exe C:\Users\ilhan\Documents\GitHub\scipy\scipy\_build_utils/cythoner.py)
Checking for function "open_memstream" : NO
Configuring messagestream_config.h using configuration
Checking for size of "void*" : 8
Run-time dependency threads found: YES
Checking for size of "void*" : 8
Dependency threads found: YES unknown (cached)
Compiler for C supports arguments -Wno-unused-but-set-variable: YES (cached)
Compiler for C++ supports arguments -Wno-format-truncation: YES
Compiler for C++ supports arguments -Wno-class-memaccess: YES
Build targets in project: 199

SciPy 1.10.0.dev0

  User defined options
    prefix: C:\Users\ilhan\Documents\GitHub\scipy\build-install

Found ninja-1.10.2.git.kitware.jobserver-1 at C:\Users\ilhan\AppData\Local\Programs\Python\Python39\Scripts\ninja.EXE
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_ufuncs_pxi_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_ufuncs_pxi_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_ufuncs_pxi_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_ufuncs_pxi_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_ufuncs_pxi_pxd' has more than one output! Using the first one.
WARNING: custom_target '_stats_pxd' has more than one output! Using the first one.
WARNING: custom_target 'cython_special' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_stats_gen_pyx' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_spatial_pxd' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_spatial_pxd' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target 'cython_linalg' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_lib_pxd' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_dummy_init_cyoptimize' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.
WARNING: custom_target '_cython_tree' has more than one output! Using the first one.

Traceback (most recent call last):
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\ilhan\AppData\Local\Programs\Python\Python39\Scripts\ninja.exe\__main__.py", line 7, in <module>
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\site-packages\ninja\__init__.py", line 51, in ninja
    raise SystemExit(_program('ninja', sys.argv[1:]))
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\site-packages\ninja\__init__.py", line 47, in _program
    return subprocess.call([os.path.join(BIN_DIR, name)] + args)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 351, in call
    return p.wait(timeout=timeout)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 1189, in wait
    return self._wait(timeout=timeout)
  File "c:\users\ilhan\appdata\local\programs\python\python39\lib\subprocess.py", line 1470, in _wait
    result = _winapi.WaitForSingleObject(self._handle,
KeyboardInterrupt

Aborted.

This is probably a Fortran issue I think. Because somehow I managed to build NumPy. Or meson/gcc is searching for something and not mentioning it. I can't find what the invocation line is because it is way deep under the dev.py machinery which is undocumented. Or something else. But this is probably a good place to stop.
By the way the double run requirement is still there the first run after the cleanup is giving this
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]> python .\dev.py build
💻  meson setup build --prefix build-install
The Meson build system
Version: 0.63.1
Source dir: C:\Users\ilhan\Documents\GitHub\scipy
Build dir: C:\Users\ilhan\Documents\GitHub\scipy\build
Build type: native build

meson.build:1:0: ERROR: prefix value 'build-install' must be an absolute path

A full log can be found at C:\Users\ilhan\Documents\GitHub\scipy\build\meson-logs\meson-log.txt
Meson build setup failed!
C:\Users\ilhan\Documents\GitHub\scipy [main ≡]>

One other problem with the OpenBLAS @andyfaff linked has the wrong architecture for my computer so I can confirm that OpenBLAS is not the issue because my local built has the same issue

How odd - and I see that you are using the Rtools compilers this time round.    What system are you on?  32 or 64 bit Windows?  Which Windows version?  Virtual machine or direct boot?  How much RAM?   Sorry if you've said before.

CPU
11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz   2.30 GHz

RAM
32GB

OS
Windows 10 Home 19044.1949 64Bit

Direct Boot

Python
3.9.6 (now will try Python 3.10)

OpenBLAS
0.3.21

meson
0.63.1

ninja
1.10.2.git.kitware.jobserver-1

pybind11
2.10.0

numpy
1.24.0.dev0+695.g50a74fb65

I think somehow gcc is picking up the 32-bit version of the compiler somehow. Is there any way to force ninja or meson to invoke 64-bit compilation parameters?

What do you get for:
get-command gcc
get-command gfortran

Is your Python install 32-bit or 64-bit?
Did you try compiling with Numpy wheel?

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     gcc.exe                                            <IP_ADDRESS>    C:\rtools\ucrt64\bin\gcc.exe
Application     gfortran.exe                                       <IP_ADDRESS>    C:\rtools\ucrt64\bin\gfortran.exe

Python 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929 64 bit (AMD64)] on win32

I've reached out to MSYS2 folk and they mentioned invoking build within the ucrt environment and also mentioned https://github.com/msys2/MINGW-packages/issues/12409. Don't know if related

After cleaning up almost everything from registry, path, AppData folders, then installing everything from scratch using UCRT64 environment, then installing Python 3.10,  I managed to build SciPy. There goes my 3 months.
I am going to repeat my highly unpopular opinion: our build systems (NumPy included) are undocumented and lives in the heads of a few maintainers. In its current state, none of the Windows build instructions (one of which is authored by me) are up-to-date or accurate for the local builds.

@ilayn any chance you could write it down while it's still fresh for you?

I am going to repeat my highly unpopular opinion: our build systems (NumPy included) are undocumented and lives in the heads of a few maintainers.

I think that would qualify as a popular opinion, in the sense of shared by many people.
Do you have time to briefly record where you looked for instructions so we can attack this?
I did check my own most recent edits to one set of instructions carefully - did you try those?  Did they work as expected?
https://github.com/scipy/scipy/wiki/Easy-Windows-10-Build-Scipy-from-source

I've reached out to MSYS2 folk and they mentioned invoking build within the ucrt environment and also mentioned msys2/MINGW-packages#12409. Don't know if related

That issue is about compiling Scipy with the MSYS2 Python, rather than with a Numpy built with MSVC, such as Numpy from a wheel.   In that case, where Numpy uses the MSYS2 default 80-bit long doubles, the default Meson build flags are wrong, because they assume that Numpy uses long-double = np.float64 .
So, if you did compile your own Numpy using gcc, and build against that, that could be a problem.  Did you do that?

@ilayn any chance you could write it down while it's still fresh for you?

I wish I can but after reading meson tutorials multiple times, our own meson.build instructions, our own source files, NumPy's source files, NumPy's issues, distutils, setuptools, I can guarantee that this NumPy/SciPy compilation business is beyond my intelligence.

I did check my own most recent edits to one set of instructions carefully - did you try those? Did they work as expected?

Not with Python 3.9. Then I gave up and installed MSYS2 directly. Most common issue with our instructions is over relying on conda and venvs which is not necessarily the same with the system-wide versions then it becomes yet another catch-me-if-you-can situation if something doesn't work. If it works for other people, that's fine but non-windows users assume too much about how win people should work.

So, if you did compile your own Numpy using gcc, and build against that, that could be a problem. Did you do that?

I did every combination, (ready-built/local-built OpenBLAS) x (pypi NumPy/locally built NumPy) x (my build attempts of SciPy)

Do you have time to briefly record where you looked for instructions so we can attack this?

As I mentioned above, I am basically looking at bits and pieces that people left around in the issues and PRs. I tried my version of the build instructions your easy version, some blog posts and so on.
There is no single place where it says, this the pyx file it is going to become this C source file after running these lines with this tool. Then this tool will pick it up and create .obj and compile then it will dump stuff here, make sure it finds it there. All should be there to be compiled in one go. Also we can't use MSVC directly because  so we need a workaround and so on
Compilation is laborious, fully agree, but seriously not that complicated if you lay down the steps. Essentially one should be able to unroll what meson does behind the scenes line by line, but I couldn't manage to do that after trying too many times and we have no documentation to see which step exactly trips up. But anyways just my experience. It doesn't mean others have the same experience.

I did check my own most recent edits to one set of instructions carefully - did you try those? Did they work as expected?

Did not work with Python 3.9

What happened with Python 3.9?
I agree, it's rather hard to work out what Meson is doing, but I would argue that it's not nearly as hard as working out what Distutils is doing.
The trick, I found, is to get used to looking at the ninja.build file and the compilation logs.  Not trivial, but I found I could unstick myself after a while (including some time being very unsure I could unstick myself).
@rgommers - any comments / tips you'd like to add?

What happened with Python 3.9?

This whole kerfuffle was with Python 3.9 and using recent compilers (my suspicion of what is going on in hindsight, I might be wrong).

I agree, it's rather hard to work out what Meson is doing, but I would argue that it's not nearly as hard as working out what Distutils is doing.

Yes totally agree. That was just a hopeless situation.

The trick, I found, is to get used to looking at the ninja.build file and the compilation logs.

I did started looking into it but then quickly went over my head. Most of these compilation-related tools are notoriously bad at telling what they are doing even though they paint the terminal for about a kilometer down.

The basic problem here seems to be: setting up a build environment with the correct compilers on Windows is very difficult. I think this has always been the case, and is only going to improve if we are able to get rid of long double or Fortran. Not impossible, but another heavy lift.

The trick, I found, is to get used to looking at the ninja.build file and the compilation logs.

You shouldn't even have to look at the logs, that's one thing I quite like - introspection capabilities are very good. build.ninja is one, meson introspect is the other. I had documented the latter in the original build scripts, but it hasn't transferred to the html docs. Rather than expand on it here, let me open a PR to add it to http://scipy.github.io/devdocs/dev/contributor/meson_advanced.html
The way I look at build.ninja is to search for a name of the extension module of interest
# These rules are usually not needed to understand the problem, but can be looked up at the top of the file:
rule c_COMPILER
 command = arm64-apple-darwin20.0.0-clang $ARGS -MD -MQ $out -MF $DEPFILE -o $out -c $in
 deps = gcc
 depfile = $DEPFILE_UNQUOTED
 description = Compiling C object $out

rule c_LINKER
 command = arm64-apple-darwin20.0.0-clang $ARGS -o $out $in $LINK_ARGS
 description = Linking target $out

# Say we're interested in an extension written in Cython, e.g. _decomp_update.pyx
# Then I just open build.ninja with a text editor and search for the name. Here are the build rules,
# ignoring DEPFILE and DEPFILE_UNQUOTED lines (those are usually not interesting):

# step 1: `.pyx.in` to `.pyx` code generation with Tempita
build scipy/linalg/_decomp_update.pyx: CUSTOM_COMMAND ../scipy/linalg/_decomp_update.pyx.in | ../scipy/_build_utils/tempita.py /Users/rgommers/mambaforge/envs/scipy-dev/bin/python3.9
 COMMAND = /Users/rgommers/mambaforge/envs/scipy-dev/bin/python3.9 ../scipy/_build_utils/tempita.py ../scipy/linalg/_decomp_update.pyx.in -o scipy/linalg
 description = Generating$ scipy/linalg/_decomp_update$ with$ a$ custom$ command

# step 2: `.pyx` to `.c` compilation with Cython
build scipy/linalg/_decomp_update.cpython-39-darwin.so.p/_decomp_update.c: CUSTOM_COMMAND scipy/linalg/_decomp_update.pyx | /Users/rgommers/code/scipy/scipy/_build_utils/cythoner.py scipy/__init__.py scipy/linalg/__init__.py scipy/linalg/cython_blas.pyx
 DESC = Generating$ 'scipy/linalg/_decomp_update.cpython-39-darwin.so.p/_decomp_update.c'.
 COMMAND = /Users/rgommers/mambaforge/envs/scipy-dev/bin/python3.9 /Users/rgommers/code/scipy/scipy/_build_utils/cythoner.py scipy/linalg/_decomp_update.pyx scipy/linalg/_decomp_update.cpython-39-darwin.so.p/_decomp_update.c

# step 3: use C compiler to go from `.c` to object file (`.o`)
build scipy/linalg/_decomp_update.cpython-39-darwin.so.p/meson-generated__decomp_update.c.o: c_COMPILER scipy/linalg/_decomp_update.cpython-39-darwin.so.p/_decomp_update.c
 ARGS = -Iscipy/linalg/_decomp_update.cpython-39-darwin.so.p -Iscipy/linalg -I../scipy/linalg -I/Users/rgommers/mambaforge/envs/scipy-dev/lib/python3.9/site-packages/numpy/core/include -I/Users/rgommers/mambaforge/envs/scipy-dev/include/python3.9 -fvisibility=hidden -fcolor-diagnostics -Wall -Winvalid-pch -std=c99 -O2 -g -Wno-unused-function -Wno-conversion -Wno-misleading-indentation -Wno-incompatible-pointer-types -Wno-cpp

# step 4: generate a symbol file (uses `meson --internal symbolextractor`); you can safely ignore this step
build scipy/linalg/_decomp_update.cpython-39-darwin.so.p/_decomp_update.cpython-39-darwin.so.symbols: SHSYM scipy/linalg/_decomp_update.cpython-39-darwin.so
 IMPLIB = scipy/linalg/_decomp_update.cpython-39-darwin.so

# step 5: link the `.o` file to obtain the file extension module (`.so`)
build scipy/linalg/_decomp_update.cpython-39-darwin.so: c_LINKER scipy/linalg/_decomp_update.cpython-39-darwin.so.p/meson-generated__decomp_update.c.o
 LINK_ARGS = -L/Users/rgommers/mambaforge/envs/scipy-dev/lib -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,dynamic_lookup -bundle -Wl,-undefined,dynamic_lookup -lm -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,/Users/rgommers/mambaforge/envs/scipy-dev/lib

This is already not the simplest example, because it uses a Tempita template so there's a codegen step. But it seems pretty understandable what is going on.
It looks to me like this kind of understanding wouldn't have helped too much in this particular issue though, because the problem seems to not be with any of these steps but with some weirdness in the compiler/environment itself.

Docs PR opened: gh-16931


Javascript p.register args NickName is safe?

Hi,
First My devel stack is .NET But this question is client api...
If this issue is Unmatched repo. guide to right repo please 😁
Question.
Javascript p.register args NickName is safe?
That's mean i understand set NickName is client only action. no server valid check....
i known...
Bitwarden guys all security expert!
under my question is yours view baby level question... haha 😅
sample code.
<input id="nickname" type="text" name="nickname" maxlength="50" />
<input type="button" value="Register Now" onclick="RegisterNow();" />

async function RegisterNow() {
  var nickName = document.getElementById('nickname').value;
  var p = new Passwordless.Client({ ... });

  // ...
  // Call my defined web api, get register token
  // - /GetRegisterToken.aspx
  // (** transfer with NickName to web api. but NickName is no response client)
  // Response JSON
  // { "statusCode" : "OK", "registerToken" : "..." ... }
  //var registerToken = resp.registerToken;
  // ...
  var regiResult = await p.register(registerToken, nickName);
  // ...
}

Make situation.
Bad guy NickName value write web attack code (ex, XSS)
use Chrome DevTools or ...
  //var regiResult = await p.register(registerToken, nickName);
  var nickName_BADGUY_REWRITE_VALUE_IS_BAD_CODE = '...';
  var regiResult = await p.register(registerToken, nickName_BADGUY_REWRITE_VALUE_IS_BAD_CODE);
}

After web app login using passkey.
go to my page get credentials list.
GET https://v4.passwordless.dev/credentials/list?userId=GUID HTTP/1.1
ApiSecret: ...

And response JSON in NickName value is safe?
or value is unsafe. but Bitwarden make scenario under safe.
that's mean credentials list is my account credentials.
other don't view this credentials.
register time, write bad nickname, and get credentials list response JSON bad NickName. self attack?
More question.
Nickname. passwordless.dev admin dashboard view list users time.
web browser display nickname is safe?
Please answer 😀
Thanks.

Hello @kjyoffice!
Thank you for your detailed question.
For all user input, I would recommend you to encode it properly depending on where you will render it, e.g. if you want to render it in HTML, you should HtmlEncode it. If you want to pass it as part of a URL, you need to UrlEncode it. If you want to make it part of a DB query you need to encode it properly or use whatever tools is offered, e.g. sql parameters.
We currently do not try to encode it to make itself for all these scenarios and we should make sure this is appropriately documented and perhaps add a default encoding.


when "repeated field items has nil element" occur, protobuf send data will timeout

Hello:
when I set response a array, and array has only on element, and this element is nil, it will occur "repeated field items has nil element" error, and when this error occur, protobuf send data will timeout, can you help me?
Thank you very much.

I have the same problem, did you find a solution?

@wednesdaysunny  You may need to post out your source then people can see what's going on here?

Closing issue as stale. There is insufficient information to address this. If you have a reproduction, file a new issue. Thanks.

I had the same problem.
I built a sample at https://github.com/ryanking8215/pb_nil_element

Repeated fields aren't allowed to contain nil messages, and many operations (Marshal, probably others) will panic if they encounter one.
The v2 API does permit nil values in repeated message fields, but until it is released you'll need to avoid them.

@neild

The v2 API does permit nil values in repeated message fields, but until it is released you'll need to avoid them.

Is there documentation about that change somewhere, like a roadmap?


Color in the format string is not propagated

Hi,
I tried to add color to the format string for defmt_decoder in probe-rs to make it more readable, but the color specification on the string did not propagate properly.
Here is the testing PR in probe-rs: https://github.com/probe-rs/probe-rs/pull/2063
This would help readability a lot. Is there someway to make this happen or does defmt_decoder need extension?
This also broke in probe-run v0.3.9 -> v0.3.10 where the file info part of the printing got the color wrong.
probe-run v0.3.9:

probe-run v0.3.10 and probe-rs run:

There was a new release on 05.02.2024. Can you check if it works now?

I just tried {L} {s} ({f:dimmed}) and with the current defmt release behaves as expected.


[Src && Example && CI/CD] Make it adapt to UNIX, fix some bugs and implement RPC module

Purpose

Make it correct in UNIX.
Develop RPC module based on Protobuf.

Changes

Fix wrong spells in comments.
Fix some bugs which make some examples crush in UNIX (e.g. Poller (UNIX)). It is about race condition.
Fix bugs in Logger. It is about race condition.
Implement RPC module including RpcChannel, RpcCodec and RpcServer.
Develop a RPC demo (Time Service) using RPC module.
Add dependencies for installing Protobuf in CI/CD configuration files.

Review Instructions

Read the code modified.
Adapting to UNIX failed.

lgtm


Fix add-users script

Fixes the issue where sometimes the add-users script would not work because it would error out and exit before chown or chmod all the files it was supposed to.
One case I found for this is when a users home directory had no files the xargs command would fail.
Changes that happened:

Clean up the Dockerfile a little bit, and update README
Fix find and xargs commands in add-users script

add -r to xargs to not process empty arguments passed to it (when no files in users home directory)
add -mindepth option to find to only look at files/folders in the users home directory
fix typo in Directory permissions variable

Added changes discussed in comments in 969e2f5bba2379a39fe901591d0e9b11f4272dc7
Added log files for services in supervisor

Hey @ndigati, can we merge this PR?
Thanks for doing this docker image 👍
This is the perfect use case for my ip camera using a s3 bucket 🙏


Move AppUI specific types from appui-abstract to appui-react

This PR moves AppUI specific types from @itwin/appui-abstract to @itwin/appui-react.

Note new deprecation format mentionned by https://github.com/iTwin/itwinjs-core/pull/4907/files

@jason-crow @jjbeckman13 @kckst8 @johnnyd710
Hey guys, would you mind taking a pass at this too as representatives from the product team and make sure we don't inadvertently break you guys


Clarify lambda positioning

This is to help resolve an inconsistency in the report at https://github.com/fsprojects/fantomas/issues/1189 .

@Smaug123 this is a good first example. I do have some follow-up questions on this, I'll get back on this later this week.

I'm guessing this also applies when no infix operators are involved?
let printListWithOffset a list1 =
    List.iter (
        ((+) a)
        >> printfn "%d"
    ) list1

Is list1 after the )?
What happens if there is an extra argument before the parenthesis?
Example:
let mySuperFunction a =
    someOtherFunction a (fun b ->
        // doing some stuff her
       b * b
    )

Did I assume correctly that the lambda is one further indented?
What happens when there a two multiline lambda's?
let mySuperFunction v =
    someOtherFunction (fun  a  ->
          let meh = "foo"
          a
     )  (fun b ->
              // probably wrong
              42
     ) v

I think your examples are right except for the last one where there's too much indentation:
let mySuperFunction v =
    someOtherFunction (fun  a  ->
        let meh = "foo"
        a
     ) (fun b ->
        // probably wrong
        42
     ) v

But I am toying instead with:
let mySuperFunction v =
    someOtherFunction
        (fun  a  ->
            let meh = "foo"
            a
         )
        (fun b ->
            // probably wrong
            42
         )
        v

which at least generalises nicely to having arbitrary small arguments (e.g. we could move v one argument place earlier and it would be obvious what should happen).

I like the
let mySuperFunction v =
    someOtherFunction
        (fun  a  ->
            let meh = "foo"
            a
        )
        (fun b ->
            // probably wrong
            42
        )
        v

the idea, I'll ask some questions along the way to nail down the patterns that Fantomas would need to respect.

@JackMatusiewiczGR Mind approving this again? I didn't know we had stale review dismissal enabled.

@Smaug123 how would
lambdaList
|> List.map (function
    | Abs(x, body) -> 1 + sizeLambda 0 body
    | App(lam1, lam2) -> sizeLambda (sizeLambda 0 lam1) lam2
    | Var v -> 1)

look like in this case?

That structure is a little awkward. Personally I format it as:
lambdaList
|> List.map (
    function
    | Abs(x, body) -> 1 + sizeLambda 0 body
    | App(lam1, lam2) -> sizeLambda (sizeLambda 0 lam1) lam2
    | Var v -> 1
)

But I recognise this rule is rather ugly in how specific it is. (In this case only, I put function on a new line indented one scope, so that the indentation rules for the pattern match don't look absolutely mad.)
This doesn't really come up in GR's code, I think.


Support BBR congestion algorithm

Reference to https://github.com/quic-go/quic-go/issues/341 and https://github.com/quic-go/quic-go/pull/1888
This PR implements the BBR congestion algorithm.
For reference only.
BBR Version:  https://github.com/google/quiche/blob/e7872fc9e12bb1d46a118949c3d4da36de58aa44/quiche/quic/core/congestion_control/bbr_sender.cc

Source File
Performance

utils/ringbuffer.go
100%

utils/ringbuffer_test.go
100%

utils/windowed_filter.go
100%

utils/windowed_filter_test.go
100%

congestion/packet_number_indexed_queue.go
100%

congestion/packet_number_indexed_queue_test.go
100%

congestion/bandwidth_sampler.go
100%

congestion/bandwidth_sampler_test.go
100%

congestion/bbr_sender.go
100%

congestion/bbr_sender_test.go
30%

bbr version:  https://github.com/google/quiche/blob/e7872fc9e12bb1d46a118949c3d4da36de58aa44/quiche/quic/core/congestion_control/bbr_sender.cc

In WIFI 433Mbps network environment, use BBR congestion algorithm can up to 13MiB/s but CUBIC can only up to 6Mib/s
perf % go run cmd/main.go --upload-bytes=1\000\000\000 --download-bytes=1\000\000\000 --server-address=xxx
2023/08/30 14:23:09 uploaded 953.7 MiB: 155.20s (6.1 MiB/s)
2023/08/30 14:23:09 downloaded 953.7 MiB: 68.04s (14.0 MiB/s)
{"latency":223.251678209}

perf % branch:[master]% go run cmd/main.go --upload-bytes=1\000\000\000 --download-bytes=1\000\000\000 --server-address=xxx --use-bbr
2023/08/30 14:25:55 uploaded 953.7 MiB: 72.91s (13.1 MiB/s)
2023/08/30 14:25:55 downloaded 953.7 MiB: 69.68s (13.7 MiB/s)
{"latency":142.597904583}

In Wi-Fi 433Mbps network environment, use BBR congestion algorithm can up to 13MiB/s but CUBIC can only up to 6MiB/s
perf % go run cmd/main.go --upload-bytes=1\000\000\000 --download-bytes=1\000\000\000 --server-address=xxx
2023/08/30 14:23:09 uploaded 953.7 MiB: 155.20s (6.1 MiB/s)
2023/08/30 14:23:09 downloaded 953.7 MiB: 68.04s (14.0 MiB/s)
{"latency":223.251678209}

perf % go run cmd/main.go --upload-bytes=1\000\000\000 --download-bytes=1\000\000\000 --server-address=xxx --use-bbr
2023/08/30 14:25:55 uploaded 953.7 MiB: 72.91s (13.1 MiB/s)
2023/08/30 14:25:55 downloaded 953.7 MiB: 69.68s (13.7 MiB/s)
{"latency":142.597904583}

Is this BBRV2 or BBRV3?

@aggresss Thanks for your amazing work. However I believe there's a serious bug when using this over localhost connections (at least on Windows):
Steps to reproduce the problem:.

Create a large random file (say 100MB) in a directory.
Go to the example directory and run the quic-go example server with the command:go run . -b -www C:\dir\to\random\

Change to the `example\client' directory:go run . -q -insecure https://<IP_ADDRESS>:6121/random_file

Observations:.

On both of my Windows PCs, the connection hangs indefinitely, blocking the transfer of the file.
CPU usage also spikes to very high load while the connection is hanging.

I've tried debugging, but to no avail. I suspect this problem is due to the low latency or some other properties of localhost that make the code run into some edge cases. (This bug is NOT seen with the default cubic congestion control)
I'm the developer of Hysteria, a QUIC-based proxy project, and I'm very interested in integrating your BBR implementation. If you are interested, we can work together to further debug this bug.

So I did some more tests, and it appears that the connection hanging issue also exists for cubic, using the latest code from master not this fork. Interestingly, I can only reproduce this issue when using a Windows machine as the server and a Linux machine as the client (using the same example code from quic-go as mentioned above). When the roles are reversed, the problem doesn't seem to occur. Also the CPU spikes/deadlock appear on the client side, NOT on the server (sender) side.
I will investigate this further, and maybe @marten-seemann can try to reproduce it?

Alloc & CPU pprof files of the server (during connection hanging & CPU 100%) are attached.
Showing nodes accounting for 7702.53MB, 99.90% of 7710.56MB total
Dropped 20 nodes (cum <= 38.55MB)
      flat  flat%   sum%        cum   cum%
 7702.03MB 99.89% 99.89%  7702.03MB 99.89%  github.com/quic-go/quic-go.init.0.func1
    0.50MB 0.0065% 99.90%  7708.54MB   100%  github.com/quic-go/quic-go.(*connection).run
         0     0% 99.90%  7708.04MB   100%  github.com/quic-go/quic-go.(*connection).maybeSendAckOnlyPacket
         0     0% 99.90%  7708.04MB   100%  github.com/quic-go/quic-go.(*connection).triggerSending
         0     0% 99.90%  7708.04MB   100%  github.com/quic-go/quic-go.(*packetPacker).PackAckOnlyPacket
         0     0% 99.90%  7708.04MB   100%  github.com/quic-go/quic-go.getPacketBuffer (inline)
         0     0% 99.90%  7708.04MB   100%  sync.(*Pool).Get

This triggerSending -> maybeSendAckOnlyPacket code path allocated nearly 8GB of memory in 15 seconds.
Duration: 15.13s, Total samples = 15.46s (102.20%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 7990ms, 51.68% of 15460ms total
Dropped 214 nodes (cum <= 77.30ms)
Showing top 10 nodes out of 142
      flat  flat%   sum%        cum   cum%
    1520ms  9.83%  9.83%     1520ms  9.83%  runtime.stdcall2
    1400ms  9.06% 18.89%     1400ms  9.06%  runtime.stdcall1
    1400ms  9.06% 27.94%     1400ms  9.06%  runtime.stdcall4
     680ms  4.40% 32.34%      680ms  4.40%  runtime.unlock2
     620ms  4.01% 36.35%      620ms  4.01%  runtime.stdcall6
     610ms  3.95% 40.30%     1350ms  8.73%  runtime.selectgo
     580ms  3.75% 44.05%     2030ms 13.13%  runtime.lock2
     450ms  2.91% 46.96%      450ms  2.91%  runtime._ExternalCode
     400ms  2.59% 49.55%      400ms  2.59%  runtime.procyield
     330ms  2.13% 51.68%      330ms  2.13%  runtime.memclrNoHeapPointers

pprof-alloc.pb.gz
pprof-cpu.pb.gz
@marten-seemann You might be interested in this, as I can confirm the built-in cubic also has this problem, although the way it is triggered is slightly different. See the post above.

@tobyxdd @zengxiaobai
I have fixed the issue mentioned above and rebase the commit on v0.45.0

Thank you for the PR. Unfortunately, we won't be able to merge a 4000 LOC change. I've opened #4565 to track BBRv3 support.

Thank you for the PR. Unfortunately, we won't be able to merge a 4000 LOC change. I've opened #4565 to track BBRv3 support.

The performance of cubic in high latency networks is indeed unsatisfactory, so if this PR can play a driving role, it is also very good.


Remove unnecessary callout_is_default checks

Since all the callouts are considered default headers, then there is no point in doing the grpc_static_callout_is_default check. Removing this should save some per-RPC performance.

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                             ++++++++++++++

 -------------- SHRINKING                                                                           --------------
  -0.0%    -160 [None]                                                                              -7.14Ki  -0.1%
      -0.0%    -104 [Unmapped]                                                                          -7.12Ki  -0.1%
      -3.0%     -32 [None]                                                                                0  [ = ]
      [DEL]     -24 grpc_static_callout_is_default                                                          -24  [DEL]
  -1.4%     -32 src/core/lib/transport/metadata_batch.cc                                                -32  -1.4%
      -7.1%     -19 maybe_link_callout                                                                      -19  -7.1%
      -9.8%     -16 maybe_unlink_callout(grpc_metadata_batch*, grpc_linked_mdelem*) [clone .isra.3]         -16  -9.8%

  -0.0%    -192 TOTAL                                                                               -7.17Ki  -0.1%

****************************************************************

libgrpc++.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -120  -0.0%

  [ = ]       0 TOTAL     -120  -0.0%

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                             ++++++++++++++

 -------------- SHRINKING                                                                           --------------
  -0.0%    -160 [None]                                                                              -7.14Ki  -0.1%
      -0.0%    -104 [Unmapped]                                                                          -7.12Ki  -0.1%
      -3.0%     -32 [None]                                                                                0  [ = ]
      [DEL]     -24 grpc_static_callout_is_default                                                          -24  [DEL]
  -1.4%     -32 src/core/lib/transport/metadata_batch.cc                                                -32  -1.4%
      -7.1%     -19 maybe_link_callout                                                                      -19  -7.1%
      -9.8%     -16 maybe_unlink_callout(grpc_metadata_batch*, grpc_linked_mdelem*) [clone .isra.3]         -16  -9.8%

  -0.0%    -192 TOTAL                                                                               -7.17Ki  -0.1%

****************************************************************

libgrpc++.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -120  -0.0%

  [ = ]       0 TOTAL     -120  -0.0%

****************************************************************

libgrpc.so

     VM SIZE                                                                                FILE SIZE
 ++++++++++++++ GROWING                                                                             ++++++++++++++

 -------------- SHRINKING                                                                           --------------
  -0.0%    -160 [None]                                                                              -7.14Ki  -0.1%
      -0.0%    -104 [Unmapped]                                                                          -7.12Ki  -0.1%
      -3.0%     -32 [None]                                                                                0  [ = ]
      [DEL]     -24 grpc_static_callout_is_default                                                          -24  [DEL]
  -1.4%     -32 src/core/lib/transport/metadata_batch.cc                                                -32  -1.4%
      -7.1%     -19 maybe_link_callout                                                                      -19  -7.1%
      -9.8%     -16 maybe_unlink_callout(grpc_metadata_batch*, grpc_linked_mdelem*) [clone .isra.3]         -16  -9.8%

  -0.0%    -192 TOTAL                                                                               -7.17Ki  -0.1%

****************************************************************

libgrpc++.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -120  -0.0%

  [ = ]       0 TOTAL     -120  -0.0%

[trickle] No significant performance differences

[trickle] No significant performance differences

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,961,043      Total (<)      1,961,099

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,883,490      Total (<)     10,883,610

 No significant differences in binary sizes

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,961,043      Total (<)      1,961,099

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,883,487      Total (<)     10,883,608

 No significant differences in binary sizes

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,961,043      Total (<)      1,961,099

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,883,491      Total (<)     10,883,605

 No significant differences in binary sizes

Bazel TSAN build for C/C++ flake: #16665

Interestingly, this basically reverts the changes I made in 9e3a19e as part of #12298.  I added that commit at Craig's suggestion to allow for the future possibility of having a static metadata element that does prevent the chttp2 server from sending a Trailers-Only response (i.e., an element that we want to be static because it's common enough even though it's not something we generate internally).
In any case, I'm fine with this if there's a real performance win.


4.0.14+ sometimes fail to save spectra

Not sure what caused this, but it has been addressed by #282.
When someone comes back with an error message, then we reopen the issue.


Screenshots contain non-microsoft application names

The screenshots in this document need to be updated to hide the non-microsoft application names (spector.exe)  or new screenshots need to be captured.

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

ID: d1b44cc6-3534-3e62-e8db-736bba57b110
Version Independent ID: d1b44cc6-3534-3e62-e8db-736bba57b110
Content: Performance tracing and analysis with WPA - Mixed Reality
Content Source: mixed-reality-docs/mr-dev-docs/develop/advanced-concepts/hololens-performance-tracing-howto.md
Product: mixed-reality
Technology: mr-dev
GitHub Login: @typride
Microsoft Alias: tmilligan

Resolved and merged!
https://github.com/typride/mixed-reality-pr/pull/1


New version: AlekseyHoffman.Sigma-File-Manager version 1.7.0

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[ ] Have you tested your manifest locally with winget install --manifest <path>?
[X] Does your manifest conform to the 1.4 schema?

https://github.com/microsoft/winget-pkgs/pull/97103#issuecomment-1586293726
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/109710&drop=dogfoodAlpha

@OfficialEsco Thank you very much


PubTest: Add a lockfile for dart-http

To avoid having to frequently update the expected results for the
dart-http test case add a lockfile for the project.
Because it cannot be added to the repository of the external project, add it
to the parent directory and copy it to the project directory when executing
the test.

/rebase


Fix github page workflow

Description
Please include a summary of changes, motivation and context for this PR.
@anutosh491  The Github page workflow was broken when we stopped using condas emsdk. This PR should fix that.
Fixes # (issue)
Type of change
Please tick all options which are relevant.

[ ] Bug fix
[ ] New feature
[ ] Added/removed dependencies
[ ] Required documentation updates

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 80.80%. Comparing base (4439505) to head (afa6720).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #191      +/-   ##
==========================================
- Coverage   81.10%   80.80%   -0.31%
==========================================
  Files          19       19
  Lines         974      974
  Branches       93       93
==========================================
- Hits          790      787       -3
- Misses        184      187       +3

see 1 file with indirect coverage changes
see 1 file with indirect coverage changes


proc-macro-error is unmaintained

c.f. https://github.com/rustsec/advisory-db/pull/2057
utoipa> osv-scanner --lockfile Cargo.lock
Scanned /home/jayvdb/rust/utoipa/Cargo.lock file and found 344 packages
╭───────────────────────────────────┬──────┬───────────┬──────────────────┬─────────┬────────────╮
│ OSV URL                           │ CVSS │ ECOSYSTEM │ PACKAGE          │ VERSION │ SOURCE     │
├───────────────────────────────────┼──────┼───────────┼──────────────────┼─────────┼────────────┤
│ https://osv.dev/RUSTSEC-2024-0370 │      │ crates.io │ proc-macro-error │ 1.0.4   │ Cargo.lock │
╰───────────────────────────────────┴──────┴───────────┴──────────────────┴─────────┴────────────╯

https://github.com/GnomedDev/proc-macro-error-2 is the recommended alternative

ugh, it appears to be coming into the lock file but isnt in the utoipa dep tree, and cargo-deny is smart enough to know this, but osv-scanner is not
> cargo deny check advisories
2024-09-05 23:33:00 [WARN] unable to find a config path, falling back to default config
advisories ok

This dep is coming into the lock file via rust_decimal, via borsh which directly depends on the problem crate, and I have raised https://github.com/Kyuuhachi/syn_derive/issues/4 .
I think this wont affect many utoipa uses, and there is nothing utoipa can do to fix it, so closing.


updated video player 0.7.5

has Exception
I/dalvikvm( 5366): Could not find method android.graphics.SurfaceTexture.setOnFrameAvailableListener, referenced from method io.flutter.view.FlutterView$SurfaceTextureRegistryEntry.
W/dalvikvm( 5366): VFY: unable to resolve virtual method 697: Landroid/graphics/SurfaceTexture;.setOnFrameAvailableListener (Landroid/graphics/SurfaceTexture$OnFrameAvailableListener;Landroid/os/Handler;)V
D/dalvikvm( 5366): VFY: replacing opcode 0x6e at 0x0015
E/flutter ( 5366): [ERROR:flutter/shell/platform/android/platform_view_android_jni.cc(40)] java.lang.NoSuchMethodError: android.graphics.SurfaceTexture.setOnFrameAvailableListener
E/flutter ( 5366): 	at io.flutter.view.FlutterView$SurfaceTextureRegistryEntry.(FlutterView.java:969)
E/flutter ( 5366): 	at io.flutter.view.FlutterView.createSurfaceTexture(FlutterView.java:955)
E/flutter ( 5366): 	at io.flutter.plugins.videoplayer.VideoPlayerPlugin.onMethodCall(VideoPlayerPlugin.java:291)
E/flutter ( 5366): 	at io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:191)
E/flutter ( 5366): 	at io.flutter.view.FlutterNativeView.handlePlatformMessage(FlutterNativeView.java:163)
E/flutter ( 5366): 	at android.os.MessageQueue.nativePollOnce(Native Method)
E/flutter ( 5366): 	at android.os.MessageQueue.next(MessageQueue.java:138)
E/flutter ( 5366): 	at android.os.Looper.loop(Looper.java:150)
E/flutter ( 5366): 	at android.app.ActivityThread.main(ActivityThread.java:5323)
E/flutter ( 5366): 	at java.lang.reflect.Method.invokeNative(Native Method)
E/flutter ( 5366): 	at java.lang.reflect.Method.invoke(Method.java:515)
E/flutter ( 5366): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:828)
E/flutter ( 5366): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:644)
E/flutter ( 5366): 	at dalvik.system.NativeStart.main(Native Method)
E/flutter ( 5366):
F/flutter ( 5366): [FATAL:flutter/shell/platform/android/platform_view_android_jni.cc(77)] Check failed: CheckException(env).
F/libc    ( 5366): Fatal signal 6 (SIGABRT) at 0x000014f6 (code=-6), thread 5366 (ive.mysterylive)
handle_request(15)

There is no video_player v0.7.5. Even if, this sounds like a video_player related issue so you should post the issue in the package's GitHub.

I am closing this. Please reopen if you think this has something todo with chewie.


New-AzResourceGroupDeployment -TemplateFile my.bicep fails

Bicep version
Bicep CLI version 0.3.1 (d0f5c9b164)
Describe the bug
A clear and concise description of what the bug is vs what you expected to happen
To Reproduce
Install az module
install bicep
make a new bicep file and put in any bicep resource
new-azresourgroupdeployment -TemplateFile my.bicep -resourcegroupname -my-rg

the bicep file
resource stg 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'alexstorageone1'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

The error message:
PS C:\CreateWebapp\bicep2> New-AzResourceGroupDeployment -ResourceGroupName my-rg -TemplateFile ./simple.bicep -debug
DEBUG: 14:59:05 - NewAzureResourceGroupDeploymentCmdlet begin processing with ParameterSet 'ByTemplateFileWithNoParameters'.
DEBUG: 14:59:05 - using account id<EMAIL_ADDRESS>

Performing the operation "Creating Deployment" on target "my-rg".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): a
DEBUG: [Common.Authentication]: Authenticating using Account<EMAIL_ADDRESS>environment: 'AzureCloud', tenant: 'GUIDHERE'
DEBUG: SharedTokenCacheCredential.GetToken invoked. Scopes: [ https://management.core.windows.net//.default ] ParentRequestId:
DEBUG: SharedTokenCacheCredential.GetToken succeeded. Scopes: [ https://management.core.windows.net//.default ] ParentRequestId:  ExpiresOn: 2021-03-18T14:58:03.0000000+00:00
DEBUG: SharedTokenCacheCredential.GetToken invoked. Scopes: [ https://management.core.windows.net//.default ] ParentRequestId:
DEBUG: SharedTokenCacheCredential.GetToken succeeded. Scopes: [ https://management.core.windows.net//.default ] ParentRequestId:  ExpiresOn: 2021-03-18T14:58:03.0000000+00:00
DEBUG: [Common.Authentication]: Received token with LoginType 'User', Tenant: 'GUIDHERE', UserId<EMAIL_ADDRESS>New-AzResourceGroupDeployment: Unexpected character encountered while parsing value: r. Path '', line 0, position 0.
DEBUG: AzureQoSEvent: CommandName - New-AzResourceGroupDeployment; IsSuccess - False; Duration - 00:00:00.0517462; Exception - Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: r. Path '', line 0, position 0.
   at Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.ResourceManagerCmdletBase.HandleException(ExceptionDispatchInfo capturedException)
   at Microsoft.Azure.Commands.ResourceManager.Cmdlets.Implementation.ResourceManagerCmdletBase.ExecuteCmdlet()
   at Microsoft.WindowsAzure.Commands.Utilities.Common.CmdletExtensions.<>c__3`1.<ExecuteSynchronouslyOrAsJob>b__3_0(T c)
   at Microsoft.WindowsAzure.Commands.Utilities.Common.CmdletExtensions.ExecuteSynchronouslyOrAsJob[T](T cmdlet, Action`1 executor)
   at Microsoft.WindowsAzure.Commands.Utilities.Common.CmdletExtensions.ExecuteSynchronouslyOrAsJob[T](T cmdlet)
   at Microsoft.WindowsAzure.Commands.Utilities.Common.AzurePSCmdlet.ProcessRecord();
DEBUG: Finish sending metric.
DEBUG: 14:59:08 - NewAzureResourceGroupDeploymentCmdlet end processing.

Additional context
Dynamic properties are also not available.
Me and some of my colleagues all seem to be having the same issue.
PS C:\CreateWebapp\bicep2> bicep --version
Bicep CLI version 0.3.1 (d0f5c9b164)
PS C:\CreateWebapp\bicep2> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Performing a bicep build and then deploying the generated json file works fine.

Can you confirm that you have Az version 5.6.0 installed?
Get-InstalledModule -Name Az

PS C:\Users\AlexanderVanoosthuys> Get-Module az -ListAvailable

    Directory: C:\Program Files\PowerShell\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Script     5.6.0                 Az                                  Core,Desk

PS C:\Users\AlexanderVanoosthuys> Get-InstalledModule -Name Az

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
5.6.0                Az                                  PSGallery            Microsoft Azure PowerShell

@BethanyZhou - can you take a look at this one? I am not able to reproduce this.
@alexv-be is it possible you have multiple versions of Az installed?

Hi, faced with the same issue. I had Az modules 3.6.1 and 5.5.0 installed. After deleting them and restart vs code all is ok.
You can try to follow the same approach hope it will help.

So, turns out
same deal for my colleagues, $env:PSModulePath.ToString().Split(";") | Get-ChildItem | Where-Object -Property Name -Like "az.*" | Group-Object | Select-Object Name, count gave the output that some folders existed > once.
The new-azresourcegroupdeployment is a little on the sensitive side, but this can be closed I think?

Glad we figured it out! I have had issues in the past with multiple installs and my solution has always been deleting them all and starting over :) I'm far from an expert on this stuff though - there is probably a better way to handle it.


Minor fixes in migrating to modern redux documentation

name: :memo: Documentation Fix
about: Fixing a problem in an existing docs page
Checklist

[ ] Is there an existing issue for this PR? - No, due to minimal changes done in my opinion.  Please let me know if it is desired and I'd be happy to create one.
[ ] Have the files been linted and formatted?

What docs page needs to be fixed?

Sections

Overview
Store Setup with configureStore
Reducers and Actions with createSlice
Data Fetching with RTK Query
Reactive Logic with createListenerMiddleware
Migrating TypeScript for Redux Logic

Page

Migrating to Modern Redux

What is the problem?

Overview

Extra period at end of sentence, The good news is that you can migrate your code to modern Redux incrementally, piece by piece, with old and new Redux code coexisting and working together!..

Store Setup with configureStore

devTools field in configureStore options object uses sanitizeState when it doesn't exist in devToolsExtension.ts in redux toolkit and I believe is meant to be stateSanitizer.
Additionally, the ternary for setting the devTools field is syntactically incorrect since it is missing a colon and should probably use === instead of == for equality.

Reducers and Actions with createSlice

Extra period at end of sentence Redux Toolkit's createSlice API was designed to eliminate all the "boilerplate" with writing reducers, actions, and immutable updates!..
I believe that the todosSlice.js example is missing the state reference when attempting to "mutate" the todos list.
I believe that in the todoToggled, the usage of state.find should be state.todos.find to be correct.

Data Fetching with RTK Query

In todos.js example describing a saga example, the ../actions/todos import is missing a '.

Reactive Logic with createListenerMiddleware

I believe that in pingSlice.js, instead of ping being exported I believe it should be pong based on the createSlice method declared above.
Additionally, the actionCreator field in startListening should also be pong since ping is not a valid actionCreator.

Migrating TypeScript for Redux Logic

In the example src/app/store.ts describing anti-patterns, the line export const createStore(rootReducer) is invalid syntax since no reference is being specified.

What changes does this PR make to fix the problem?

Overview

Remove extra period at end of sentence.

Store Setup with configureStore

Changes sanitizeState field in devTools object to match field stateSanitizer in devtoolsExtension.ts in redux toolkit.
Updates import to match wording of field change for consistency.
Adds : to ternary used to set the devTools field in configureStore between options and updates equality operator from == to ===.

Reducers and Actions with createSlice

Removes extra period at end of sentence Redux Toolkit's createSlice API was designed to eliminate all the "boilerplate" with writing reducers, actions, and immutable updates!..
In the todosSlice.js example, I add the missing state reference when attempting to "mutate" the todos list.
In the todoToggled actionReducer, the usage of state.find is changed to be state.todos.find.

Data Fetching with RTK Query

Corrects import statement by adding ' in todos.js example describing a saga example, for the ../actions/todos import.

Reactive Logic with createListenerMiddleware

Changes the exported ActionReducer from ping to pong in pingSlice.js.
Changes the actionCreator field in startListening to be pong.

Migrating TypeScript for Redux Logic

Adds store reference to correct invalid syntax in the example src/app/store.ts describing anti-patterns on the line export const createStore(rootReducer).

PS
Huge thank you to @markerikson for recently creating this page!  It came just in time for me to learn about modern redux existing and start migrating my personal app to utilizing it from "old" redux core.

Hmm, is Prettier not checking .mdx files? I feel like it would have caught some of this.
Anyways, thanks!

Thanks!  (To be fair, I cranked the entire page in 5 hours of manic writing, including writing every single code sample from scratch. If that's all I screwed up, I think I did okay overall :)  )


Fix attempt - Handle unmuting channels with ":" in url

Supposed to fix issue number: #2587

Note:
Search acts bit strange if the same lbryUrl is in muted channels multiple times. Duplicated ones don't disappear when they should. (Had 4 times the DEADBUG Says in muted list)

Tested using index as a key in here, and above stopped from happening. But couldn't figure out a good way to make unique keys, so didn't do anything for it for now.  Guess this also pretty rare to happen.
In here -> https://github.com/OdyseeTeam/odysee-frontend/blob/master/ui/component/claimList/view.jsx#L442

Just realized I should probably make sure that claimId is actually the "full" claimId, so marking as draft for now.

The approach that Jessop took to handle # vs : is through
export function isURIEqual(uriA: string, uriB: string) {
  const a = uriA && uriA.replace(/:/g, '#');
  const b = uriB && uriB.replace(/:/g, '#');
  return a === b;
}

It's probably more robust than accessing [1] or search.
Maybe can take the reducer for subscriptions.js as reference.  Just need to find all places of uri-comparison, I think.

reduceUriToChannelName might be the culprit for the search problem.  The comment version was updated to handle #/: but the blocked list version did not.

Thanks for pointing out that way to do it! Will try with it.

Regarding the search thing, just to make sure we are talking about same thing. Did you also saw the text after the screenshot?
Also the "DEADBUG says" channel isn't included to props.uris for the ClaimList when the issue happens.  The 3 extra ones just kind of don't seem to disappear from the list when they should. And it's possible get more of them if the search term matches that channel.
dublicates.webm