[vcpkg-tool-meson] fix #41869

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[ ] The "supports" clause reflects platforms that may be fixed by this new version.
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Only fixes ports built with meson, not other ports that use python directly. adding a python._pyd file will also fix this issue. However, python._pyd will completely overwrite sys.path and ignore all relevant environment variables, which may cause new bugs

I don't remember which ports fail if this is commented.

The problem is you cannot properly install additional python packages.

Discussion in https://github.com/microsoft/vcpkg/pull/41871#discussion_r1823212205 is not resolved. Mentioning this here so that maintainers see it.

Discussion in #41871 (comment) is not resolved. Mentioning this here so that maintainers see it.

Have resolved. vcpkg_find_acquire_program(PYTHON3) not exist in vcpkg_install_meson now. because python could be send as additional_binary to vcpkg_configure_meson which could not be achieved by vcpkg_find_acquire_program(PYTHON3) in vcpkg_install_meson

for port gobject-introspection, it always use python in "D:\vcpkg\downloads\tools\python\python-3.12.7-x64\python.exe" as meson main binary. (loged in meson.log) Even I delete all vcpkg_find_acquire_program(PYTHON3) in port vcpkg-tools-meson.
however, the port gobject-introspection send "python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe'" as additional binary. This cause port failed.
Could anyone tell me how meson decide the main python binary.

for port gobject-introspection, it always use python in "D:\vcpkg\downloads\tools\python\python-3.12.7-x64\python.exe" as meson main binary. (loged in meson.log) Even I delete all vcpkg_find_acquire_program(PYTHON3) in port vcpkg-tools-meson. however, the port gobject-introspection send "python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe'" as additional binary. This cause port failed. Could anyone tell me how meson decide the main python binary.

Maybe gobject-introspection/portfile.cmake#L47.

for port gobject-introspection, it always use python in "D:\vcpkg\downloads\tools\python\python-3.12.7-x64\python.exe" as meson main binary. (loged in meson.log) Even I delete all vcpkg_find_acquire_program(PYTHON3) in port vcpkg-tools-meson. however, the port gobject-introspection send "python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe'" as additional binary. This cause port failed. Could anyone tell me how meson decide the main python binary.

Maybe gobject-introspection/portfile.cmake#L47.

No, this line is the additional binary mentioned in my question, but here python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe ', but the python I see based on the logs is "D:\vcpkg\downloads\tools\python\python-3.12.7-x64\python.exe"

the port gobject-introspection send "python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe'" as additional binary.

Ah, gobject-introspection, the port still waiting for proper cross-build support.
Why does it have to use the host python from the vcpkg port as an additional binary? A poor attempt to fix the original problem?

the port gobject-introspection send "python='D:/projects/test-vcpkg/build/vcpkg_installed/x64-windows/tools/python3/python.exe'" as additional binary.

Ah, gobject-introspection, the port still waiting for proper cross-build support. Why does it have to use the host python from the vcpkg port as an additional binary? A poor attempt to fix the original problem?

I just want this pr does not break other port. gobject-introspection is just a example. It exposes a problem that I'm having trouble understanding, which is how meson decide to use which python. In my original understanding, if a python is specified in the additional binary, then meson should use that python, and if not, find a python from the PATH, but this example disproves the above assumption. This may cause my logic for this pr to no longer be accurate.

I have a lot of python installed on my host, both python312 installed directly, and the installation of memba which comes with python. so without vcpkg intervention, I don't think meson should pick python under downloads by itself.
I tried to exclude the vcpkg_find_acquire_program( PYTHON3) interference, tried commenting out ports/vcpkg-tool-meson/vcpkg-port-config.cmake#L47, and since the code here is just checking to see if the python version is greater than 3.7, I think it's safe to temporarily comment it out.
After that I fixed the previously mentioned bug and got z_vcpkg_extract_python to work. Since the specified python can be detected from the additional binaries used by gobject-introspection, vcpkg_find_acquire_program(PYTHON3) in vcpkg_configure_meson is also not called, and PYTHON3 is specified to "${CURRENT_HOST_INSTALLED_DIR}/tools/python3/python${VCPKG_HOST_EXECUTABLE_SUFFIX}", PYTHON3_ DIR to "${CURRENT_HOST_INSTALLED_DIR}/tools/python3" and add it to the PATH
The appeal path is judged to be compliant, set the environment variable PYTHONHOME: "${CURRENT_HOST_INSTALLED_DIR}/tools/python3", export the cmake variable VCPKG_PYTHON3_DIR
The presence of VCPKG_PYTHON3_DIR is detected in vcpkg_install_meson, so set the environment variable PYTHONHOME
During the above process vcpkg_find_acquire_program(PYTHON3) was not called any more. But I found "Main binary: ${DOWNLOADS}/tools/python/pythonXXX/python.exe" in meson.log. Of course, since the PYTHONHOME is set to "${CURRENT_HOST_INSTALLED_DIR}/tools/python3", the build failed.
That's what happened to me last night.
In fact something happened before that struck me as odd. In a previous version of pr, vcpkg_add_to_path(PREPEND "${PYTHON3_DIR}") was placed in the if scope, which caused it to potentially not be executed. So ci did fail.
When I looked at the logs, I found that in vcpkg_install_meson, meson was complaining that it couldn't find python.
vcpkg_install_meson in this version of pr call neither vcpkg_find_acquire_program(PYTHON3) nor  vcpkg_add_to_path(PREPEND "${PYTHON3_DIR}"), so rightfully I assumed that it was the vcpkg_add_to_path(PREPEND "${PYTHON3_DIR}") in vcpkg_configure_meson that did the trick.
When I moved vcpkg_add_to_path(PREPEND "${PYTHON3_DIR}") out of the if scope, the error disappeared, which confirmed my suspicions. But I don't think that vcpkg_add_to_path(PREPEND "${PYTHON3_DIR}"), located in vcpkg_configure_meson, should work on another scope that is completely unrelated!
Tonight i will try again, do more research.

I found that in vcpkg_install_meson, meson was complaining that it couldn't find python.

meson running again in the build/install step (i.e. appearing in package-...log)? Maybe via an build/install rule...

vcpkg_configure_meson runs MESON which is actually "${PYTHON3}" meson.py.

scripts/cmake/vcpkg_find_acquire_program(MESON).cmake#L3 vcpkg_find_acquire_program(MESON) uses the cmake variable PYTHON3 as the interpreter for meson. So the order of vcpkg_find_acquire_program(MESON) and vcpkg_find_acquire_program(PYTHON3) is very important. To be more precise, PYTHON3 must be determined before calling vcpkg_find_acquire_program(MESON).

It is not meant to be necessary to set PYTHON3 before calling vcpkg_find_acquire_program(MESON). scripts/cmake/vcpkg_find_acquire_program(MESON).cmake#L3 sets the interpreter to PYTHON3, with the consequence that vcpkg_find_acquire_program() must also call vcpkg_find_acquire_program(PYTHON3). That's how this variables is initialized.
However I do agree that order is important:
Once PYTHON3 is initialized, it defines what is returned by vcpkg_find_acquire_program(PYTHON3).
Once MESON is initialized, it defines what which installation of python is used to run meson.

As a result, this python will be used in vcpkg_install_meson, even if neither vcpkg_find_acquire_program(PYTHON3) nor vcpkg_find_acquire_program(MESON) is used in vcpkg_install_meson

vcpkg_install_meson runs ninja runs build rules. The build rules define which python to use: absolute path as determined during configuration, or python3 via environment variable PATH if sloppy.

meson running again in the build/install step (i.e. appearing in package-...log)? Maybe via an build/install rule...

To anser my own question (from looking at pkgconf): Yes, there are rules which run meson (REGENERATE_BUILD, but also meson-internal__install as a dependency of install). These rule use an absolute path to python.

Regardless of the specific meson/python case, vcpkg_find_acquire_program(script_tool) will do an implicit vcpkg_find_acquire_program(interpreter).
vpckg-port-config.cmake is how some behaviors are changed along port dependencies. It is a tricky game. Now that you point at vcpkg-tool-meson's implementation:

Is it intentional that initializes PYTHON3 for downstream ports (main effect), or does it only want to check the version (side effect)?
If it is intentional, wouldn't this script be the natural home for additional python setup? (DRY.)

