add RESTler support for formData API

This is one of my swagger 2.0 specification, and I have a lot of these kind of data problems.
/get_model_feature:
    post:
      tags:
      - "Model"
      summary: "Obtain all device features of a device model"
      consumes:
        - application/x-www-form-urlencoded
      parameters: #input
        - in: "formData"
          name: "dm_name"
          description: "device model name"
          type: string
          required: true

      responses:
        "200":
          description: "ok"
          schema:
            "$ref": "#/definitions/DeviceFeature"

This is the result of Restler-fuzzer testing:
-> POST /get_model_feature HTTP/1.1\r\nAccept: application/json\r\nHost: <IP_ADDRESS>:7788\r\n\r\n
! producer_timing_delay 0
! max_async_wait_time 20
PREVIOUS RESPONSE: 'HTTP/1.1 400 BAD REQUEST Content-Type: text/html  Content-Length: 192  Connection: keep-alive
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">  <title>400 Bad Request</title>
Bad Request

The browser (or proxy) sent a request that this server could not understand.
'

We can see that the request sent a empty data when we use - in: "formData" , it only send data with
Parameters:
  - in: "body"

How can I fix it?
Thank you!

Could you attach your dict.json and grammar.py?

This is my dict.json
{
  "restler_fuzzable_string": [
    "fuzzstring"
  ],
  "restler_fuzzable_string_unquoted": [],
  "restler_fuzzable_datetime": [
    "6/25/2019 12:00:00 AM"
  ],
  "restler_fuzzable_datetime_unquoted": [],
  "restler_fuzzable_uuid4": [
    "903bcc44-30cf-4ea7-968a-d9d0da7c072f"
  ],
  "restler_fuzzable_uuid4_unquoted": [],
  "restler_fuzzable_int": [
    "0",
    "1"
  ],
  "restler_fuzzable_number": [
    "0.1",
    "1.2"
  ],
  "restler_fuzzable_bool": [
    "true"
  ],
  "restler_fuzzable_object": [
    "{}"
  ],
  "restler_custom_payload": {},
  "restler_custom_payload_unquoted": {},
  "restler_custom_payload_uuid4_suffix": {}
}

This is grammar.py
from __future__ import print_function
import json
from engine import primitives
from engine.core import requests
from engine.errors import ResponseParsingException
from engine import dependencies
req_collection = requests.RequestCollection([])
# Endpoint: /get_model_feature, method: Post
request = requests.Request([
    primitives.restler_static_string("POST "),
    primitives.restler_static_string("/"),
    primitives.restler_static_string("get_model_feature"),
    primitives.restler_static_string(" HTTP/1.1\r\n"),
    primitives.restler_static_string("Accept: application/json\r\n"),
    primitives.restler_static_string("Host: <IP_ADDRESS>:7788\r\n"),
    primitives.restler_refreshable_authentication_token("authentication_token_tag"),
    primitives.restler_static_string("\r\n"),

],
requestId="/get_model_feature"
)
req_collection.add_request(request)

Hello @rreexxllii0310,
RESTler does not currently support form data parameters.
As a workaround, you could manually edit the grammar to send the required content type and additional parameters.
Marking this issue as a feature request.

Hello @marina-p ,
Sorry for lately reply.
We have successfully sent form data parameters by edit the grammar, thank you!

Hello @marina-p,
Does RESTler currently support form data parameters?


Zoomed in dialogue boxes are cut off in both windowed and full screen

When click "learn more" and dialogue boxes zoom forward, some of both the NPC and the text is cut off by the screen. This is not just a 'windowed view' problem

This also breaks the game if you click on the third character in the current scene because the dialogue box floats backwards and I can't reach the "go back" button. Perhaps a quick fix would be to not disable scrolling when the dialogue box is up?

Jay says the easiest workaround as of now is to play in widescreen (i.e. adjust the aspect ratio of the window).

played in 1600x900 and it still happened. Is there an ideal res we should designate for the demo?

try 1334x1008

dont have that option but tried on closest. Better, but now when i clicked on him he just vanished haha.


Can't get it to work in newly generated project

I can't make it work in my projects. I tried with the latest RN, tried with older versions and always get the same error. What's interesting is that the sample project works fine.
Steps to reproduce:
react-native init TestApp

npm install

npm install react-native-threads

react-native link react-native-threads

Create new file index.thread.js in the root.
Add
import { Thread } from 'react-native-threads';

and
componentDidMount () {
    const thread = new Thread('./index.thread.js');
}

to App.js
react-native run-ios

And the result is:

Hi @vsakos, as far as I can tell you aren't doing anything wrong, I'm not sure why you're running into this error. Is there any code in your index.thread.js file?  Would you be able to link to a small example application replicating this issue?

closing due to inactivity/lack of response


[Feature] Sort policies alphabetically before evaluating them

Problem Statement
When multiple policies are present, sort them alphabetically to apply them in a deterministic order.
Solution Description
When multiple policies are present, sort them alphabetically to apply them in a deterministic order.
Alternatives
No response
Additional Context
No response
Research

[X] I have searched other issues in this repository and mine is not recorded.

@vishal-chdhry assigned to you


Error 1 google/protobuf/port_def

