[IGNORE] flub/connection-info-wtf bkp

copy-pasted from original
Description
This migrates Endpoint::connection_info and Endpoint::connection_infos to Endpoint::node_info and Endpoint::node_info_iter.  This returns information about nodes in the node map.  This has not that much to do with connections.  Calling this connections is rather misleading.
It documents all types below it properly, deprecating some problematic fields and functions.
Breaking Changes
iroh-net

Endpoint::connection_info -> Endpoint::node_info
Endpoint::connection_infos -> Endpoint::node_info_iter (returns Iterator instead of Vec.
ConnectionInfo -> NodeInfo
DirectAddrInfo::last_control is deprecated, it contains misleading information.
NodeInfo::id is removed, it was internal information.
NodeInfo::last_received is deprecated as this information is wrong and can not currently be provided.
NodeInfo::last_alive_relay is deprecated as it is a simple accessor for an already public field.

iroh

Client::connections -> Client::node_info_iter
Client::connection_info -> Client::node_info

Notes & open questions
This started as a documentation PR, so really concentrates on doing the
documentation right.  It could not avoid doing some fixes to the API though.
The node_info_iter() API is potentially a weird naming and API choice.  It
is a Vec returned as an iter.  I think this is ok for several reasons:

The API name is much better than e.g. a single-letter difference: node_infos.  This would be a lot more prone to typos.
Returning things as an iterator is kind of rust-like.
If some place collects it into a Vec again the compiler will optimise it away.

The node discovery uses some deprecated APIs.  This is the reason I have left
those around as deprecated instead of entirely removing them.  The information
provided by these APIs is not what it claims to be and finding the right way to
fix the usage is better done as a follow-up: #2621.
Change checklist

[x] Self-review.
[x] Documentation updates following the style guide, if relevant.
[x] Tests if relevant.
[x] All breaking changes documented.

everyone seems happy with the state of things so I'm going to close this


stub generator bean classes with OpenApi

Hi, first af all thank You so much to have shared the source code of the project. After this, I want ask You if can make a new branch with stub, server and client structure (like other webservices projects example structure) and in stub child project use openapi dependency to make the bean classes from a swagger file (in the following link there is the dependency https://mvnrepository.com/artifact/org.openapitools/openapi-generator-maven-plugin ).
Best regards

I will think about this.

Thank You....hope that You are interested to this "refactor"

news?

I pushed up a stubs and client project.


fix: modal rename update references

Description
Whenever the modal widget was dropped, it had cross icon and close button to close the current modal which had reference to the current modal. On changing the modal name the references to both the button was not getting changed. This was happening only when before making changes to both the buttons, the modal name was changed.
This PR fixes the references for the both the buttons and verifies the flow through cypress test.
Fixes #34823
or
Fixes Issue URL

[!WARNING]
If no issue exists, please create an issue first, and check with the maintainers if the issue is valid.

Automation
/ok-to-test<EMAIL_ADDRESS>:mag: Cypress test results

[!TIP]
🟢 🟢 🟢 All cypress tests have passed! 🎉 🎉 🎉
Workflow run: https://github.com/appsmithorg/appsmith/actions/runs/9873957636
Commit: 8b3582e50631b455985a44ac228ab24624d6dd43
Cypress dashboard.
Tags: @tag.Widget
Spec:
Wed, 10 Jul 2024 13:17:48 UTC

Communication
Should the DevRel and Marketing teams inform users about this change?

[ ] Yes
[ ] No

Summary by CodeRabbit

New Features

Updated ModalWidget to include dynamic triggers for iconChild and cancelBtnChild, enabling onClick actions.

Tests

Added test scenarios for verifying modal name changes and their references within widgets (Bug 34823 and Modal Rename Update Ref).

/build-deploy-preview skip-tests=true

Can we please have a unit test instead of a cypress test ? This PR is adding to an existing functionality to our widgets which can be sufficiently tested with a unit test.
The cypress test is also testing drag and drop, renaming widget , submit and other user flows that can be skipped.

@rajatagrawal I my opinion this should be an integration test as the default properties are same as before, we just have added another key to dynamicTriggerPathList. This is a flow that needs to be test if the references of the modal are updated on the components inside modal widget on renaming or not.
Can you elaborate more about how we can do it via jest test case ?


Changes for DNNL1.x fused_batch_norm

This PR has changes needed to support DNNL1.x fused_batch_norm alone. This goes with other changes for DNNL1.x from Intel

Heads-up: we have just found some unit test failure (with MKL DNN v1.0 build) and will provide fix next Monday. Thanks!

@gzmkl Appreciate the heads up! Please mention me when you open the PR and I'll review it.

@jojivk73 can you please resolve conflicts? Thanks!

@penpornk conflicts and formatting should be resolved now. Please wait for @jojivk73 to ping you again for re-review. Thank you for again!

 Thank you

Avoiding any functional changes since the team is debugging issues. Will use execute_primitive for part of the code. Added TODOs


Add About Us Page

I'll add an about us page to the website.

@its-kumar-yash Do star 🌟 the repo to start

Can I add the about us page for your website?

@Aaditya8C already assigned.

Fixed


Replace MonoTorrent.Logger with NLog

MonoTorrent.Logger is rather hard to use and configure.
For me it is easier to add Debug.WriteLine to debug issues than configure MonoTorrent.Logger.
NLog is a pretty much standard go to library for .NET logging now.
It is super flexible, supports namespace and message filtering, hot reload and tons of other great features.
Why not replace MonoTorrent.Logger with NLog?
For connection specific stuff you could add extension methods like:
public static void Info(this NLog.Logger logger, IConnection connection, string message)
{
    logger.Info (connection.ToString () + " : " + message);
}

public static void Debug (this NLog.Logger logger, IConnection connection, string message)
{
    logger.Debug (connection.ToString () + " : " + message);
}

Yeah - the built in logger is not great at all.
I'm a little averse to building in a specific logging framework as I feel most users of the library likely have their own framework of choice.
Perhaps the logging API could be made more pluggable.

I bet that on Windows most of people are going to use NLog, not sure about Xamarin or Mono.
If you are going to refactor it, my ask would be to make logger aware of class it is called from, so it is possible to filter events for specific components.

Maybe the logging package from https://github.com/dotnet/extensions could be an option.

I think that's a pretty reasonable idea for an end user to choose.
However if I were to use that in MonoTorrent itself I'd have to pull in a whole dependency injection framework too.
My intention is to expand the ILogger interface to provide a way to set the kinds of logging which should be gathered, and then allow a user provided logger to be attached.
en

NLog is fairly widely used so if either of you were interested in creating/contributing a MonoTorrent.NLog library I'd be happy to include it in this repo and ship a nuget package for it. The idea would be that anyone using NLog in their applications would be able to reference that package and have a simple way to push monotorrent logging into NLog.

I have my branched version where I just dropped in NLog directly.
Will take a look what it is going to take to abstract it out.

Would something like this be usable for you?

The ILogger interface is a single method which takes an enum and an object[]

https://github.com/alanmcgovern/monotorrent/pull/312/files#diff-e7c627f094543bea93bc7e8eb28882cfR17

Every loggable event has a unique value in the enum. The xml docs on each enum describe when the logging event will be raised, and describe the objects which will be passed to the logging method.

https://github.com/alanmcgovern/monotorrent/pull/312/files#diff-4607f9986cfcf019dbb89792a6f1bb79R27-R30

When implementing ILogger you can generate a unique string for each log event, and can safely cast the items in the array to the types described in the xml docs.

https://github.com/alanmcgovern/monotorrent/pull/312/files#diff-7d00eb8edd98fe42bd960caf86397241R27

Actually I had a very different idea.
Instead of creating unique enum value per event, make logger implementation class aware.
In other words in every class you want to use logger, you have to define it as
private static readonly MonoTorrent.Logger logger = LogManager.GetCurrentClassLogger();
And then you could log anything using adhoc strings, and it also helps to have helper methods to log connection specific stuff:
public static void Info(IConnection connection, string message)...
Then in logger implementation you could choose to filter events from specific components, which is useful if you want to debug something specific.
This is flexible and consistent with how NLog is working, so plugging in NLog is going to be straightforward.
Here is a sample NLog config to illustrate the idea.
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      keepVariablesOnReload="true" autoReload="true">

  <targets async="true">
    <target name="logfile" xsi:type="File" fileName="${var:app_local_state_folder}\log.txt" />
    <target name="debugger" xsi:type="OutputDebugString" />
  </targets>

  <rules>
    <logger name="MonoTorrent.Client.*" minlevel="Error" writeTo="debugger" />
    <logger name="MonoTorrent.Client.ConnectionManager" minlevel="Error" writeTo="logfile" >
      <filters>
        <when condition="not contains('${message}','ipv4')" action="Ignore"/>
      </filters>
    </logger>

    <logger name="MonoTorrent.UWP.Client" minlevel="Info" writeTo="logfile" />
  </rules>
</nlog>

If MonoTorrent user choose to use different library, it will be possible to implement same functionality if necessary.
What do you think?

Well, I suppose there are a few questions I should ask.
Firstly, my hope is that every will use the MonoTorrent NuGet package. There should be no reason for anyone to make changes to MonoTorrent itself, unless they intend to contribute those changes to me because they're fixing a bug or adding a missing feature.
With that in mind, my first question is - why are you trying to add logging to monotorrent's private classes? This is a very unusual thing for a user of a library to be doing. This kind of logging requires changing monotorrent internals, which means you'd never be able to use the nuget package.
There are three aspects to logging. Which of these are you looking to address as it changes how the implementation is done:

Make it easier for developers of the library to understand what's going on.

This can be implemented as you suggested, by having class level loggers which capture the class name. For my own use I'd find this style of logging too unstructured. For example, I would prefer all logging related to piece picking to have the prefix PiecePicker:  regardless of which class the log statement came from. It makes filtering logs much simpler, and these logs would be for my benefit, and also for any contributors.

Make it easy for users of the library to provide good diagnostics for the developers of the library.

If monotorrent had good internal logging (which it currently does not) then it should be easy for someone using the NuGet package to write those logs to disk and submit them to help diagnose issues.

Give users of the application the library is embedded into a high level overview of what's going on inside MonoTorrent.

This is what I was aiming for with my PR. I was looking to provide a very simple public API for someone to integrate with so they can get logging about some, or all, of the aspects of the library which they may not normally get clear visibility into. A user of the MonoTorrent nuget package would implement one method in ILogger, then call something like:
Logger.Enable(new MyLogger (), LogType.IncomingConnection | LogType.OutgoingConnection | LogType.BlockedConnection)
and then they'd get logging only for those three events. They could also do:
Logger.Enable (new MyLogger (), LogType.All) and get logging for everything monotorrent currently exposes.

Thanks for detailed explanation, indeed I look at this from the perspective of library developer (your point 1), while your PR is more suitable for library consumers (points 2 and 3).
I think that 1 is most important here, because for 2 it should be pretty easy to compile MonoTorrent instead, and I'm not sure if a lot of people care about 3 (as far as I understand this is kind of messages view in uTorrent).
Regarding implementation, agree that your proposal is more structured. But this will make a bit harder to integrate it with NLog which has a lot of functionality around class names.
How do you feel about combining approaches (making logger class aware and also having enum for component), so it integrates nicely with all log providers, and can be used to address all points you listed? This will give library developers and consumers more flexibility on how they want to use logging.
As for your last question, the only reason I'm not using MonoTorrent from nuget is because I build it for UWP, which still has a lot of quirks (like file access API differences) and extra features (like C++/WRT)

I think this will be a better match for what you're trying to accomplish.
https://github.com/alanmcgovern/monotorrent/commit/e23fadcbe7e0e5d920bf2b22c1964320540e38c3
Internally in monotorrent we can port everything to a static readonly Logger logger = Logger.Create () . This captures the class name. As a consumer of the library you can implement ILogger and then proxy the data to nlog, or do whatever you want.
Does this work for you?

Thanks, this is perfect!
Couple of comments:

I don't think that it makes sense to add InfoFormatted since it is easier to use $ style string interpolation now.
It would be nice to add special methods that take IConnection for logging connection specific events.

I don't think that it makes sense to add InfoFormatted since it is easier to use $ style string interpolation now.

This is an internal implementation detail and so won't be exposed to users of the library. I intend to add several internal overloads of these logging methods so that the invocations to the loggers are zero-allocation for the case where no ILogger is supplied. Some of the more verbose logging statements could be called thousands of times a second and it'd be a shame if that continually allocated junk string instances which were never actually used :)

It would be nice to add special methods that take IConnection for logging connection specific events.

Those will probably be added internally alright. However for you, a consumer of an unmodified monotorrent (ideally ;) ), the only thing you should ever receive will be two strings link. One for the classname and one with the already-formatted logging data. In this setup you'll never receive typed parameters and so won't be able to construct your own logging stirng. However, that's not something a user of a library would need to do anyway so that's fine.