(I don't know.)

Regardless of the specific meson/python case, vcpkg_find_acquire_program(script_tool) will do an implicit vcpkg_find_acquire_program(interpreter).

是的，我看到这一行了 vcpkg_find_acquire_program.cmake#L81

Is it intentional that it initializes PYTHON3 for downstream ports (main effect), or does it only want to check the version (side effect)?

I think it's just trying to check the version. Expecting it to initialize downstream PYTHON3 is too subtle and exposes PYTHON3 to too big scope. Not to mention that calling vcpkg_find_acquire_program(PYTHON3) multiple times is no different than calling it once, and there's no need to call it again in vcpkg-configure-meson if it's intended.

@vipcxj could you please test https://github.com/microsoft/vcpkg/pull/41874?


feat(mimes): Make mimes illiterate

About the PR

I made mimes illiterate .
Why / Balance

Mimes are supposed to communicate with others through body language and gestures, However due to paper, players have gotten around this limitation by writing what they want to say on paper instead of on chat.
This creates an annoyance for others who are forced to read their writings.
I personally think its quite dumb for a person to choose mime, a character that is not supposed to talk, but talks anyways through paper.
Technical details

Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Screencast from 06-18-2024 06:30:58 PM.webm
Breaking changes

Changelog

:cl:

tweak: Mimes are now illiterate. Anything they write will be incomprehensible.

Should I make it so they can't read paper either?

Should I create an  illiterate, give it to mimes, and check for that instead of relying on mimepowers?

I like the idea. Monkeys and kobolts should definetely have this without cognizine. Maybe make it so that the letters are scrambled instead of just replacing it with question marks?

How would mimes fill out paperwork from HoP and such? Just, not?

Should I create an illiterate component, give it to mimes, and check for that instead of relying on mimepowers?

It should be a componenet and trait in my opinion. That way a player can choose if they want it and you can add it to animals.

should make them literate whenever they break their vow

How would mimes fill out paperwork from HoP and such? Just, not?

HoP would have to follow "the laws" and be more accommodating to those who are not able to communicate in traditional means.

should make them literate whenever they break their vow

I can do this.

Should I create an illiterate component, give it to mimes, and check for that instead of relying on mimepowers?

It should be a component and trait in my opinion. That way a player can choose if they want it and you can add it to animals.

What namespace would the illiterate component go into?

Yeah scrambling the letters would probably be better!

Yeah scrambling the letters would probably be better!

It scrambles now.
Added a video to the PR description

you also should make this a component instead of hardcoding it to mime powers

Have you checked what happens with markup text? You might need to sanitize it.
Here are some examples you could try.

Okay but what if I as a mime enjoy drawing on papers using written description ? that kind of ruins it
I do agree you shouldn't straight up ask things as a mime writing what you want on a paper, but forcing it like that ? Not certain that's the best way
thing I'm talking about:

Well, as long as mimes can still break their vow using the @laughs command, this is not preventing much. If some mimes don't follow rules why take away the writting priviledge for all mimes? However, I do agree this needs to be a component and a trait for who ever needs it, and built-in for animals without cognize ASAP.

trait for who ever needs it, and built-in for animals without cognize ASAP. Pun Pun shouldn't able to write!

that's an excellent point, it would be great use of that, and make a bit more sense. While pun still could draw ya know, not as well as a mime (or humanoid)

Also putting this, trying not to be a bloat for the PR but maybe just add their sensical point.

The trait itself would be great, have use and overall be nice but forced may not be the best bet

part of the problem is that most people have never seen a mime. the biggest problem is
job-description-mime = Entertain the crew through non-vocal means, and engage with light rivalry with the clown.
made a pr #29266 to tweak

Closed until I finish my PHD. Thesis


Package upgrade: dio 4.0.0 --> 4.0.4

Summary
Package upgrade: dio 4.0.0 --> 4.0.4
Changelog
[General] [Change] - Upgrade dio from 4.0.0 to 4.0.4 (changelog)
Test Plan
Regression test the following areas:
./lib/core/providers/speed_test.dart
./lib/app_networking.dart

Deferred


Create mapping between List and DataTable

Hi,
This is a fantastic library. It would be nice if we could map between List and DataTable and viceversa.
Thanks,

I think we can solve this by custom mapping. https://stackoverflow.com/questions/564366/convert-generic-list-enumerable-to-datatable


how to generate question automatically?

we can split articles into pieces and then convert them to embeddings using openAI.
However, how can we generate questions automatically?
we only have articles, we don't have questions. manually write?

That just need a little more logic, you can give ChatGPT some part of the content as context and ask him for questions. For more resonable questions, you will need to sample more content like a chapter or two and group them with clustering, then sample from each group to ask ChatGPT for questions

@hktxt added example code to generate question now


Script fails in netbox v3.3.9

2022-12-13 13:36:48,646 - INFO: Starting NetBox Sync v1.3.0 (2022-09-06)
2022-12-13 13:36:48,688 - INFO: Successfully connected to NetBox 'x.x.x.x'
2022-12-13 13:36:48,689 - INFO: Initializing sources
2022-12-13 13:36:48,792 - INFO: Successfully connected to vCenter SDK 'vcenter.abc.com'
2022-12-13 13:36:50,219 - INFO: Successfully connected to vCenter SDK 'vcenter.xyz.com'
2022-12-13 13:36:50,220 - INFO: Querying necessary objects from NetBox. This might take a while.
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/requests/models.py", line 910, in json
    return complexjson.loads(self.text, **kwargs)
  File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)
  File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 2 column 1 (char 1)

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "netbox-sync.py", line 145, in <module>
    main()
  File "netbox-sync.py", line 108, in main
    nb_handler.query_current_data(source.dependent_netbox_objects)
  File "path of the file", line 505, in query_current_data
    full_nb_data = self.request(nb_object_class)
  File "path of the file", line 328, in request
    result["results"].extend(response.json().get("results"))
  File "/usr/local/lib/python3.8/dist-packages/requests/models.py", line 917, in json
    raise RequestsJSONDecodeError(e.msg, e.doc, e.pos)
requests.exceptions.JSONDecodeError: [Errno Expecting value]
<!DOCTYPE html>

    <title>Server</title>
    <link rel="stylesheet" href="/static/netbox-light.css" />
    <meta charset="UTF-8">

                         Server

                                There was a problem with your request. Please contact an administrator.

                            The complete exception is provided below:

<class 'Ke'>

'decomissioned'
Python version: 3.10.6
NetBox version: 3.3.9

                            If further assistance is required, please post to the NetBox discussion forum on GitHub.

                            Home Page

: 1
The remote script failed with exit code 1
The action netbox-sync scheduled on a Worker failed

Script was running fine on previous version.
The user and token still exists.

Issue got resolved as custom field is missing in new version config file


Using other transitions, like moveOver

Hi, I went through the repository and saw some additional transitions like move-over and flex-grow.
I believe move-over is exactly what I need. I want to have the newView slide upwards, over the oldView, and then remove the oldView. In reverse, I'd like to have the newView be displayed under the oldView, and then animate the oldView downwards, so it reveals the newView from under it.
I tried using this with:
   ...
     this.use('moveOver', 'toUp')
   ...

but it doesn't work. There is no animation, the newView just appears over the oldView.
Any ideas? Thank you.

move-over slides both the old and new views together, so not what you want. There isn't a built in transition that does, but it should be very easy to add.
I suggest copying move-over into your own new transition and editing it to take out the part of the animation you don't want.
Since your case is not symmetric, you probably want two different transitions. One that slides the new view on top of the old, and one that puts the new view behind the old and slides the old away.

Ok, cool, i'll try and make my own transitions.

@tehmaestro: Did you end up making this type of transition? I'm looking to do the same thing.

Hi, I used a different transition in the end. But it really is super easy to create your own.


SleepAnalysis permission throws an authorization error

When linking healthkit I get an authorization error saying that we need at least one permission.
Code :
AppleHealthKit.initHealthKit( {
    read: [HKPERMISSIONS.SleepAnalysis],
  }, async (err, results) => {
    if (err) {
      console.log('error initializing Healthkit: ', err);
      return;
    }
});

healthkit version: ^0.7.3
react-native: 0.59.8
expo: 35.0.0
My FIX is:
changing the file RCTAppleHealthKit+TypesAndPermissions.m
 [HKObjectType quantityTypeForIdentifier:HKCategoryTypeIdentifierSleepAnalysis];

to this
[HKObjectType categoryTypeForIdentifier:HKCategoryTypeIdentifierSleepAnalysis];

Then it works totally fine.

This fixed it for me. Thanks, @abeeralshaer!
Perhaps you can make a PR?


bug: cannot accept new blocks after restoring node from dump

Problem
I'm running privnet with the current master and patch (66e7d98e0497781fa09b6817ed8de19527eb2509) with the 5th local node. I do the following steps:

Stop local node
Wait until 4 nodes will process one more block
Run local node

Result: local node cannot accept new blocks after restoring from dump:
neospcc@neospcc-ThinkPad-T590:~/Documents/GitProjects/nspcc-dev/neo-go$ ./bin/neo-go node -p
2020-09-28T14:05:26.373+0300	INFO	restoring blockchain	{"version": "0.1.0"}
2020-09-28T14:05:26.376+0300	INFO	starting rpc-server	{"endpoint": ":20331"}
2020-09-28T14:05:26.376+0300	INFO	service is running	{"service": "Prometheus", "endpoint": ":2112"}
2020-09-28T14:05:26.376+0300	INFO	service hasn't started since it's disabled	{"service": "Pprof"}
2020-09-28T14:05:26.376+0300	INFO	node started	{"blockHeight": 32, "headerHeight": 33}
2020-09-28T14:05:26.377+0300	INFO	new peer connected	{"addr": "<IP_ADDRESS>:20335", "peerCount": 1}
2020-09-28T14:05:26.377+0300	INFO	new peer connected	{"addr": "<IP_ADDRESS>:20336", "peerCount": 2}
2020-09-28T14:05:26.377+0300	INFO	new peer connected	{"addr": "<IP_ADDRESS>:20334", "peerCount": 3}
2020-09-28T14:05:26.378+0300	INFO	new peer connected	{"addr": "<IP_ADDRESS>:20333", "peerCount": 4}
2020-09-28T14:05:26.378+0300	INFO	started protocol	{"addr": "<IP_ADDRESS>:20335", "userAgent": "/NEO-GO:0.91.1-pre-237-g66e7d98e/", "startHeight": 66, "id":<PHONE_NUMBER>}
2020-09-28T14:05:26.379+0300	INFO	started protocol	{"addr": "<IP_ADDRESS>:20334", "userAgent": "/NEO-GO:0.91.1-pre-237-g66e7d98e/", "startHeight": 66, "id": 823238801}
2020-09-28T14:05:26.379+0300	INFO	started protocol	{"addr": "<IP_ADDRESS>:20336", "userAgent": "/NEO-GO:0.91.1-pre-237-g66e7d98e/", "startHeight": 66, "id":<PHONE_NUMBER>}
2020-09-28T14:05:26.380+0300	INFO	started protocol	{"addr": "<IP_ADDRESS>:20333", "userAgent": "/NEO-GO:0.91.1-pre-237-g66e7d98e/", "startHeight": 66, "id":<PHONE_NUMBER>}
2020-09-28T14:05:26.384+0300	WARN	blockQueue: failed adding block into the blockchain	{"error": "postPersist failed: VM has failed: error encountered at instruction 5 (SYSCALL): runtime error: index out of range [1] with length 0", "blockHeight": 32, "nextIndex": 33}
2020-09-28T14:05:26.386+0300	WARN	blockQueue: failed adding block into the blockchain	{"error": "postPersist failed: VM has failed: error encountered at instruction 5 (SYSCALL): runtime error: index out of range [1] with length 0", "blockHeight": 32, "nextIndex": 33}

Is OnPersistEnd called without previous Initialize?

IIUC, we do not call Initialize() for native contracts during restoring from dump.
BTW, this bug is caused by https://github.com/nspcc-dev/neo-go/blob/master/pkg/core/native/native_neo.go#L263, as pubs have length = 0.


Inject an Environment Variable that indicates the retry count

Inject an Environment Variable that indicates the retry count, maybe one for the max count too?
$RETRY_COUNT or $COUNT
This lets the script or command printout the attempt number or choose different options based on the count.

Good idea.
Is RETRY an established convention that something else uses? If it isn't, it makes sense to choose an environment variable name that matches the condition variable attempt. It is also probably best to "namespace" the variable with a unique prefix. That way it won't override a variable the user might want from the environment.
What would you say to RECUR_ATTEMPT? I could also pass RECUR_MAX_ATTEMPTS to the command.

I have implemented this in 3f134ca3944c10000ecd4fba9cb2536f148a14cb. Could you try it?


Update HRA info email address to .iu.edu and select which email address is correct to use

From this page https://github.com/x-atlas-consortia/hra-apps/tree/main/applications/ftu-explorer/, if you click on use FTU explorer and are directed to this page: https://apps.humanatlas.io/ftu-explorer/#/ in the upper right corner of the page it says "contact" and when you click on it, it opens a dialog page that lists<EMAIL_ADDRESS>which is different than the email address we use in the footer for all HRA pages "Contact HRA team" in portal which is<EMAIL_ADDRESS>Questions:

Which email address should be used for all official email for HRA?
a) We have a separate email account we set up which we had agreed to use and do use in the footer across all HRA portal pages "Contact HRA team" button<EMAIL_ADDRESS>b) On FTU explorer top right "contact" goes to<EMAIL_ADDRESS>(this is not specific to HRA)
Correct whichever email address to use iu.edu rather than indiana.edu since IU is discontinuing all "indiana.edu" See https://kb.iu.edu/d/birs

The Cell Distance explorer does not have any "contact" button.

We should use<EMAIL_ADDRESS>. I am unassigning myself and @LibbyUX  as any of our programmers can work on this. Essentially, we find all uses of an email infoccf or cnscentr and replace with<EMAIL_ADDRESS>

Hi @bherr2 & @emquardokus ,
We do have a contact button in the CDE: There is a contact option in the footer of the CDE, Dashboards, and future interfaces using this footer. We want to keep things simple here.
Let's discuss a global contact/feedback component eventually.
Thank you!

Yes, I see! Thank you @emquardokus + @bherr2 for getting the email address squared away for consistency!
I read Ellen's second comment here as a reminder of something I need to specify eventually. I have an opportunity to improve the consistency of the contact flow around our UIs. If either of you have any suggestions for this component, I would love to discuss on #387 !

Fixed this in PR #512

Hey @emquardokus I just sent a test email to<EMAIL_ADDRESS>- Can you confirm it was received?

@LibbyUX I did not see your message, so I sent my own directly to the<EMAIL_ADDRESS>and it made it through, so not sure---the email address is working though in general. I can try from website link.

@LibbyUX I see what's happening now.  When you click on "contact" in FTU explorer, it opens a window and it looks like you should be able to "submit" the message directly from there, but instead of it submitting it and sending, it instead opens up your mail program locally on your computer with a prefilled in email. That is NOT how this worked before when the email was set to the cns center one.  Can this be fixed please?

Yes, I had the same experience. The modal component itself is quite buggy. This is morphing into a different issue, however.
Let's close this issue out by removing the contact button entirely from the FTU explorer. I will specify improvements in a week or two.

Also, let me make a separate issue for that. We have a lot of high priority requests out right now so this is the best we can do.

@LibbyUX removing contact button is consistent with both the EUI and RUI tools.  The ASCT+B reporter has a contact button at the bottom of it's tool screen, but it immediately just opens a template through your own email program rather than opening a dialog box from browser and acting like you can send your message from it.  That would be the easiest compromise?

@emquardokus 100%. I submitted #531 for this update. I will close this as completed with the intent of updating this in July.


Add entries in Windows Start menu for other options than "--basics"

From<EMAIL_ADDRESS>on 2010-02-17T04:27:38Z
Spyder crashes at startup on Windows XP SP3 after splash screen. Fresh install.

Installed latest Python (python-2.6.4.msi)
Installed Spyder (1.0.3_py26)
Installed PyQt (Py26-4.7-1)

I've removed "--basics" in shortcut - after that everything works fine.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=154

From pierre.raybaut on 2010-02-21T12:57:10Z
Done in v1.1.0alpha1
Status: Fixed

From pierre.raybaut on 2010-02-20T00:41:53Z
Well, you must be the first scientific user to be using Python without numpy, scipy
and matplotlib installed! ;-)
The purpose of the '--basics' option is precisely to load these modules at startup.
As Spyder means Scientific PYthon Development EnviRonment, I assume that essential
scientific modules are installed.
I guess I will add a submenu in Windows Start menu:
"Spyder (no option)"
"Spyder (--basics)"
"Spyder (--all)"
"Spyder (--light)"
Summary: Add entries in Windows Start menu for other options than "--basics"
Status: Accepted
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low


Xcode 10 / Swift 4.2 Compatibility

Use Swift 4.2 names for UITableViewCell.EditiingStyle and UITableView.RowAnimation

Probably want to wait until the official release is out before merging this :)

Thanks for this! Even though this was first, I'm going to close it and merge this one instead to get the updated examples and Travis config.


