Possible to use dynamic CAS URL in web.config

Our CAS developer constantly changes the CAS URL with new builds, if I set the URL in the web.config I need to update the CAS path when he updates to a new build and URL. Is there a way to pull data from the systems environmental variables to populate it?
I've seen that they can add a key, but now how to use the key within the same file.
For more details please see https://stackoverflow.com/questions/57226685/is-it-possible-to-reference-environmental-variables-within-a-net-projects-web-c
Any options, bypasses, workarounds greatly appreciated.
Thanks,

With regards to Windows system environment variables... you'd still have to manually update the CAS URL there.  If I've understood you correctly, then you're just moving your problem from one place to a different place.
I'd ask the question "why does your CAS URL change every time your CAS SSO is updated?"  I can't think of any good reason to do that.  CAS is meant as a SSO (Single Sign On) system and usually lots of different systems use it as an authentication mechanism.  That's not something you'd want to keep changing the URL of.

Maybe you and your team (and the CAS sysadmins) want to get together and put some automation behind your deployment processes.  Something like Ansible.  The scenario would be the CAS sysadmin deploys a new instance of CAS along with a new URL via Ansible.  Then the next task would kick off to modify the web.config file on the web server(s) of your applications.

Honestly another quick solution is to make an entry in your DNS (your actual company DNS or whatever) for something like sso.example.com (but with your domain after the sso.)  Then all of your applications just point to this domain.  Then that name with resolve in your DNS to the new URL the CAS sysadmin keeps changing unnecessarily.
This way you abstract away the madness that your CAS sysadmin is doing.

I can't tell you why he changes the URL with new builds? But with the System Variable at least there would only be one location to update if multiple applications were made, I wouldn't need to go into every web.config to fix, just the Server's Environment Variable. From what I've seen online it doesn't seem that you can reference keys created within the web.config later on within the file.
I did see somewhere that linking an app.config file may be possible, then I would just be able to create an external file and have all our projects link/pull in that file.
https://www.youtube.com/watch?v=-KdqdWTNO7Q
Just not sure yet if that would work.

I'm not actually sure I'm fully understanding your situation and I probably can't unless I see what you have actually done in your web.config.
You work at the University of South Dakota, correct?  You guys already have your CAS server pinned to a "static" URL.  This is it: https://sso.usd.edu
That's what you put in the web.config.  Does that not work?

In the web.config file in the <forms> element:

Set the loginUrl to https://sso.usd.edu/login
Set the defaultUrl will be to a path in your actual application you want as the default page after authentication with CAS.

In the web.config file in the <casClientConfig> element:

Set the casServerLoginUrl to https://sso.usd.edu/login
Set the casServerUrlPrefix to https://sso.usd.edu
Set the serverName to the actual URL of your application of the web.config you are editing.

All of that should work.

Behind the scenes I think what you are referring to is the cluster of servers the CAS sysadmins are using behind a load balancer.  They conveniently tell you the hostname of the actual server that is serving your CAS login page from behind the load balancer.  If you view the source of the HTML on the login page there is an HTML tag called labelHostname.  E.g. usd-cas4.usd.edu
I wouldn't actually use the servers behind the load balancer.  Instead use sso.usd.edu

I think I was mistaken, it seems like our DEV version was changing very often, but the DNS for PROD was correct. I was just given some incorrect info which lead me on a wild goose chase. After speaking with our Operations team I believe no issue will come about until our next CAS upgrade.

:thumbsup:


Feat/vue2 2 vue3

PR Summary
Please include a short description using non-technical terms about the changes you are introducing.
Other considerations:
Testing steps/scenarios:

[ ] List all the testing tasks that applies to your fix and help peers to review your work.

Demo link:

Store
Editor

Checklist:

[ ] Added PR summary for release notes
[ ] Followed theme code principles
[ ] Linted with Theme Check
[ ] Tested on mobile
[ ] Tested on multiple browsers
[ ] Tested for accessibility

Migrated Renderless components are throwing a warning saying they should have a render function or either a <template> tag. That's why I can't push the folder change yet.

Product Options component and mixin were migrated to the composition API.
Mixins are still compatible, but are deprecated and not recommended by Vue docs.

Composables vs Mixins


phone restarts and adb gets disabled whenever i plug my phone to pc

well whenever i plug my phone to pc my phone immidiatly restarts and when it starts again ADB is disabled this happened after i installed scrcpy ..before installing scrcpy phone worked fine with ADB on the same system ...

well whenever i plug my phone to pc my phone immidiatly restarts

This is not related to scrcpy.

before installing scrcpy phone worked fine with ADB on the same system ...

Probably a coincidence, "scrcpy" is not even "installed", it's just extracted somewhere, it should not have any impact on your phone rebooting automatically when you plug it :/


https://developer.mozilla.org/en-US/docs/MDN/Feedback

Why does MDN have literally the worst, most useless search feature of any site on the Internet?

We agree it is not great. But we have a very limited size dev team that always has other, higher priority things to work on. And it is not as if MDN is unsearchable — everybody just uses a search engine rather than the on site search.
We are hoping to revisit this soon.


Using xcassets

Using xcassets and CocoaPods 1.0.1 Support.

Not possible as we support many older versions of iOS.


[iOS] Implemented tooltip

Related Issue
Fixed #5473
Description
Implemented tooltip & changed long press gesture to tap gesture.
How Verified
Ran unit tests and manually tested

.
Microsoft Reviewers: Open in CodeFlow

needs CI pipeline update to be able to consume fluent package

/azp run AdaptiveCards-SharedModel-CI

/azp run AdaptiveCards-.NET-PR

/azp run android-ci.yml

build failure has to do with broken symlinks in the PR -- I'm trying to fix now

/azp run uwp-ci.yml

uwp builds are failing due to an expired certificate in one of the uwp projects
https://github.com/microsoft/AdaptiveCards/pull/6470

been working on fixing unit test breakage caused by pod dependency.   didn't realize PR was auto merged. created a new pr.


GameRules for instances more things that are affected by gamerule doMobGriefing

Added GameRules for Zombies and Zombie Variants Stepping on and destroying turtle eggs, Powder Snow Block Getting destroyed when a mob on fire goes through with it, and ravagers breaking blocks

Also there is a reason behind adding a gamerule per every every zombie variation and zombified piglins on breaking turtle eggs, there are alot of times where players need to for example disable turtule egg breaking for all the zombie types but keep it on for zombified piglin(mostly for gold farming reasons).
Also I want to add a another commit to this PR about some mobs breaking doors in the hard mode (same mobs that break turtle eggs + vindicator), and for that I am not sure if a one single gamerule would work or adding one per every mob would be beneficial.

Seems like everything is fine, I'll do my own adjustments later, but yeah; About the remaining few, I'll probably only have one game rule for letting zombies breaking doors since I don't see a reason to split it


clearer documentation of NPMPublishTask

In the README it says that NPMPublishTask adds a publish task but it doesn't say how. How about changing:
The NpmPublishTask will automatically create a publish task which performs the following steps:
to:
The NpmPublishTask constructor will automatically create a publish task which performs the following steps:
Since more is going on than constructing I think it would be a good idea to have another way besides constructing it and thus remove the unnecessary variable without having the bare constructor which many find distracting. This could be backward-compatible. How about jake.package()' or 'jake.publish_task?
Another thing: since the primary place to read the README is GitHub, and most programmers prefer syntax highlighting, how about fencing the code blocks?

The only objection I'd have to changing the API is that what we have now is fairly close to Rake (which also has PackageTask) -- all other things being equal, if things are the same or similar, it makes it easy for people to transition from one to the other.
But I agree with you that the wording in the docs could be improved -- perhaps something like "When you instantiate an NPMPublshTask, Jake automatically creates a publish task which performs ..."
Also, since Jake is an open-source thing, it's always great to get pull-requests with obvious improvements like the syntax-highlighting. Send me a pull-request for the README, and I'll merge it ASAP.
Thanks! :)

Oh, I see where that pattern comes from now. I agree that we should just stick to the pattern, since this library is designed to map directly to Rake. I think your wording is good but I'll try to improve upon it.
I considered sending a pull request but I saw that not many pull requests had been merged lately. I guess it's just because not many have been sent. :) Expect two pull requests from me soon, one for the syntax highlighting and one for the doc change.


Fix install script

fix not launch.is_installed("opencv-contrib-python")
launch.is_installed("opencv-contrib-python") will always be false
use launch.is_installed("cv2.ximgproc")
otherwise on every launch it will wasting time try to install opencv-contrib-python again
add install help message when failed to import cv2.ximgproc
in termainl and UI
screenshot

additional business
hi I'm the maintainer of webui's extension index
if you wish to have this extension listed on webui's extension index please send a PR to https://github.com/AUTOMATIC1111/stable-diffusion-webui-extensions

Thank you!


"Error response from daemon: Address already in use" error during docker build dockerhost-equinix-ubuntu2204-armv8-1

Latest failure https://ci.adoptium.net/job/build-scripts/job/jobs/job/release/job/jobs/job/jdk8u/job/jdk8u-release-linux-arm-temurin/8/console
10:01:19  Execution error: java.io.IOException: Failed to run image 'adoptopenjdk/ubuntu1604_build_image'. Error: docker: Error response from daemon: Address already in use.
[Pipeline] echo
10:01:19  java.io.IOException: Failed to run image 'adoptopenjdk/ubuntu1604_build_image'. Error: docker: Error response from daemon: Address already in use.
10:01:19  	at org.jenkinsci.plugins.docker.workflow.client.DockerClient.run(DockerClient.java:148)