Agree, both are valid points. Added couple of comments to https://github.com/alanmcgovern/monotorrent/commit/e23fadcbe7e0e5d920bf2b22c1964320540e38c3
in order to allow injecting loggers that take full class name in a constructor.
And I think it also make sense to add Warning logging.
Other than that looks good.
Thanks for taking time to make it extensible.

Can you take a look at https://github.com/alanmcgovern/monotorrent/commit/e9753c343105442cb6a712dea7be0a8a942ddf33 and see if it's suitable enough. If not - can you make a pull request with suggested changes so I have a better idea what you want to accomplish? I'm flexible :)
There's an Info/Debug/Error in the interface now, which will allow a little bit of variance in what's logged too :)

This has been implemented already and is available in the main branch.
If there are any further tweaks needed just let me know!


Wrong comment when setting default CleanPodPolicy

fixes #698

This change is

/ok-to-test

@gaocegege thanks for your review ! addressed the comment

/lgtm
/approve
Thanks for your contribution!

/test kubeflow-tf-operator-presubmit


fixed off-by-one read in ngx_resolver_copy().

Fixed off-by-one read in ngx_resolver_copy() as done in nginx:
http://hg.nginx.org/nginx/rev/5d561a77502e

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

The tengine mainline has been updated to 1.24.x. So this fix has been included.


improve a bit the file formats docs

[x] fix some outdated references to cscolors.json
[x] add some missing properties on Text styles
[x] add shadows.json doc
[x] add gradients.json doc

Thanks, this is great! I haven't touched the docs for these in a while, and I was pretty sure there was stuff missing.


U618/T649 Animations in replay

Animations are now shown in the replay.
Instead of rendering the active player entities in the replay, copies of them are made an rendered instead to prevent bugs and make it easier to update them with the normal systems.
Note: Replay copies of the entities aren't added to any systems until the killcam is starts.
RenderInActiveGameComponent and RenderInReplayComponent have been added and need to be attached to entities in ordered to be rendered in the corresponding scenarios.
Removed the replay-specific copy of the transform component since that is no longer needed now that replay entities can use the same systems as the normal entities.

Also added torch throwing and candle extinguishing to the replay since they were easy to do (but with some bugs if the replay starts when the candle is supposed to be on the ground).
Also made the performance test a bit more accurate by limiting the fake players' projectiles' lifetimes since players are responsible for destroying their own projectiles so those projectiles in the performance test will survive for their entire lifetime (which used to be like 4 seconds and is now 0.4 seconds).

Crash has now been fixed.
There were some behavior implementations in ReceiverBase which have now been moved out to NetworkReceiverSystem.


Add namespace support for business user IDs

See:

https://github.com/snowplow/snowplow/issues/376

Closing because it has been with no activity for a long time.
Please, feel free to reopen or comment this issue, whether it's of your interest or you want to contribute on this.


Cut (Ctrl + X) deletes lines but pastes nothing

I also met same the problem of #4185 and the data clipped are lost. Has this issue been resolved?

Sorry for never getting back to you on this issue, somehow this slipped through the cracks.
We have made a lot of improvements and fixes in this space and believe this may have been resolved.
Please ensure you update to the latest version of VS code and the extensions.
Closing as I believe it may have been resolved,
If not please ping here and I'll reopen this or feel free to create a new issue.


Enable the release configuration in the CI matrix.

See https://github.com/Azure/azure-sdk-for-c/issues/1110

See https://github.com/Azure/azure-sdk-for-c/pull/1098


Add Icons to Footer

Hello Project Admin
I would like to add icons to Footer
Can you assign me this issue under GSSOC'24 @thestarsahil

Can you please assign it to  me.

you can assign that task to me under gsssoc-ext and hacktoberfest.. level 3 label


ARROW-7980: [Python] Fix creation of tz-aware datetime dtype on first pandas import

This is not that straightforward to test: the test I added failed on master in isolation (and is now fixed with this patch), but it passed anyway when running the full test suite (since by the time that test is ran, another test already caused the pandas import checks to have run).
I could do something with a subprocess to ensure we check this "fresh", but not sure that is worth the trouble (does pytest provide some helper for this?)

I agree this should be tested in isolation. subprocess.check_call should be easy enough for this.

Done, and added a utility to make it easier to write such tests requiring isolation in the future

@wesm Thanks for adding the test!


Allow multiple tasks to be set up with -t flag

This merge changes the -t or --tasks flag to polaris setup to allow multiple task to be specified.
Since there is not a sensible way to specify cached steps for each of several tasks, the --cached flag only works when a single task is specified to to -t or -n.

Checklist

[x] User's Guide has been updated
[x] Developer's Guide has been updated
[x] Documentation has been built locally and changes look as expected
[x] Testing comment in the PR documents testing used to verify the changes

Testing
I was able to set up and run the single-column ocean tests on my laptop:
$ polaris setup -t ocean/single_column/cvmix ocean/single_column/ideal_age -p ...

Then,
$ source load_polaris_env.sh
$ plaris serial
ocean/single_column/cvmix
  * step: init
          execution:        SUCCESS
          runtime:          0:00:01
  * step: forward
          execution:        SUCCESS
          runtime:          0:00:02
  * step: viz
          execution:        SUCCESS
          runtime:          0:00:01
  task execution:   SUCCESS
  task runtime:     0:00:04
ocean/single_column/ideal_age
  * step: init
          execution:        SUCCESS
          runtime:          0:00:01
  * step: forward
          execution:        SUCCESS
          runtime:          0:00:02
  * step: viz
          execution:        SUCCESS
          runtime:          0:00:01
  task execution:   SUCCESS
  task runtime:     0:00:04