TIP: use this to keep track of payments!
/pay [amount] [user]`

Probably a bug with how I was editing the database


[Java][CI] Source Verification Java Linux Conda on AMD64 Latest fails

Describe the bug, including details regarding any error messages, version, and platform.
It seems that the CI verify-rc-source-java-linux-conda-latest-amd64 , has been consistently failing when we run the crossbows. The release verification fails each time.
Component(s)
Java

cc @lidavidm

@raulcd has this been observed already in the pre-release events?

I can reproduce this locally in a container and it produces just as little output as the crossbow log does.
Looking at this bit,

2024-10-01T02:37:19.1534699Z ##[warning]Future Miniforge releases will NOT build Mambaforge installers. We advise you switch to Miniforge at your earliest convenience. More details at https://conda-forge.org/news/2024/07/29/sunsetting-mambaforge/.
2024-10-01T02:37:19.1545889Z ERROR: executing pre_install.sh failed

pre_install.sh looks like a conda/mambaforge thing so it seems like that's what's failing and not the verification itself. I looked at the deprecation URL they link to and notice we're just at the edge between the window where the installer will wait for 30s before proceeding and the October first brownout window of 2024-10-01 where installs will fail.
Is it possible the failure is related to the deprecation of mambaforge and that the fix is to switch to miniforge as they indicate?

Right, probably it could be. Need to look into this I haven't come across this kind of an error before.

I posted on Zulip too: https://ursalabs.zulipchat.com/#narrow/stream/180245-dev/topic/Mambaforge.20deprecation.2C.20brownouts.20start.20Oct.202024.

Issue resolved by pull request 44278
https://github.com/apache/arrow/pull/44278


use BaseIntermediateOutputPath

if you add BaseIntermediateOutputPath settings to the projects you will be able to have the solutions open concurrently and not have unintended side effect of VS re-using files in the bin obj directory
eg
<BaseIntermediateOutputPath>obj\Debug\WinRT\</BaseIntermediateOutputPath>

Done


Combine Abaqus and PERMAS formats

It seems to me that these two formats are simply isomorphic...

Keywords in Abaqus begin with *, while in PERMAS $

Comments: ** vs !

Point coordinates: *NODES vs $COOR

Element names...

https://github.com/nschloe/meshio/blob/master/meshio/permas/_permas.py

https://github.com/nschloe/meshio/blob/master/meshio/abaqus/_abaqus.py

Since the current Abaqus implementation is (slightly) more efficient (seek and tell are extremely costly), maybe we can merge PERMAS into Abaqus.

Well spotted! @nilswagner Is this a fact?

@nilswagner Ping.

! corresponds to **
$ELEMENT corresponds to *ELEMENT
$COOR corresponds to *NODE
Element definitions can take place over several lines in PERMAS. This is currently not considered by the parser.
The first character of the continuation line is a &, e.g.
  $ELEMENT TYPE = HEXE27
<PHONE_NUMBER>    1001943    1000012    1001919    1004157    1001941    1000001    1001918    1000009    1001944    1004159    1001947    1004162
     &           1005965    1004160    1001920    1004161    1001942    1000015    1001952    1000018    1001953    1004158    1001958    1000016    1001956
     &           1000017

*ELEMENT, TYPE=C3D27, ELSET=P_BEAM
737,   1000010,   1000012,   1000009,   1000001,   1000015,   1000018,   1000017,   1000016,
1001943,   1001941,   1001918,   1001919,   1001952,   1001958,   1001956,   1001953,   1001944,
1001947,   1001942,   1001920,   1005965,   1004157,   1004158,   1004159,   1004160,   1004161,
1004162

Ok, so it seems indeed that these two formats are simply isomorphic...
Cells defined by multiple lines are well treated by the current Abaqus parser (https://github.com/nschloe/meshio/pull/436).
@nilswagner Do you have a more informative documentation for the PERMAS format (other than https://www.intes.de/)?


Less hardcoded settings

Removed all /web specific beta flags
Added in frame config for frame beta settings
Added in APP_BETA_FEATURES (an array) to app-config.js with an example flag
Cleaned up the markup a bit on the main page
Note, this only changes true/false beta flags. All other flags will still have to be hand built for now. #changeoften

Default frame settings

Example of how /web will use it

Resolves #73

:+1:

:+1:


[HOLD for payment 2024-04-09] [Simplified Collect][Workflows] Bank account info still displayed in Make or track payments after disconnecting

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

Version Number: 1.4.51-1
Reproducible in staging?: y
Reproducible in production?: unable to check in production
If this was caught during regression testing, add the test name, ID and link from TestRail: n/a
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: applause internal team
Slack conversation:
Action Performed:
precondition: user created a paid policy in OD and added a bank account

Go to https://staging.new.expensify.com/
and log in
Select the paid policy workspace in the workspace switcher > Settings
Click on Workflow
Enable Make or track payments toggle
Select Bank account
Click on the Bank account option > Disconnect

Expected Result:
The bank account information disappears, and "Connect bank account" is displayed
Actual Result:
The bank account information is still displayed even after refreshing the page. Also, after disconnecting the bank account, toggling off/on the "Make or track payments" option, and clicking on bank account the disconnected bank account shows up.
Workaround:
unknown
Platforms:

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

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

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/43996225/632be4d0-8d5f-4425-8edf-11cd7c2b9ff7

View all open jobs on GitHub

@bfitzexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

We think this bug might be related to #wave-collect - Release  cc @trjExpensify

This is related to the workflows project, yeah. CC: @lakchote

cc @ishpaul777 since you worked on the implementation of this feature

Oh we might actually handle this as part of https://github.com/Expensify/App/pull/37680, when we clean up the current VBBA keys and use the new reimbursementAccount<policyID> format. @nkuoch could you please confirm if changing resetFreePlanBankAccount to use ${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID} instead of ONYXKEYS.REIMBURSEMENT_ACCOUNT is currently in that issue's scope?

Let me take it over. I've actually decided not to use ${ONYXKEYS.REIMBURSEMENT_ACCOUNT}${policyID} anymore. I'll give a better update in a bit.

@nkuoch mind taking a look at https://github.com/Expensify/App/issues/39439?

Offer sent @getusha

Payment complete. I don't think a regression test is necessary here. Let's close this out.


Build fails with gradle's --parallel option

I've the following task:
task buildImage(type: DockerBuildTask, dependsOn: prepareImage) {
   imageName = nameWithVersion
   buildContextDirectory = file("${project.buildDir}/imageData")
}

The 'prepareImage' task creates/fills the ${project.buildDir}/imageData directory.
This works correct, but with the --parallel option the build fails:
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':docker:AppServer:buildImage'.
> java.io.FileNotFoundException: /home/peter/develop/tn2/products/docker/AppServer/build/tmp/tarBuildcontextForBuildImage/buildContext_tn2__app_server_1_0_0_1145-1.0.0.tgz (No such file or directory)

I think this fails because the tarBuildcontextForBuildImage does not depend on the 'prepareImage' task. During the build gradle outputs:
:docker:AppServer:tarBuildcontextForBuildImage UP-TO-DATE
:docker:AppServer:prepareImage
:docker:AppServer:buildImage FAILED

The tarBuildcontextForBuildImage task does not create the tgz because the input directory is not created/filled yet.
The tarBuildcontextForBuildImage task should depend on the tasks that the buildImage task depends on.

I guess you're right. I'll look into it.

@pdwinkel would like to try adding the following line to your build script? If that works for you, I would add the fix to the plugin:
tarBuildcontextForBuildImage.mustRunAfter prepareImage

Thanks!

Yes, that works!

@pdwinkel the fixed release is available as version 2015-02-15T13-45-26.

Works. Thx.


Window could remember its size

and the margin between the three big buttons could shrink when decreasing window size

I don't really like storing the window size in the settings.
Anyway, now both the main and the options windows should be able to remember their sizes.
Also, the spaces between the buttons are now resizable.

Cool, thank you!


MGDOBR-188 Create kustomize overlays for basic usage scenarios

Signed-off-by: Karel Suta<EMAIL_ADDRESS>MGDOBR-188
Refactored kustomize script to support three scenarios:

Local operator development (operator running locally)
Operator image testing (operator running on Minikube)
E2E testing (all components deployed on Minikube)

Pending tasks:

Adjust shard operator CI check
Publish minikube operator image?

Please make sure that your PR meets the following requirements:

[x] Your code is properly formatted according to this configuration
[x] Your commit messages are clear and reference the JIRA issue e.g: "[MGDOBR-1] - $clear_explanation_of_what_you_did"
[x] All new functionality is tested
[x] Pull Request title is properly formatted: MGDOBR-XYZ Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains link to any dependent or related Pull Request
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket

Currently covering only operator scenarios, will extend it to cover manager too.

@r00ta The main part of the PR is ready for review. Please take a look when you will have time.
There are some duplications of resources from dev folder.
Thinking about publishing minikube image for operator together with OpenShift one, so people can use it in kustomize directly, what do you think?

Hey @sutaakar , I see that all the configurations are in the base-.. folder and the overlays are just including/excluding some of the resources.
Actually, the idea behind this kustomize project was to keep the base as the base layer, and then the overlay as the specification for each environment (for example, you can see that the base does not create any Openshift Route, because it is created in the prod overlay).
Now, regarding the deployment of the entire platform to kubernetes, I wish it is possible to do it just creating a new kubernetes overlay and specify the resources there (ingresses, etc..).
I see you'd like to use kustomize also to setup just kafka/keycloak for local development, but I think we might do that in the dev folder and leave this kustomize folder just for the deployment of the entire platform to a particular environment.
What do you think? If you have a different idea, let's talk about it ;)

@r00ta I used this approach also to simplify deployment for local development. As I see now there are several steps needed to start the local environment. By adding it into kustomize it can be created by one command (+ one more to start Keycloak).
Also it allows sharing of configuration with the complex setup.

@r00ta Could you please take a look?

Looking now

Nice work! I have just a minor nitpick :)

@r00ta Thanks, what nitpick?

@r00ta Done


BUG - Any change to a zone deletes all  rrsets.[].comments[].account

Summary
PowerDNS Version: 4.5.4
PDA Version: 4.1.1
When a PATCH is issued to the PowerDNS zone endpoint {{base_url}}/api/v1/servers/{{server}}/zones/{{zoneId}} all account fields are deleted.
Reproducer
These were issued from Postman directly to PowerDNS using the PowerDNS API_KEY for authentication. The user tailsync is a PDA user account and is the account that manages the zone exo.lab..

Create RR with a comment in a given zone.

PATCH {{base_url}}/api/v1/servers/{{server}}/zones/{{zoneId}}
{
    "rrsets": [
        {
            "name": "test.exo.lab.",
            "type": "A",
            "ttl": 60,
            "changetype": "REPLACE",
            "records": [
                {
                    "content": "<IP_ADDRESS>",
                    "disabled": false
                }
            ],
            "comments": [
                {
                    "account": "tailsync",
                    "content": "just plain text",
                    "modified_at":<PHONE_NUMBER>
                }
            ]
        },
        {
            "name": "other.exo.lab.",
            "type": "A",
            "ttl": 60,
            "changetype": "REPLACE",
            "records": [
                {
                    "content": "<IP_ADDRESS>",
                    "disabled": false
                }
            ],
            "comments": [
                {
                    "account": "tailsync",
                    "content": "just plain text also",
                    "modified_at":<PHONE_NUMBER>
                }
            ]
        }
    ]
}

On the PowerDNS-Admin UI, logged in as tailsync modify any record, click save, then Apply Changes.

See all account fields deleted.

GET {{base_url}}/api/v1/servers/{{server}}/zones/{{zoneId}}
{
    "account": "tailsync",
    "api_rectify": false,
    "dnssec": false,
    "edited_serial":<PHONE_NUMBER>,
    "id": "exo.lab.",
    "kind": "Native",
    "last_check": 0,
    "master_tsig_key_ids": [],
    "masters": [],
    "name": "exo.lab.",
    "notified_serial": 0,
    "nsec3narrow": false,
    "nsec3param": "",
    "rrsets": [
        {
            "comments": [
                {
                    "account": "",
                    "content": "just plain text",
                    "modified_at":<PHONE_NUMBER>
                }
            ],
            "name": "test.exo.lab.",
            "records": [
                {
                    "content": "<IP_ADDRESS>",
                    "disabled": false
                }
            ],
            "ttl": 60,
            "type": "A"
        },
        {
            "comments": [
                {
                    "account": "",
                    "content": "just plain text also",
                    "modified_at":<PHONE_NUMBER>
                }
            ],
            "name": "other.exo.lab.",
            "records": [
                {
                    "content": "<IP_ADDRESS>",
                    "disabled": false
                }
            ],
            "ttl": 60,
            "type": "A"
        },
        ... omitting rest of large response ...
    ],
    "serial":<PHONE_NUMBER>,
    "slave_tsig_key_ids": [],
    "soa_edit": "",
    "soa_edit_api": "DEFAULT",
    "url": "/api/v1/servers/localhost/zones/exo.lab."
}

We don't manage accounting at the record level but at the zone level. The code that loads the content in the js table doesn't keep track of the account. As we don't keep track of changes the whole zone is submitted again.
We have some feature requests to track changes more precisely, we could check on that then.


delete where in will not trigger steam

delete where in will not trigger steam

So logically should   call _changeListener? .add(_entityName);

I think we should change @Delete

yes, you're right. In the current version Query requests doesn't trigger the change notification.
But I have already implemented it in this PR #733


experimental support for building without environmental variables

Both embedded-server and no-server fully work. Heres a checklist ill keep updated i guess:

[x] Compressed embedded assets (brotli gzip)
[x] no-server
[x] embedded-server
[x] Pass test suite
[x] Create additional tests for changed/new code (not really sure what to add for config testing)
[x] TAURI_INLINED_ASSETS support
[x] TAURI_CONFIG support
[x] Refactor AppConfig -> AppContext to prevent repetition.  (i.e. &application.config.config -> &application.ctx.config)
[x] handle public paths as in webpack instead of iteratively removing parents from assets

This is the replacement for #830.  That PR was more about seeing if it was possible, this PR is about actually removing core environmental build variables from tauri.
This branch/pull request should be tracking changes from dev to prevent having a massive conflict at the end.  This touches a few "core" files like runner.rs and has some tentacles in otherwise not related code due to moving tauri-api::config into tauri-config so conflicts are definitely going to happen.
As of the first commit, it can build a no-server application that has been run with tauri dev or tauri build to generate the index.tauri.html.

As a high level overview of additional changes planned in this branch:

All tests need to be updated
Support for embedded-server. (and every existing way of using tauri)
Handle additional env vars like TAURI_CONFIG and TAURI_INLINED_ASSETS which are currently ignored

See comments on #830 for a more specific overview if needed

the last commit added support for embedded-server,

Because of some necessary changes to codegen, I lifted the code from the tauri_includedir_codegen repo into tauri-macros/src/include_dir.rs along with the rework.  Since the frontend to that dependency also didn't make much sense, I moved tauri_includedir::Files into tauri-api/src/assets.rs as Assets.  This commit doesn't add support for gzip since it was not used anyways.  It keeps the structure support for it however, and just needs to be actually implemented in the match in include_dir.rs.  I left a few TODO comments that should be handled by the time this PR would be ready

Off the top of my head, some todos:

replacement for the get() testing in tauri-api/src/config.rs
finish gzip support in tauri-macros/src/include_dir.rs
support TAURI_CONFIG environmental variable to override any actual config with the content sent in that env var
make sure TAURI_INLINED_ASSETS actually works, since the code was ported
probably add some tests around the AppConfig and some more tests wherever the config or environmental variable was previously used

I've left the bundler and cli completely untouched, only touching tauri, tauri-api, and (new) tauri-macros.  There's still a few places env vars are used in the latter, such as endpoint assets handling and runner splashscreens.
note for myself:
https://github.com/tauri-apps/tauri/blob/d0c41e477e692cd80b95d218f30f4b1d1c4e17d3/tauri/src/app/runner.rs#L292

Another relative large change.
Asset compression has been re-implemented in the proc-macro from the code that moved over from tauri_includedir_codegen.  This implementation happens to use Brotli because of higher compression ratios + faster/equal decompression speed and for the nice Read interfaces it implements allowing us to stream compressed brotli assets directly to the browser with embedded-server.
Both embedded-server and no-server fully work. Heres a checklist ill keep updated i guess:

[x] Compressed embedded assets (brotli)
[x] no-server
[x] embedded-server
[x] Pass test suite
[ ] Create additional tests for changed/new code
[x] TAURI_INLINED_ASSETS support
[ ] TAURI_CONFIG support
[ ] Refactor AppConfig -> AppContext to prevent repetition.  (i.e. &application.config.config)

exchanged out brotli for gzip with flate2.  removes the extra new brotli dependency and more importantly keeps the scope of this PR smaller.  I think using brotli for asset embedding compression is an interesting conversation to come back to.  replacing gzip with brotli is rather simple, as you can see in the 3693df9395204175a5e71914cfb671e2ae065a3d commit

So as this comes closer to something we can merge in, it would be good to know how we can validate this approach. Also, is this going to introduce any kind of breaking changes for consumers or devs?

I agree that validation that this doesn't break anything is important.  This would be a breaking change for consumers, as the public API would change in a few ways.  The largest change by far is how entry into the App changes to include the struct derived with the new proc-macro.
Previously:
use tauri::AppBuilder;

fn main() {
  AppBuilder::new()
    .setup(|w, s| todo!())
    .invoke_handler(|w, arg| todo!())
    .build()
    .run();
}

With this change:
use tauri::{AppBuilder, FromTauriConfig};

#[derive(FromTauriConfig)]
struct Config;

fn main() {
  AppBuilder::<Config>::new()
    .setup(|w,s| todo!())
    .invoke_handler(|w, arg| todo!())
    .build()
    .unwrap() // new
    .run();
}

That FromTauriConfig derive also provides an attribute #[tauri_config_path = "my/custom/path.json"] to point to a config file relative to the app's cargo manifest.  An example of that attribute in use can be seen in the tauri/examples/communication/src-tauri/src/main.rs diff.  The build() now returning a Result<App, Error> is due to serde_json parsing the config file during the build.  This might be changed because technically any failures would have happened during the proc-macro and not given a chance to be built by the AppBuilder.
In short, the main needed change is the derive + passing the config as the generic to AppBuilder. Where that generic is passed in is up for change, but somewhere during the AppBuilder.
The other changes to the public api happen in a few public functions exposed in tauri-api and tauri.

#[doc(hidden)] AsTauriConfig trait in tauri-api which is what the proc-macro implements and the AppBuilder requires.
crate tauri_includedir is changed to tauri-api::assets::Assets.  The tauri_includedir_codegen counterpart is now part of tauri-macros under include_dir.rs.
Public API changes where config::get() was previously used.  These now require a Config argument or similar.  These functions previously took no arguments.

tauri-api::cli::get_matches(config: &Config)
tauri-api::notification::Notification::new(identifier: impl Into<String>)

Various non-public apis take a new argument similar to the previous changes

tauri::endpoint::asset::load(/* ... */, ctx: &AppContext)
tauri::endpoint::notification::send(/* ... */, config: &Config)

A new internally used struct to help App handle needing to pass the configs during runtime.  AppContext which holds a Config, tauri-api::assets::Assets (embedded files), and a static string of the index.tauri.html.

Like before, the exact api changes and ways of passing the data through are up for change.  The main important piece is passing something so that those function have the information.  The AppContext is this helper in this implementation.

Otherwise, I've touched the bundler and cli alone (besides the init template) to help prevent too much churn at once.  Since some of the parameters passed to the changes are just ignored (like TAURI_DIR and TAURI_DIST_DIR) there shouldn't be much conflict there.  Some of the parameters passed from them are still used like TAURI_CONFIG / TAURI_INLINED_ASSETS.
I still need to test more examples, so I'll be going through the examples repo one by one later this week and comparing dev to this branch.

I've started to test examples 1 by 1 in tauri-apps/examples#398.  Before the next testing, I need to expand on the last commit (32a007fd996e796331c8fe4c2677fe8a6ec5f3ad) to fix paths on windows builds.  In short, we need to use the extended path version of windows paths to support paths >260 which came up during testing.

Hey @chippers i'm sorry it took so long but we're back. I'll make some time in the next few days to review this amazing work! This is something that we need :)

Cool, I'll take a look at some of the updates since 8f06882fd100e73004d1d13c34d9a2d1536d8b66 and see if it needs any changes before updating from dev again. Feel free to mention me on the discord @chip if you want to discuss parts of it

I've updated this branch to the tauri-v0.11.1 release (14 days ago), but some of the more recent changes have many more conflicts and I will need to look into them in the next few days

I was going to do that for you :) I think I can help

We should wait for WRY to land on dev before fixing the conflict issues here.

We'll need to archive tauri-includedir since this change kills it :P

My bad :joy:


Bikeshed may generate an empty row in a property definition table

The property definition of font-style in CSS Fonts 4 ends with an HTML comment in the source:
https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/Overview.bs#L1115
That comment is not new. What's new is that Bikeshed now generates an empty row at the end of the definition table when it processes that block, see:
https://drafts.csswg.org/css-fonts-4/#font-style-prop
I believe that's the only occurrence across specs. At least that's the only spec on which Reffy crashed because it did not know what to do with an empty row ;). The spec could perhaps simply be updated to move the comment out of the <pre> tag.
Via https://github.com/w3c/webref/issues/1130

Fixed in 761dd74f0, I'll cut a release in a few.

And yeah, previously I did an early pass, before almost any other text processing, to remove comments from the source. This was unsafe, since it would strip them from, say, the contents of an <xmp>, or within a markdown code block. Now that I parse comments along with everything else, I can properly leave them alone in any context where I'm parsing as text rather than HTML. That means the comment now persists until I do propdef block parsing, and I happily generate a table row for it. And I purposely don't escape the text when I build the HTML, here, so you can insert markup and it'll work normally, so that ends up just stretching the comment across the th and into the td.
Anyway, I now strip comments from the lines when parsing def blocks.


[pre-sve] TC-MF-1.9 : DUT getting commissioned after 20 failed attempts

Problem
TC-MF-1.9

expected behavior
The test case to open a commissioning window using the first raspberry pi via,
./chip-tool pairing open-commissioning-window 1 1 900 1000 3840

And entering the invalid code of the generated by chip-tool on second pi. It should fail with integrity check failed. Trying this 20 times and giving the correct pairing code on 21st attempt the commissioning should fail.

actual behavior
Commissioning seems to be passing on the 21st attempt on the 2nd pi.

system configuration
Silabs DUT
EFR32 + RS9116
EFR32 + WF200

logs

tc-mf-1.9(2).txt
tc-mf-1.9(1).txt

Trying this 20 times and giving the correct pairing code on 21st attempt the commissioning should fail.

No, it should not.  What should fail is the 21st PBKDFParamRequest message after 20 PASE setup failures.
But if the pairing code is failing integrity checks, there are no PASE attempts at all.
I just looked at the test plan, and it says to use an incorrect setup code, not an invalid one:

Set up a TH_CR2 to start attempting to do PASE to DUT_CE and failing 20 times. This can be done using a valid manual code with an incorrect setupcode


Implement Logger Class Header File That Can Be Utilized From Any Of The Code File

Put this file in include/keyflow. Make sure it can be utilized from any of the file so that we can remove our dependency from std::cout. If debug flow is disabled, it should only print in the file, otherwise it should print both in the file and the console.

closed with commit and push to main: https://github.com/hetulbhatt/KeyFlow/commit/e72423a2edcc3f3e1b7f0b3edeb176092549aea8


kubectl default namespace not always 'default' but depends on kubeconfig

This is different from what happens outside of a cluster; when kubectl runs outside a cluster and you don't specify a namespace, the kubectl command acts against the default namespace.
On the above documentation, the kubectl does not act against 'default' namespace but the one assigned to the current-context. The kubeconfig files default context may be pointed to 'default' namespace, but that is not the default namespace all the time.

Hey, I had to search to retrieve where the context of what you mentioned, it's from here for further info.
This is indeed a simplification but might be correct most of the time with default configured kubeconfig contexts. It could be more precise, mentioning the kubeconfig file (keeping in mind that this section is about in-cluster config).
/sig cli
/triage accepted
/priority backlog
/language en

/retitle kubectl default namespace not always 'default' but depends on kubeconfig
If you can find a better title, just needed to make something a bit more precise than just an issue on kubectl

/assign


fix late limit header name #92

Close #92

Codecov Report

Merging #93 (3018149) into main (067a4f5) will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #93      +/-   ##
==========================================
+ Coverage   97.30%   97.32%   +0.02%
==========================================
  Files          25       25
  Lines        1001     1009       +8
==========================================
+ Hits          974      982       +8
  Misses         18       18
  Partials        9        9

Impacted Files
Coverage Δ

gesa/client.go
93.23% <100.00%> (ø)

gesa/rate_limit.go
100.00% <100.00%> (ø)

internal/header.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


proposal: os/exec, syscall: allow child processes to inherit all inheritable handles from the parent process

On Windows, one must explicitly list the handles that will be inherited by a new process when calling syscall.StartProcess and os.StartProcess. This is problematic for applications that don't know which handles they have inherited from their parent process and want to spawn new child processes with the same inherited handles, as in #53652.
Windows does not provide an API to list all inherited handles, but suggest to use some form of process communication (source), so these applications are left behind without a solution other than reimplementing syscall.StartProcess.
In fact, before go1.17 we did support this use case, all inheritable handles were passed explicitly. #44011 changed syscall.StartProcess to use the more robust approach of passing them implicitly. What I'm proposing here is to allow users to opt into the old behavior by adding a new property to syscall.SysProcAttr property, named InheritAllInheritableHandles.
It would look like this:
type SysProcAttr struct {
        // ...
        // Existing props
	NoInheritHandles           bool                // if set, each inheritable handle in the calling process is not inherited by the new process
	AdditionalInheritedHandles []Handle            // a list of additional handles, already marked as inheritable, that will be inherited by the new process
	ParentProcess              Handle              // if non-zero, the new process regards the process given by this handle as its parent process, and AdditionalInheritedHandles, if set, should exist in this parent process
	// New props
	InheritAllInheritableHandles bool // if set and NoInheritHandles is unset, each inheritable handle in the calling process is inherited by the new process
}

If InheritAllInheritableHandles is set and NoInheritHandles is unset, then syscall.StartProcess would ignore AdditionalInheritedHandles and call the relevant windows APIs as before CL 288297. We could also fail in case both InheritAllInheritableHandles and NoInheritHandles are set, I'm still not sold on this.
Notice that handles passed in AdditionalInheritedHandles will still be inherited when InheritAllInheritableHandles is set, as they must be marked as inheritable to be usable in AdditionalInheritedHandles.
@golang/windows @alexbrainman @zx2c4

I don't really understand what the meaning of the NoInheritHandles field is if inheritable handles are not inherited by default. Its doc comment currently talks about handles that are not inherited, but that seems to be the current default behavior anyway.
Can we updates the documentation for NoInheritHandles to describe which handles it actually affects? (That is, which handles would change from inherited to not because of that field being set?)

I don't really understand what the meaning of the NoInheritHandles field is if inheritable handles are not inherited by default. Its doc comment currently talks about handles that are not inherited, but that seems to be the current default behavior anyway.

The doc comment is outdated. syscall.StartProcess always adds stdin, stdout and stderr to the list of inherited handles regardless of the AdditionalInheritedHandles content. NoInheritHandles is a knob that disables handle inheritance, so in practice the only reason to set is to not inherit the standard handlers, other handlers are already not inherited unless they are added to  AdditionalInheritedHandles.

Can we update the documentation for NoInheritHandles to describe which handles it actually affects? (That is, which handles would change from inherited to not because of that field being set?)

Yep, will submit a CL improving the doc comments.

Huh, I've just seen that pipes returned by os.Pipe are marked as inheritable since CL 288299, so applications using InheritAllInheritableHandles would inadvertently leak all file descriptors created using os.Pipe(). This is bad, because leaking a file descriptor can cause hangs or security issues when spawning malicious processes.
I see three options to overcome this issue:

Add a warning to InheritAllInheritableHandles docs says that when used in a process that also calls os.Pipe(), all pipes that shouldn't be inherited should be marked an such, possibly using a lock that ensures that another thread doens't call syscall.StartProcess in between os.Pipe() and syscall.SetHandleInformation(h, syscall.HANDLE_FLAG_INHERIT, 0).
Change os.Pipe() on Windows so the pipe returned is not inheritable, and find another way to solve #21085.
Don't accept this proposal.

I like the second one, if that's feasible and can mitigate possible breaking changes.

I am still very confused. os/exec by default directs Stdin, Stdout, and Stderr to os.DevNull anyway. Are the parent's os.Stdin, os.Stdout, and os.Stderr inherited by default even if they are not being used as the corresponding streams for the child process?
On the other hand, if the user explicitly sets cmd.Stdout = os.Stdout or similar, then it seems like it would be confusing for NoInheritHandles to undo that. Similarly, if the user calls cmd.StdoutPipe, then it would be confusing for NoInheritHandles to immediately break that pipe.
(exec.TestNoInheritHandles unfortunately doesn't shed any light on the situation, because it doesn't test the behavior with a  of the child process at all. 😵💫)

Perhaps NoInheritHandles should cause syscall.StartProcess to error out if attr.Files contains any handles that refer to files other than NUL?
Along those same lines, perhaps NoInheritHandles should be deprecated, and we should set bInheritHandles to false by default whenever attr.Files contains only NUL files?

It looks like the field was added in the first place in https://go.dev/cl/261917 for #42098, but I don't see any tests associated with that proposal or CL at all.
(CC @ianlancetaylor @JohanKnutzen).

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasuserw says (emphasis mine):

By default, passing TRUE as the value of the bInheritHandles parameter causes all inheritable handles to be inherited by the new process. This can be problematic for applications which create processes from multiple threads simultaneously yet desire each process to inherit different handles.

That problematic case seems like what essentially always happens in a Go program. In particular, it seems like allowing InheritAllInheritableHandles would be reintroducing a problem exactly analogous to the one that forces the use of syscall.ForkLock on Unix platforms.
...actually, come to think of it: it appears that syscall.ForkLock is still used in net.sysSocket on Windows, but since CL 288297 it is no longer used in syscall.StartProcess on Windows, so it currently has no effect except to cause lock contention in net.sysSocket.
If we were to add InheritAllInheritableHandles, would we also need to restore the use of syscall.ForkLock in syscall.StackProcess? (Or would we just accept and document that it is inherently racy if inheritable handles may be opened concurrently?)

I am still very confused. os/exec by default directs Stdin, Stdout, and Stderr to os.DevNull anyway. Are the parent's os.Stdin, os.Stdout, and os.Stderr inherited by default even if they are not being used as the corresponding streams for the child process?

Will investigate more next week. I'll have to run some tests to understand this.

...actually, come to think of it: it appears that syscall.ForkLock is still used in net.sysSocket on Windows, but since CL 288297 it is no longer used in syscall.StartProcess on Windows, so it currently has no effect except to cause lock contention in net.sysSocket.

In fact, it is no longer necessary to cover the case where WSA_FLAG_NO_HANDLE_INHERIT is not supported on Windows, as it supported since Windows 7, so the use of syscall.ForkLock can be removed, therefore InheritAllInheritableHandles wouldn't need to lock neither.

I am still very confused. os/exec by default directs Stdin, Stdout, and Stderr to os.DevNull anyway. Are the parent's os.Stdin, os.Stdout, and os.Stderr inherited by default even if they are not being used as the corresponding streams for the child process?

Got the answer: os/exec does set the standard handles to os.DevNull by default, and this is honored by the OS, child process can't access them.

On the other hand, if the user explicitly sets cmd.Stdout = os.Stdout or similar, then it seems like it would be confusing for NoInheritHandles to undo that. Similarly, if the user calls cmd.StdoutPipe, then it would be confusing for NoInheritHandles to immediately break that pipe.

That's correct. Setting NoInheritHandles makes child processes to not inherit any handle, even the standard ones explicitly set, e.g. using cmd.Stdout = os.Stdout.

Perhaps NoInheritHandles should cause syscall.StartProcess to error out if attr.Files contains any handles that refer to files other than NUL?
Along those same lines, perhaps NoInheritHandles should be deprecated, and we should set bInheritHandles to false by default whenever attr.Files contains only NUL files?

Agree with both, NoInheritHandles behavior can already be achieved by setting Stdin, Stdout, and Stderr to os.DevNull and not adding (or only adding os.DevNull) handles to AdditionalInheritedHandles, which is the os/exec default behavior. Therefore, deprecating  NoInheritHandles will reduce the cognitive burden of understanding how to inherit handles.

so these applications are left behind without a solution other than reimplementing syscall.StartProcess.

Allowing process to inherit all its handles is looking for trouble in general. Perhaps this should be hard to do. Perhaps reimplementing syscall.StartProcess is better than allowing user to set new InheritAllInheritableHandles field without considering the consequences.

Agree with both, NoInheritHandles behavior can already be achieved by setting Stdin, Stdout, and Stderr to os.DevNull and not adding (or only adding os.DevNull) handles to AdditionalInheritedHandles, which is the os/exec default behavior. Therefore, deprecating NoInheritHandles will reduce the cognitive burden of understanding how to inherit handles.

Sounds reasonable to me.
Alex


Handoff to GitHub.com on Mac

It would be nice to have support for handoff feature.
The use case is pretty obvious, say I’m opening an issue or something else after reading notification in the app, what if I want to dig deeper in the code or conversation and my Mac is nearby? It would be handy (😅) to have handoff to Safari on Mac with a link to corresponding issue or something else you’re currently viewing in the app on GitHub.com. It also fits pretty nicely in the philosophy of the app to not have full-blown GitHub experience on mobile.
Sent with GitHawk

@BasThomas how much handoff support did you add before?
Sent with GitHawk

@rnystrom zero, I’m afraid, I’m not familiar with iOS developmnet
Sent with GitHawk

Handoff works when you are in an issue or pull request.
Sent with GitHawk

@jdisho argh, you're absolutely right, it is working. Maybe it was some quirkiness in my home network when I've tried it the first time. I'll close the issue then.

Yup, issues and pull requests are supported.
Sent with GitHawk


fix: update metadata title to correct page title

Description
Update so that the correct title is in the document home page

References
Close https://github.com/openfga/openfga.dev/issues/32
Review Checklist

[ ] I have added documentation for new/changed functionality in this PR or in openfga.dev
[X] The correct base branch is being used, if not main

@adriantam can you share a few examples of what it will be like on other pages?

Can we try using something like
<meta property="og:image" content="https://openfga.dev/img/openfga_logo.svg" />

...which should add an image to our Discord embeds and any other rich object embeds?
https://cookieandrock.dev/posts/candr-website-005 has some info that might be relevant for creating a component that we can reuse.

@adriantam can you share a few examples of what it will be like on other pages?

Create a Store | OpenFGA

I looked deeper into the standard to refresh my memory, and it looks like only raster images are supported.
Maybe we should make another task for this, and I'll

make an image
place image in the right folder
add the appropriate og:image tag


fix the bug that for block_k=16 mma, the compilation crash on Ampere.

The origin issue is reported here https://github.com/triton-lang/triton/issues/3435: The issue happens during compilation, when arith.sitofp (from i8 to fp16) operates on the tensor operand which has dot_op layout with the first dimension of the tensor being 16 and opidx = 1. For example: %104 = arith.sitofp %103 : tensor<16x64xi8, #triton_gpu.dot_op<{opIdx = 1, parent = #mma, kWidth = 4}>> to tensor<16x64xf16, #triton_gpu.dot_op<{opIdx = 1, parent = #mma, kWidth = 4}>> Investigation shows that the bug happens in TritonGPUToLLVM pass. in the corner case (block_k = 16 and opidx = 1) extra elements will be unpacked in include/triton/Conversion/TritonGPUToLLVM/ElementwiseOpToLLVM.h:line (here). The code unpack extra elements due to an implicit assumption in lib/Dialect/TritonGPU/IR/Dialect.h, at here, at least 4 rep will be loaded. Therefore, in our patch, extra loaded elements are dropped in the corner case.
The core Triton is a small number of people, and we receive many PRs (thank
you!).  To help us review your code more quickly, if you are a new
contributor (less than 3 PRs merged) we ask that you complete the following
tasks and include the filled-out checklist in your PR description.
Complete the following tasks before sending your PR, and replace [ ] with
[x] to indicate you have done them.

[x] I am not making a trivial change, such as fixing a typo in a comment.

[x] I have written a PR description following these
rules.

[ ] I have run pre-commit run --from-ref origin/main --to-ref HEAD.

Select one of the following.

[ ] I have added tests.

/test for lit tests
/unittest for C++ tests
/python/test for end-to-end tests

[x] This PR does not need a test because FILL THIS IN.

Select one of the following.

[ ] I have not added any lit tests.
[x] The lit tests I have added follow these best practices,
including the "tests should be minimal" section. (Usually running Python code
and using the instructions it generates is not minimal.)

Hi, thanks for your information. However, a PR like this is not acceptable.
Most importantly, I don't see any test case included

We can take a first pass at this from the Google side, since we asked Nvidia for help with this, and once it's in an acceptable state we will assign to a core maintainer for final approval. @Moerafaat can take a first look (unfortunately, I don't think I can assign him officially as the reviewer), since he's most familiar with that part of the codebase. And then @chsigg can serve as the final quality gate, as agreed between OAI & Google.

Hi, thanks for your information. However, a PR like this is not acceptable.
Most importantly, I don't see any test case included

Thank you for your feedback! I’ll work on adding the test cases. Additionally, could you please let me know if there’s anything else that might be missing?

The mixed precision stuff is quite fragile as far as I know. I'm not sure as I haven't been taken a look for a while.

Thanks for the effort here, I will take a deeper look. Just a few notes for now:

Can you please provide a permalink for this? "lib/Dialect/TritonGPU/IR/Dialect.h, at line 2000, at least 4 rep will be loaded."
At the time of reporting the issue, this was one instance of failures that happened due to "size mismatch during packing in LLVM". Can you verify that the matmul with swapped input order works, i.e. S8xF16 ?
The way we currently work around this issue is in the auto-tuner. It is currently handled in a generic way (i.e. not specific to S8 for example). You can see here that we are disabling tiling configurations that would potentially lead to running into this issue. Ideally a solution would be accepted if we can remove this restriction in the auto-tuner without any failing tests. Can you include this as part of your change as well and see if we get any failures?

I was also trying to see other scenarios that we ran into that could be classified as the same issue. For example, looking at this sample HLO:
triton_dot {
  parameter = f8e4m3fn[32,32]{1,0} parameter(0)
  parameter.1 = f8e4m3fn[32,32]{1,0} parameter(1)
  ROOT dot = f32[32,32]{1,0} dot(parameter,parameter.1), lhs_contracting_dims={1}, rhs_contracting_dims={0}
}

ENTRY e {
  parameter = f8e4m3fn[32,32]{1,0} parameter(0)
  parameter.1 = f8e4m3fn[32,32]{1,0} parameter(1)
  ROOT dot = f32[32,32]{1,0} fusion(parameter,parameter.1), kind=kCustom, calls=triton_dot,
    backend_config={"fusion_backend_config":{kind: "__triton_gemm", triton_gemm_config: {"block_m":16,"block_n":16,"block_k":16,"split_k":1,"num_stages":2,"num_warps":2,"num_ctas":1}}}

With your change this will fail with the same "size mismatch" error. I suspect that in this case it would be because the adjustment will not apply to the left-hand side because of the restriction on the OpIdx. Is that restriction necessary or is something else the reason for failing in this example?

Another example where the current solution would fail is for this example:
parameter_0 = s8[64,64]{1,0} parameter(0)
  convert.2 = bf16[64,64]{1,0} convert(parameter_0)
  parameter_1 = bf16[128,32]{1,0} parameter(1)
  parameter_2 = u16[64,8]{1,0} parameter(2)
  ROOT dot.0 = bf16[64,32]{1,0} dot(convert.2, parameter_1, parameter_2), lhs_contracting_dims={1}, rhs_contracting_dims={0}, sparsity=L.1@2:4

This one goes through tt.sparse_dot (only exists if you use XLA's Triton). It's fine if you can't reproduce this example, but what I could also observe with this example for some tilings (for example shape[0] = 64, shape[1] = 16 for OpIdx = 0) is that this will also run into the same failure. So I'm questioning if the condition strictly applies for shape[0]?

Also make sure to run pre-commit on the change.

Thanks for the effort here, I will take a deeper look. Just a few notes for now:

Can you please provide a permalink for this? "lib/Dialect/TritonGPU/IR/Dialect.h, at line 2000, at least 4 rep will be loaded."
At the time of reporting the issue, this was one instance of failures that happened due to "size mismatch during packing in LLVM". Can you verify that the matmul with swapped input order works, i.e. S8xF16 ?
The way we currently work around this issue is in the auto-tuner. It is currently handled in a generic way (i.e. not specific to S8 for example). You can see here that we are disabling tiling configurations that would potentially lead to running into this issue. Ideally a solution would be accepted if we can remove this restriction in the auto-tuner without any failing tests. Can you include this as part of your change as well and see if we get any failures? Also note that we have a similar restriction here for sparsity that we would like to remove as well.

Thanks for the detailed comments. I update the commit log by adding the permalink.  I will test other cases and take a deep look into it.   Could you provide an example code for running this gemm_fusion_autotuner ?

Thanks for the effort here, I will take a deeper look. Just a few notes for now:

Can you please provide a permalink for this? "lib/Dialect/TritonGPU/IR/Dialect.h, at line 2000, at least 4 rep will be loaded."
At the time of reporting the issue, this was one instance of failures that happened due to "size mismatch during packing in LLVM". Can you verify that the matmul with swapped input order works, i.e. S8xF16 ?
The way we currently work around this issue is in the auto-tuner. It is currently handled in a generic way (i.e. not specific to S8 for example). You can see here that we are disabling tiling configurations that would potentially lead to running into this issue. Ideally a solution would be accepted if we can remove this restriction in the auto-tuner without any failing tests. Can you include this as part of your change as well and see if we get any failures? Also note that we have a similar restriction here for sparsity that we would like to remove as well.

Can I ask what is the data tiling configurations restriction in here  besides triton's restriction? As far as I know, triton has the restriction that block_m >=16, block_n >=16, block_k>=16, and block_m, block_n, block_k should be power 2.    Besides the triton restriction and (block_k != 16) which leads to crash.  What is other restriction in the autotuner? Thanks!

Thanks for the effort here, I will take a deeper look. Just a few notes for now:

Can you please provide a permalink for this? "lib/Dialect/TritonGPU/IR/Dialect.h, at line 2000, at least 4 rep will be loaded."
At the time of reporting the issue, this was one instance of failures that happened due to "size mismatch during packing in LLVM". Can you verify that the matmul with swapped input order works, i.e. S8xF16 ?
The way we currently work around this issue is in the auto-tuner. It is currently handled in a generic way (i.e. not specific to S8 for example). You can see here that we are disabling tiling configurations that would potentially lead to running into this issue. Ideally a solution would be accepted if we can remove this restriction in the auto-tuner without any failing tests. Can you include this as part of your change as well and see if we get any failures? Also note that we have a similar restriction here for sparsity that we would like to remove as well.

Thanks for the detailed comments. I update the commit log by adding the permalink. I will test other cases and take a deep look into it. Could you provide an example code for running this gemm_fusion_autotuner ?

You can run tests here that are purposed for this. You don't have to worry about coverage for now, I can test internally and report to you other issues if they arise.

Thanks for the effort here, I will take a deeper look. Just a few notes for now:

Can you please provide a permalink for this? "lib/Dialect/TritonGPU/IR/Dialect.h, at line 2000, at least 4 rep will be loaded."
At the time of reporting the issue, this was one instance of failures that happened due to "size mismatch during packing in LLVM". Can you verify that the matmul with swapped input order works, i.e. S8xF16 ?
The way we currently work around this issue is in the auto-tuner. It is currently handled in a generic way (i.e. not specific to S8 for example). You can see here that we are disabling tiling configurations that would potentially lead to running into this issue. Ideally a solution would be accepted if we can remove this restriction in the auto-tuner without any failing tests. Can you include this as part of your change as well and see if we get any failures? Also note that we have a similar restriction here for sparsity that we would like to remove as well.

Can I ask what is the data tiling configurations restriction in here besides triton's restriction? As far as I know, triton has the restriction that block_m >=16, block_n >=16, block_k>=16, and block_m, block_n, block_k should be power 2. Besides the triton restriction and (block_k != 16) which leads to crash. What is other restriction in the autotuner? Thanks!

The restriction here is Triton specific only at the mentioned line. The idea here is that block_k = 16 is specific to cases where we have 8-bit width types. The way it is written here is just the generalization for any bit-width.

Thanks for the clarification. Currently, I have updated the code through following:
(1) addressed the crash issues of 8-bit x 16-bit MMA.
(2) add comprehensive python tests for 16-bit x 8-bit MMA and 8-bit x 16-bit MMA for small tile size with various data types, including float16, bfloat 16, int8, float8_e5m2, float_e4m3.
(3) add lit test case.
I have also runed the test on Ampere and Hopper. The pe-commit has been done.

After addressing the last comment from @chsigg I think the PR would be ready for OAI to have a look.

I have restructured the code in the newest commit. All the test and pre-commit have been done again.

@Jokeren, this should be ready for review now. Would you mind to take a look? Thanks!

cc @ThomasRaoux

IMHO, I think it's fine to merge if it's an urgent issue that prevents you guys from moving forward, and we can use your code as a reference while we're refactoring the dot operand layout.

@ThomasRaoux it is indeed working around the issue, but not in an invasive manner I would say as the change is small and local. We work around it in XLA by entirely omitting tiling configurations that include such cases. We really would like to include these sizes in our tiling configs and this fix will allow us to do so.
We have many cases where we maintain some fixes internally (some are hacks), but ideally where we can, it would be great to have the changes upstream to minimize the differences. This allows us to also monitor issues and collaborate easily if this diff is smaller.

@ThomasRaoux just a friendly ping on this thread when you have time to take a look :)

Trying to do rebase and test it on Ampere.  However, currently pytest of upstream has errors on ampere platform. Report the issue here https://github.com/triton-lang/triton/issues/4990

Closed the PR following the request.


Remove version: Twinkstar.TwinkstarBrowser version 8.8.1000.2305

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://d1.twinkstar.com/win/Twinkstar_v8.8.1000.2305_Release32.exe
Response status code does not indicate success: 404 (Not Found).
(Automated message - build 867)

URL: https://d1.twinkstar.com/win/Twinkstar_v8.8.1000.2305_Release32.exe
Response status code does not indicate success: 404 (Not Found).
(Automated message - build 867)

URL: https://d1.twinkstar.com/win/Twinkstar_v8.8.1000.2305_Release32.exe
Response status code does not indicate success: 404 (Not Found).
(Automated message - build 867)


update documents for set()

Hi,
The old function string quite confused me, it sounds like

If you set nx=True, redis create a new key when it not exists,
If you set nx=False, redis doesn't create new key when it not exists.

https://redis.io/commands/set#options

thanks!


Any timeline on the release of segmentation code?

Not yet, unfortunately. The earliest timeline would be a few weeks after the CVPR deadline. I will write a comment here after the deadline to give you an update.

Okay thanks!
But till that time could you tell me which particular DRN model (A,B,C and size) you used for results in you paper?


Update documentation build docs

Update https://ml.dask.org/contributing.html#documentation to be more in line with https://docs.dask.org/en/latest/develop.html#contributing-to-documentation
In addition I just tried to run
conda env create -f ci/environment-docs.yaml --name=dask-ml-dev-docs
cd docs
make html

and got
(dask-ml-dev-docs) Ray@UM-404XFVH4 docs % make html
Running Sphinx v1.8.5

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/opt/anaconda3/envs/dask-ml-dev-docs/lib/python3.6/site-packages/sphinx/config.py", line 368, in eval_config_file
    execfile_(filename, namespace)
  File "/opt/anaconda3/envs/dask-ml-dev-docs/lib/python3.6/site-packages/sphinx/util/pycompat.py", line 150, in execfile_
    exec_(code, _globals)
  File "/Users/Ray/Documents/PYTHON_dev/dask-ml/docs/source/conf.py", line 23, in <module>
    from dask_ml import __version__ as version
ModuleNotFoundError: No module named 'dask_ml'

make: *** [html] Error 2

You'll need to install the package locally.
conda activate dask-ml-dev-docs
python -m pip install -e .
cd docs
make html

https://github.com/dask/dask-ml/pull/694


Improvements for RLayerTileWMSProps

Just giving the context about my issue:
I'm using RLayers to load some layers from GeoServer, and I was implementing a print button to make it possible to print only the portion that is visible on the map viewport.
This is an example of the print function:
if (olMap) {
      console.error('Map not found')
      return
    }

    const canvas = olMap.getViewport().querySelector('canvas')
    if (!canvas) {
      console.error('Map canvas not found')
      return
    }

    const imgData = canvas.toDataURL('image/png')
    const pdf = new jsPDF({
      orientation: canvas.width > canvas.height ? 'landscape' : 'portrait',
      unit: 'px',
      format: [canvas.width, canvas.height],
    })

    pdf.addImage(imgData, 'PNG', 0, 0, canvas.width, canvas.height)
    pdf.save('mapa.pdf')

So, when I try to use functions like "toDataURL" I have errors like this
Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported.
    at handleClick (http://localhost:3002/static/js/bundle.js:4406:28)
    at HTMLUnknownElement.callCallback (http://localhost:3002/static/js/bundle.js:382147:18)
    at Object.invokeGuardedCallbackDev (http://localhost:3002/static/js/bundle.js:382191:20)
    at invokeGuardedCallback (http://localhost:3002/static/js/bundle.js:382248:35)
    at invokeGuardedCallbackAndCatchFirstError (http://localhost:3002/static/js/bundle.js:382262:29)
    at executeDispatch (http://localhost:3002/static/js/bundle.js:386406:7)
    at processDispatchQueueItemsInOrder (http://localhost:3002/static/js/bundle.js:386432:11)
    at processDispatchQueue (http://localhost:3002/static/js/bundle.js:386443:9)
    at dispatchEventsForPlugins (http://localhost:3002/static/js/bundle.js:386452:7)
    at http://localhost:3002/static/js/bundle.js:386612:16

doing some research on this, I got:
The error "Failed to execute 'toDataURL' on 'HTMLCanvasElement': Tainted canvases may not be exported." occurs when you attempt to access or modify the pixels of a canvas that has loaded images from different origins than the page's origin without the correct permissions. This is known as the Same-Origin Policy, a security measure to prevent malicious scripts from reading sensitive data from other sites.
From this point, I already configured GeoServer CORS, and I was trying to pass CORS configuration on the components that I'm using, the RLayers component that not was possible to pass the crossOrigin parameter is the RLayerTileWMS and that's why I'm open the issue to improve the RLayerTileWMSProps.
I also was thinking to fork this repository, implement by myself and use it as a private package, but I'm pretty sure that's not the best way here.
I also have the piece of code that would resolve my issue below:
import TileLayer from 'ol/layer/Tile';
import TileWMS from 'ol/source/TileWMS';

import React from 'react';
import {RContextType} from '../context';
import {default as RLayerRaster, RLayerRasterProps} from './RLayerRaster';

// TileWMS options from https://openlayers.org/en/latest/apidoc/module-ol_source_TileWMS-TileWMS.html
/**
 * @propsfor RLayerTileWMS
 */
export interface RLayerTileWMSProps extends RLayerRasterProps {
    params?: Record<string, unknown>;
    url: string;
    crossOrigin?: string //CHANGE HERE
}

/**
 * Tiled layer using WMS
 */
export default class RLayerTileWMS extends RLayerRaster<RLayerTileWMSProps> {
    ol: TileLayer<TileWMS>;
    source: TileWMS;

    constructor(props: Readonly<RLayerTileWMSProps>, context?: React.Context<RContextType>) {
        super(props, context);
        this.createSource();
        this.ol = new TileLayer({source: this.source});
        this.eventSources = [this.ol, this.source];
    }

    protected createSource(): void {
        const {params, url, crossOrigin, projection} = this.props; //CHANGE HERE
        const options = {params, url, crossOrigin, projection}; //CHANGE HERE

        this.source = new TileWMS(options);
        this.eventSources = [this.ol, this.source];
    }

    protected refresh(prevProps?: RLayerTileWMSProps): void {
        super.refresh(prevProps);
        this.createSource();
        this.ol.setSource(this.source);
        this.attachOldEventHandlers(this.source);
    }
}

I hope that my request makes sense and I need to say thank you, this is the best "React.JS" package that I found to work openlayers!

Yes, CORS should be supported, this is indeed an omission. Can you submit a PR, I will merge it.


Update to version 1.4.0-SNAPSHOT

Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Your code is properly formatted according to this configuration
[ ] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting master: [0.9.x] KOGITO-XYZ Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains link to any dependent or related Pull Request
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket

How to retest this PR or trigger a specific build:

Pull Request
Please add comment: Jenkins retest this

Quarkus LTS checks
Please add comment: Jenkins run LTS

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

gonna merge once kogito-runtimes will pass in the PR check. Optaplanner, apps and examples will be updated in separate PRs automatically

The Linux check is successful.


Some problems when using Tab Completion

Tab can also complete the second value after the first value has been entered.

I'm not completely sure on what you mean - is it the fact that you could complete multiple materials in a row? If so, that's intended behavior; you're not just completing materials, but can choose from all predicates, including logical junctions - and will be used implicitly. Also note how not all suggestions are meant as tab-completions, especially when using the ?-syllable to construct custom groups - then, it's meant as a preview of members.
Hopefully I did not completely misunderstand your point - please feel free to elaborate further if that's the case.

ohh
okay,got it


fn decomp_tx: Do not zero txa before initialization

This adds some complexity, but it improved performance significantly, especially on intel. Zeroing an entire page of stack with memset (which is what was previously happening) is expensive.

AFAICT this is the single biggest potential perf win in rav1d.

In my testing, it looks like the latest version with less unsafe is equivalent to the unsafe pointer writes with the assert bounds check. Commenting that assert out gains a tiny bit on my i7-1260p, but seems equivalent on my Zen 4 7700X.


How to train NRMS model ?

I am glad to see this repo for news recommendation task! I recently tried to implement NRMS or other attention-based models on the MIND dataset, but found that the Dataset, Dataloader, Trainer, Recommender in the original design of RecBole needed to be modified to fit this specific task. Are you planning to integrate this repo back and rearrange your unified framework RecBole by task? If so, we can easily and conveniently run experiments on different datasets.
By the way, I tried to run the NMRS model with the following command.
python run_recbole_trm.py -m NRMS -t 8

The MIND dataset doesn't seem to be ready yet, some preprocessing is needed to get behaviors.tsv and npbehaviors.tsv defined in NRMS.yaml, how can I train the NRMS model correctly, thanks!

Any update on this ?

Due to the use of text data in news recommendation, the original MIND dataset needs to be configured here. In the future, we will consider developing a separate news recommendation library based on the existing foundation. Thank you.


Limit inference of Sendable for public, frozen types relying on preconcurrency

When inferring Sendable for a public, frozen type, that Sendable conformance
becomes part of the contract. Therefore, don't infer this conformance
when any of instance storage is implicitly non-Sendable.
Fixes rdar://88652324.

Build failed
Swift Test Linux Platform
Git Sha - 9ed776ddb235e3fd5970ee90aa65535442213850

@swift-ci please test

Original: #41351


The documentation sucks

This documentation only describes the interface of the method and nothing more.  Not at all useful.

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

ID: 15c4d50d-a88b-36d7-885a-38bb5ff15fad
Version Independent ID: 7ffdf124-d6ff-401c-3ecf-037b46f7a7a1
Content: DbSet<TEntity>.Attach(TEntity) Method (System.Data.Entity)
Content Source: [EF/xml/System.Data.Entity/DbSet1.xml](https://github.com/aspnet/EntityFramework.ApiDocs/blob/live/EF/xml/System.Data.Entity/DbSet1.xml)
Product: entity-framework
GitHub Login: @dotnet-bot
Microsoft Alias: divega

Duplicate of https://github.com/aspnet/EntityFrameworkCore/issues/17508


Add new num variant for a slider with incremental steps. This will require adding another optional field to the prop.

Tagging:
https://github.com/MIT-CAVE/cave_app/pull/166
https://github.com/MIT-CAVE/cave_static/pull/510

Added validation here: https://github.com/MIT-CAVE/cave_utils/commit/eee01d1c6d1472d24a647b65c3305a326598413b


TODO'S for Google Maps Bug?

I'm submitting a ...  (check one with "x")

[x] question
[ ] any problem or bug report

OS:  (check one with "x")

[x] Android
[x] iOS
[ ] Browser

Current behavior:

The last days, Google really fu*ked it up and cause thousands of App Crashes. The IssueTracker is here: https://issuetracker.google.com/issues/154855417
Now they came up with a "Solution", but i don't know how this will work with this Plugin.
Android:
On Android they said that The updates to Google Play Services to fix the crash is now available to all devices with Google Play Services version 17.4.55 and newer. End users' devices need to download and apply the updates. They recommend if we use Android Maps SDK v3 beta to roll out a Code Workaround which they provided.
-> What about this Plugin? Which SDK is used? Which Play Version? Do we have to change something here?
iOS:
For iOS they seems to don't have a Fix, they just give a Code Workaround (really nice Google 😒). So we should add this Workaround to this Plugin?
What do you think about this whole Topic and my Questions? If you have any Plan, i will give my best to support you with PR's, etc.
Support this plugin activity
I appreicate if you give me a beer :beer: from here

You can specify the  Google Play Services version 17.4.55 with PLAY_SERVICES_VERSION
https://github.com/mapsplugin/cordova-plugin-googlemaps/blob/master/README.md#install-optional-variables-configxml

But this set's the play-service-maps Version right? I don't think they mean this, because the latest Version of this seems to be 17.0.0 (See here).
And what about iOS?

play-service-map is part of Google Play Services

Actually I have no problems on Android and iOS.
If you still have the problems, try to reinstall your apps.

I have no Problems either, but have seen many many Crash Reports. I manually added one Workaround in Android to stop the App crashing, which seems to work, but i want a final solution.
I cannot say 400.000 Users to reinstall their app. 🤔
I don't know if i understand the Google Play Version Thing correctly, but there is no Version 17.4.55 we can use. Is this maybe kind of a internal Version Users need to install on their device?
Still: They recommend the Workaround for iOS

I don't think 400.000 people face this problem.
The problem occurs only the people who launched at the day.
And reinstalling your app is the fastest way to solve the problem instead of waiting next release at this time.

Oh, I found one thing. You can specify google maps SDK for Android version 3 if you want.
Define GOOGLE_MAPS_ANDROID_SDK in config.xml.
<preference name="GOOGLE_MAPS_ANDROID_SDK" value="maps-sdk-3.0.0-beta" />

Okay seems to be resolved then. One last Question: What is the default Android SDK that is used if i don't specify GOOGLE_MAPS_ANDROID_SDK?

v2


DO NOT MERGE - Bring Stripe Connect tweaks in from 2-0-stable-stripe

Is the intention that we port this into 2-2-stable and then rebase our branch 2-2-stable-healthwave off of it?