conda install caffe-gpu  make all -j && make py
log:
compilation terminated. make: *** [.build_release/src/caffe/layers/base_data_layer.o] Error 1 In file included from ./include/caffe/util/cudnn.hpp:8:0,                  from ./include/caffe/util/device_alternate.hpp:40,                  from ./include/caffe/common.hpp:19,                  from src/caffe/data_reader.cpp:6: .build_release/src/caffe/proto/caffe.pb.h:10:40: fatal error: google/protobuf/port_def.inc: No such file or directory  #include <google/protobuf/port_def.inc>

@zihaozhang9
This issur is about CAFFE, you can search for solutions online.


TypeError: Cannot read property 'toString' of null in JVM internals

Trying to use the webroot at:
https://github.com/ianopolous/DoppioDemo
A type error is thrown in the message element of:
function flatThrowableToJS(ft) {
  var cause = ft["com/javapoly/FlatThrowable/causedBy"];
  return {
    name: ft["com/javapoly/FlatThrowable/name"].toString(),
    message: ft["com/javapoly/FlatThrowable/message"].toString(),
    stack: ft["com/javapoly/FlatThrowable/stack"].array.map(function (e) {
      return e.toString();
    }),
    causedBy: cause === null ? null : flatThrowableToJS(cause)
  };
}

@ianopolous That was a bug in Javapoly. I have pushed a fix just now. Please let us know here if it doesn't work.

Closing because this is not DoppioJVM code.


logstash... Address in use {:host=>"<IP_ADDRESS>", :port=>5000}