Task Runtimes:
0:00:04 PASS ocean/single_column/cvmix
0:00:04 PASS ocean/single_column/ideal_age
Total runtime: 0:00:08
PASS: All passed successfully!

@sbrus89, this is ready to review.

@sbrus89, since this was a feature request, I'm going to leave it for you to review, unlike the recent bug fixes.


Bug when list have no items

I found a bug when recycler view list adapter is empty.
For solve it, at ScrollListener implementation of FastScroller class, after retrieve first recycler view child:
View firstVisibleView = recyclerView.getChildAt(0);
.. Verify if firstVisibleView is null and return without execute rest of method.
View firstVisibleView = recyclerView.getChildAt(0);
if(firstVisibleView == null)
    return;

This check avoid app's crash!
I hope I helped!

The problem is that it should not be visible or operational at all when adapter is empty. I must have tested something and set it to VISIBLE when it really should be GONE.
I think that onScrolled should not be called for an empty recyclerView so it should not be an issue anymore. I applied the fix and uploaded it, please check if it works for you.


Report txt: fix printing of non-ascii details

Previous commit introduced couple of issues regarding details of reports that could lead to situations like:

remediation instructions has not been printed when non-ascii characters have been present
possible unwanted empty line when remediation has been specified but relative symlinks hasn't
if the URL title contained non-ascii character, it has been broken too (on py2)

This should handle all mentioned problems when generating the txt file.

/rerun

@oamg/developers
tested manual on RHEL 7 & RHEL 8:
----------------------------------------
Risk Factor: high
Title: [snip]
Summary: [snip]
Related links:
    - Difference in Python versions and support in RHEL 8: https://red.ht/rhel-8-python
    - kurník řepa: https://red.ht/rhel-8-python
Remediation: [hint] Please run "alternatives --set pythořn /usr/bin/python3" after upgra%čde
Key: 0c98585b1d8d252eb540bf61560094f3495351f5

Risk Factor: high (inhibitor)
Title: Upgrade requires links in root directory to be relative
Summary: After rebooting, parts of the upgrade process can fail if symbolic links in / point to absolute paths.
Please change these links to relative ones.
Remediation: [command] sh -c ln -snf bořek /bořislav && ln -snf root/tlučhuba /kuřislav
Key: 3d895ad37ceaf4157864d439edb6bd75562061fa

Note there are no any unit-tests for this and I am skipping to add them now to unblock upstream testing of upgrades.

LGTM!

[x] - remediation gets printed even with non-ascii characters
[x] - unwanted empty line is no longer present when external links aren't specified
[x] - link with non-ascii characters gets printed just fine

Tested on RHEL8 and RHEL7 as follows:
Risk Factor: high (inhibitor)
Title: Local repository detected
Summary: The following local repository has been found: my-repo (their baseurl starts with file:///). Currently leapp does not support this option.
Related links:
    - Customizing your Red Hat Enterprise Linux in-place upgrade ľščťžýáíéôúäň: ľščťžýáíéôúäň https://red.ht/ipu-customisation-repos-known-issues
Remediation: [hint] By using Apache HTTP Server you can expose your local repository via http. See the linked article for details. ľščťžýáíéôúäň
Key: 3450b32bfad8e1837b73b18e56c556d1052d5e4b
----------------------------------------
Risk Factor: high
Title: Remote root logins globally allowed using password
Summary: RHEL9 no longer allows remote root logins, but the server configuration explicitly overrides this default. The configuration file will not be updated and root is still going to be allowed to login with password. This is not recommended and considered as a security risk.
Remediation: [hint] If you depend on remote root logins using passwords, consider setting up a different user for remote administration. Otherwise you can ignore this message.
Key: e738f78bc8f3a84411a4210e3b609057139d1855


Allow only initial selection for Nav

Is your feature request related to a problem? Please describe
A tour.py could improve its UX by preselecting nav item based on active hash.
Describe the solution you'd like
Introduce initial_value attr on ui.nav_card.
Describe alternatives you've considered
Tried to use value, but this allows app developers to manually control which nav item is currently active (clicking on other items does not work out of the box unless handled in python code via value). However, I only care about the initial selection without further overhead.

The initial_value / value duo introduces a new kind of behavior that might need to be applied to all such components going forward.
It would be good to solve this problem without introducing the initial_value attribute.
I don't think there is a scenario where the app author will want to control the value on every click. It's more likely that the app author intends the value to be an initial value, and then have the nav behave normally for subsequent clicks.
What do you think about:

When a value is specified, we use that to initialize the nav, and store it in an internal initialValue variable.
When an item is clicked, we use that as the active item (ignore the value attribute).
If the app author changes the value explicitly later, we can detect that by comparing state.value with our initialValue variable, and use that to set the active item.

Brilliant proposal @lo5!

I don't think there is a scenario where the app author will want to control the value on every click. It's more likely that the app author intends the value to be an initial value, and then have the nav behave normally for subsequent clicks.

I 100% agree, however, it seems like there can be some people needing that - see #283.
I went through all the components using value and it seems like we are not consistent in this behavior. Some components use it for initial value only and some for full control. I suggest applying your proposal and unify all the components to have the same behavior. However, note this might be a breaking change for some apps unfortunately.

Part of #1154


Investigate Jenkins Reliability + Durability

We will be staying on Celery so Jenkins will function only as CI/CD platform


Selected text can now display itself in a different color from surrounding text (Resolves #1332)

Selected text can now display itself in a different color from surrounding text (Resolves #1332)
When selected text changes color, we don't want that color change to be reflected in the document content. It's a transient visual detail that shouldn't be serialized or saved. Therefore, to accomplish this effect, we add an attribution to selected text within the presentation pipeline. This is the pipeline that applies the stylesheet, for example.
Also includes:

ColorAttribution to change the color of spans of text.
Minor adjustment to prevent an NPE related to ContentLayers
A new "in the lab" demo area and scaffold. This will be a place for us to demo features that haven't stabilized yet. In a followup PR, I'm going to move the tagging demos into the lab area.

https://github.com/superlistapp/super_editor/assets/7259036/675d1ab7-4f88-41a8-a8e6-d8eb3f8dc1f8

FYI @miguelcmedeiros @Jethro87 @jmatth @Dboy233


Make node search bar

Looks like there is a CI failure, which I didn't notice since CircleCI went down and stopped running builds.
><EMAIL_ADDRESS>test /root/hetmech-frontend
> react-scripts test

 PASS  src/app.test.js
  ✓ renders without crashing (98ms)

  console.error node_modules/react/cjs/react.development.js:188
    Warning: Each child in a list should have a unique "key" prop.

    Check the render method of `Key`. See https://fb.me/react-warning-keys for more information.
        in span (at key.js:10)
        in Key (at app.js:13)
        in div (at app.js:11)
        in App (at app.test.js:8)

  console.error node_modules/react-dom/cjs/react-dom.development.js:506
    Warning: Invalid DOM property `class`. Did you mean `className`?
        in span (at key.js:10)
        in section (at key.js:18)
        in Key (at app.js:13)
        in div (at app.js:11)
        in App (at app.test.js:8)

The web UI looks great. Since this is a new repo, I strongly recommend that we use the indentation of 2 characters in JS code to make the coding style consistent with most of the other JS projects. (I don't think I am a coding style fundamentalist, but this is one of the few rules that I do want to enforce.)

The CI failure seems to be due to class (instead of className) in line 10 in src/key.js:
 <span class='key_entry'>


Custom array indices segfault in CkVec inside of LB framework

Original issue: https://charm.cs.illinois.edu/redmine/issues/1887

This bug was reported to us by James Bordner from the Enzo-P/Cello team. Depending on the order of bits in their custom array indices, their code could segfault during calls from the load balancing framework to CkVec, by passing an out of bounds index. Below is the email from James which contains a stack trace and instructions for reproduction.
Below is a stack trace from gdb.  In frame 4 which triggers the assertion error, len == 5664 and n==1080033280.  In frame 5, hash == -3645, so index = (0+ -3645) % 20117 == -3645.
If you want to try running the problem yourself, first try to get Enzo-P installed and running (see Getting started using Enzo-P).  Then edit src/Cello/mesh_Index.hpp by moving the line "unsigned array : INDEX_BITS_ARRAY;" above the line "unsigned  tree : INDEX_BITS_TREE;" and recompiling.  The problem I'm running is "charmrun +p2 bin/enzo-p input/load-balance-4.in +balancer RotateLB".  I built Charm 6.8.2 using "./build charm++ netlrts-linux-x86_64".
Thanks!
James
#0  0x00000000007f75a7 in LrtsAbort (
message=0xa0cf40 "Assertion "n<len" failed in file cklists.h line 221.")
at machine.c:554
#1  0x00000000007f7036 in CmiAbortHelper (source=0xa34f61 "Called CmiAbort",
message=0xa0cf40 "Assertion "n<len" failed in file cklists.h line 221.",
suggestion=0x0, tellDebugger=1, framesToSkip=0)
at machine-common-core.c:1454
#2  0x00000000007f7066 in CmiAbort (
message=0xa0cf40 "Assertion "n<len" failed in file cklists.h line 221.")
at machine-common-core.c:1458
#3  0x0000000000800f1b in __cmi_assert (
errmsg=0xa0cf40 "Assertion "n<len" failed in file cklists.h line 221.")
at convcore.c:3820
#4  0x000000000069fc42 in CkVec::operator[] (this=0x108d830,
n=1080033280) at cklists.h:221
#5  0x00000000007a1013 in BaseLB::LDStats::getHash (this=0x108d818, oid=...,
mid=...) at BaseLB.C:189
#6  0x00000000007a1101 in BaseLB::LDStats::getHash (this=0x108d818, objKey=...)
at BaseLB.C:202
#7  0x00000000007a1137 in BaseLB::LDStats::getSendHash (this=0x108d818,
cData=...) at BaseLB.C:208
#8  0x00000000007a929e in CentralLB::removeCommDataOfDeletedObjs (
this=0x111ca10, stats=0x108d818) at CentralLB.C:1464
---Type  to continue, or q  to quit---
#9  0x00000000007a6fb4 in CentralLB::LoadBalance (this=0x111ca10)
at CentralLB.C:713
#10 0x00000000007b04d2 in CkIndex_CentralLB::_call_LoadBalance_void (
impl_msg=0x3c86310, impl_obj_void=0x111ca10) at CentralLB.def.h:1848
#11 0x00000000006e1825 in CkDeliverMessageFree (epIdx=260, msg=0x3c86310,
obj=0x111ca10) at ck.C:597
#12 0x00000000006e1971 in _invokeEntryNoTrace (epIdx=260, env=0x3c862c0,
obj=0x111ca10) at ck.C:641
#13 0x00000000006e1a8d in _invokeEntry (epIdx=260, env=0x3c862c0,
obj=0x111ca10) at ck.C:652
#14 0x00000000006e31d1 in _deliverForBocMsg (ck=0x1019838, epIdx=260,
env=0x3c862c0, obj=0x111ca10) at ck.C:1083
#15 0x00000000006e32dc in _processForBocMsg (ck=0x1019838, env=0x3c862c0)
at ck.C:1101
#16 0x00000000006e387d in _processHandler (converseMsg=0x3c862c0, ck=0x1019838)
at ck.C:1263
#17 0x00000000007fdc93 in CmiHandleMessage (msg=0x3c862c0) at convcore.c:1619
#18 0x00000000007fdf17 in CsdScheduleForever () at convcore.c:1856
#19 0x00000000007fde48 in CsdScheduler (maxmsgs=-1) at convcore.c:1792
#20 0x00000000007f6e31 in ConverseRunPE (everReturn=0)
at machine-common-core.c:1298
#21 0x00000000007f6d38 in ConverseInit (argc=5, argv=0x7fffffffe988, fn=
0x6d5ba5 <_initCharm(int, char**)>, usched=0, initret=0)
at machine-common-core.c:1199
#22 0x00000000006d3ebd in main (argc=5, argv=0x7fffffffe988) at main.C:18