Fails when trying to build the adoptopenjdk/ubuntu1604_build_image container.
In the output of systemctl status docker i'm seeing alot of
1608Z" level=warning msg="Failed to release ip address fd00::242:ac11:6 on delete of endpoint vigorous_moser (032124688c57279fe4c2d3b009657e9e0ecfcc3c3c864df1a25b401c56880e1b): invalid pool id: "
2136Z" level=warning msg="Failed to release ip address fd00::242:ac11:6 on delete of endpoint jolly_kepler (1dbea71fb955424e3375d1160ba46a5506c211c07498c5c3611668d2b8726c31): invalid pool id: "
7042Z" level=warning msg="Failed to release ip address fd00::242:ac11:6 on delete of endpoint relaxed_snyder (5949395cb5706d0fab0a19ae7e3a81ff2e2b616b7d511d0a8a9b8989fb2852c0): invalid pool id: "

vigorous_moser, jolly_kepler and relaxed_snyder are deleted adoptopenjdk/ubuntu1604_build_image containers.
Earlier, the address fd00::242:ac11:6 was associated with a running debian docker static container on that host, which made me suspect that docker is trying to assign this address to adoptopenjdk/ubuntu1604_build_image containers but can't because it is in use by the debian container.
├─621944 /usr/bin/docker-proxy -proto tcp -host-ip :: -host-port 2211 -container-ip fd00::242:ac11:6 -container-port 22
...
30c474a94c16  aqa_deb11  "/usr/sbin/sshd -D"  7 months ago  Up 21 minutes  21/tcp, <IP_ADDRESS>:2211->22/tcp, :::2211->22/tcp  deb11.2211

I removed the debian container and then tried rebuilding adoptopenjdk/ubuntu1604_build_image but no luck. Got the same error

Restarting the machine has solved the problem. Am able to create docker images on the machine without hitting the address in use error
Ive added 3 new nodes to the machine
https://ci.adoptium.net/computer/test-docker-ubuntu2204-armv8-3/
https://ci.adoptium.net/computer/test-docker-ubuntu2204-armv7l-1/
https://ci.adoptium.net/computer/test-docker-ubuntu2204-armv7l-2/

Added a Ubuntu 2004 node to the same dockerhost
https://ci.adoptium.net/computer/test-docker-ubuntu2004-armv7l-4/
https://ci.adoptium.net/job/AQA_Test_Pipeline/207/console

Im going to close this since the error no longer appears


Forming the correct "rxpk" and "txpk", Lora-Semtech-Bridge or LoraServer and the "rfch" to go for

At the moment When LoraServer forms a packet and sends it over MQTT, we see something like the message below before it hits the Lora-Semtech-Bridge.
{"txInfo":{"mac":"008000000000aaaa","immediately":false,"timestamp":1886440700,"frequency":925700000,"power":20,"dataRate":{"modulation":"LORA","spreadFactor":10,"bandwidth":500},"codeRate":"4/5"},"phyPayload":"FFoo="}
Late on the bridge receives this and makes it like how LoRaWAN package should look like,
{"txpk":{"imme":false,"tmst":1886440700,"freq":925.7,"rfch":1,"powe":20,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":17,"data":"ffOO"}}
One idea could be that in the long run, just to map the values to the correct format on the LoraServer  dependent on the chip we are sending it to (in this case Semtech).
And also some information such as the rfch value is never been assigned through the code so it gets defaulted to zero on txpk. This limits the gateways e.g. with only Radio 1  enabled (set in the packet forwarder) cuz the txpks sent over rfch 1 will be replied on rfch 0 rather than 1.
So I was thinking in the normal situation which the hybrid gateway is using it's both rfchs (both SX1257 s), why not to actually alternate the rfch on the txpk at the LoraServer to share the load between two SX1257s rather than hammering one all the time.
This also could potentially prevent the packages to be overwritten on SX1301 until they move the experimental-Just-in-Time-Queue implementation of Semtech Packet Forwarder to the master branch and release it.
(Meanwhile, the easy solution) would to read the rfch value from rxpk and assign it to the same key on rxpk rather than letting it getting defaulted. :raised_hands:

I think rfch parameter is to distinguish between several RX paths (aka physical antennas) rather than SX1257 chips. Imaging a high performance gateway with three sectorial antennas and three SX1301 chips. rfch indicates which sector received from.
typical gateway implementations use two SX1257 chips and both share the same antenna, both are RX capable but only one is TX capable. In this case I think rfch should be always 0. But maybe there is some gateway with two SX1257, both RX and TX capable and each one use different antenna, in this case rfch can be 0 or 1.
As a resume,  if the network server want to send a message to a node, it must use the same rfch than the one through previously received a message.

I did some testing with this, if I remember correctly I was unable to send using rfch=1. Will do some more testing tonight.

Just did some testing again. The join-request was received on rfch: 1. The join-accept was sent with the same rfch: 1 to the gateway. This resulted in the following error (packet_forwarder):
ERROR: SELECTED RF_CHAIN IS DISABLED FOR TX ON SELECTED BOARD
WARNING: [down] lgw_send failed

Snippet from my radio config:
       "radio_0": {
            "enable": true,
            "type": "SX1257",
            "freq": 867500000,
            "rssi_offset": -166.0,
            "tx_enable": true
        },
        "radio_1": {
            "enable": true,
            "type": "SX1257",
            "freq": 868500000,
            "rssi_offset": -166.0,
            "tx_enable": false
        },

To be honest I just recently got to know that radio tag has those extra keys from an IM880 datasheet (which I don't own). Mine is very simple
   "radio_0": {
       "enable": true,
       "freq": 915500000
   },
   "radio_1": {
       "enable": true,
       "freq": 916300000
   }

Have you tried setting tx_enable to true? (I mean for testing purposes)
@nestorayuso

typical gateway implementations use two SX1257 chips and both share the same antenna, both are RX capable but only one is TX capable.

By "TX Capable" you mean the actual physical capability? If so, I wasn't aware of SX1257 have two edition. And if software enables (capable) what stops us from enabling them both?
And also, as I mentioned before most of my knowledge in this part is based on guesswork. I would wonder where did you learn these information from
such as,

rfch parameter is to distinguish between several RX paths (aka physical antennas) rather than SX1257 chips

Cheers guys

there is only one implementation of sx1257. with capable or not capable I mean enabled in the json file and physically routed tx pins in a pcb to a balun, PA, antenna.
my knowledge is based on guesswork too and maybe i am wrong on rfch or other assumptions

Let guess our way to the success :smile:
The downside of any new tech. No doc and lots of potential.
So you reckon what would the problems if we enable both radios to TX as well.
Thanks for the reply

As your gateway's pcb does not route physically TX pins to a balun... If you enable it in json, the TX range will be zero or few centimeters.


DOC:Update the learn.md

What's wrong with the existing documentation
As your app is dockerize and also have kubernetes so i want to update learn.md for this so that user feel easy to run this ap through docker and kubernetes
Add ScreenShots
no screenshot neede
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@agarwalhimanshugaya Issue assigned to you


environ was not find by heroku

tried to deploy my app but i encounter this issue ,think i did correctly!
remote: -----> $ python manage.py collectstatic --noinput
remote:        Traceback (most recent call last):
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/environ/environ.py", line 403, in get_value
remote:            value = self.ENVIRON[var_name]
remote:          File "/app/.heroku/python/lib/python3.10/os.py", line 679, in __getitem__
remote:            raise KeyError(key) from None
remote:        KeyError: 'SECRET_KEY'
remote:        The above exception was the direct cause of the following exception:
remote:        Traceback (most recent call last):
remote:          File "/tmp/build_d1c609fa/manage.py", line 16, in <module>
remote:            execute_from_command_line(sys.argv)
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
remote:            utility.execute()
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute
remote:            self.fetch_command(subcommand).run_from_argv(self.argv)
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/core/management/__init__.py", line 266, in fetch_command
remote:            settings.INSTALLED_APPS
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/conf/__init__.py", line 87, in __getattr__
remote:            self._setup(name)
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/conf/__init__.py", line 74, in _setup
remote:            self._wrapped = Settings(settings_module)
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/django/conf/__init__.py", line 183, in __init__
remote:            mod = importlib.import_module(self.SETTINGS_MODULE)
remote:          File "/app/.heroku/python/lib/python3.10/importlib/__init__.py", line 126, in import_module
remote:            return _bootstrap._gcd_import(name[level:], package, level)
remote:          File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
remote:          File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
remote:          File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
remote:          File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
remote:          File "<frozen importlib._bootstrap_external>", line 883, in exec_module
remote:          File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
remote:          File "/tmp/build_d1c609fa/btre/settings.py", line 21, in <module>
remote:            SECRET_KEY =env('SECRET_KEY')
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/environ/environ.py", line 197, in __call__
remote:            return self.get_value(
remote:          File "/app/.heroku/python/lib/python3.10/site-packages/environ/environ.py", line 407, in get_value
remote:            raise ImproperlyConfigured(error_msg) from exc
remote:        django.core.exceptions.ImproperlyConfigured: Set the SECRET_KEY environment variable

Looks like you did not set the environment variables before deploying. Did you follow our page?
You might have, but the line with the problem doesn't look like it was generated by cookiecutter-django:
# btre/settings.py
SECRET_KEY =env('SECRET_KEY')

Which is quite different from how the secret key is set on prod:
https://github.com/cookiecutter/cookiecutter-django/blob/ee20b4d156d2e4165d6f69331da4dcbc8c526337/{{cookiecutter.project_slug}}/config/settings/production.py#L19
Did you change it? If so, you need to set the environment variables accordingly.
Hope that helps 😄


Fix deselecting node

When clicking away, it should remove the infobox

I can no longer reproduce this issue on main


[Feature request] Command Line Interface

I think a commandline in interface would be very handy to automate conversion. E.g. I would like to integrate qStrConverter into my CI in a workflow where I commit in an xlsx file and have it generate the ts.
This of course does not work with a GUI so a pure command line interface is needed.
an example usage would be:
qTsConverterCli xlsx-to-ts --in=myfile.xlsx --out=myfile.ts

So I looked at the tests to get an Idea about the internals of qTsConverter and I think this should be fairly straightforward to implement witth Qt included Batteries.
I could make a PR for this, but I don't know if you guys maybe have your own ideas about how it should work. Just let me know, but for my workflow it would enough improvement to invest some work on my side ;)

Thank you for the suggestion :), CLI version can be very handy, I will work on the first draft of implementation!
After this you can add more feature or arguments in easy and fast way :)

@joernweissenborn first simple implementation done in master... Let me know if can be a good start :)

I will try it out asap. Maybe you can add a small usage to your readme?
Otherwise thanks for the effort!

One question: how to you handle exceptions? For usage in CLI one needs a non zero exit code if problems are encountered.

I will take care of that

So I tried out the interface now, works fine :+1:
Haven't tested exceptions so far.

I close this issue... If you have other specific requests feel free to open other requests :)