logstash container first run produces:
logstash_1       | 16:12:14.320 [[main]-pipeline-manager] INFO  logstash.inputs.tcp - Starting tcp input listener {:address=>"<IP_ADDRESS>:5000"}
logstash_1       | 16:12:14.347 [[main]-pipeline-manager] INFO  logstash.inputs.tcp - Starting tcp input listener {:address=>"<IP_ADDRESS>:5000"}
logstash_1       | 16:12:14.349 [[main]-pipeline-manager] ERROR logstash.inputs.tcp - Could not start TCP server: Address in use {:host=>"<IP_ADDRESS>", :port=>5000}
logstash_1       | 16:12:14.350 [[main]-pipeline-manager] ERROR logstash.pipeline - Error registering plugin {:plugin=>"<LogStash::Inputs::Tcp port=>5000, id=>\"6daac4ada47edb10ed11af15cbbf99365c6490ec-5\", enable_metric=>true, codec=><LogStash::Codecs::Line id=>\"line_69ca403c-935e-495b-9124-398fad87342e\", enable_metric=>true, charset=>\"UTF-8\", delimiter=>\"\\n\">, host=>\"<IP_ADDRESS>\", data_timeout=>-1, mode=>\"server\", proxy_protocol=>false, ssl_enable=>false, ssl_verify=>true, ssl_key_passphrase=><password>>", :error=>"Address already in use - bind - Address already in use"}
logstash_1       | 16:12:15.373 [[main]-pipeline-manager] ERROR logstash.agent - Pipeline aborted due to error {:exception=>#<Errno::EADDRINUSE: Address already in use - bind - Address already in use>, :backtrace=>["org/jruby/ext/socket/RubyTCPServer.java:118:in `initialize'", "org/jruby/RubyIO.java:871:in `new'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-tcp-4.1.0/lib/logstash/inputs/tcp.rb:279:in `new_server_socket'", "/usr/share/logstash/vendor/bundle/jruby/1.9/gems/logstash-input-tcp-4.1.0/lib/logstash/inputs/tcp.rb:89:in `register'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:282:in `register_plugin'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:293:in `register_plugins'", "org/jruby/RubyArray.java:1613:in `each'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:293:in `register_plugins'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:436:in `start_inputs'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:337:in `start_workers'", "/usr/share/logstash/logstash-core/lib/logstash/pipeline.rb:232:in `run'", "/usr/share/logstash/logstash-core/lib/logstash/agent.rb:387:in `start_pipeline'"]}
logstash_1       | 16:12:15.491 [Api Webserver] INFO  logstash.agent - Successfully started Logstash API endpoint {:port=>9600}
logstash_1       | 16:12:18.388 [LogStash::Runner] WARN  logstash.agent - stopping pipeline {:id=>"main"}
dockerelk_logstash_1 exited with code 0

As it is separated container, nothing can occupy this port. To be on a safe side I scaned host machine ports and port 5000 is free
what can be behind? Any ideas?
Maybe main problem could be: docker4windows Version 17.03.1-ce-win5 (10743)

One of your inputs is defined twice (look at the first 2 lines), make sure you don't have a duplicate either in logstash/config or logstash/pipeline.

thank you very much @antoineco, I noticed it right after I posted the issue. Of course, this is my fault, I somehow created "logstash - Copy.conf" file

Glad you figured it out (y)


[MXNET-915] Java Inference API core wrappers and tests

Description
Adds the Java friendly version of some of the core classes that will be used for the Java Inference API. Also adds very basic unit tests for them. The purpose of which is to test that the wrapper is actually callable from Java. Testing of the Scala implementation of the wrapped class is left to the Scala testing.
Also increased the max limit on line length in our styletest config. The existing 100 limit is very easy to hit (our own style config file actually goes over this but it doesn't check itself).
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@mxnet-label-bot [pr-awaiting-review, Scala]

The api is written completely in Scala. The Java code would be the junit tests which are there to ensure good Java compatibility. They aren't mixed. One group is in src/main/scala and the other is in src/test/java.


prometheus配置请教

Please provide an in-depth description of the question you have:我是使用kubesphere安装的prometheus,我应该如何添加GPU的监控
What do you think about this question?:
Environment:

HAMi version:
Kubernetes version:
Others:

Normally, HAMi will have metrics ports exposed, and you need to configure something like service monitor to let Prometheus capture them, or add annotations on HAMi Service.


Add $PONYUP_PREFIX as another option to point ponyup's prefix

Title.For easier to deploy the development environment and runtime enviroment, user can set this environment variable before running the ponyup or shell and use the ponyup with prefix as $PONYUP_PREFIX until the variable was unset, if user wants to use other than $PONYUP_PREFIX for once, they can use --prefix to change the prefix.

We briefly mentioned this in today's sync call and this makes sense to me. :+1:

For me, I'm creating and using a tool that setting the every environment I want and run my editor for portable use(eg. setting up a pony environment before running the vscode whatever OS re-installed or change the OS) without virtualization tech.
For persent ponyup I can't using a more better option than modifing the batch file generated by ponyup or wrapping the ponyup batch with --prefix arg when I placed the ponyup prefix out of default place and using this place for daily ponyup use.

More questions:

Would you want to have a single ponyup binary that is installed in a single location and then use that with different installation locations for binaries it installed?

OR

Would you be wanting to install different ponyup binaries in different locations and each of those has its own install location?

If ponyup acts like rustup's role in ponylang,It's yes to installing the ponyup binary to a single location then use different location for toolchain binaries.

Would you be installing multiple versions of pony tools in each location or a single version?

For my preference I would like to install multiple versions of pony tools in each location.

Rather than overriding prefix, this should be an option to override the default location to look look for/install the ponyp directory.  So that the default_root can be overridden and then there's no oddness with interacting with the prefix option.
https://github.com/ponylang/ponyup/blob/main/cmd/main.pony#L17


draft PR: fixes issue #1203

@juped i have a couple of questions that I need some clarifying on:
Does passing in Extension into the two classes NOT allow for the init method defined inside of them to override the Extension's init method?
When it was not passed, tests fail(which is not a surprise), but when they are passed into the class, the tests pass(whcih I'm very surprised about).

Something like class WithExtension(Extension) means that WithExtension extends the Extension class.
You should also see if you can copy the DeprecationWarnings used elsewhere in Pallets, e.g. https://github.com/pallets/werkzeug/blob/34e7b4cd37979d3b4cd9f428df348876b9f72c0e/src/werkzeug/utils.py


Features and Fixes to report HTML

artifact-13.pdf
Sample thus for

This is coming along great!
In the artifact-13.pdf example.

[ ] can we remove the word "mark" appended to the y-axis of the sub-phases of duration section.
[ ] should we prefix "control" and "experiment" in the key?
[ ] should we bold the numerical deltas for both Hodges-Lehmann and the Conf Interval? eg ...two distributions is -132 ms and ...is between -143 ms to -47 ms
[ ] if we can do anything about the blurry canvas elements; how do things look if we don't scale to the viewport width, but rather center align?


⚠ Thumbnails API Endpoint has degraded performance

In 900f5e2, Thumbnails API Endpoint (https://thumbnails.roblox.com/v1/assets?assetIds=82738847&format=Png&isCircular=false&size=30x30) experienced degraded performance:

HTTP code: 200
Response time: 1007 ms

Resolved: Thumbnails API Endpoint performance has improved in 09312f9 after 44 minutes.


Update durable-functions-error-handling.md

Currently not able to pass in a Custom Error Handle in the Typescript runtime, however this isnt clear in the documentation. Happy to revise the new note into a better format.

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

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

https://github.com/Azure/azure-functions-durable-js/issues/103 This is the issue where MS state this functionality isnt implimented yet

@dannyb648 thanks for the help documenting this!

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

Merged Accepted from me, thanks guys for the better working!

@dannyb648 thanks again for the help with our docs #sign-off

@ggailey777: I'm sorry - only the author of this article, @, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

#sign-off

@cgillum: I'm sorry - only the author of this article, @ggailey777, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

I should be able to #sign-off on this PR.

I should be able to #sign-off on this PR.

Bug opened for PRMerger issues when the author metadata attribute is set globally in a separate file: https://ceapex.visualstudio.com/Engineering/_workitems/edit/349218


Usage of 'npm ci' for Build Pipelines

Expected Behaviour
Local build always also corresponds to CI/CD build using 'npm ci'
See for more information:

https://docs.npmjs.com/cli/v7/commands/npm-ci/
https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci

Actual Behaviour
Because of the overarching use of npm install, it is not impossible that the local build differs from the build in the pipeline, due to dependency updates.
Reproduce Scenario (including but not limited to)
Steps to Reproduce
Platform and Version
Archetype 31 and previous
Sample Code that illustrates the problem
see: https://github.com/eirslett/frontend-maven-plugin#running-npm
Using the frontend-maven-plugin used in the archetype, it is possible to customize the arguments via the plugin configuration (install -> ci).
Logs taken while reproducing problem

This duplicates #685

Could this be closed then?


Update scatter.jl

scatter showed the plot twice, this removes the bottom plot

thanks, but unfortunately since a lot of things have change in DocumenterVitepress, I will need to do a big update on how the site is being built. I will keep this issue in mind. Thanks again.

fixed on latest.


Pod: Upgrade OLMKit version (3.0.0)

Closes https://github.com/vector-im/riot-ios/issues/1930.

I needed to update fastlane to make lint work:


Remove docker related pre-requirements

As far as I can see, what hyper needs from docker is only downloading images.
If this part of job can be done by registry API inside hyper, users can install less pre-requirement software. And this can really  make "Hyper = Hypervisor + Kernel + Docker Image" concept more clearly. As for myself, the relation between docker and hyper confused me for a long time.

Thank you @oilbeater , this issue will be closed after eliminate all docker dependencies.

fixed by https://github.com/hyperhq/hyper/commit/b569471193d5a730deb5e509ec2fb1fd22c659d4


Is it possible to update p with loss of another parameter p_?

for example:
grads = grad(loss)(p2, x, y)
inner_sgd_fn = lambda g, state: (state - alpha*g)
p = tree_multimap(inner_sgd_fn, grads, p2)
or
grads = jax.grad(loss)(p2, x, y)
updates, state = opt.update(grads, state)
p = optax.apply_updates(p, updates)

Yes, nothing in the API would prevent you from doing so. The gradient computation from the loss is completely separate from applying the updates in Optax (as you showed in your code snippet). Are there any issues you encountered when trying to do this?

As long as p and p2 that seems fine.

Closing this as I think the question has been answered.


broken link for sql:weekday

The types JavaDoc has a broken link in the Server Doc column for sql:weekday
http://docs.marklogic.com/javadoc/client/doc-files/types/item.html
https://github.com/marklogic/java-client-api/blob/b5350b2cfcf09c45422817bb25a37d2ed37f8eb3/marklogic-client-api/src/main/javadoc/doc-files/types/item.html#L343
http://docs.marklogic.com/sql:weekday returns an HTTP 404 and is not listed as one of the MarkLogic SQL functions: http://docs.marklogic.com/sql

I think this is a documentation bug on the server.
In Query Console, sql:weekday(fn:current-date()) seems to work just fine.

Okay, there are a number of sql:* functions (sql:datepart, sql:dateadd, sql:datediff) that seem to be referenced in various site pages, but don't have a documentation page available. I'll file an internal bug to get them investigated and resolved.

Thanks, @hansenmc , for the scrupulous attention here.
Stating the obvious, if we don't document a function, that makes it hard to use...

Issues for /javadoc/ reported in internal bugs should be gone once the documentation build picks up the Java doc generated from this fix.

Verified a local Java docs build. Available from Interface SqlExpr at marklogic-client-api/build/docs/javadoc/index.html?overview-summary.html,  weekday link.
Broken link at docs.marklogic.com tracked via internal bug tracking system; reference BT 53936.


round_ties_up fix

Objective
round_ties_up checks the predicate:
0. <= value || value.fract() != 0.5

which is meant to determine if the value is negative with a fractional part of 0.5.
However given a negative value, fract returns a negative fraction so the predicate is true for all numeric values and ceil is never called.
Solution
Changed the predicate to value.fract() != -0.5 and added a test.
Also improved the comments a bit.

Just to confirm, this PR made a small visual change in example overflow_debug:
https://github.com/bevyengine/bevy/assets/8672791/4adcb5ec-7ba4-4736-a65c-b68300f5bc27
It feels OK for me

Just to confirm, this PR made a small visual change in example overflow_debug:

Yep this is as expected, overflow_debug and z_index are the only UI examples which use negative coordinates atm. z_index can also show changes but you have to set a weird scale factor to see them.


Question: is it possible to ignore a subdomain?

For example, because the subdomain is managed through a different tool (e.g. terraform) or account (to split user privileges).
If not, would you accept a patch to add support for that?

If the sub-domain is managed as a separate zone octoDNS won't touch it if not configured to manage it as well (which it wouldn't be if you're using terraform instead.)
You may need to manage the NS records for the sub-domain in the parent with octoDNS depending on the details of the setup so that queries for subdomain.foo.com. know where to look for the sub-zone's records.

That works for me, thanks @ross


Errors in full factorial sampling when using weights

Using the weights argument for the FullFactorial sampling class throws up a few issues (under Anaconda3-2020.02-Windows-x86_64, with smt-0.4.3-cp37-cp37m-win_amd64.whl from PyPI):
If used with an array as input for weights:
Traceback (most recent call last):
  File ".\rbf.py", line 31, in <module>
    ff = smt.sampling_methods.FullFactorial(xlimits=lims, weights=np.array([ff_nx, ff_ny]))
  File "C:\Anaconda3\lib\site-packages\smt\sampling_methods\sampling_method.py", line 38, in __init__
    self.options.update(kwargs)
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 115, in update
    self[name] = dict_[name]
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 71, in __setitem__
    self._assert_valid(name, value)
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 85, in _assert_valid
    assert value in values or isinstance(
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

I've patched my own version to fix this by changing the options declare statement in the class initialisation
        self.options.declare("weights", values=[None], types=[list, np.ndarray])

to
        self.options.declare("weights", values=None, types=[list, np.ndarray])

If used with a list as input for weights:
Traceback (most recent call last):
  File ".\rbf.py", line 32, in <module>
    ff = smt.sampling_methods.FullFactorial(xlimits=lims, weights=[ff_nx, ff_ny])
  File "C:\Anaconda3\lib\site-packages\smt\sampling_methods\sampling_method.py", line 38, in __init__
    self.options.update(kwargs)
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 115, in update
    self[name] = dict_[name]
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 71, in __setitem__
    self._assert_valid(name, value)
  File "C:\Anaconda3\lib\site-packages\smt\utils\options_dictionary.py", line 86, in _assert_valid
    value, types
TypeError: isinstance() arg 2 must be a type or tuple of types

Again, I've patched my own version by changing the options declare statement in the class initialisation
        self.options.declare("weights", values=[None], types=[list, np.ndarray])

to
        self.options.declare("weights", values=None, types=(list, np.ndarray))

Finally, fix another couple of errors (numpy module name, and a type error with /= operator) with the weight normalisation in _compute (line 41), by changing
            weights /= numpy.sum(weights)

to
            weights = weights / np.sum(weights)

I can try to commit a fixed version of the code if it's easier.

Thanks! It seems you find a nest of bugs! Definitely a lack of testing. A PR will be welcomed for sure.


[BUG] unable to edit config on ish

Describe the bug:
Unable to edit the configuration file using ish on iOS.
FileNotFoundError: No such file or directory /root/Library/mov-cli
Expected behavior:
Config file should be editable
Screenshots
If applicable, add screenshots to help explain your problem.
Error:

Show full terminal output.
Make sure to run mov-cli with --debug flag for full output.

{terminal_output}

Platform (please complete the following information):

OS: [e.g. Windows]
Version: [e.g. 0.5.8]

Additional context / possible cause or solution:
Add any other context about the problem here or possible causes and solutions.
Version
If you don't use the latest Version and create a Bug-Report, it will be closed and left unanswered.

We know that there some issues with mov-cli and iOS.

I think that "Library" directory has to be created, I patched a very similar bug with Andriod today. #248
Here was my fix, I think the same should be duplicated for iOS: https://github.com/mov-cli/mov-cli/commit/27704d7e59eb76e5e24cb4f40af30c16e4075401

This issue is now fixed with the newest version.
See: https://github.com/mov-cli/mov-cli/commit/519b6b4b0dc0ee610a4923cf382ffd1204ae95fa


Create UI Mockup Designs

As a designer, I want to be able to create mockup UI designs of the several pages within our project so that the front-end team can start developing the designs using React.
Acceptance Criteria:

Create overall mockup designs for the web app
Designs to include and cover all development pages
Colour schemes indicated (both light and dark mode)
Development tools link with Materials UI library (for react development)
Google Sign in capabilities indicated
All features included

https://www.figma.com/file/r5qJlpk8p9iZE8VWJplKv8/Prototype-701?node-id=6%3A270


Updating code with type optional

Proposed change
This PR refactors the type annotations in the Home Assistant core codebase, specifically by improving the type safety of variables that were previously incorrectly assigned None with non-nullable types. The primary focus was replacing str type hints with Optional[str] where the assignment involved None. This improves the overall type correctness, readability, and maintainability of the codebase, while also removing the need for # type: ignore comments.
Specific Changes Made:
Updated type hint for flow_id from str to Optional[str], allowing it to accept None values.
Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New integration (thank you!)
[ ] New feature (which adds functionality to an existing integration)
[ ] Deprecation (breaking change to happen in the future)
[ ] Breaking change (fix/feature causing existing functionality to break)
[x] Code quality improvements to existing code or addition of tests

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to documentation pull request:

Checklist

[x] The code change is tested and works locally.
[x] Local tests pass. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist
[x] I have followed the perfect PR recommendations
[x] The code has been formatted using Ruff (ruff format homeassistant tests)
[ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[ ] The manifest file has all fields filled out correctly.
Updated and included derived files by running: python3 -m script.hassfest.
[ ] New or updated dependencies have been added to requirements_all.txt.
Updated by running python3 -m script.gen_requirements_all.
[ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

[ ] I have reviewed two other open pull requests in this repository.

This PR is too complicated. It contains two different aims. Split them d distribute them into distinct PRs.


Update README.md

fixed docs for Splitting panes :)

From tmux manpage for split-window command:

Create a new pane by splitting target-pane: -h does a horizontal split and -v a vertical split

prefix | uses -h flag so I guess that means it's a horizontal split?
Either way, I think terms "horizontal" and "vertical" are confusing. How about we use "left" and "right" like DEFAULT KEY BINDINGS manpage section?

"	       Split the current pane into two, top and bottom.
%	       Split the current pane into two, left and right.

Feel free to update the PR if you think that's the right approach.


[release-1.8] Add canonical service tags to all trace spans

This is an automated cherry-pick of #28801

We are freezing 1.8 branch in prep for tomorrow's 1.8.0 release. Will approve once that is out.

I’m not convinced about cherry picking to release-1.8 so close to release time.

I’m not convinced about cherry picking to release-1.8 so close to release time or by default turning it on in a patch release.

I think it is fine if this goes in 1.8.1, if that is OK.
If we feel that putting this in a point release is not appropriate, then I guess that's OK too. I requested the cherry-picks to have that discussion.

@douglas-reid Actually, this change indeed looks a bit too much for patch release, since it marks as a new feature and controlled by an env var turned on by default. Can we wait for 1.9?


[DISCUSS] Handling duplicate calls to provision API

Is your feature request related to a problem?
If a user calls the provision API twice using the same workflow, its provisioned resources are duplicated.  This can be confusing as the combination of workflow step name and workflow step ID is no longer unique, and choosing the correct resource ID requires guesswork.   Also the state changes to COMPLETED when the first workflow finishes, even though more resources are being added.
Additionally this results in the additional copy (or copies) consuming cluster resources.
What solution would you like?
Prevent a workflow from being provisioned if its status is PROVISIONING.   This status may need to be checked multiple times (like double-checked-locking) to prevent the race condition where two provision calls both see NOT_STARTED before one of them begins provisioning.
While addressing this, we also should discuss how to handle FAILED.  We could prevent provisioning and require users to use the deprovision API first (basically only allow provisioning from the NOT_STARTED state) or we could try to "pick up from where we left off", adding logic to skip provisioining steps if the resource already exists (complex and brittle).
What alternatives have you considered?
Leaving the API as is, and/or encouraging use of the create API with the provisioning parameter, which does not have this shortcoming.
Do you have any additional context?
We should probably handle this similarly to trying to create the same Anomaly Detector twice.

Guard rails are a good idea, I think we should block another provision call if the status is PROVISIONING, COMPLETED, or FAILED and only allow provisioning from a NOT_STARTED state. This is somewhat similar behavior implemented for the update API in https://github.com/opensearch-project/flow-framework/pull/416

The solution looks good to check for the status for the previous provision. Trying to understand more here

This status may need to be checked multiple times

Do we have to build a functionality like what we have for retry currently to keep checking for the status or a cron job of our own?

While addressing this, we also should discuss how to handle FAILED

If the status of the previous provision is FAILED. We can perform either options:

Let the user know the previous provision was failed for the workflowId, run the deprovision API manually. This would eventually delete the workflowID if deprovisioning is successful. There can be a case where deprovisioning itself failed, then this might result in a deadlock condition.

We can perform deprovisioning on our end, but again we might face the above issue. User has to perform a manual deprovisioning in such cases based on our log message Failed to deprovision some resources.

I am inclined towards option 1.

Trying to understand more here. Do we have to build a functionality like what we have for retry currently to keep checking for the status or a cron job of our own?

No, it's not about retries it's merely to catch a race condition.

Thread A checks status as not started, moves on to next step.
Thread B  checks status as not started, moves on to next step.
Thread A changes status to provisioning.
Thread B continues and results in a duplicate.

But relying on the status won't work as once you change it to provisioning... so we really need some other way to "lock" a thread for provisioning.


instance variable was not initialized in all of the 'initialize' methods, rendering it nilable

https://play.crystal-lang.org/#/r/1le9
this is seems related to finished macro

Please copy-paste the failing example in the issue:
class A1
  macro finished
    @x : String
    def initialize(@x)
    end
  end
end

class A2
  macro finished
    @y : Int32
    def initialize(@y)
    end
  end
end

p A1.new ""
p A2.new 10

@kostya What was your use case here, do you remember?

no

now i remember why this needed, for auto_constructor and auto_json shards, which generate instance variables from array. I not use this shards anymore, because many problems with them.


Add virt-what check for system on google cloud.

@linl-rh If it is a gcp metal system, should we check the output equal 'google_cloud'? Thanks

Discussed offline, don't consider a gcp metal system currently.


WIP: Feature/python bindings

Python bindings to interact with the Yosys C++ API Yosys from within Python. This feature enables to call Yosys data structures and functions from a Python script, and to call passes written in Python from the Yosys shell.

Overall this is very cool, and I like the approach it has taken! Just a few small comments left.
Could you update the installed packages in .travis.yml so this builds on CI, and also add the new dependencies to the README?

Thanks for the reminder @cliffordwolf !
Generally very happy with this now. My last remaining issue is that as far as I can tell, this is enabled by default for all Yosys targets. It would be good to confirm that it works for all of them (e.g. mxe, msys2, Emscripten, Visual Studio) and if not, either fix it or disable it by default if it isn't practicable to get it to work (I suspect this may be the case for Emscripten at least).

I've now merged it, but also set ENABLE_PYOSYS=0 as default value.

I'd like to keep the root dir as clean as possible. Would it be possible to move __init__.py and py_wrap_generator.py to misc/, maybe make __init__.py a make target and only place it in the top-level dir if we are actually performing a build with python enabled?

I'd like to keep the root dir as clean as possible. Would it be possible to move __init__.py and py_wrap_generator.py to misc/, maybe make __init__.py a make target and only place it in the top-level dir if we are actually performing a build with python enabled?

This is a simple fix. No need for a build-target for init.py, as it is not needed when importing the .so file from the yosys directory, just when it is installed, so copying it on install (from the misc dir) is enough.
I am not a github pro, is there any way to update this pull-request with a new commit?

My last remaining issue is that as far as I can tell, this is enabled by default for all Yosys targets. It would be good to confirm that it works for all of them

I need to setup a lot of virtual machines to test this out, unfortunately this will take some time.

I am not a github pro, is there any way to update this pull-request with a new commit?

No, but you can just push to your existing branch and create another PR. But usually one would create a new feature branch, forked from current master, and create a new PR. (This sounds like a hassle but it's really just a few seconds once you are used to git.)

I need to setup a lot of virtual machines to test this out, unfortunately this will take some time.

I did turn it off by default for now. So no need to get wild with testing on all platforms yet.

But usually one would create a new feature branch, forked from current master, and create a new PR.

I stuck to the same feature-branch for now since I already pushed to it before you commented, but will keep your suggestion in mind for next time. Thanks!


make: Add -O2 flag to CFLAGS

This is necessary to fortify source.
Fixes #110
Signed-off-by: Archana Shinde<EMAIL_ADDRESS>

LGTM

LGTM


How to disable past dates in pick me up datepicker

I've checked with documentation not having any information about disable past dates. May I know how to disable past dates based on current date.

If you need to disable all dates before some time, use min option.
If you need custom dates disabling - use render option and return {disabled: true} for those dates that you wish to be disabled.


feat: remove deprecated args and cmd for v1.0.0

Signed-off-by: yxxhero<EMAIL_ADDRESS>remove deprecated args and cmd
TODO:

[ ] update documents

@yxxhero As discussed in Slack, can we move this behind a feature flag = envvar that is named like HELMFILE_V1_MODE so that we don't need to maintain two branches (0.x and 1.x) for undefined period, and testing differences between v1 and v0.x is easier as we can selectively turn on v1 mode in the same test that runs v0.x test, etc?

Instead of the envvar, we might alternatively use a build tag (maybe specify the v1 build tag only when you want to enable v1 behavior?). Which method would you prefer?

@mumoshu It's up to you. I follow you. Thanks very much.

@yxxhero Can we safely close this as we've already merged https://github.com/helmfile/helmfile/pull/598?

@mumoshu we need to remove more code for deprecated args and cmd. WDYT?

@yxxhero I believe so! It's not now though., right? To repeat code deletions done in this PR, we need to fully remove the deprecated features. But we can't do that until we finally stop maintaining helmfile v0.x.

@mumoshu I think so. so this PR can't be merged until v1.0. but we can do this PR before v1.0.

@yxxhero I agree with you! But keeping this up-to-date with the main branch and fixing merge conflicts so often might be tiresome, right?
Can we perhaps do better, by turning this into a pull request that adds a code comment saying // TODO: Remove this function once Helmfile v0.x reaches EOL to every function you removed in this PR, instead of removing the function code itself?
That way, we can merge this ASAP, leaving no toil to keep this up-to-date, and it's still super easy to remove all the related code once Helmfile v0.x is EOLed, because we can just search for everything commented with the TODO thing for removal.
WDYT?

@mumoshu yeah. good idea. I will do that.

see: https://github.com/helmfile/helmfile/pull/628


Liveness compatibility: Make statusport conditional

Make status port and applicationsPort conditional on opting into liveness check.
Without this change, a pinned proxy image with an older version of proxy fails to start with Error: unknown flag: --statusPort
If a user starts using the new liveness check feature, then they can also set status.sidecar.istio.io/port: "0" to opt out.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: nmittler
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mandarjog
If they are not already assigned, you can assign the PR to them by writing /assign @mandarjog in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mandarjog  is this needed in master? If so, could you create a cherrypick PR?


chore: Remove unused yarn releases

https://www.electron.build/index.html#installation:~:text=Yarn is strongly recommended instead of npm.


Change default asyncio mode to fix error on fixtures

Issue
Today pytest-asyncio was updated and changed the default asyncio mode to strict. This breaks some fixtures that we have in our charms, specially the ones used in the new relations tests.
Release notes about the update.
Solution

Change the default asyncio mode to auto (the recommended if we do not use multiple async frameworks).

Release Notes

Change default asyncio mode to auto.

Just as a heads up, one could do the same on pyproject.toml, which is helpful when having multiple tests.
[tool.pytest.ini_options]
minversion = "6.0"
log_cli_level = "INFO"
asyncio_mode = "auto"

Great! Thanks for sharing, @paulomach!


Undo / Redo

I instantiate a squire editor (not in an iframe) and reuse it whenever an element needs to be edited.
Is there a way to clear the undo stack ?
Or is the workaround that I need to instantiate a new editor every time ?

ok, I should've inspected the code before posting this issue. apologies. I think I just need to do this each time I reuse my editor:
this._undoIndex = -1;
this._undoStack = [];
this._undoStackLength = 0;
this._isInUndoState = false;


Revert "Add preinstall message to Rush projects"

This reverts commit 98c4b34884a44d3f8f8b07c86feb783b1d64676f.
Closes #2779

 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: lenkan sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

This fix has been merged into master, we will have an updated release shortly. Thanks for your contribution :)


Fix various Golint and Go-vet issues

See individual commits for details

ping @johandorland PTAL 🤗

These kind of PRs are the best 👍 It's too bad the remaining linting issues are all on publicly exported interfaces that can't be changed, but ~80 errors is better than ~280.

I was doubting if I would add well-formed variants, alias the old ones, and mark them deprecated, but thought that was better left for a separate change.
And you're more than welcome! I was updating dependencies, spotted some of these linking errors, and it was an ok time to spend a rainy Saturday 🤗

Two more linting issue that could be fixed is the comment on Result.AddError as it doesn't follow the right format and the returned type of NewRawLoader causes a linting error. There are also what looks like two copy/paste errors, but apart from that it looks splendid.

Thanks for reviewing; I think I addressed all of them now 👍

I was doubting if I would add well-formed variants, alias the old ones, and mark them deprecated, but thought that was better left for a separate change.

I doubt all the all caps constant variables were ever consciously intended to be public in the first place and I really don't see any good reason why someone would have a need for them. Maybe I'll just rename them to something private and linting-compliant and tag a v2.0.0 sometime.
Anyway, thanks 👍


Start of Reply/Boost Back functionality

I took a quick stab to adding the reply/boost back functionality. It's all front-end code right now and implements a basic interface, but doesn't implement boosting yet.
The reply_address fields are currently parsed in javascript from the TLVs returned by the backend.
Here's what the Reply button looks like:

Here's what the Boost interface looks like:

There are a bunch of items I still need to add to this

[x] Add backend endpoints to have Helipad send boosts through the local LND node
[ ] Add an option to boost from the browser/Alby
[ ] Track node boosts with a new sent_boosts table
[ ] Add reply_address fields to the existing boosts table? (I could leave as-is and keep parsing with javascript or parse with rust)
[ ] Add lightning address resolver to frontend or backend
[ ] Add node alias resolver so that the Recipient field shows the node name rather than a hash

One thing I worry about with node-based boosting is that the interface isn't currently password protected. Anyone who has access to the Helipad URL of your node could have a lot of fun boosting random people.

This is a great start.  I'll jump in and help out as soon as I get back to Helipad.

This seems to work correctly for my kind beta tester: Adam Curry. I'll go ahead and merge it.


PackCreator tool proposal to assist pack creation

Describe The Problem To Be Solved
How to help people not fully familiar with Open-CMSIS-Pack specification and usage to create pack ?
Suggest A Solution
ST demonstrated in Open-CMSIS weekly its new version of its "PackCreator" tool implemented as a VScode extension. ST is considering to contribute to Open-CMSIS with this tool after execution of ST internal export control check and FOSS-OUT processes.
The demo took place during Open-CMSIS weekly call so the recording is available with the minutes here: https://linaro.atlassian.net/wiki/download/attachments/29070917693/GMT20231121-145728_Recording_2560x1600.mp4?api=v2
-> Please log in this issue your comment on this proposal.

@iomint do you still plan to release the PackCreator tool?


Refactor type erasure & add inner accessors to CentralDifference adaptor

I recently started building a dynamic geometry generator using the library. I wanted to use the CentralDifference adaptor but needed to access the parameters of the inner sampling function at the same time. This fixes the issue and avoids a fat-pointer vtable dynamic binding.

I'm reconsidering the naming of the source() function. I think it should be something like inner() instead, since the outer type is a source as well.

Hey, sorry, I somehow missed the notification for this pull request. The changes look great to me.
I'm in favour of changing the name of the accessor to innner()

Hey, thanks for the reply! I'll figure out the final changes during the next week and update the request.

Half of this is in now (the type erasure).


Creating entry for R.H. Sapat College of Engg., Management Studies and Research

Courses offered : https://ges-coengg.org/about-college-courses-offered/
Affiliated/Recognized by Savitribai Phule Pune University : http://bcud.unipune.ac.in/utilities/college_search/CEGN018790_ENG/Pune_University_College

@KunalGautam Pull request merged. Thank you!


sleep_ms in debug mode hangs Pico W indefinetely

I am running Windows, and installed all tool chain through MSYS2 (cmake, ninja, arm-none-eabi-toolchain, openocd). I did not compile anything, since openocd 12.0 stated that it had support for the Pico W.
#include <stdio.h>
#include "pico/stdlib.h"

int main()
{
    stdio_init_all();
    while (true)
    {
        printf("Hello, world!\n");
        sleep_ms(1000);
    }
}

I can flash the Pico W with above code using openocd, and it works as expected. However, when I use Cortex-Debug in VS Code, it seems the Pico W stops at sleep_ms(1000) and only sends one "Hello World" and none after that. If I remove the line with sleep_ms(1000) then I get a flood of messages as expected.
Here is my launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceFolder}",
            "executable": "${command:cmake.launchTargetPath}",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "servertype": "openocd",
            "gdbPath": "gdb-multiarch",
            "device": "RP2040",
            "configFiles": [
                "interface/cmsis-dap.cfg",
                "target/rp2040.cfg"
            ],
            "openOCDLaunchCommands": [
                "adapter speed 5000"
            ],
            "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/rp2040.svd",
            "postRestartCommands": [
                "break main",
                "continue"
            ],
        }
    ]
}

Debugging causes the Pico W to hang at sleep_ms and I don't know why.

Finally I fixed issue. It is problem with OpenOCD 12.0 as explained by a SysProg employee here https://forums.raspberrypi.com/viewtopic.php?p=2070447&hilit=debugging+timer#p2070447 even though RP2040 support is added the timer peripherals are not ran. This led me to discover my issue is duplicate raspberrypi/picoprobe#47