Original date: 2018-04-25 19:44:18

Seems to have been narrowed down at least partially to an issue with custom array index documentation. Currently, the actual data for an array index as seen by the runtime (specifically for things like LB and tracing) is stored in CkArrayIndexBase::index and access via CkArrayIndex::data() (see file ckarrayindex.h). However for custom array indices and how we say to use them in the Charm++ manual, this underlying data is never set and only zero'd out by the default CkArrayIndex constructor. From what I can tell it's never set to anything related to the custom array index.

Original date: 2018-04-25 19:54:20

Our example in examples/charm++/hello/fancyarray seems to be aware of this issue, and correctly allocates it's data using placement new. I'll talk to James and see if this fixes his issues, but the documentation should be updated to indicate this. The only issue is if the data for the custom array index exceeds the size of the index data in the base class.

Original date: 2018-05-01 14:07:18

Any update from James on if this fixed the issue?

Original date: 2018-05-02 19:33:45

No. Haven't heard from him.

Original date: 2018-08-22 01:53:01

Please close this issue if it's not a real problem

Original date: 2019-04-03 21:32:21

The original problem ended up to be just a matter of poor documentation/examples. That is address in this patch: ~~https://charm.cs.illinois.edu/gerrit/c/charm/+/5057~~ https://github.com/UIUC-PPL/charm/commit/120fd57189e67b780417f4ae3445b665a731d34a


Can I use go-mobile to build an android app with go-sdl2?

There is a example using shared library. Can I use go-mobile to create a native app with go-sdl2?

Hi @stillwarter, we don't use gomobile but you can take a look at https://github.com/gen2brain/go-sdl2-android-example as an example on how to use go-sdl2 on Android.


AsyncAssistantStreamManager Error

Confirm this is an issue with the Python library and not an underlying OpenAI API

[X] This is an issue with the Python library

Describe the bug
async def requestGpt(response):
print("requestGpt called")
async with client.beta.threads.runs.stream(
thread_id=thread.id,
assistant_id=assistant.id,
event_handler=EventHandler(response)
) as stream:
await stream.until_done()
When I use this way to call a assistant streaming, the type of stream is AssistantStreamManager, not the AsyncAssistantStreamManager
To Reproduce
async def requestGpt(response):
print("requestGpt called")
async with client.beta.threads.runs.stream(
thread_id=thread.id,
assistant_id=assistant.id,
event_handler=EventHandler(response)
) as stream:
await stream.until_done()
Code snippets
No response
OS
macOS
Python version
Python 3.10
Library version
openai             1.23.6

Hey @Senna1960321 thanks for reporting. I have not been able to repro this. I tried creating a thread and an assistant then running the snippet you provided but I got an AsyncAssistantStreamManager as expected.
To be clear, you are using an AsyncOpenAI object as your client, right? Could you please provide more comprehensive repro instructions (i.e. an end-to-end repro)?

Yes, I want to use a AsyncOpenAI object as my client. @meorphis
This is my code, the type of stream is AssistantStreamManager
client = OpenAI(
api_key='openai_key'
)
message = client.beta.threads.messages.create(
thread_id=thread.id,
role="user",
content="Please answer again, I do not understand you."
)
class EventHandler(AsyncAssistantEventHandler):
# def init(self, response):
#     super().init()
#     self.response = response
@override
async def on_event(self, event: AssistantStreamEvent) -> None:
    print("on_event called")
    if event.event == "thread.run.step.created":
        details = event.data.step_details
        if details.type == "tool_calls":
            print("Generating code to interpret:\n\n```py")
    elif event.event == "thread.message.created":
        print("\nResponse:\n")

async def requestGpt():
print("requestGpt called")
stream = client.beta.threads.runs.stream(
thread_id=thread.id,
assistant_id=assistant.id,
event_handler=EventHandler()
)
print(f"Stream type: {type(stream)}")
async with stream as stream:
await stream.until_done()

Hey @Senna1960321 - thank you for posting your code. What I meant is that instead of
client = OpenAI(
    api_key='openai_key'
)

You should be using:
client = AsyncOpenAI(
    api_key='openai_key'
)

This will solve your problem :)

Thanks a lot @meorphis , I tried it so that it did solve my problem perfectly


improving SDK topic route availability, when namsrv  restart

The issue tracker is used for bug reporting purposes ONLY whereas feature request needs to follow the RIP process. To avoid unnecessary duplication, please check whether there is a previous issue before filing a new one.
It is recommended to start a discussion thread in the mailing lists in cases of discussing your deployment plan, API clarification, and other non-bug-reporting issues.
We welcome any friendly suggestions, bug fixes, collaboration, and other improvements.
Please ensure that your bug report is clear and self-contained. Otherwise, it would take additional rounds of communication, thus more time, to understand the problem itself.
Generally, fixing an issue goes through the following steps:

Understand the issue reported;
Reproduce the unexpected behavior locally;
Perform root cause analysis to identify the underlying problem;
Create test cases to cover the identified problem;
Work out a solution to rectify the behavior and make the newly created test cases pass;
Make a pull request and go through peer review;

As a result, it would be very helpful yet challenging if you could provide an isolated project reproducing your reported issue. Anyway, please ensure your issue report is informative enough for the community to pick up. At a minimum, include the following hints:
BUG REPORT

Please describe the issue you observed:

What did you do (The steps to reproduce)?

sdk send message thrown topic not exists Exception,when namesrv restart and  broker register topic unfinished

What is expected to see?

What did you see instead?

Please tell us about your environment:

Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

Can you give the relevant log error information?

Can you give the relevant log error information?

you can get TOPIC_NOT_EXIST response code and error msg is：No topic route info in name server for the topic

Can you give the relevant log error information?

you can get TOPIC_NOT_EXIST response code and error msg is：No topic route info in name server for the topic

thanks

Close as its PR is merged.


Output from no_std tests?

I'm looking into using Miri to test some thumbv7em-none-eabihf code from an operating system kernel. I was curious if there's any supported way to get output (e.g. stdout) from a no_std test right now, or to abort.
Approaches I've tried:

If I can extract my code into a lib that isn't necessarily no_std and supports a platform where std is available (the test host, or if I want 32-bit, something like armv7-none-linux-eabihf), then I can run it with the test harness and get status/failure reporting.
If I can construct my test as a no_std/no_main program using a #[start] fn, I can return a handful of bits of information, but only in the exit code from start -- in particular, it's not clear that I can abort from a deep place in the callstack, since abort isn't in core.