subnet bits should not be modified if tenant has instances

Updates to subnet bits should not be allowed if there are already tenant IPs allocated.

also - all cncis should be removed.


Closes #523 #524 - Create 'fluo list' command to list all Fluo applic…

…ations
within a Fluo instance.  Allow Fluo commands to be run without apps
directory configured.

Noticed that the list command ignores extra arguments.
Fluo instance (localhost/fluo) contains 2 applications

Application         Status
-----------         ------
app2                STOPPED
app1                STOPPED

Command line should no longer ignore extra argument in 60aed4c1f

+1


Current 0.3 Sink interface inflicts complexity on implementers

In my existing futures 0.1 Sink implementations, the single start_send method was able to access the SinkItem (it needs the item buffer's length), calling tokio_threadpool::blocking if necessary and depending on that result, consuming the item buffer and returning Ready, or giving the item back via NotReady:
https://github.com/dekellum/body-image/blob/316596356fd72042cba2c6c4dc00b584ea99576d/body-image-futio/src/uni_sink.rs#L68
I'm now trying to port these Sinks to futures 0.3-alpha. With the current Sink interface, it is necessary to signal any potential for Poll::Pending (for Sink meaning lack of readiness to receive) in the trait method poll_ready, before the Item buffer is given.
https://github.com/dekellum/body-image/blob/316596356fd72042cba2c6c4dc00b584ea99576d/body-image-futio/src/uni_sink.rs#L134
The futures compatibility layer already deals with this interface difference, in the Sink01As03 shim (#1364), by maintaining an additional buffer of one Item, and deferring the actual consumption of that Item to subsequent calls to poll_ready and poll_flush.
I couldn't find an original rationale for this change to the Sink interface? Intuitively I would think it should simplify aspects of the Forward combinator, but at the expense of pushing the issue to most Sink implementers, where the complexity risks bugs.  As we are still alpha, is there any willingness to reconsider this interface change? Alternatively, would it be reasonable to introduce here some alternative trait, e.g. TardySink:
/// A sink which doesn't know it's readyiness until it tries to consume an Item
trait TardySink<Item> {
    type SinkError;

    fn poll_send(self: Pin<&mut Self>, cx: &mut Context, item: Item)
        -> (Poll<Result<(), Self::SinkError>>, Option<Item>);

    fn poll_flush(self: Pin<&mut Self>, cx: &mut Context)
        -> Poll<Result<(), Self::SinkError>>;

    fn poll_close(self: Pin<&mut Self>, cx: &mut Context)
        -> Poll<Result<(), Self::SinkError>>;
}

...and impl Sink<Item> for TardySink<Item> using the same 1-item buffering strategy as in Sink01As03, but not depending on anything from futures 0.1?  Note, the tuple return type of poll_send above is awkward. An alternative would be a TardyPoll<Item> enum with TardyPoll::Pending(Item) variant and some easy conversion to Poll.

So I think the goal around splitting poll_ready and send is similar to the goal for why we have poll_ready in tower_service::Service. It allows you to send items off task and poll for readiness separately from having to submit an item. I think for your usecase you could just have a sink inbetween that buffers and does the calculations then submits similar to the compat type.

The counter to that goal, is that at least a subset of Sink implementations, where readiness is either (minimally) dependent on the Item, or worse as in my case, were readiness can't be determined until we make a sometimes costly attempt to consume the Item.
To your last point, yes I agree, my proposed support would also need a TardySinkWrapper<T: TardySink> struct to hold the 1-Item buffer. It can't be a blanket impl Sink<Item> for TardySink<Item>.  Bare with me—so far I don't fully understand your impl. in #1364, Compat01As03Sink. How much simpler does that get if something like TardySink exists which uses Pin, etc, and is otherwise more consistent with 0.3?

I've made some progress implementing 0.3 Sinks for both my original application (early links for which are above) as well as a draft attempt at independent reusable generic helper types for the same.  Basic tests are passing, including with Pending scenario's.   Here is a more complete generic TardySink trait and BufferedSink wrapper type:
https://github.com/dekellum/tardy-sink/blob/master/src/lib.rs#L51
Unfortunately there is still a lot about Compat01As03Sink I don't understand, which is worrisome, and I suspect I won't be the last Sink (0.3) implementer to have these questions.  Most notably:

Why does it bother spawning the inner 0.1 Sink on a (potentially Independent?) 0.1 executor and using the returned Spawn::poll_fn_notify,  while my simpler implementation and tests, doesn't appear to need this?

Unlike Compat01As03Sink I'm currently imposing some Unpin bounds on the TardySink impl and its Item. I'm not sure if that makes mine too restrictive, or how hard it would be to remove those bounds?

So I would appreciate some feedback on this with either of the following goals in a new PR:

To include this in futures 0.3 for reuse and living documentation, not relegated to the compat feature.

Offering this as part of the documentation and as an example (though, I'm not sure which crate and examples directory it fits in).

Why does it bother spawning the inner 0.1 Sink on a (potentially Independent?) 0.1 executor and using the returned Spawn::poll_fn_notify,  while my simpler implementation and tests, doesn't appear to need this?

That's the compatibility layer, we need to map any 0.1 task::current().notify() to the 0.3 cx.waker().wake(), this is done by sort of running the current poll within a slim executor that does that mapping. If your implementation is 0.3 native it doesn't need this.

Unlike Compat01As03Sink I'm currently imposing some Unpin bounds on the TardySink impl and its Item. I'm not sure if that makes mine too restrictive, or how hard it would be to remove those bounds?

Those bounds can be removed by adding some pin-projection in to the BufferedSink implementation, I would recommend dropping the where Self: Unpin, Item: Unpin from TardySink directly and just have those bounds on the BufferedSink to make removing them in the future easier (hopefully at some point we will have some good documentation on how to do pin-projection...)
(Whether this should be added to futures, I'm not sure, I don't know what all the tradeoffs between the two APIs are, and it seems bad to offer both as interfaces that could be used by libraries, but having a way to easily implement whatever the Sink API is no matter what your underlying data model supports seems useful).

That's the compatibility layer, we need to map any 0.1 task::current().notify() to the 0.3 cx.waker().wake() [...] If your implementation is 0.3 native it doesn't need this.

That's a relief, thank you. I though I might be missing something fundamental.

seems bad to offer both as interfaces that could be used by libraries, but having a way to easily implement whatever the Sink API is no matter what your underlying data model supports seems useful.

Fair enough. So it does come back to the need for clarification as to the intention/goals of the 0.3 Sink interface change, and to calibrate against the induced complexity, how frequently Sink implementations have readiness dependent on the Item.
Who might be able to authoritatively answer?

Those bounds can be removed by adding some pin-projection in to the BufferedSink implementation

I managed to implement the pin-projections and removed the Unpin requirement:
https://github.com/dekellum/tardy-sink/blob/master/src/lib.rs

RFC: Any positive or negative opinion on at least the problem statement of this issue?  @cramertj? @taiki-e? @seanmonstar?   (Just picking folks I see contributing/commenting frequently on the project, who haven't yet commented. Apologies if this is unwelcome.)
If something like TardySink is only rarely needed, then I guess I could package this as a small standalone crate.  If it will be a common enough problem, asked about here repeatedly and needing a documented solution, then I could offer a PR to merge this here. In futures-sink crate, specifically?

@dekellum I'm sorry if i may be missing something but at a high level im assuming what you want is something like this? https://github.com/libra/libra/blob/master/network/src/sink/buffered_send.rs

I haven't commented because I thought others did a fair job.

Any positive or negative opinion on at least the problem statement of this issue?

I read through the original issue, and the replies, and now I don't know what exactly the problem statement is.

@LucioFranco At a quick glance, your BufferedSend link looks like about half of whats needed to fix the problem described here. It does the one-buffering (e.g. Option<Item>, but it doesn't offer a single method allowing underlying readiness to be dependent on the Item (length in my case).    Could you describe how this is used in libra or by libra users?  I'm interested, if you are interested, in seeing if this libra use case could be solved with the same TardySink or similar here.

@seanmonstar  Fair enough, my initial report was less informed/articulate and the thread spends more time on solution implementation details.
Reformulated Problem Statement
There is at least a subset of Sink implementations, where readiness is either (minimally) dependent on the Item, or worse as in my case, were readiness can't be determined until we make a sometimes costly attempt to consume the Item.
In futures 0.1, the Sink interface directly supported this need (allowing the SinkItem to be returned in the single start_send method. In futures 0.3 (as of alpha 16) this interface has been changed, such that readiness must be indicated (via poll_ready) before the Item is seen. The way to deal with these conflicting needs is to buffer one Item, but implementing this may be overly challenging and bug prone for every user that needs it.

Thus I'm offering and suggesting merging such a secondary utility as TardySink (yes, naming is hard) as in https://github.com/dekellum/tardy-sink/blob/master/src/lib.rs here.

@dekellum

It does the one-buffering (e.g. Option<Item>, but it doesn't offer a single method allowing underlying readiness to be dependent on the Item (length in my case).

How about SinkExt::buffer?

I saw SinkExt::buffer, @taiki-e, an its implementation informed TardySink.  I assume (but have not profiled) the Option<Item> of TardySink has some perf advantage over VecDeque<Item> of capacity 1, but more importantly, Buffer just wraps over the same futures 0.3 Sink interface, so it doesn't satisfy the need of seeing Item to decide readiness, as in TardySink::poll_send.

I think this is safe to close now that there are workarounds (although they may not have exactly the same performance characteristics of those based on the previous Sink trait). The current shape of the Sink trait was informed by quite a bit of feedback, and I don't personally think there's enough evidence here to suggest that we should go back to the original signatures.

Part of what I was looking for, in opening this issue 5 months ago, was the details of "quite a bit of feedback" and the design justification for the new Sink trait.  I'm sure there must have been reasons for it, but I haven't to date been able to find it.   Yes I found a workaround in the course of this.  I'm not sure how easy it will be for anyone else to find, left as is, or via this closed issue.


vulkan-loader: demos: fix cube/cubepp

Motivation for this change
Working dir needs to be at the binary location, otherwise some assets aren't found.
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Thanks.  This looks good to me.  I assume these are the only two demo executables that need this in the current sdk?  There used to be 'tri', but I think that got removed.
Also, 'smoketest' doesn't need cwd set, does it?

Yes, smoketest runs fine as is. cube, cubepp and smoketest are the only binaries in the demos output.


RFC / useTransition 🤯 and possible improvements

As we all know, transitions are hard. 🤯
If you want put your ideas in here and we'll discuss them, no matter how wild they are.
What people don't easily understand is that transition is a value retainer, it's not magic, it just saves a value (or an array of values) and looks for the addition or removal of keys. On changes it can retain the old value and pass it to the view, so that it can fade out an old state. So that has to be expressed better in the docs for sure. But the api is a little weird, too.

A transition result is always an array. In theory this probably cannot change since there are reasons for it, it has to be documented better. Maybe it can be abstracted, though.

That array contains objects made of { item, key props }, which is weird. Often people see "item" down in the view section and don't know where it comes from. This can be changed.

Some ideas:
// Proposed shortcut signature, if items are atomic (as in, items serve as keys)
const items = ['each', 'item', 'can', 'serve', 'as', 'a', 'key']
useTransition(items, config)

// When items aren't atomic it needs a key-accessor to recognize items
const items = [{ id: 0, text: 'hello' }, { id: 1, text: 'world' }]
useTransition(items, item => item.id, config)

// Function abstraction?
// Shorter, saves user from worrying about keys, retained item can be named properly
const transition = useTransition(visible, { from: {}, enter: {}, leave: {} })
return transition((visible, style) => visible && <a.div style={style}>hello</a.div>)

The current solution:
const transitions = useTransition(visible, null, { from: {}, enter: {}, leave: {} })
return transitions.map(
  ({ item: visible, props, key }) =>
    visible && (
      <a.div key={key} style={props}>
        hello
      </a.div>
    )
)

One thing that would be amazing (and maybe you can already do this, but i just don't know how) is to be able to imperatively update and access the spring that results from the transition. I've been finding it difficult to combine transitions with gesture based controls, so I usually just end up using useSpring and manually unmounting using onRest callbacks.
Maybe something like this (pseudo code)?
return transition((visible, style, set) => {
 const someGestureFn = (x) => set({ x })
 return visible && <a.div style={style}>hello</a.div>
})

@bmcmahen indeed, useTransition is the only hook that doesn't support set. We could extend the signature as we have done with the other hooks:
const transitions = useTransition(items, config)
const [transitions, set] = useTransition(items, () => config)

// Proposed shortcut signature, if items are atomic (as in, items serve as keys)
const items = ['each', 'item', 'can', 'serve', 'as', 'a', 'key']
useTransition(items, config)

👍 on the new useTransition overload
The proposed "function abstraction" is kinda like renderprops for hooks. I like how it abstracts away the responsibility of passing a key, but maybe it's too much magic for some people? I say go for it.
I think making the transition callback's argument an object is the right choice, because it encourages everyone to use the same variable names (when destructuring the property names). Also, it allows for more properties to be added in the future if necessary. We could even add a setter method to the object argument (aka: the item) by default.

Another idea would be to normalize the api and remove the two signatures in favour of an optional dependencies array, like useMemo/useEffect/useCallback:
const [props, set] = useSpring({ opacity: show ? 1 : 0 }, [show])
const [springs, set] = useSprings(items, item => ({ opacity: show ? 1 : 0 }), [show])
const [springs, set] = useTrail(items, { opacity: show ? 1 : 0 }, [show])
const [transition, set] = useTransition(items, { from: { x: 0 }, enter: { x: 1 } }, [])

I would like this very much. Would reduce the api surface and would help us to figure out changes.

This is already added to useSpring and useSprings in v9 (thanks to @Nizarius).
Except it doesn't cause a setter to be returned. (which I'm not a huge fan of. I like the function syntax for setter mode)

Hi Paul! Thanks for creating this awesome animation library. I've been trying to wrap my head around react-spring for a couple of days now, so here are a few observations from a newbies perspective, hope that helps.
First of all, I was somewhat confused about the different function signatures with set. Why would you need that in the first place? Can't you just always return an array  [props, set] and let the user ignore set if they don't need it?
// either
const [props] = useSpring({opacity: show ? 1 : 0})
// or
const [props, set] = useSpring({opacity: 0})
set({opacity: 1})

This feels much more natural to me, kinda looks like the useState-Hook if you squint a bit.
Second, the useTransition-API was really confusing and unintuitive for me as a beginner as well. I had a simple use case (fading out a single component on unmount) that I wanted to implement, but which felt very awkward with the current API. I kept asking myself things like "why does it return an array? I just want to animate a single component..." or "what is this whole key thing about?". I think your function abstraction suggestion would definitely be a move in the right direction.
That being said, I really enjoyed the solution for animating transitions that react-pose  went for, which is extremely simple and elegant. I wonder if something like that would be possible with react-spring, too. It might look something like this (just spit-balling, not sure if that could even work with the way react-spring is built):
import { animated, useTransition, Transition } from "react-spring";

const [props, set] = useTransition({
  from: {}, enter: {}, leave: {},
});

return (
  <Transition>
    {visible && <animated.div style={props}>hello</animated.div>}
  </Transition>
);

Transition would be responsible for handling its childrens mount/unmount-animations, similar to react-pose's PoseGroup.
Additionally, if you have a list of elements, you could have a useTransitions-Hook which would be a sort of transition-equivalent of useSprings:
const [transitions, set] = useTransitions(items, items => items.key, {
  from: {}, enter: {}, leave: {},
});

return (
  <Transition>
    {transitions.map(({ item, key, props }) => (
      <animated.div key={key} style={props}>
        {item.text}
      </animated.div>
    ))}
  </Transition>
);

I feel like splitting useTransition into two things similar to useSpring/useSprings could actually simplify a lot of use cases. I'm not sure how much of that is actually feasible, I just wrote it down the way it makes the most sense to me from a beginners perspective. Hope that helps!

I like the idea of splitting useTransition into two things. Maybe useListTransition and useTransition. The latter for single component mounts and unmounts. As a newbie, using arrays and keys when trying to animate a single component on mount / unmount (ie a modal) was a bit confusing 😄

@biowaffeln
const [props, set] = useSpring({opacity: 0})

would set opacity to 0 on every render pass. if the parent decides, for whatever reason to render, opacity will go zero. but this can be fixed using dependencies:
const [props, set] = useSpring({ opacity: visible ? 1 : 0 }, [visible])

And i agree, this should be the only documented api signature.
As for transition and pose's approach. I don't like it. I need things to be explicit without going into too much overhead. But that wrapper is magic again, and it will use React.cloneChildren and mutate stuff. React-spring is shooting for something that gives you control. In this case it costs 1 or 2 lines more, will i think sometimes it's worth it.

Isn't internally generating the keys an option, perhaps using a WeakMap, so the short signature can be used for everything?

@mfarhadpur which signature?

@drcmda He's talking about omitting the item => item.key argument.
@mfarhadpur Yeah, that sounds like a great idea! It doesn't even need to be a WeakMap, just a Map will do.

@drcmda Yes, I mean the proposed useTransition(items, config) as @aleclarson explained.

That could work!

@drcmda So, it's coming ?:)

still in consideration. the only worry i have is having yet another major for this. it would simplify the api, since you only need one signature. but people would have to adjust their code once again. there's a pr now that had this working, it looked good to me at least.

@drcmda Checking the arguments passed would enable supporting both "legacy" and new API, no?

Anyone that wants to implement what @phaistonian said is welcome to. Just follow these commands:

git clone https://github.com/react-spring/react-spring.git -b v9-api #670
git remote add <user> https://github.com/<user>/react-spring.git (replace <user> with your name, and be sure to fork this repo)

I don't currently need this, but it's nice to have for sure.

Checking the arguments passed would enable supporting both "legacy" and new API, no?

Hmm, sure about that? For instance ...
const props = useSpring({ x: 1 })

would now be:
const [props /*, set*/] = useSpring({ x: 1 })

The call signature is the same but the result is different.

For v9, we could require the deps array to opt-in to the [props, set, cancel] return signature.
// Still works like v8
const props = useSpring({ x: 1 })

// These are equivalent in v9 (but the latter is deprecated)
const [props, set] = useSpring({ x: 1 }, [])
const [props, set] = useSpring(() => ({ x: 1 }))

interesting ... you two saved the day! 😍

Indeed that could work - sorry for being late to this part :)
ps: The API is half of the project; it defines scalability, attraction, and endurance. Not once have I regretted introducing breaking changes in favor of extra "sanity".

The new API for useTransition is being worked on here: https://github.com/react-spring/react-spring/pull/750

Now available in v9.0.0-rc.2 #985


[CORE-645] Nebula - Add active chain in context filters

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR enhances the ChatPageContent component by integrating the useActiveWalletChain hook, allowing it to manage the active wallet chain alongside the active account. It refines context filter handling and updates the logic for setting wallet addresses and chain IDs.
Detailed summary

Added useActiveWalletChain to manage the active wallet chain.
Renamed _contextFilters to contextFilters for clarity.
Updated setContextFilters to use useCallback.
Refined context filter logic to include wallet addresses and chain IDs.
Adjusted conditions for updating context filters based on user interactions and active account/chain presence.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#5782  👈 (View in Graphite)
main

How to use the Graphite Merge Queue
Add either label to this PR to merge it via the merge queue:

merge-queue - adds this PR to the back of the merge queue
hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.


stat sinks/tracers: use new style names

Modifies the well-known-names of the built-in stat sinks and
tracers to use the same name as the extension build system.
(Repeats #9921 for two new factory types.)
Risk Level: low, previous name is still accepted
Testing: existing tests + deprecated tests for old names
Docs Changes: updated names
Release Notes: updated
Deprecated: old names are logged as deprecated
Signed-off-by: Stephan Zuercher<EMAIL_ADDRESS>

No rush on this one.


feature: pass request to render:route hook

Resolve #2749
@Atinux @pi0 I modified the hook as #2749 described, could you help to review and make a decision?

Codecov Report

Merging #2754 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev    #2754   +/-   ##
=======================================
  Coverage   99.91%   99.91%
=======================================
  Files          23       23
  Lines        1211     1211
=======================================
  Hits         1210     1210
  Misses          1        1

Impacted Files
Coverage Δ

lib/core/middleware/nuxt.js
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hey :)
I agree to give it as 3rd parameter instead to have no breaking change and looks more like our renderRoute method. Why not giving the context as 3rd parameter directly?

@Atinux Changed.


Fixed t2-unlimited bug (related issue #35)

Thanks @suizman for reporting the bug!

v1.9.0 has been released.

Hi,
What if we don't want to have t2 unlimited checked? Is there a way to make that an input variable?


Set OSABI to Standalone

OSABI has broken between nightly-2022-04-25 and nightly-2022-04-26: https://github.com/rust-lang/rust/compare/18f314e7027fe7084aaab8620c624a0d7bd29e70...055bf4ccd521c2c2185166c86951be7be145727c

I opened https://github.com/rust-lang/rust/issues/97535.


Save scrolled position

First of all, thanks for this project, looks very nice!
Is it possible to access the current scrolled position and return to it programmatically?
Let's say I'm currently on a tab where I need to scroll to; somewhere on the far right of the total amount of tabs. External changes need me to re-initialize the scrolling tabs and basically 'resets' the scrolling to the far left. I can off-course 're-click' the formerly active tab with jquery, but I also would like to automatically 're-scroll' to the position of the this tab, is this possible?
Hopes this makes sense to you..

Sry, missed the
$('.nav-tabs').scrollingTabs('scrollToActiveTab');

Tried the:
$('.nav-tabs').scrollingTabs('scrollToActiveTab');

That isn't working for me

Would you be able to put together something that demonstrates your scenario and scrollToActiveTab not working?
Here's a codepen showing it working: https://codepen.io/mikejacobson/pen/eYVYLLK
After a small delay, it programmatically selects Tab 15 and then scrolls to it using scrollToActiveTab.
Maybe you could use that as a starting point?
It's difficult to troubleshoot without seeing how you're using it, but you might want to try calling scrollToActiveTab after a slight delay using setTimeout—maybe the tabs just need a moment to stabilize after the new tab is selected and before scrollToActiveTab is called?

Mike; Thanks so much... It was a typical case of RTFM.... I needed to set the correct Bootstrap version in the settings.... Bootstrap 3 sets the 'active' class different then Bootstrap 4 (or later) does. Setting 'Bootstrap: 4' in the init settings totally did the trick!


Still working?

I've just bought a new Win 11 home  PC.
Does this still work with the latest Win 11 edition?
If not, is there an alternative?
Thanks.

I installed it on Windows 11 23H2 (22631.4112) and noticed the automatically downloaded files overwrote Windows 11 original files... but the fact is they have a different length (and date)!
E.g.:
BEFORE:
...
15/05/2024  19:29            36.992 AppPrivacy.admx
...

AFTER:
...
07/12/2019  02:09            32.147 AppPrivacy.admx
...

🤔I don't think it's good...

It seems there are newer ADMX files for my Windows 11 23H2 available for download from MS servers:
Administrative Templates (.admx) for Windows 11 2023 Update (23H2)

Very curious too, hope it doesn't become abandonware :'(

@Fleex255  i wanted to take a moment to express my gratitude for the excellent work you’ve done on Policy Plus. It has been an invaluable tool, and its user-friendly design and functionality have made managing policies much more easier.
I was wondering if there are any updates or upcoming features planned for Policy Plus?
Thank you once again for your hard work and dedication. Looking forward to hearing from you.


Update SqlQueryBuilder.cs

If the table was in a different schema (than dbo) it added an unnecessary "dbo." prefix, which was causing an error when the SetOutputIdentity was true.

I have merged your commit but made some changes, fix was moved to TableInfo:
Schema = relationalData.Schema ?? "dbo";
And then there is no need for explicit schema since it will be added with FULL property.
q += $" OUTPUT INSERTED.* INTO {tableInfo.FullTempOutputTableName}";


Live

Docs Build status updates of commit 6b1d06d:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Toggle Theme Color

Related Issue
Fixes #718
Description
@SUGAM-ARORA I have changed the Toggle theme color to a new colour for the page that looks quite attractive for the website. Kindly review this.
Type of PR

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

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]
Checklist:

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

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

@Ojas-Arora Update branch


chore: Move instance to providers

Fixes #
Description
The goal is to move the instance provider to its own package to prevent import dependency that may be caused when trying to access the providers from controllers. This will also instantiate the instance as a singleton in the context.
How was this change tested?

Manually tested

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[ ] No

Release Note

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

We should think about adding tests as a suite_test.go for instance package. Can you create an issue to create tests for this package so that we track it properly?

#3514

Discussed offline. Are planning to create a test.Context function that instantiates the common context members for testing so that users don't have to individually define all the members when initializing a cloudprovider


Add instructions to run asset transfer flows using Fabric CLI

Update README in Weaver and Labs documents pages.

Fixed in #57


Implement future incompatibility report support

cc rust-lang/rust#71249
This implements the Cargo side of 'Cargo report future-incompat'
Based on feedback from alexcrichton and est31, I'm implemented this a
flag --future-compat-report on cargo check/build/rustc, rather than
a separate cargo describe-future-incompatibilities command. This
allows us to avoid writing additional information to disk (beyond the
pre-existing recording of rustc command outputs).
This PR contains:

Gating of all functionality behind -Z report-future-incompat.
Without this flag, all user output is unchanged.
Passing -Z emit-future-incompat-report to rustc when
-Z report-future-incompat is enabled
Parsing the rustc JSON future incompat report, and displaying it
it a user-readable format.
Emitting a warning at the end of a build if any crates had
future-incompat reports
A --future-incompat-report flag, which shows the full report for
each affected crate.
Tests for all of the above.

At the moment, we can use the array_into_iter to write a test.
However, we might eventually get to a point where rustc is not currently
emitting future-incompat reports for any lints. What would we want the
cargo tests to do in this situation?
This functionality didn't require any significant internal changes to
Cargo, with one exception: we now process captured command output for
all units, not just ones where we want to display warnings. This may
result in a slightly longer time to run cargo build/check/rustc from
a full cache. since we do slightly more work for each upstream
dependency. Doing this seems unavoidable with the current architecture,
since we need to process captured command outputs to detect
any future-incompat-report messages that were emitted.

r? @Eh2406
(rust_highfive has picked a reviewer for you, use r? to override)

cc @ehuss @pnkfelix

This can be tested on https://github.com/Aaron1011/arrayinto

Thanks!
I wouldn't worry about the caching of the -Z flag. I'm not expecting this to stay unstable for very long, but will give us a chance to test drive it.
As for errors, the answer is "it depends". Most of Cargo uses string-based errors with anyhow, and most errors are propagated with ?. We also try to be careful to add context to every message (particularly for file I/O which often results in confusing errors without context). There is a chain_err method to help with that (which should eventually be replaced with anyhow's with_context which is essentially the same).
I would recommend moving the code in the command module to the ops module. Generally the code in command is just arg parsing, and then the actual implementation is in an ops submodule. The ops side can return a CargoResult which is a little easier to work with than CliResult.
Since this is modifying the JobQueue, that area of Cargo is much more sensitive to managing errors since it must wait for all threads to finish even if there is an error. So, as you may have noticed there is some special handling of errors there.
It looks like you already found drop_println!, which deals with I/O errors.
As for tests, in the short term I think it would be fine just to pick a warning that is unlikely to change soon. An alternative would be to create a fake rustc that emits the appropriate JSON (the tests do that in several places like this. But that wouldn't be testing that it actually integrates with the real rustc properly. Another alternative would be to embed a fake lint in rustc directly, but I'm not sure if that's necessary.
As for handling canceled builds, it looks like you have support for that, which looks good to me. Is there a specific sequence of interactions that you are concerned about?
Let me know if you have any specific questions or particular areas you'd like me to look at. There's also the new Contributor Guide which briefly provides some overviews of things like error handling. If there's something missing there, it may be useful to help highlight what needs expanding.

As for handling canceled builds, it looks like you have support for that, which looks good to me. Is there a specific sequence of interactions that you are concerned about?

If a user performed the following actions:

Run a build to completion, which produces a future-incompat-report
Change a bunch of things
Start a new build, but immediately kill it before we opened and truncated the previous report
Ran cargo describe-future-incompatibilities

Then 'stale' warnings would be shown. I'm not sure that this really matters - I would expect people who really care about these warnings to have the commands run on CI, where they would always run to completioin.

Yea, I wouldn't worry to much about that specific sequence.  We can always gauge later if people run into confusing situations or stale entries or whatever. It should be relatively easy to tweak and change this command.
When reading the file, it might be good to be somewhat tolerant of errors (print anything if possible, and then display an error if it has problems deserializing it). That might help in case the file gets partially written or corrupted or was generated with a different version of Cargo that changes the format, but even that I wouldn't worry too much about.
It's tough to predict every confusing circumstance, but here's one possibility:

cargo test: shows a warning for a dev-dependency
User editor runs cargo check in the background which will delete the file (and not generate a warning since it is not checking dev-dependencies).
User runs cargo describe-future-incompatibilities and it prints nothing.

I'm not sure how likely that is. I'm not too worried about it, but those are the kind of weird things that might confuse people.

User's editor runs cargo check in the background which will delete the file (and not generate a warning since it is not checking dev-dependencies).

Oh, that's quite subtle. I think it would be a good idea to add a header (or footer) to the displayed message to tell the user which cargo command generated the report.

Nice work! I have only one minor criticism about the implementation, which is that it only prints the offending crate's name and never prints the version. The RFC specifies that cargo shall print the version if there are multiple packages with that name in the cargo build graph. I'd personally extend it from the build graph to the entire DAG encoded in Cargo.lock, basically using the same logic that adds version numbers to crates in Cargo.lock formats 2 onwards.
The reasoning why I asked for this to be added to the RFC was to make sure that users know which version is the offending one, so that they can base further actions on that.
From the maintainer POV of crates that yield such warnings, it might even be very useful to have the version number printed all the time, because the warning might not happen at the latest version of the crate but an older one. If the report includes the older unmaintained version number, the maintainer can immediately close the issue report and tell people to update (if that's their choice, maybe they consider the older version branch still maintained, then they want to publish an upgrade). If there is no version number in the report, the maintainer has to ask first which version of the crate creates the warning, or investigate themselves whether the latest version of their crate creates that warning, or whether it's an older version. It's more helpful to be told by the users though, because that's the version the users care about. Maybe it's 3 semver breaks ago, one never knows (and it doesn't help that the download graph of crates.io only lists a limited number of versions).

One of the reasons Cargo doesn't have the issues of reading files from old builds is that it's not something  that Cargo does today, basically for all the reasons mentioned here because it's quite hard. A case like @ehuss mentions above seems pretty worrisome to me, and could perhaps be solved by adding a CLI flag to cargo build (and other subcommands) rather than adding a new subcommand?

@pnkfelix What are your thoughts on @alexcrichton 's proposal? Would this require amending the RFC?

Actually that's a good point @alexcrichton . If the cargo describe-future-incompatibilities command would instead be a flag of cargo build/cargo check etc. it would be possible to reuse the cached json files that contain the output of rustc, thus removing the need for the extra level of caching that this PR adds. A bad alternative would be to make cargo describe-future-incompatibilities call cargo build etc. internally, but one doesn't know which precise command the user has put in previously, so one has to make a guess. The guess would be close but not precise though. Often it can lead to rebuilding of the entire crate graph only to give a result that maybe enables different cargo features etc. So a flag on cargo build/cargo check etc might be the way to go.

:umbrella: The latest upstream changes (presumably #8818) made this pull request unmergeable. Please resolve the merge conflicts.
Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@alexcrichton @est31: I've re-implemented this as a --future-incompat-report flag on cargo check/build/rustc, as you suggested. In additional to eliminating the race condition issues, this also made the implementation significantly less complicated.

@ehuss: This is now ready for review.
While I believe this still follows the spirit of RFC 2834, the describe-future-incompatibilities command does not exist at all. Do we need to amend the RFC with this change - if so, what is the process for doing so?

Oh, sorry, I just saw you sent an update here.  I apologize, I did not post a comment sooner before you made some changes. We discussed this a little in our team meeting.  There were two things that we discussed:
The concern of the temporal nature of the cache:  If the cache is deleted and recreated each time a command is run, there is some concern that it will be confusing if it fluctuates (based on what is built), and the time lag between seeing the notification, and the user running the command to display the report (during which other commands may have been run).  I personally don't feel strongly about it, but would it be possible to change the on-disk representation to accommodate that concern?  Perhaps it could retain the last N runs (maybe as separate files, or all in one file), and the command would by default display the last report, but have an option to display a specific (older) report?  This is instead of using a flag as suggested above.  Would you be willing to maybe go in that direction?
The other thing we discussed was perhaps changing the top-level command name.  I feel a little uncomfortable adding a lot of highly specific top-level cargo commands, since it can make it a little harder to document and for users to navigate.  I was wondering what you think about changing it so that there is a cargo report command that takes a sub-command argument, like cargo report future-incompatibilities.  This would allow us to add additional report-like features, like "show build timings", or "explain why the last build wasn't cached", and they can be grouped within a single command.
I don't think in general that design tweaks need to go through any sort of process to amend the RFC. As long as the spirit of the original RFC is retained, I think it is up to each team to decide on the final implementation.

Perhaps it could retain the last N runs (maybe as separate files, or all in one file), and the command would by default display the last report, but have an option to display a specific (older) report? This is instead of using a flag as suggested above. Would you be willing to maybe go in that direction?

Personally, I think this is very unlikely to be used:

If I want to see the report for a specific command (e.g. cargo check), I think just adding --future-incompat-report will be generally faster than looking up a specific report in a list. Adding a flag is fast and easy to type, while viewing a list requires the user to find the particular command they are looking for in a potentially long list of commands.

I think the two best use-cases of this feature are gating PRs on CI, and 'nudging' local users to update their dependencies when working on a crate locally. I don't think retaining a list of past reports is useful in either of those scenarios, and would require dealing with the various race conditions that @alexcrichton and @est31 were worried about.

The concern with a flag is that it may not be easy, or even possible to run cargo directly.  For example, if it is wrapped in another build system (like x.py), it may not be obvious which command to run, where to run it, which arguments to pass, etc.  Another concern is if someone is using an editor which uses cargo to drive messages, it also may be confusing to know how to recreate the same command on the command-line, and people sometimes have difficulty figuring out how to add additional cargo flags to the editor config.
In terms of the list, the intent is that the error message would specify exactly what you can run, maybe something like:
to see what the problems were, run `cargo report future-incompatibilities --report=7`

The user would copy and paste that, and see exactly which messages to display.  If they ran the command without any options, it could just display the last report.
I don't feel strongly about the difference, but I think the spirit of the RFC was to make it easy to view the report, regardless of what kind of environment cargo may be running in.

@ehuss: It looks like @alexcrichton and @est31 both expressed a preference for a flag over a command. Is there any more work for me to do at the moment, or should I wait for a decision to be made?

What about printing the path containing the report? Then you can just cat it.

I don't write out the report to disk in the new implementation - it gets constructed in-memory by processing the (potentially recorded) rustc output lines.

@ehuss

For example, if it is wrapped in another build system (like x.py), it may not be obvious which command to run, where to run it, which arguments to pass, etc.

One could argue that a flag is better for x.py because cargo generate-future-incompatibility-report would look inside the target directory, but rust's buildsystem would most likely put the report into somewhere inside build/.

Sorry but to elaborate on my comment from earlier, I wanted to point out my concerns with the strategy of "use the last file to issue the report" with races and such. One solution is a flag to the build command but another solution is as @ehuss mentioned which is to have some sort of identifier which can uniquely identify one report.
After discussing I personally lean more towards keeping it as a separate command. We've gotten a lot of cargo reports recently about how configuring the build command line options or environment is difficult due to the build invocation being buried in a different system somewhere. This is leading us to lean more heavily on configuration files which is an out-of-band way to configure Cargo's build such that everyone invoking doesn't have to implement their own solution. This is a case which I think falls into that where having a separate command to read the report I think makes the most sense at this point.

:umbrella: The latest upstream changes (presumably #8837) made this pull request unmergeable. Please resolve the merge conflicts.
Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

Before I re-add the separate command (with numbered reports), does everyone agree that this is the route we want to take?

Personally I think it'd be best for this separate command to take in a full path instead of an identifier, because those environments mentioned might move the target dir (e.g. by setting CARGO_TARGET_DIR) to locations that default cargo doesn't expect (x.py does this for example). And if it takes the full path, is it needed at all? Can the command offer significant features that go beyond cat? I lean towards yes, because it can detect whether the terminal supports ANSI colors or not, but that's about it.

Printing a full path would make this more difficult to use on CI - you would either need to extract the path from the Cargo output, or hard-code what you think it should be. A flag doesn't have those kinds of issues.

@Aaron1011 that's a good point I guess. Maybe one can have both a flag/.cargo config setting and a command?

I've rebased this against master.
I think having some version of this available on nightly would be useful in resolving questions about a flag vs command. Everything is gated behind -Z future-incompat-report, so we aren't comitting to anything.

Should I implement a separate command in addition to a flag, or can we land this with just a flag for experimentation?

If you'd like to land this immediately, then I would like to see the performance question resolved first, primarily for Windows. I don't think that's been followed up on. This is adding what has the possibility of being a nontrivial amount of work for incremental compiles of projects with many crates on, probably worst-so on Windows.
I am personally leaning towards a subcommand myself, but I'm not sure I understand the point about running on CI? How are users expected to run this on CI?

@alexcrichton How I interpreted that remark was: if you get a warning on CI how do you get the detailed message? You can add something like cargo print-future-incompat to the ci files, but if there is the requirement for randomly generated keys/ids or one needs to cat a file at a special location whose path contains a changing hash, then you can't really add that to the files unless you make it extract the path/id from the stdout which is weird. You need something that works all the time. That's where a flag would be useful. Or a .cargo/config setting or something like that.
Note that CI environments can compile different code from the one the local dev compiles. One example is platform specific dependencies. So debugging it outside of CI might not be really easy.

:umbrella: The latest upstream changes (presumably #8441) made this pull request unmergeable. Please resolve the merge conflicts.
Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

I ran some performance tests on Windows, and didn't see any significant issues (it adds maybe 1-5 ms with caches warm). That makes sense to me, because in the normal case there are no output files, so the only cost is to try to open a non-existent file for each unit, which should be pretty fast.
I still feel like I would prefer a separate command as opposed to a flag.  I've seen people have difficulty figuring out how to wire Cargo flags into editors or larger build systems, or get confused about how different commands build different sets of dependencies or with different features.  However, I don't feel strongly about it, since I don't expect these warnings to come up often in practice.  I can help with implementing it if you'd like.  We could also move forward with a flag and add a separate command at a later date if it seems like it is too difficult for people to use.  @alexcrichton Do you have a preference one way or the other?

I don't have a preference beyond being able to reliably match the output of the report with the invocation that produced the report, so either is fine by me.

:umbrella: The latest upstream changes (presumably #8934) made this pull request unmergeable. Please resolve the merge conflicts.
Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@alexcrichton Rebased against master

Ok thanks! We discussed this in a recent Cargo team meeting and concluded that for now a separate subcommand is the best option, however, rather than a flag-on-build. Would you be up for implementing that? The difference from before, however, is that an argument will indicate a report identifier of some kind to emit which is checked against the on-disk state to ensure it matches.

@alexcrichton: Is the report id required? If so, it seems somewhat cumbersome to require users to make up an id when they invoke the command.

I personally believe that it's important to solve the problem where if you get told you should get the future incompatibility report that when you run the command you should be guaranteed to get that report, not something created in the meantime. My assumptions is that Cargo will print a copy/pasteable command which would include the Cargo-generated ID in it.

For example, if it is wrapped in another build system (like x.py), it may not be obvious which command to run, where to run it, which arguments to pass, etc.

If you make it a flag you could use CARGOFLAGS to pass arguments to cargo. Making it a separate subcommand means you'd have to modify bootstrap itself.

I think it shouldn't be an either or, but a both. In some scenarios a flag or config setting are easier, in others a command is. Also the more methods there are, the less restrictive the feature feels to people.

@alexcrichton Does having both a flag and a command sound reasonable to you?

If it's a small handful of lines to have both that doesn't seem unreasonable, but I would otherwise imagine that we wouldn't want too many ways to do the same thing. It can be a burden in Cargo to support if we're not careful.

If it's a small handful of lines to have both that doesn't seem unreasonable, but I would otherwise imagine that we wouldn't want too many ways to do the same thing. It can be a burden in Cargo to support if we're not careful.

I've added back the cargo describe-future-incompatibilities command. It's invoked like this:
cargo describe-future-incompatibilities --id <ID>
The ID can be obtained from the last invocation of a cargo command (e.g. cargo build). Currently, the id is generated via the UUID crate (which I added as a dependency), but I'm open to alternatives.
If the provided id does not match the id stored in the file, the report is still printed (with a warning displayed before and after it). This should avoid frustrating situations where a user knows a report exists, but cannot access it.

I've added back the cargo describe-future-incompatibilities command. It's invoked like this:
cargo describe-future-incompatibilities --id <ID>
The ID can be obtained from the last invocation of a cargo command (e.g. cargo build). Currently, the id is generated via the UUID crate (which I added as a dependency), but I'm open to alternatives.
If the provided id does not match the id stored in the file, the report is still printed (with a warning displayed before and after it). This should avoid frustrating situations where a user knows a report exists, but cannot access it.

@alexcrichton: Are there any changes that you'd like me to make>

@alexcrichton: Are there any changes that you'd like me to make>

:umbrella: The latest upstream changes (presumably #8037) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #8037) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton: I've addressed your comments

@alexcrichton Are there any changes that you'd like me to make?

:umbrella: The latest upstream changes (presumably #9175) made this pull request unmergeable. Please resolve the merge conflicts.

Rebased

I wanted to write a few more concerns about the implementation. I don't think any of these need to be addressed now, but I think they need to be considered eventually.

The way color is handled seems a little awkward. One of the use cases is that the user runs cargo in an editor, sees the message that they need to run cargo describe-future-incompatibilities, they do that, and the message isn't colored. Not a big deal, color isn't super important, but that seems like a common situation. Ideally I would think the report data would be saved to the file in a more raw form, and then just re-render it as requested.
This doesn't really work in editors (the user will never see the warning). It's a bit of an unfortunate behavior of Cargo in general (#8283), and the way most editor integration works. That seems like a concern, since in many cases that means the messages won't be seen.
Requiring -Z future-incompat-report with cargo build -Z unstable-opts --future-incompat-report seems a bit awkward (it could be implied by the presence of --future-incompat-report). I understand why it is done that way, and hopefully it won't be too much of a problem.
I think the command should save at least a few reports in the on-disk file, so that if there are things like background jobs (like cargo watch), it doesn't make it difficult to view a report. Per my suggestion far above, I think it would be easy to save them in an array, and just trim it to N reports. It could also use monotonic numeric IDs instead of the strange random IDs (the next ID could be computed by 1+ the max ID in the file). Then the report command could default to showing the report with the greatest ID when not given an ID.
The message to "run cargo describe-future-incompatibilities" could also include the target directory if using a non-default one.
The RFC discussed a mechanism to silence the warnings.  I'm not sure exactly what that should look like, but un-silenceable warnings can be frustrating, especially if it is not possible to update the offending dependency (or no new version is available).

I think the command should save at least a few reports in the on-disk file, so that if there are things like background jobs (like cargo watch), it doesn't make it difficult to view a report. Per my suggestion far above, I think it would be easy to save them in an array, and just trim it to N reports. It could also use monotonic numeric IDs instead of the strange random IDs (the next ID could be computed by 1+ the max ID in the file). Then the report command could default to showing the report with the greatest ID when not given an ID.

I'm concerned that this PR is adding an increasingly large amount of complexity to deal with a very unusual situation. See my previous comment https://github.com/rust-lang/cargo/pull/8825#discussion_r564675726 - can you come up with a concrete sequence of commands that will actually cause a report to get overwritten with a different one (as opposed to an identical version of the existing report)?

If I run cargo test in my terminal, then head over to my editor and make some changes while that works.  The editor runs cargo check, which does not include dev dependencies, and overwrites the report from cargo test. I had back over to my terminal and see the warning.  I run cargo describe-future-incompatibilities --id=abcd, and it returns the error: Your report may have been overwritten by a different one..  Two things:

That's an unpleasant experience. It does print the ID for the last report, but it seems confusing to me.
The information for cargo test may be different from cargo check due to different dependencies.

Can you help me understand what the complexity would be?  I would expect it to just be a few lines of code. Something like:
let mut on_disk_report = load_reports()?;
if on_disk_report.reports.len() > MAX_REPORTS {
    on_disk_report.reports.remove(0);
}
let id = on_disk_report.reports.iter().max_by_key(|report| report.id).unwrap_or(0) + 1;
on_disk_report.reports.push(Report{id, contents});
on_disk_report.save()?;

I'm fine if you don't want to implement it here, it can be done later.

@ehuss: I'd like to implement that later, if it's okay with you. I think it would be good to get some version of this available on nightly, so that people can start testing this out in various scenarios.

@ehuss: I've addressed your review comments. Could you add your other implementation concerns to the rustc tracking issue?

:umbrella: The latest upstream changes (presumably #9022) made this pull request unmergeable. Please resolve the merge conflicts.

Yep, I think addressing those later is fine.  I pushed a few minor changes and updated the tracking issue.
Thanks! 🎉
@bors r+

:pushpin: Commit 139ed73f536d73467161cf2b88b2ed173ce52a99 has been approved by ehuss

:hourglass: Testing commit 139ed73f536d73467161cf2b88b2ed173ce52a99 with merge 7441e8c234ea60c0d07f7c1323c60e26b552e64e...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 7441e8c234ea60c0d07f7c1323c60e26b552e64e to master...

@Aaron1011 Thanks for your work on this! This feature will be a great tool for developing the standard library.


May support for the shell /bin/sh ?

What version?
No response
Which command?
No response
What happened?
My Enviroment:

macOS
fish
xcode
nodejs (installed with proto)

it happens error when xcode building script shell, show [Error] Could not find node.. The reason is xcode use /bin/sh run shell script.
When I run proto activate sh in fish shell, show Error:
Error: shell::no_hook_support

  × Your shell, sh, does not support "on change directory" hooks. Please remove the command from your
  │ shell that is triggering this hook.

But I find /Users/j/.proto/shims & /Users/j/.proto/bin in sh shell env.PATH.
May support sh shell ?
Trace logs?
No response
Operating system?
MacOS
Architecture?
arm64

@microJ Since sh doesn't support activation hooks, what are you using proto activate for exactly? Just to inject the shim/bin paths?

@milesj yes, Xcode run scripts with  sh. But I can add shims/bin to  $PATH to resolve


Add networking options for vde_vmnet support

Ref #81

I think I've addressed all comments now.
I don't know how I can force QEMU to use eth0 for vde and eth1 for slirp; any suggestions?

Thanks, but the slirp eth does not link up for me
suda@lima-default:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:34:71:8a:4e:62 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic enp0s1
       valid_lft 85382sec preferred_lft 85382sec
    inet6 fd69:599c:c913:ae3f:2034:71ff:fe8a:4e62/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591992sec preferred_lft 604792sec
    inet6 fe80::2034:71ff:fe8a:4e62/64 scope link
       valid_lft forever preferred_lft forever
3: enp0s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Config: the default template but network.vde.url = "/var/run/vde.ctl"

Thanks, but the slirp eth does not link up for me

I'll take a look; I've done all my testing with a modified Alpine image (just added an entry for eth1 to /etc/network/interfaces). Will try with default image.

https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#fallback-network-configuration

Cloud-init will attempt to determine which of any attached network devices is most likely to have a connection and then generate a network configuration to issue a DHCP request on that interface.

Looks like it only enables the first interface by default.
So we need to generate network config explicitly 😞
https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#examples

So we need to generate network config explicitly

Yes, that's what I've been thinking too. I will try if a simple config is going to work:
network:
  version: 2
  ethernets:
    id0:
      match:
        macaddress: '00:11:22:33:44:55'
      dhcp4: true
    id1:
      match:
        macaddress: '00:11:22:33:44:66'
      dhcp4: true

@AkihiroSuda you said (on Slack): "vde will be eth0 and slirp will be eth1". Does it really matter?
If not then I would prefer to always use eth0 for slirp, so it has a predictable interface name. Otherwise it will be eth1 when you configure vde, but eth0 if you don't.

If not then I would prefer to always use eth0 for slirp, so it has a predictable interface name. Otherwise it will be eth1 when you configure vde, but eth0 if you don't.

SGTM

I've updated the PR to allow the specification of multiple interfaces (e.g. both a host and a bridged network).
For testing I defined 2 interfaces on the same vde_switch (which doesn't make much sense, but shows the feature):
network:
  vde:
  - url: "/var/run/vde.ctl"
  - url: "/var/run/vde.ctl"
    name: "yo0"

With the default template it produces (IPv6 lines removed for brevity):
$ lima ip addr
bash: line 1: cd: /Users/jan/suse/lima: No such file or directory
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:11:11:11:11:11 brd ff:ff:ff:ff:ff:ff
    altname enp0s1
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic eth0
       valid_lft 85741sec preferred_lft 85741sec
3: vde0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:0b:6d:67:d6:48 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic vde0
       valid_lft 84877sec preferred_lft 84877sec
4: yo0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:59:7a:b1:ad:46 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic yo0
       valid_lft 84877sec preferred_lft 84877sec

This required some refactoring, as limayaml.FillDefault now needs the file path of the YAML file to calculate the default MAC addresses. I've also removed limayaml.Validate and renamed ValidateRaw to Validate. The places that used to call the original Validate function had already called FillDefaults anyways, so there was no need for it (unless I missed something).


Different glowing color for NFT loots

When a mob die and drop an item, there is currently a white glow effect but we could change the color if the loot is an NFT.
We could also discuss to color it according to the item type or rarity

would be possible to color it in regard to the item rarity and to make some particles around it or some slight beacon effect if it's NFT ; this way it can show both the NFT tag and the rarity tag

for now we don't intend to implement ground items, nor a rarity system


Unable to connect to IBMi

Every time I try to connect it gives a ECONNRESET error, the SSH port is open.

⚠ REMOVE THIS LINE AND ANY SENSITIVE INFORMATION BELOW! ⚠

Context
Version

Code for IBM i version
2.8.0

Visual Studio Code version
1.87.2

Operating System
win32_x64

Active extensions
Code for IBM i Walkthroughs (vscode-ibmi-walkthroughs): 0.4.0
Emmet (emmet): 1.0.0
Git (git): 1.0.0
Git Base (git-base): 1.0.0
GitHub (github): 0.0.1
GitHub Authentication (github-authentication): 0.0.2
JSON Language Features (json-language-features): 1.0.0
MDOpen for MDCMS 8.6.x (mdopen-8-6): 0.0.26
Merge Conflict (merge-conflict): 1.0.0
Node Debug Auto-attach (debug-auto-launch): 1.0.0
TypeScript and JavaScript Language Features (typescript-language-features): 1.0.0

Not connected 🔌

@jstillman01 Please try using another SSH client, e.g. PuTTY, and verify that you have SSH access from your workstation and your user. Post the results here...

Thank you for your time, this issue has been solved on our end.


How to Set a user and passwd?

When i connect zk, I need set user name and password, how i can do this in your sdk?

The connection object has an AddAuth method: https://godoc.org/github.com/samuel/go-zookeeper/zk#Conn.AddAuth
Note though there's a pending PR to fix re-submitting auth on reconnect: https://github.com/samuel/go-zookeeper/pull/139


fieldmap-based SDC on partial-FOV dataset

What happened?
We have been trying to use fieldmap-based SDC for a partial-FOV high-resolution dataset.
Using previous fmriprep versions (up to 22.0.2), coregistration and brain parcellation (for extracting greymatter and whitematter/csf signal etc.) were not working sufficiently well.  Results without using SDC were quite OK (I have posted this issue a few month ago here:
https://neurostars.org/t/problems-with-fieldmap-based-susceptibility-distortion-correction-in-combination-with-a-high-resolution-partial-volume/23694)
We have now tried the latest version 22.1.0 and the good news is that coregistration looks great now!  However, brain parcellation still fails for our partial FOV dataset.  This can be seen in the *.desc-rois_bold.svg figures. I have uploaded the fmriprep figures for 2 exemplary subjects and 2 exemplary BOLD runs here:
https://cloudstore.zih.tu-dresden.de/index.php/s/mNATzSHYt5WETy3
Thanks for your great work and hoping for a solution.
What command did you use?
docker run -ti --rm -v "/mnt/g/SPM_data/445/bids/:/data:ro"  -v "/mnt/g/SPM_data/445/bids/derivatives/fmriprep:/out"  -v "/mnt/g/tmp/:/work" -v "/mnt/c/Allgpsy/hruge/Freesurfer:/fslic:ro" -v "/mnt/g/SPM_data/445/:/plugin:ro"  nipreps/fmriprep:22.1.0    /data /out participant --participant-label   22443  -w /work --fs-license-file /fslic/license.txt  --output-spaces anat  MNI152NLin2009cAsym fsnative  --use-plugin /plugin/plugin_mem.yml --stop-on-first-crash   --ignore sbref  --bold2t1w-init header

What version of fMRIPrep are you running?
22.1.0
How are you running fMRIPrep?
Docker
Is your data BIDS valid?
Yes
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
No response
Additional information / screenshots
No response

To be clear, the main issue here is the BOLD mask? The registration and distortion correction look okay to me. While it would be good to improve masking, it's quite hard to do with partial-FOV. I would consider just resampling your anatomical mask into the BOLD field-of-view, and doing some manual touch-ups.
If there are other processing issues I'm missing, please let me know.

Yes, as of 22.1.0 only the mask is the remaining issue (in previous versions it was also the registration).
What I find strange though is that mask issue seems to be particularly bad when SDC is used.
Also, since registration works fine now even with SDC, I thought that now also mask creation (and hence confound/nuisance regressor extraction) should now also work properly.   But probably I am misconceiving how masks are derived (I had assumed by help of T1-based brain tissue segmentation applied to the co-registered BOLD images).    And therefore I concluded that this would likely point towards some sort  of bug.   If not,  I'll proceed with an 'in-house' workaround as you suggested.
Thanks again for your work!

That is a good point that the mask derived post-SDC is worse than without when the SDC is reasonable. Definitely worth keeping in mind as we continue to improve SDC edge cases, but for now this won't be a high priority target.
Thanks again for the report!


Documentation on how to create the test-bench for RISCOF

Hello everyone,
I read your doc about how to build your model plugin. But I couldn't find any description of how the test-bench should be build. I don't know what my test-bench should do and what I need to integrate (like a memory for the instructions etc.). Do you have some information about this or do I have to find it out by investigating other test-benches, like from NeoRV32 or SERV et. ?
Thank you and Best regards,
Julien

I've reviewed the Spike RISCOF plugin documentation and it seems to match the official RISCOF documentation. I understand what the plugin does; however, I'm facing challenges in creating a test-bench for my processor to interface with the RISCOF environment. The documentation mentions that for an RTL-based DUT, I should point to the final binary executable of the test-bench produced by a simulator (like Verilator, VCS, Incisive, etc.).
I am currently trying to conduct the compliance tests for the Ibex processor using the RISCOF framework, but I am unsure how to create a suitable test-bench for the Ibex that works with RISCOF. Could you provide detailed steps or examples on how to set up this test-bench?

I think I have to create something similar like the test-bench for the NeoRV32 which I found here https://github.com/stnolting/neorv32-riscof/blob/main/sim/neorv32_riscof_tb.vhd
But I was wondering if you have any specific guide to create such a test-bench

Hmm okay I think I get it now. I will investigate the links you sent me, thanks a lot for the help it was really useful.
Best regards
Julien