Since Miri appears to detect and emulate certain I/O routines on std platforms, I wonder if it's possible to call into these from a no_std environment? This would give a test-only facility similar to "semihosting" on ARM embedded targets, where the test harness could call magic functions. (Concretely, the two magic functions I want are: write byte sequence to stdout, and abort; this would let me implement a panic_handler that does something other than hang the process, which appears to be the only option in a test right now.)
From web searches, it looks like I might be the second user of MIRI_NO_STD after your test suite, so I could not find any worked examples to crib from. :-)
Thanks in advance!

The OS interface miri emulates depends on the target_os key in the target specification, which for your target is "none". As such miri doesn't emulate any OS. It should be possible to modify miri to add another OS interface for your target. As for aborting you can call the unstable core::intrinsics::abort() function. It is available on every target.

Can you link to any documentation for these magic functions you use for semihosting? It sounds like maybe we could shim those to do... something?

Can you link to any documentation for these magic functions you use for semihosting? It sounds like maybe we could shim those to do... something?

You probably don't want to emulate the ARM semihosting interface per se because it's implemented by particular use of a bkpt machine instruction -- below the level where you're emulating, and ARM-specific. That said, here are some decent docs on the interface, and here's the canonical Rust interface.
It's a broader interface than what I'd need for testing -- in particular it allows for input and filesystem access on the host. Though I guess such things might be useful.

The OS interface miri emulates depends on the target_os key in the target specification, which for your target is "none". As such miri doesn't emulate any OS. It should be possible to modify miri to add another OS interface for your target.

As an operating system kernel, none is the typical OS component of the target triple. I suppose we could alter the build system to build for a non-none platform and use Miri's emulation of that. Probably the closest thing to my original suggestion would be to make up a new target_os, such as miri, and provide a basic interface there. (Are either of these what you were suggesting, or did I misunderstand?)
I'd argue for providing an emulated interface for target_os = "none", since this will be a very common need in no_std contexts. Currently code like tests/pass/no_std.rs that is executed on a target_os = "none" triple only has the ability to return or hang, as far as I can tell.

As for aborting you can call the unstable core::intrinsics::abort() function. It is available on every target.

Ah, I hadn't noticed that. Under Miri, calling that causes the program to exit with status code 0, so it doesn't enable me to report test success/failure. But that does let me at least write a panic_handler that does something other than hang, so, that's nice.

It looks to me like the writing to host stdout/stderr is pretty simple, I can probably whip up an implementation of it in Miri. Do you have an example program I can try out a prototype on?

One thing you could try is to use
extern "C" {
    fn abort() -> !;
    fn putc(c: u8);
}

I think miri will just interpret those even on unsupported targets

I would indeed quite like to have a magic Miri library that works like this, but I don't know how to implement that.
The shim infrastructure checks targets, as far as I can tell:
error: unsupported operation: the target `none` is not supported
  --> src/main.rs:20:9
   |
20 |         printf("hi\0".as_bytes().as_ptr().cast());
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the target `none` is not supported
   |

which is probably the correct thing to do.

I don't think emulating that is the right choice.

Can you expand on why? Personally, I would like to run code under Miri without modification to the code. And if there is hackery that needs to be done in order to execute code under Miri, I'd rather it be done in one place inside this codebase than spread across the ecosystem (or done in one-off things when debugging). But I just have no idea if these things apply to embedded programming. I just don't know what that's like.
Last night I whipped up a very crude implementation of the semihosting APIs for printing in Miri. Maybe I'll have time to touch it up today https://github.com/rust-lang/miri/compare/master...saethlin:miri:cortex-m-semihosting

I would indeed quite like to have a magic Miri library that works like this, but I don't know how to implement that. (Best I can do is spooky magic symbols you have to declare yourself, or sticking definitions for those in some crate you can use. I like neither.)

We could inject a module into the sysroot that all programs compiled under miri then have access to

I think miri will just interpret those even on unsupported targets

Heheheh I will try this. Probably not the ideal long term solution but who knows!

I don't think emulating that is the right choice.
Can you expand on why? Personally, I would like to run code under Miri without modification to the code.

Certainly! I would also like to run code under Miri without modification. The cortex-m-semihosting API is

ARM-specific -- my software runs on a variety of architectures
Merely one of several ways of getting debug printfs etc out of even ARM-specific software -- we don't use it in production code because it hits breakpoints when used and is thus incompatible with realtime applications. There's the semihosting mechanism, there's the ITM peripheral that's accessed by memory mapped I/O, there are vendor-specific trace peripherals or UARTs, ...etc.

In general I expect essentially all embedded code to require modification to run on Miri, either because its preferred I/O facility is not present, or because it spends a lot of its time doing stuff like MMIO to peripherals that are not emulated by Miri (and rightfully so, QEMU has a hard time getting these peripherals right already). Us embedded folk are already pretty used to programming against thin abstraction layers that get implemented for different targets, because the targets are so wildly different -- so if I need to implement one against a Miri-specific API that's no big deal compared to doing it for ST ARM Cortex with their peripherals, NXP ARM Cortex with their peripherals, ARM A-class, AArch64, AVR, RISC-V, .....
Does that make sense?

We already have magic Miri-provided extern functions. We can just add another one for printing to stdout (and probably another one for stderr).
abort already exists as an intrinsic, so... I guess we could also have it as a Miri extern function but it seems less necessary.

@RalfJung that sounds pretty reasonable. It looks like this would be a matter of defining the function in src/shims/foreign_items.rs? Would it need to do anything fancier than write to interpreter stdout/stderr? (I suppose I could check the various fs shims for examples.)

Would it need to do anything fancier than write to interpreter stdout/stderr?

Not really, no.

So, something like this then? https://github.com/cbiffle/miri/commit/48f09537307d2648596dae7419de220df7647702
(I'd extend it to stderr before submitting a PR.)

Yeah that looks good, just please move the use up to the file level.

Fixed in #2606 .


This error check seems unreasonable (MAX_EXTENSIONS) at vulkan_context.h

Version: 4.0
Shouldn't we replace this with a comment to tell if ever we may care about more than 128 extensions, we should increase the constant MAX_EXTENSIONS to 254? Unless we reach this specific situation this condition will be false.
https://github.com/godotengine/godot/blob/851cb429631168369d2a51812de763b658795fbf/drivers/vulkan/vulkan_context.cpp#L251
Does it ever occur for a driver have a limit for the number of extensions? Because to me, even limiting the number of extensions affordable seems odd.

Does godot have a mailing list? I think it would be more proper to talk about this kind of thing through one, but I couldn't find any mailing list with godot devs.

This is the best place to replace issues. If you want a more casual discussion come join us on IRC there link is here http://docs.godotengine.org/en/latest/community/channels.html :)

https://github.com/godotengine/godot/blob/851cb429631168369d2a51812de763b658795fbf/drivers/vulkan/vulkan_context.cpp#L362
Later extension_count is reset. I'll start removing these checks as they don't seem of any use

Following up on https://github.com/godotengine/godot/pull/36424#issuecomment-1174957263, could you describe what use case you have that requires more than 128 extensions?
If the value is too low and can be hit in realistic use cases, then it should simply be increased. If there are realistic use cases that would add tens of thousands of extensions for example, we would need to reconsider how this array is sized (and e.g. make it dynamic and grow in powers of two).


[Feature] turn into plugin

is it possible to turn it into a plugin where u chose any of the HL scheme and it gets applied automatically ?

https://github.com/ctf0/vscode-terminal-themes


Fixing issue 11848

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No, no need to refresh for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run

The new version is adding a path that was not found in the old version.
New: Microsoft.RecoveryServices/stable/2020-10-01/bms.json#L21:5
The above is not a breaking change. This API was an existing API which was missed while consolidating all APIs in latest version in this PR https://github.com/Azure/azure-rest-api-specs/pull/11733/files. This PR is adding that API back. No SDKs are generated on top of this version 2020-10-01 yet

Approve breaking change "This PR is adding one API back which was missed while consolidating all APIs in the latest version in this PR Combining existing versions in latest version 2020-10-01 by pratimaupadhyay02 · Pull Request #11733 · Azure/azure-rest-api-specs (github.com). No SDK has been generated on top of this package yet"


Dynamic Thresholding's Influence on Other Extensions' CFG Scale

Hi. Just a quick question. Does Dynamic Thresholding affect the CFG Scale settings of other Automatic1111 extensions, in any way?
There are many examples of these popular extensions, but off the top of my head, how about ADetailer/After Detailer? And if yes, how so? Does Dynamic Thresholding "add" to their settings, or does it completely override them, or is the effect something else entirely?
Anyway, thanks in advance.

That is a per-extension question, depends what the other extension does. DynThresh's alteration exist within a sampler override, so only things that use p.sampler will potentially be altered.


🚀 [Feature Request] - Create Profile page for mentor dashboard

Is your feature request related to a problem ? Please describe. ✍
Mentor should be able to edit it's profile and send data to backend
Describe briefly how you would implement this enhancement.
there is dashboard.js in components folder ... you just have to modify it to make profile page for mentor dashboard.

Additional context or screenshots

Are you contributing for a program?
GSSoC2023
Code of Conduct

[X] I have read and agree to the Contributing Guidelines of this project.

Hey @anmode , I would like to work on this issue , please assign this me.

you can reuse the code for dashboard.js actually it has same functionality as we need for profile page

you can reuse the code for dashboard.js actually it has same functionality as we need for profile page

okie

@Pragati-3003 sidebar update hua h ..please pull latest changes and how profile page is going?
seee there is dashboard.js in component folder it would be very help. actually whi h almost profile page

@Pragati-3003 ? are you working on it? if not please let me know

@Pragati-3003 ? are you working on it? if not please let me know

Ya  , I am working.

actually jo popup m aarha h whi form chayeh... and thoda UI improve
usse popup mt banao please....


1e+ is parsed incorrectly

This should be parsed as a dimension with a unit of e followed by a delim token +.
I didn't verify this with the specification, so maybe good to review relevant sections.
https://github.com/romainmenke/css-tokenizer-tests/blob/main/CHANGELOG.md#111

Yep this looks correct.

If the next 2 or 3 input code points are U+0045 LATIN CAPITAL LETTER E (E) or U+0065 LATIN SMALL LETTER E (e), optionally followed by U+002D HYPHEN-MINUS (-) or U+002B PLUS SIGN (+), followed by a digit, then:

My reading is that it must include both the plus sign and the digit to continue parsing the exponent.

Thanks! This is now released as https://github.com/keithamus/csslex/releases/tag/v1.0.3

Awesome!

@romainmenke also noticed https://github.com/romainmenke/css-tokenizer-tests/commit/3b31516cd9147f6d19d748dcc0cf80bf9ac145a8 so I've released https://github.com/keithamus/csslex/releases/tag/v1.0.4 to fix that 😉

Haha, was just filing an issue 🙇
I've switched the fuzzer to compare with csslex but it tends to find issues one by one :)

After ±3 million randomly generated bits of CSS I am fairly certain that there are no more issues 🎉


Inquiry about the plan to release DefUseChain module

Hi~
First of all, thank you for sharing such an awesome static analysis tool like Scalpel.  It has been incredibly useful in my work.
I notice that there is a module named DefUseChain in SSA, but it seems that it is not implemented yet. Do you have any plan to implement and release it?
Thanks :)

Hi,
Thank you for your interest. Yes, this is in progress work and we will have a major release in coming month. Please feel free to share your ideas and contribute.

There is an existing implementation of Def-Use chains, it's pretty well-tested.
https://github.com/serge-sans-paille/beniget
I think it would be easy to adjust it work with ast nodes (it works with gast, wich is compatibility layer on top of ast, but it's mainly the same except for deprecated nodes and except handlers.)
Adjusting that module would be the path of least resistance in term of implementation, I've already done it once.

Thanks for this point.  Sure, I will look into the project and see how we can appropriately integrate this tool into Scalpel.

Also, DUC is under development at https://github.com/SMAT-Lab/Scalpel/blob/scalpel-base-dev/src/scalpel/duc.py


Retry named pipe connection on race condition

If the named pipe server does not have an outstanding call to ConnectNamedPipe() at the time the client calls CreateFile() or WaitNamedPipe(), the client can receive ERROR_FILE_NOT_FOUND and ERROR_BAD_PATHNAME errors.  When that's the case, there is no choice but to retry after a short delay in the hope that next time, the server will be able to accept the connection.
This error occurs infrequently in low traffic situations, but it manifests quite reliably when clients open concurrent connections and/or open many short-lived connections in a short period of time.
Fixes #67.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: AndreLouisCaron sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@StefanScherer I don't mean to put any pressure, but I'm hoping that this can get merged sometime soon.   Please let me know if I can do anything to help speed up the process.

Maybe @jstarks can have a look at your PR to improve stability opening a named pipe. 🙏

@jstarks I'm still hoping you might have a chance to review this sometime soon :-)

Again, I don't mean to put any pressure, but this issue is blocking Windows support of the Terraform provider for Docker.
I also (albeit rarely) encounter this issue with regular Docker usage on Windows when running scripts that quickly issue a series of Docker commands.
If this fix is not suitable, I'll gladly improve it according to your suggestions, but I'd like to somehow make opening the named pipe more resilient in the near future :-)

@jstarks @jhowardmsft @darstahl any update on this topic? What's the status of the go-winio library overall ?

This issue is responsible for failures in my test suite at AppVeyor, testing an IPC based transport for mangos (see github.com/go-mangos/mangos/pull/318 and https://ci.appveyor.com/project/gdamore/mangos/build/1.0.187 )

These changes feel wrong to me.
First off, there are legitimate reasons why you would get ERROR_FILE_NOT_FOUND or ERROR_BAD_PATHNAME, which indicate that truly there is nothing at the other end.  Retrying forever is clearly incorrect.
I'll comment on the diffs.

@gdamore Thanks for the feedback.

First off, there are legitimate reasons why you would get ERROR_FILE_NOT_FOUND or ERROR_BAD_PATHNAME, which indicate that truly there is nothing at the other end

Yes, that's pretty obvious to anybody from the name of the constants.  However, the named pipe API makes no difference between "you caught the server at a bad time" and "there really is nothing at the other end".  I honestly can't see how to retry to hide the former without changing the meaning of the latter.

This looks to me like it creates an infinite loop if there really is no pipe server present. [...] Probably what you could do is move this check to after the timekeeping validation. [...] What you do need to do is bail if the time is after the absolute timeout above.

Thanks for spotting this, it's clearly a major issue.  Also, thanks for the suggestions, that loop structure sounds better than what I have here.

We're now 6 weeks after I posted this and there has been no feedback until now.  Is there any chance applying this feedback will get the PR merged?  If not, then I'm unlikely to put more work into this.

That's disappointing.  I wonder if I should switch to npipe instead... I was hoping that being from Microsoft that this would get a bit more "official" support.

I'd offer to write up the necessary code changes myself (heck almost tempted to fork this project), but if I do it that means getting a CLA, which is a PITA and probably takes longer.  Someone should tell Microsoft that CLAs are bad juju in the open source world.  (If buying GitHub means that there will be more CLA stuff on GitHub, that's a bad thing.)

Having said that, I just read Microsoft's CLA, and its pretty benign.  It doesn't seem to do anything other than reassert the terms in the license (but adds a patent grant clause, which an Apache license would do anyway), along with an assertion that the IP you're contributing is yours to do so with.  Specifically it doesn't seem to grant microsoft ownership of the IP itself.

The lack of activity here is depressing.  Maybe it's time to fork this project? On the one hand its only been a about a month and a half since the last commit to this project.  On the other hand... we're talking about a Microsoft repository.  They should care about stuff carrying their name, and there should be more than one employee there with the ability to at least comment on this stuff.

Actually, what I'm going to do is fork this, and submit a new PR that properly addresses this.  I'm pretty sure that if you implement things correctly, you will get ERROR_FILE_NOT_FOUND only if the pipe hasn't had any instances created.  If the code is done correctly, there should always be an instance waiting around.  (This may mean that we need the listener to be modified to do that... I've got code that does this for my own NNG C based project.)   Then you only need to treat ERROR_PIPE_BUSY as a transient error that you retry.

I have a new theory.  Which is kind of ugly, but I think it may work.  The best way to solve this would have been if CreateFile didn't return success unless a matching ConnectNamedPipe was made, but it appears that the Win32 API is designed to match CreateFile with CreateNamedPipe instead of ConnectNamedPipe.
I suspect that the reason we are seeing problems in containers is different handling of closed pipes -- the original code opens a named pipe client to connect it with FirstHandle.  But then closes it.  I think this actually leaves the pipe not in listening state, leading to no active pipes at some times.
As a workaround, I think simply not closing the scratch pipe that was opened would do the trick.  That would then need to be closed only when we are closing the listener.
Stay tuned.

Its worse, because the use of WaitNamedPipe is indeed racy.  The semantic of specifying 0 to get a server determined timeout is highly problematic, since there isn't really a way to make that work reliably that isn't racy in the existing Win32 API.

So what I'm doing is creating a "default" timeout of 5 seconds, and spinning at 10 msec intervals.  This is still not perfect because a super-busy pipe server can "miss" connections (one of the connection requests can timeout due to starvation), but its really the best we can do without a listen queue like TCP has.  5 seconds was chosen as a default to improve the likelihood of success, and 10 ms represents something approaching a clock tick on most platforms.

Please have a look at #80 -- I took a rather different approach, and I would like to have folks try it out to see if it makes their lives better.

I recommend the submitter to close this PR.  It clearly is wrong, and I believe #80 is far superior.  I'm worried that the presence of this open PR may hinder the timely acceptance of #80.  I think we all want to see forward progress here.

Closing in favor of #80.


First query - too specific

This first tutorial query needs to be much broader, so that the learner doesn't get "No results found in the specified time frame." on their first try.
This query is a little better:
union DeviceProcessEvents, DeviceNetworkEvents | where Timestamp > ago(7d) | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,  FileName, ProcessCommandLine, RemoteIP, RemoteUrl, RemotePort, RemoteIPType | top 100 by Timestamp

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

ID: 5bc0f70e-62ba-9d2b-1f24-83e8abb513bf
Version Independent ID: 117e04d7-f7b9-a3db-e2a2-46da46008c96
Content: Learn the advanced hunting query language in Microsoft 365 Defender
Content Source: microsoft-365/security/defender/advanced-hunting-query-language.md
Product: m365-security
Technology: m365d
GitHub Login: @schmurky
Microsoft Alias: maccruz

@msbemba

@TBSJordanNash Thank you for your feedback. I get what you are saying, however the reason we have specific commands and process is to understand how they are being used.
Thank you again for your feedback.
@yogkumgit  This can be closed.
Thanks
Sri

@msbemba Thank you very much for the contribution and sharing this explanation. @TBSJordanNash Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Provide git extension interface API

While I was trying to use parts of the git extension I noted there is no "exports" variable available when using the following snippet:
let gitExt = vscode.extensions.getExtension('vscode.git');
console.log(gitExt.exports);

Wouldn't  it be good to have such exports available for other extension developers the way it is described here
Kind of an API for important git commands, like checkout, branch, commit.

How's this coming along?

Another checkup.
I've just run into having to find a project's git remote from my extension, and this would really be useful!.
Instead, for now, I'll copy/paste the code from the extension to re-implement it for my purposes 😒: https://github.com/Microsoft/vscode/blob/b161ce4305a101a54c3088040fa2dc544755e2d5/extensions/git/src/git.ts

This is now in.

Verifier: check out https://github.com/Microsoft/vscode/blob/master/extensions/git/src/api/git.d.ts


npm run setup failing

After cloning, trying to follow the README running npm run setup .
><EMAIL_ADDRESS>setup /Users/patriciojeri/Sites/react-boilerplate
> node ./internals/scripts/setup.js

module.js:471
    throw err;
    ^

Error: Cannot find module '/Users/patriciojeri/Sites/react-boilerplate/internals/scripts/setup.js'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3

npm ERR! Darwin 14.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "setup"
npm ERR! node v6.9.2
npm ERR! npm  v3.10.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>setup: `node ./internals/scripts/setup.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>setup script 'node ./internals/scripts/setup.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./internals/scripts/setup.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.

Node: v6.9.2
NPM: 3.10.9

FIX: If you followed the instructions from http://www.reactboilerplate.com/ like me, you need to clone with git clone --depth=1 https://github.com/mxstbr/react-boilerplate.git instead of git clone git@github.com:mxstbr/react-boilerplate and then npm run setup works.

I get the same issue and cant run it from a fresh clone.

@iwoork Try yarn install (or npm install) in place of npm run setup. That won't clean the git repo from your clone, but otherwise it's the same.

I'm getting Could not find or load main class install when I try to use yarn.

Found the problem. npm needs to be updated.


Update interfaces for the hall events module

As part of #92, #95.
Update the Model.java and Logic.java interfaces to handle the new hall events module.
Also left a TODO: [Event] in the code so I know what to update for the next PR.
Changes are mainly to provide support for the hall event UI side for @yanchenglee98.
Also added one functioning test case to show how to extract the list.

Codecov Report

Merging #104 into master will increase coverage by 0.06%.
The diff coverage is 77.77%.

@@             Coverage Diff              @@
##             master     #104      +/-   ##
============================================
+ Coverage     72.29%   72.36%   +0.06%
- Complexity      454      462       +8
============================================
  Files            79       81       +2
  Lines          1462     1480      +18
  Branches        151      152       +1
============================================
+ Hits           1057     1071      +14
- Misses          359      362       +3
- Partials         46       47       +1

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)
1.00 <0.00> (ø)

src/main/java/seedu/address/model/event/Event.java
57.14% <57.14%> (ø)
3.00 <3.00> (?)

...ava/seedu/address/model/event/UniqueEventList.java
85.71% <85.71%> (ø)
2.00 <2.00> (?)

...rc/main/java/seedu/address/logic/LogicManager.java
76.19% <100.00%> (+1.19%)
4.00 <1.00> (+1.00)

src/main/java/seedu/address/model/AddressBook.java
92.30% <100.00%> (+0.64%)
13.00 <1.00> (+1.00)

...rc/main/java/seedu/address/model/ModelManager.java
100.00% <100.00%> (ø)
24.00 <1.00> (+1.00)

Continue to review full report at Codecov.

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

EDIT: was part of #91 as well.


fix uppercasing of context-macros

When uppercasing the whole macro name, in many cases context macros will not work. Consider "{DISK_SPACE_WARN:/storage/volume}", which is not the same as "{DISK_SPACE_WARN:/STORAGE/VOLUME}".
This fix changes only the part on the left side of the colon.

Thanks for the patch!


Run in a blocking thread the CQDelete command's cache removes

https://issues.redhat.com/browse/ISPN-16821

Thanks!


fix: Change from waiting for k8s readiness to full e2e

Overview
The test-runner fails because the service isn't ready after a deploy. This halts execution of the test-runner until the ingress is live.
Changes
kubectl -> curl
Testing

Coverage remained the same at 77.905% when pulling b8e5240c0b20c284e86def88cad928c2f9405baa on curl_watcher into a8bdb6728206c8366b263163b14aed5df2e80cdb on master.

Coverage remained the same at 77.905% when pulling b8e5240c0b20c284e86def88cad928c2f9405baa on curl_watcher into a8bdb6728206c8366b263163b14aed5df2e80cdb on master.


Refreshing gutter failed!

I setted a apache document root in the same directory as the git one.

Brackets 1.2.0-15697 (linux), Git 2.3.4 & Brackets-Git 0.14.19
Refreshing gutter failed!
Error: Error: spawn ENOENT
    at errnoException (child_process.js:980:11)
    at Process.ChildProcess._handle.onexit (child_process.js:771:34)

call: git status -u --porcelain -- model/php/variables.php
Error: Error: spawn ENOENT
    at errnoException (child_process.js:980:11)
    at Process.ChildProcess._handle.onexit (child_process.js:771:34)
    at Object.exports.toError (file:///home/xxx/.config/Brackets/extensions/user/zaggino.brackets-git/src/ErrorHandler.js:162:19)
    at NodeConnection.<anonymous> (file:///home/xxx/.config/Brackets/extensions/user/zaggino.brackets-git/src/Cli.js:176:44)
    at j (file:///opt/brackets/www/thirdparty/thirdparty.min.js:559:26911)
    at Object.k.fireWith (file:///opt/brackets/www/thirdparty/thirdparty.min.js:559:27724)
    at NodeConnection._receive (/utils/NodeConnection.js:492:34)

Improved error handling for this in 0.14.24


Damage doesn't accept min/max values.

when using "Damage:{min:0,max:15}" it doesn't work like Count does.  Took me awhile to figure this out.

I'm fairly confident that I'm right, but I think the following code would fix this issue, though I don't have the means to compile and all that jazz to test it out right now.  Also I'm coming from a background of LUA not Java.  I might download an IDE and test it to be sure but I don't have the time at the moment, but thought I could try to help.
insert into class
`
private static int getRandomIntInRange(int min, int max) {

	if (min >= max) {
		throw new IllegalArgumentException("max must be greater than min");
	}

	Random r = new Random();
	return r.nextInt((max - min) + 1) + min;
}

`
then replace the damage if statement at line 345 of existing code to
`
private static int getRandomIntInRange(int min, int max) {

	if (min >= max) {
		throw new IllegalArgumentException("max must be greater than min");
	}

	Random r = new Random();
	return r.nextInt((max - min) + 1) + min;
}

`


Hard link the Documents folder -> FaF can't load any mods/maps

Recently I hard-linked to a Netdrive the whole Documents folder which also contains all map/mods for FaF.
For Example, when you go to:
C:\Users\username\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance
you get linked to
G:\My Drive\hardlinks\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance
It works perfectly for every other application and game I have used so far, except FaF. Here it gets really weird:
A, If I have the mods/maps in:
G:\My Drive\hardlinks\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance
he can see everything in FaF, but can not load them. I need to have the maps/mods as well in:
C:\Users\username\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance
to be able to load them.
B, If I have the mods/maps only in:
C:\Users\username\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance
then he can not see anything. I need to have them in G:.... as well.
If there is a way to fix this behavior would be nice. Maybe to be able to manually set a path from the FaF to mods/maps?

There is a switch in the settings that you can use to store the maps/ mods in a different directory. There you can set that the client stores the vault stuff in C:/ProgrammData/Faforever/ something ... Maybe try that

There is a switch in the settings that you can use to store the maps/ mods in a different directory. There you can set that the client stores the vault stuff in C:/ProgrammData/Faforever/ something ... Maybe try that

The only setting I have found is the "Vault Fallback Location", but could not find how to enter a path manually. Enabling this made no changes.

The only setting I have found is the "Vault Fallback Location", but could not find how to enter a path manually. Enabling this made no changes.


Access URL is a URI

Very minor thing I just noticed:
https://github.com/IndustrialDataSpace/InformationModel/blob/develop/model/communication/Host.ttl#L39
The property AccessURL has range xsd:anyURI. Should we rename the property to AccessURI or change the range to xsd:anyURL?

As far as I know, there is no xsd:anyURL.  We are using xsd:anyURI because it is the
closest to an URL.
I'd suggest to leave it like this. The name / label fits but the  datatype allows more than just URLs.
The inconsistency comes from the missing xsd: property for URLs.  But, we are expecting any kind of http / mqtt / ... URL.

Ah you are right. They don't have an any url...


Feature request - Make streamfield blocks collapsible in admin

It would be nice to be able to toggle the content of StreamField blocks in the admin - so with all blocks collapsed you'd just see a list of the block type labels (something like the attached), which, when clicked on, would expand to show the corresponding fields. This would be useful in situations where there are a lot of blocks on a page and you don't want to have to scroll endlessly to find the fields you want to edit.

Hi @mattots,
This seems a bit counter-productive to me... surely if there's a particular image or bit of text you want to edit, you're better off scrolling through the interface looking for the image/text in question, rather than having to think about what type of block it is ("wait, is this an image, or a featured image...?") and clicking into them to find it?

A lot of the sites we built (and still maintain) before we started using Wagtail had something similar to (but rather more clunky than) the StreamField with collapsible blocks, so we've got quite a bit of experience of how clients use this sort of functionality, and it seems to be something that they find useful. I don't think it should necessarily be enforced, but an option to make the blocks collapsible via a parameter, and possibly to define whether they start expanded or collapsed, would be nice.

when I use StreamField I feel eager to own this feature, truly.

This feature is surely very useful, especially when there is a great number of blocks in the streamfield. @gasman is right in that seeing only the block's type is not enough to find the exact block you want to edit. But this can be easily improved by optionally using the value of a text field as a title while in collapsed state. So, for example, image blocks in the example above could be configured to have a title consisting of the 'caption' field  value. What do you thing?

@Ernest0x That sounds like a good idea, although it would add quite a bit of complexity to the implementation - you'd need some way to specify which field to use as the title, as Wagtail doesn't know which fields are the important ones.
To be honest, I'm not massively keen on this proposal, as it feels like "sweeping the real problem under the carpet". If you need to hide fields in order to make the edit interface manageable, then I'd take that as a warning sign that your information architecture could be improved. (As a rough rule of thumb - the vertical space that your edit interface takes up should not really be substantially more than the height of the page as seen on the site's front-end.)
Maybe that improvement is something that you can do as a site implementer, such as moving some data into sub-pages or snippets... maybe it calls for a new feature in Wagtail that hasn't been identified yet. Quite possibly, it's a bit of both. I feel that collapsible blocks are a similar situation to rich text fields - a convenient hack that solves the immediate problem, but closes your mind to the possibility of better ways of organising your data.
In the case of @mattots's example, I would point the finger at the 'class' and 'ID' fields - those are low-level HTML details that, ideally, editors wouldn't be dealing with. (That's not a criticism... as I say, it may well point to an as-yet-unidentified missing feature of Wagtail.) If you have several different types of image that are distinguished by different CSS/JS behaviour, then perhaps it would be more natural to make those into distinct block types - like, say, 'photo' and 'infographic' - instead of a single 'image' type.
Alternatively, one design concept we had floating around some months ago was to have a 'cog' icon in the corner of the block, to give access to the lesser-used configuration options (like I suspect 'class' and 'ID' are here) so that they aren't taking up space in the main body of the page. Either way - if we can find a way to eliminate those fields, we'd immediately halve the height of that block.
I know it probably sounds like I'm replacing a simple solution with a more complicated one, but I suspect that collapsible blocks would be a deceptively complex thing to implement (due to the need to introduce new configuration options, and possibly remember the open/closed state of each panel on a per-user basis), and my gut feeling is that there are simpler solutions that will address the root cause of the problem more effectively.

I really like the idea of the cog. You're right in pointing out the 'class' and 'id' fields as being something that most editors wouldn't/shouldn't need to worry about and in our situation its fairly rare that they actually are required (although having them there has proved useful at times which is why we keep them in by default). But being able to hide away lesser used options is a nice idea that could help keep things simpler and reduce page length.

@gasman I would suggest the use of a Meta class attribute named "admin_title_fieldname" or something like that. Remembering of open/closed state for panels is not that useful either. All panels would be loaded in a collapsed state by default, unless there are validation errors. I do not think this would add that much complexity to neither the implementation or the admin definition process.
Also, there may be great difference between data definition (admin), which is always vertical, and data representation (frontend) which may be horizontal. So, the rule of thumb you are mentioning is not practical in many cases.
Furthermore, the number of fields in a block may not be relevant. Usually, the problem appears when there is repeatability of same blocks. In the example above, the Image block, even if it only consisted of 'image', 'caption' and 'link url' fields, it would still take pretty much vertical space if it had to be repeated multiple times.
Another suggestion I am thinking now is the introduction of "container" panels. A "container" panel would act as a way to group some panels together and give them some UI possibilities like collapsing, moving up and down as a whole, removing, etc.

This would probably make managing larger lists easier. Refs #2264.

@heymonkeyriot has been secretly working on some designs that could improve giant streamfield blocks

:+1:

Though what I've been working on moves in a slightly different direction to the suggestion that @mattots made above (I hadn't seen this issue before) I think making them collapsible could make a lot of sense (and is sort of in keeping with how inline blocks can be open or closed). But collapsing them also feels like it moves away from my understanding of the original goal of streamfield, which was to have the content presented in a way that offered the least possible distraction to the editor.  I showed  @alexgleason some very rough mockups because I could be there to explain them, will share them virtually when they're a bit more together :)

How about added an optional "collapsible" class to streamfieldpanels and adding an "expand all" button.
As I see it that would solve the preference of collapsing without losing the search/overview capability.
What do you think?

As part of the Wagtail’s first Kickstarter campaign, I’m working on this!
https://www.kickstarter.com/projects/noripyt/wagtails-first-hatch

I'm interested in this feature as well.
Additionally it would be great if you could collapse top level sections of the site as well. For example the downward facing arrow to the left of the red section already makes me think I should be able to click to collapse.

Hi @commadelimited,
I am not mistaken this can be done with https://github.com/wagtail/wagtail-react-streamfield#meta-attributes-or-passed-to-init does this, so when it makes it in Wagtail, the functionality will be there.

@zerolab oh wow, nice! Thank you for the mention.

+1

Implemented as part of the telepath StreamField rewrite in 2.13.

Implemented as part of the telepath StreamField rewrite in 2.13.

Could you explain, how StreamField block can now be collapsed since the implementation in 2.13?

@bitwise-gmbh That isn't implemented yet - there's a separate ticket for that at #7705.


feat(nodebuilder/header): Add Subscribe method implementation

Blocked on method collision (cc @distractedm1nd )
Resolves https://github.com/celestiaorg/celestia-node/issues/1942

unblocked by #1944


Communication Rooms Readme Issue

Section link

Reason:
Lack type declaration.
Suggestion:
Update to updateParticipantsList:RoomParticipantPatch[] .
@joheredi, @mayurid, @alexokun for notification.

The readme code snippets are in JS not TS, so a type annotation shouldn't be necessary?

@xirzec The other code snippets in this readme are in TS. So do we need to update the issue to update other code snippets to JS?

@xirzec There are some issues with the code snippets, updating the readme code snippets to ensure consistency in https://github.com/Azure/azure-sdk-for-js/pull/28607.

@v-jiaodi Left a review, I think it looks good, but I tagged a couple folks on the ACS side for visibility. I think if they haven't responded in a few business days it should be safe to merge.


[Documentation]update readme file to reflect recent updates and changes to the plugin

Is your feature request related to a problem?
The existing README file is old and missing recent changes to our repo such as metrics Analytics and Itegrations
What solution would you like?
Update the readme file to reflect latest developments
What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?

https://github.com/opensearch-project/dashboards-observability/wiki

@YANG-DB closing because you completed this in #691 , feel free to re-open if that's not the case


URL parsing does not work - don't know why

Hello @medialize - looks like this url is not parsed properly?
http://hello.demo.be/#/views/FilterDashboard/D_OneDimension?SelectAggr…ectMeasure=Sales&SelectDimension1=Category&:embed=yes&:tabs=no&:toolbar=no
I tried uri.getSearch(true) and wanted to get the query "object" from "SelectAggr…ectMeasure=Sales&SelectDimension1=Category&:embed=yes&:tabs=no&:toolbar=no"
Doesn't work - could you tell me what I am doing wrong?

You are correct. the multiple : are causing problems.

Thanks @rodneyrehm - since it was the first time using the library I wasn't sure.

My bad, I only had a quick glance at the URL and didn't see the # in there. URI is correctly parsing your URL:
var input = 'http://hello.demo.be/#/views/FilterDashboard/D_OneDimension?SelectAggr…ectMeasure=Sales&SelectDimension1=Category&:embed=yes&:tabs=no&:toolbar=no';
var uri = URI(input);

is parsed to:
{
  "protocol": "http",
  "username": null,
  "password": null,
  "hostname": "hello.demo.be",
  "urn": null,
  "port": null,
  "path": "/",
  "query": null,
  "fragment": "/views/FilterDashboard/D_OneDimension?SelectAggr…ectMeasure=Sales&SelectDimension1=Category&:embed=yes&:tabs=no&:toolbar=no",
}

this is not a bug.

Thanks @rodneyrehm -
Could you tell me why the part of the URI that starts with "?" is not truly a querystring because of the "#" ?  I guess this is about some intricacies of URIs?

Have a look at Understanding URIs - specifically the ASCII chart detailing the components. You're being tricked by thinking ? is more important than #, while it's the other way around. Everything past the first # is considered the fragment (or hash, as its commonly referred to as well).