illegal_argument_exception when importing multiselect attribute

I have a Magento 2 store connected to the vue-storefront-api.
I created two products and created a multiselect attribute for testing purposes.
On one product I selected one option for the attribute and on the other one I selected multiple options.
Then I get this error when running yarn mage2vs import:
"statusCode":400,"response":"{\"error\":{\"root_cause\":[{\"type\":\"remote_transport_exception\",\"reason\":\"[hja_gcm][<IP_ADDRESS>:9300][indices:data/write/update[s]]\"}],\"type\":\"illegal_argument_exception\",\"reason\":\"mapper [color] of different type, current_type [long], merged_type [text]\"},\"status\":400}"},
at /var/www/node_modules/mage2vuestorefront/src/adapters/nosql/elasticsearch.js:80:15,
at respond (/var/www/node_modules/elasticsearch/src/lib/transport.js:327:9),
at checkRespForFailure (/var/www/node_modules/elasticsearch/src/lib/transport.js:267:7),
at HttpConnector.<anonymous> (/var/www/node_modules/elasticsearch/src/lib/connectors/http.js:165:7),
at IncomingMessage.wrapper (/var/www/node_modules/lodash/lodash.js:4935:19),
at IncomingMessage.emit (events.js:194:15),
at endReadableNT (_stream_readable.js:1125:12),
at process._tickCallback (internal/process/next_tick.js:63:19)]

When selection only one attribute option on both products or selecting multiple options on both, the error is not appearing.
Any hints would be appreciated! 👍

The current mapping expects the color to be configurable attribute. so product would be :
            "color": 20,

in your case it seems colors are simple text fields. In that case, adjusting
https://github.com/DivanteLtd/vue-storefront-api/blob/master/config/elastic.schema.product.json#L12
should work.
Have in mind, this is not what filters expect and the color filter in vue can not work

That makes sense, we will refactor our color attribute probably then.
Issue unfortunately occurs also when I use another attribute, for example I tried "material_filter". There I get current_type [text], merged_type [long] but maybe that's caused by the order the products are imported.
Do I have to add this attribute to the elastic.schema.product.json? If yes, what type does it need?
Thanks!

no, mapping is to define what you want to enforce. We have multiple custom attributes whch ES doesn't complain about.
the thing is: once you add data type of text ES assumes the next ones are also text and creates mapping based on this. Just make sure all products return same datatype and ES will be OK without modifying the mapping file.

ok, then I don't know why ES thinks I have different types. I just created a completely new M2 instance and added a multiselect attribute there:

This is what the M2 database contains:

Does having multiselect attributes work for you?

:thinking: good question. What I normally do for multi select  is I return them as a JSON string SET e.g:
[13,14,15]

So mabye all multiselect attribute values should be treated as text, also when only one option was selected. E.g. [13] ?!

@haelbichalex please check how “color_options” are defined. I belive that you should always warp the single values with just an array “[value]” to be 1000% on the safe side. Please make sure you ran “yarn db rebuild” in order to apply the shenanigans changes

@pkarw I don't think this has anything to do with color as it appears on a different attribute as well.
Also I tried to always just return an array here and debugged this item which shows me:
material_filter: [ '13' ],

Also running yarn db rebuild is included in running yarn mage2vs import, which I use for the initial import.
Still I'm getting the same error:
{ Error: Bad Request
    at respond (/var/www/node_modules/elasticsearch/src/lib/transport.js:308:15)
    at checkRespForFailure (/var/www/node_modules/elasticsearch/src/lib/transport.js:267:7)
    at HttpConnector.<anonymous> (/var/www/node_modules/elasticsearch/src/lib/connectors/http.js:165:7)
    at IncomingMessage.wrapper (/var/www/node_modules/lodash/lodash.js:4935:19)
    at IncomingMessage.emit (events.js:194:15)
    at endReadableNT (_stream_readable.js:1125:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
  status: 400,
  displayName: 'BadRequest',
  message: 'Bad Request',
  path: '/_reindex',
  query: {},
  body:
   { took: 246,
     timed_out: false,
     total: 88,
     updated: 0,
     created: 87,
     deleted: 0,
     batches: 1,
     version_conflicts: 0,
     noops: 0,
     retries: { bulk: 0, search: 0 },
     throttled_millis: 0,
     requests_per_second: -1,
     throttled_until_millis: 0,
     failures: [ [Object] ] },
  statusCode: 400,
  response:
   '{"took":246,"timed_out":false,"total":88,"updated":0,"created":87,"deleted":0,"batches":1,"version_conflicts":0,"noops":0,"retries":{"bulk":0,"search":0},"throttled_millis":0,"requests_per_second":-1.0,"throttled_until_millis":0,"failures":[{"index":"vue_storefront_catalog_guf_1558680746","type":"product","id":"2","cause":{"type":"illegal_argument_exception","reason":"mapper [material_filter] of different type, current_type [long], merged_type [text]"},"status":400}]}',
  toString: [Function],
  toJSON: [Function] }

{ Error: Bad Request
    at respond (/var/www/node_modules/elasticsearch/src/lib/transport.js:308:15)
    at checkRespForFailure (/var/www/node_modules/elasticsearch/src/lib/transport.js:267:7)
    at HttpConnector.<anonymous> (/var/www/node_modules/elasticsearch/src/lib/connectors/http.js:165:7)
    at IncomingMessage.wrapper (/var/www/node_modules/lodash/lodash.js:4935:19)
    at IncomingMessage.emit (events.js:194:15)
    at endReadableNT (_stream_readable.js:1125:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)
  status: 400,
  displayName: 'BadRequest',
  message: 'Bad Request',
  path: '/_reindex',
  query: {},
  body:
   { took: 246,
     timed_out: false,
     total: 88,
     updated: 0,
     created: 87,
     deleted: 0,
     batches: 1,
     version_conflicts: 0,
     noops: 0,
     retries: { bulk: 0, search: 0 },
     throttled_millis: 0,
     requests_per_second: -1,
     throttled_until_millis: 0,
     failures: [ [Object] ] },
  statusCode: 400,
  response:
   '{"took":246,"timed_out":false,"total":88,"updated":0,"created":87,"deleted":0,"batches":1,"version_conflicts":0,"noops":0,"retries":{"bulk":0,"search":0},"throttled_millis":0,"requests_per_second":-1.0,"throttled_until_millis":0,"failures":[{"index":"vue_storefront_catalog_guf_1558680746","type":"product","id":"2","cause":{"type":"illegal_argument_exception","reason":"mapper [material_filter] of different type, current_type [long], merged_type [text]"},"status":400}]}',
  toString: [Function],
  toJSON: [Function] }

it's working for now by also parsing the value to an integer in product.js:
else if (customAttribute.attribute_code === 'material_filter') {
    attrValue = [parseInt(customAttribute.value)]
}

This is a workaround though which should probably be handled somewhere and somehow else... I'm just not that into VS yet to do it myself, maybe someone can provide me a starting point 👍


Stack overflow with LEAD and LAG functions

Describe the bug
The following query causes stack overflow in rust
SELECT seq
  FROM (
    SELECT seq,
      LEAD(seq) OVER (ORDER BY seq) AS next_seq
      FROM parquet_table
  ) AS subquery
  WHERE next_seq - seq > 1

thread 'main' has overflowed its stack
error: process didn't exit successfully: `target\debug\seq.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)

To Reproduce
use datafusion::prelude::SessionContext;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
  let ctx = datafusion::prelude::SessionContext::new();
  ctx
    .register_parquet(
      "parquet_table",
      "batches.parquet",
      datafusion::prelude::ParquetReadOptions::default(),
    )
    .await?;

  let sql_query = "
  SELECT seq
  FROM (
    SELECT seq,
      LEAD(seq) OVER (ORDER BY seq) AS next_seq
      FROM parquet_table
  ) AS subquery
  WHERE next_seq - seq > 1
  ";

  let df = ctx.sql(sql_query).await?;

  df.show().await?;
  Ok(())
}

Expected behavior
The query should detect gaps in the seq number.
Additional context
datafusion = { version = "41.0.0", features = ["parquet", "default"] }
arrow = "53.0.0"

Version 42.0.0 exhibit the same issue.

take

I can reproduce it on Windows, it overflow on this loop.
I would try to write a unit test in sqlparser to cause it overflow, then I will file an issue on sqlparser-rs if needed.

I found stack overflow not happening if stack size is set to 16MiB(default is 1 MiB on Windows), so you can reproduce this issue on linux by making stack size smaller.
I don't think this is an bug, but if could be better if we document it somewhere(document stack size is very small by default on windows).
Also of note, optimized build significantly reduce memory usage, 1 MiB may be enough.

Any stack overflow is a security risk https://book.hacktricks.xyz/binary-exploitation/stack-overflow

Sorry for missing additional context, I think such stack overflow won't happen if one of those requirement is meet:

build with optimization(try running with cargo run --release)
Stack size is adjusted(1MB is unreasonably small for modern application)

And on datafusion side, I don't think there is a reasonable way reduce stack size except using iteration instead of recursive on sqlparser.
I will try rewriting parser with iteration instead of recursive.

Is it possible to detect this condition programmatically and raise an exception? Controlled exception is always better then running over to someone else region of memory.

I think such stack overflow won't happen if one of those requirement is meet

Imagine an application which implements an application to analyze structured log events. Where log events are stored in parquet files. The application is a web server which accepts adhoc SQL queries and runs them to extract useful patterns from log events. In such scenario the malicious user can craft complex SQL query to cause stack overflow and mount remote code execution attack.
In this scenario no matter how bit the stack size is. It will always be possible to craft more complex query to cause the problem.

I think such stack overflow won't happen if one of those requirement is meet

Imagine a service which implements an application to analyze structured log events. Where log events are stored in parquet files. The application is a web server which accepts adhoc SQL queries and runs them to extract useful patterns from log events. In such scenario the malicious user can craft complex SQL query to cause stack overflow and mount remote code execution attack.
In this scenario no matter how big the stack size is. It will always be possible to craft more complex query to cause the problem.

I personally think that not something to be taken into consideration under optimized build, as query with thousand of token might needed, in that case, it should be bound checked(as physical memory might not be enough).
But totally I agree that stack overflow under unoptimized build is unacceptable(it hurt developer experience), so I will work on that.
For now, you can develop the application with more stack size, and release it with optimization, it should be safe if the input were bound checked for some reasonable large number.

I think rust consumes quite a bit more stack space for debug builds than release builds (there are several past tickets in this repo related to this)

In this scenario no matter how big the stack size is. It will always be possible to craft more complex query to cause the problem.

Indeed -- it would be great if someone could put a stack limit in to try and avoid overflows (make a real error) if the query is too deply nested

Here is one stacktrace.
partial_stacktrace.txt
I am trying to understand which stack frame take some stack memory by manually read rbp and rsp in lldb. It's quite inefficient, so I might need some help on this.
In addition, if I recall correctly, it take about 100 frames to parse it. (that's where stack overflow happen)

bt_windows.txt
Here is another one that actually stack overflow.

I think rust consumes quite a bit more stack space for debug builds than release builds (there are several past tickets in this repo related to this)

In this scenario no matter how big the stack size is. It will always be possible to craft more complex query to cause the problem.

Indeed -- it would be great if someone could put a stack limit in to try and avoid overflows (make a real error) if the query is too deply nested

I think it's better to open another issue. I would like this issue to focus on reducing stack usage.
We could use asm macro to get stack usage, and detect usage(return Error) at some point
fn get_stack_usage() -> usize {
    let rbp: usize;
    let rsp: usize;
    unsafe {
        asm!("mov {0}, rbp", out(reg) rbp);
        asm!("mov {0}, rsp", out(reg) rsp);
    }
    return rbp - rsp;
}

My original thought to reduce stack usage is to move more thing to heap, but I just found another possible solution using stacker.
I will try stacker next day, then submit a PR to see if it's appropriate.

My original thought to reduce stack usage is to move more thing to heap, but I just found another possible solution using stacker.

Interesting library

Another option is to make parser tail recursive and annotate the function using https://docs.rs/tailcall/latest/tailcall/

The sqlparser library already supports limiting recursion: https://docs.rs/sqlparser/latest/sqlparser/parser/struct.Parser.html#method.with_recursion_limit
Which is a pretty good protection against stack overflows
I think stacker is a somewhat low level solution and that we would have to ensure any use doesn't cause performance or safety issues

I think it's better to open another issue. I would like this issue to focus on reducing stack usage.

I agree

Given this is a stack overflow in sqlparser, perhaps we can move the ticket there and try to solve it in the sqlparser library?

https://github.com/apache/datafusion-sqlparser-rs/pulls

https://github.com/apache/datafusion-sqlparser-rs/issues/1465

Let's use https://github.com/apache/datafusion-sqlparser-rs/issues/1465 to track this issue

BTW, you can change stack size with Cargo.toml
# 64 bit MSVC
[target.x86_64-pc-windows-msvc]
rustflags = [
	"-C", "link-arg=/STACK:8000000"
]

# 64 bit Mingw
[target.x86_64-pc-windows-gnu]
rustflags = [
    "-C", "link-arg=-Wl,--stack,8000000"
]


href doesnt work

this button open new tab with url https://getoutline.org/ru/ruhttps://github.com/Jigsaw-Code/outline-sdk
v

Thanks for the report. As far as I can tell this has been fixed.


optimize attribute reading in models/read_models??

(from a tweet)
ActiveRecord protip: I went from 3800 ops/sec to 24000 ops/sec by switching from attributes[‘name’] to read_attribute(‘name’). (https://twitter.com/mperham/status/466009719727869952)
We should bench and see if there are any noticeable improvements with this.

@kellyredding - I'm closing this. I tried this out and didn't see any performance improvement. I think most of the improvement that he was seeing was because he was using attributes which built the entire hash of all attributes values and read_attribute returned a single value.
For models we are using the default reader which apparently is the same as using read_attribute unless you override the reader method on your record. For read models we are using the hash accessor [] which is only returning a single value and is also apparently the same as read_attribute and the default reader. I hacked in read_attribute anyway and ran the bench scripts and didn't see any noticeable change so I don't think there's any performance gains to be made here.

@jcredding cool.


Add sameAsOrigin in AllowedOrigins

make pr for #44 issue

@dannys42 I made changes

Looks like some errors with the tests.  I'm rerunning them to see if the problem goes away.

Looks good now. We can merge! Thanks @makleso6 !


daylight savings time

Submitter:
I suggest the following changes:
The requirement in https://github.com/ess-dive-community/essdive-csv-structure/blob/master/csv_detailed_guide.md#temporal-data
to "Do not report time using Daylight Savings Time." is actually problematic for Alaska work. This is standard "local time" and we have been using this for many years. To edit could cause many errors. Can this be OK as long as the UTC offset is properly reported?

@regnans I will have to send this over to @robcrystalornelas since we worked quite a bit with ESS-DIVE on this one. According to current instructions, there could be UTC in standard time column in addition to the UTC daylight savings column although possibly confusing.

Our current standard supports @regnans use case. We just need to change the instructions. The intent isn't to prevent standard local time which is actually daylight savings, it is to prevent people from switching midway in the time series to daylight savings. So as long as a UTC time zone is recorded, it is ok.

To clarify, data reported in local daylight savings time is limited to data sets collected only during the summer period. We would not use daylight savings time for sensors operating all year (hopefully we have some of that data coming, but since the cameras have been out since 2019 we don't know if they are still working!!!)

@robcrystalornelas can you confirm if the text reflects the change needed? And is this issue done?

Yes, text in both detailed and quick guides are updated to reflect changes we wanted to make.  We can close out this issue.


📝 docs: make changes in README.md and add jpzs444.md

Please leave a comment if you have any clarifications or problems with my commits. Thank you! 😀

Thank you for your pull request :)

Thank you for your pull request :)

Thank you for your pull request :)

Thank you, too, for accepting my request! Hoping to have more contributions in the future. :D

Thank you for your pull request :)

Thank you, too, for accepting my request! Hoping to have more contributions in the future. :D


how I can send header with alamofire image

let imageView = UIImageView(frame: frame)
let url = URL(string: "https://httpbin.org/image/png")!
let placeholderImage = UIImage(named: "placeholder")!

imageView.af_setImage(withURL: url, placeholderImage: placeholderImage)

how I can send header in URL
var urlRequest = URLRequest(url: URL(string: "url")!)
urlRequest.setValue("my header", forHTTPHeaderField: "User-Agent")

hi my friend i have the same problem and i solved it with this code
let headers = ["Authorization": "Bearer (token)"]
let imageURL = try! URLRequest(url: gsUtil.getCompleteURI()+"image/"+usrId+".jpg", method: .get, headers: headers)

Thanks @edgarplazola! As @edgarplazola mentioned @ahmedsafadii, you will need to construct a URLRequest in order to send custom headers along with your request.
var urlRequest = URLRequest(url: URL(string: "url")!)
urlRequest.setValue("my header", forHTTPHeaderField: "User-Agent")

imageView.af_setImage(urlRequest)

Best of luck! 🍻

Cannot convert value of type 'URLRequest' to expected argument type 'URL'
    var urlRequest = URLRequest(url: URL(string: "https://api.lolsummoners.headlezz.net/images/champions/splashs/Taric0.jpg")!)
    urlRequest.setValue("my header", forHTTPHeaderField: "User-Agent")
    championSplash.af_setImage(withURL: urlRequest, placeholderImage: UIImage(named: "noimage"))

@ahmedsafadii it's af_setImage(withURLRequest: ...

Hi @cnoon, I know this is closed, but I still want to say that the af_setImage(withURLRequest: ... method is tedious，as we have write it everywhere. Do we have any chance to add a custom method to replace the method below for extra header field such as authorization token。
private func urlRequest(with url: URL) -> URLRequest {
    var urlRequest = URLRequest(url: url)

    for mimeType in DataRequest.acceptableImageContentTypes {
        urlRequest.addValue(mimeType, forHTTPHeaderField: "Accept")
    }

    return urlRequest
}`


Documentation for enabling istio on existing cluster returns error

az aks mesh enable --name $env:CLUSTER --resource-group $env:RESOURCE_GROUP
returns

(BadRequest) Requested change in revisions is not allowed. Reason: Revision asm-1-17 is not supported by the service mesh add-on. Code: BadRequest Message: Requested change in revisions is not allowed. Reason: Revision asm-1-17 is not supported by the service mesh add-on.

needed to specifically set the revision with
az aks mesh enable --name $env:CLUSTER --resource-group $env:RESOURCE_GROUP --revision "asm-1-19"

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

ID: 31367f47-0d71-8b44-ca40-e2b1c7cf3d16
Version Independent ID: 627b0d0f-0d38-e529-2e52-30823cf0008f
Content: Deploy Istio-based service mesh add-on for Azure Kubernetes Service - Azure Kubernetes Service
Content Source: articles/aks/istio-deploy-addon.md
Service: azure-kubernetes-service
GitHub Login: @shashankbarsin
Microsoft Alias: shasb

@SompoMHeckmann
Thanks for your feedback! We will investigate and update as appropriate.

#reassign:schaffererin

Hi, @SompoMHeckmann! Thank you for your feedback.
I was able to successfully run az aks mesh enable --name $CLUSTER --resource-group $RESOURCE_GROUP on an existing cluster without receiving an error message. I then created another cluster and ran the az aks mesh enable --name $CLUSTER --resource-group $RESOURCE_GROUP --revision 'asm-1-19' command on it, which was also successful. As it stands, I don't see an issue with the documentation itself.
I feel like I might be missing a bit of context here, so I'd appreciate if you could provide a bit more clarity. From my understanding, your running of az aks mesh enable --name $CLUSTER --resource-group $RESOURCE_GROUP (without the revision parameter) returned a revision-related error message? Is that correct? Did you try to run az aks mesh enable --name $CLUSTER --resource-group $RESOURCE_GROUP --revision 'asm-1-19' afterward?
Thank you!

That is correct. I tried to install and received the error message. I had az preview installed a while back, but had it removed while attempting. Thinking that may be the cause I reinstalled it and installed successfully with az aks mesh enable --name $CLUSTER --resource-group $RESOURCE_GROUP and then uninstalled istio and AK preview. Tried to install istio again with the same error message. I then added the revision and successfully installed. Researching the error, I came across another user having the same issue on https://serverfault.com/questions/1155856/azure-istio-revision-asm-1-17-is-not-supported-by-the-service-mesh-add-on/1155942#1155942 .


Cannot start VNC container but logs show it's connected

We recently have a new kind of issue with VNC container which is flickering: most of the time it works properly, but from time to time we obtain a
17:48:40.372 [main] ERROR ?.i.1.0] - Could not start container
org.testcontainers.containers.ContainerLaunchException: Timed out waiting for log output
	at org.testcontainers.containers.VncRecordingContainer$1.waitUntilReady(VncRecordingContainer.java:91)

What's surprising is that according to the source, waitUntilReady is actually waiting for Connected:
https://github.com/testcontainers/testcontainers-java/blob/92f0a4f7ffb9d46023ec77e6588e74831ee8e29f/core/src/main/java/org/testcontainers/containers/VncRecordingContainer.java#L74
and according to the logs we got after the stacktrace, VNC was indeed connected:
17:48:40.507 [main] ERROR ?.i.1.0] - Log output from the failed container:
write_header: flv_version=1, audio=False, video=True

write_metadata: {'duration': 0, 'width': 0, 'framerate': 30, 'videocodecid': 3, 'height': 0}

start recording

Connected: tc-QawfLnpD:5900

Not sure what could be related to the issue? The fact that it happens only from time to time, makes me think that it could be a kind of race condition.
For info we are using latest release of testcontainers (1.12.3) and we are running it inside a customized jenkins docker container (docker inside docker).
Here's the full stacktrace and the beginning of the VNC logs (too long to put them all, and they don't provide any more info):
17:47:37.586 [main] INFO  o.x.t.d.i.j.XWikiDockerExtension - (*) Start VNC container...
17:47:37.595 [main] WARN  o.t.utility.RegistryAuthLocator - Failure when attempting to lookup auth config (dockerImageName: quay.io/testcontainers/vnc-recorder:1.1.0, configFile: /root/.docker/config.json. Falling back to docker-java default behaviour. Exception message: /root/.docker/config.json (No such file or directory)
17:47:37.596 [main] WARN  o.t.utility.RegistryAuthLocator - Failure when attempting to lookup auth config (dockerImageName: quay.io/testcontainers/vnc-recorder:1.1.0, configFile: /root/.docker/config.json. Falling back to docker-java default behaviour.  Right now it prevents some of our tests to execute since the container is considered as "not started" and it fails entirely the test suite.


[PR] [docs] Eliminate duplicated string literals

According to the DRY principle.

Please ignore this PR, the used syntax is invalid, just the Flow server was not running.

How is this DRY?  You're now writing out each action type at least 3 extra times.
The way it is in the docs currently, because the action types are string literal values, Flow can ensure they're being used correctly across the entire codebase.  Importing a string literal constant, with its value having the same name as its identifier, doesn't add anything..?

This is one of the big wins of Flow+Redux IMO, that it cuts down on the boilerplate of needing constants and imports.  The approach of importing constants is useful if you have no type system, but otherwise redundant.

If you want to change the value of an action type (e.g. from 'BAR' to 'BAZ'):

When using string literals everywhere, you have to change its occurrences (i.e. the type definition, the action creator code and every reducer which handles the action - at least 3 changes).
When using constants, you have to change the identifier, the type and the value of the constant (always 3 changes), which are anyways near each other in the code.

Of course, if you don't have an IDE with Rename refactoring, the latter approach means more work, so it depends. Should I move the constant-based alternative version to a separate place (e.g. StackOverflow Q & A) and only add a link to it here?

Fair enough, I suppose I can see situations where an IDE constant rename would be more convenient than doing a project-wide find and replace on the string literal (if the same string literal is used elsewhere too... not a problem I've ever run into after many Redux projects).  But IMO that small convenience wouldn't be worth the extra verbosity of needing imports, especially on a new project that's just following a tutorial to get started with Flow.
I don't have any official say over the Flow docs, so will leave that question to someone on the Flow team.  Just wanted to share my preference for continuing to advise string literals.


[FancyZones] App zone history on multiple desktops

Summary of the Pull Request

Add support to save zone history over multiple desktops for single app.
After virtual desktop is deleted, remove app zone history as well.

PR Checklist

[x] Applies to #2684 and #2678
[x] CLA signed. If not, go over here and sign the CLA

Validation Steps Performed
Multiple desktops app zone history:

Create more than one desktop and assign some layout to them.
Assign two instances of the same application to different desktops.
Close those instances.
Re-open them again.
Check C:\Users\<user>\AppData\Local\Microsoft\PowerToys\FancyZones files app-zone-history.json.

Expected result: Information about zone history of single application contains information for different desktops, after application is opened, it goes to the different zone based on which desktop it is.
App zone history data of deleted desktop:

Create more than one desktop and assign some layout to them.
Assign some applications into zones on all desktops.
Delete one of them.
Check C:\Users\<user>\AppData\Local\Microsoft\PowerToys\FancyZones files app-zone-history.json and zones-settings.json.

Expected result: No data belonging to deleted desktops is found.

@vldmr11080
if you have more commits to come, please change this to a draft PR to avoid being reviewed before it's ready.

@vldmr11080
if you have more commits to come, please change this to a draft PR to avoid being reviewed before it's ready.

No, last few of them were just minor changes in unit tests, and they are finished now. Core JSONHelpers implementation is finalized already.

Is it expected that in app-zone-history was erased all history for app that was removed from one of layouts?
Repro steps:

Apply layout
Create VD
Snap window to both layouts
Resize window on any layout

App will be removed from all layouts.

Is it expected that in app-zone-history was erased all history for app that was removed from one of layouts?
Repro steps:

Apply layout
Create VD
Snap window to both layouts
Remove window from any layout

App will be removed from all layouts.

Thanks for the catch! It is not intended for sure, I'm looking into it.

This fixes the virtual desktop issue, we still have to fix history for multi monitor.


[SQL][Minor] Fix decimal type in sql doc

Test build #25819 has started for   PR 4121 at commit 472f3cb.

This patch merges cleanly.

Test build #25819 has finished for   PR 4121 at commit 472f3cb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/25819/
Test PASSed.

@scwf Is it under the Scala tab? Actually, we will have a major overhaul of our SQL doc for 1.3 release at a later time. Maybe it is better to review our doc once we have updated it?

yes, it is under scala tab. ok, close this and update it when major overhaul of sql doc for 1.3 release


[devbox] Add version detection to the go planner

Summary
Add version detection to the go planner based on the contents of go.mod. When we don't have a corresponding package in nixpkgs we default to 1.19
How was it tested?
Compiled and ran against local project.

Awesome!
It's worth noting that if a user adds an additional go package(with a version that's different from the one in the go.mod file) to their devbox config, they will still run into a build error complaining about the conflict. IIRC, Nix has a way to set which package has priority so you can install multiple versions of a package so it may be worth adding a step to the build to handle that.
Not really sure how often someone will want multiple versions of a language in a devbox container but since it's a valid option it's probably worth having something in place to either handle it or warn the user when the scenario is detected.


npm WARN deprecated

Hi,
I receive a warning at the $ npm install --global yo stage of set up at http://yeoman.io/codelab/setup.html. Below is my screenshot of the problem.

I'm running OS X 10.11.6 El Capitan. Node 4.5.0 and NPM 2.15.9.
Thanks,
Austin.

http://stackoverflow.com/questions/33487085/yodoctor-command-not-found-when-installing-yo-from-terminal

Trying number 3. After entering export PATH=“/path/to/node_modules/.bin:$PATH" to command line, I get an angle bracket prompt. What do I do? http://notions.me/post/adding-npm-bin-to-path does not make it clear.

@AustinMH looks like you use an angled " instead of a normal ".

@SBoudrias Thanks! I fixed the brackets and got this:

How do I know if the global npm module folders is chown/chmod to me?

/path/to/x was an example value. You need to change it to match your own computer file layout.

So, when I enter "npm list -g" I get the location "/Users/austinmunsch-hayhurst/.node_modules_global/lib", So would I "export PATH=“/Users/austinmunsch-hayhurst/.node_modules_global/lib/.bin:$PATH"?

@AustinMH if you cd in that folder, you can check where the .bin folder is located

I'm getting "No such file or directory" even though "npm list -g" finds it at "/Users/austinmunsch-hayhurst/.node_modules_global/lib". Am I missing the right syntax in using cd here?

did you try npm prefix -g?

Here, I used "npm bin" to locate the bin folder. I used the path it gave in the "export PATH=“/path/to/node_modules/.bin:$PATH"" formula, but after checking .bash_profile, everything was still unchanged.


Fix security issues

This addresses CWS-611 and CWS-613, plus updates versions to fix github security alerts


Add Code of Conduct

We recommend that every repo has a code of conduct. If you don’t feel comfortable creating your own Code of Conduct from scratch we highly recommend using one of the templates provided by GitHub. If you do use a template, please read through the template and ensure that you can and will abide by the Code of Conduct.
Please follow these instructions on how to add a Code of Conduct.

I read and added the code of conduct as CODE_OF_CONDUCT.md


Investigate explosion of disk usage of prometheus

You can see that disk usage exploded around June 28. https://github.com/2i2c-org/infrastructure/pull/2730 coincides with that - a prometheus version bump

No corresponding explosion in time series

Using prometheus_tsdb_head_series

Second inflection point was around when https://github.com/2i2c-org/infrastructure/pull/2621  was merged

Looks like this is actually the case for a lot of our prometheii

https://github.com/2i2c-org/infrastructure/pull/2932 bumps up everything to a miniumum of 200Gi.

I made a simple prometheus dashboard showing remaining disk space in all our prometheuses: https://grafana.pilot.2i2c.cloud/d/d560fa89-38bc-4253-964e-82573ea91d57/global-prometheus-health?orgId=1&var-cluster=All

ok, most prometheuses have more disk space now! But this isn't a long term solution yet.

These relevant changes were made June 27-29.

https://github.com/2i2c-org/infrastructure/pull/2706
https://github.com/2i2c-org/infrastructure/pull/2730
https://github.com/2i2c-org/infrastructure/pull/2731

I wonder if it was prometheus version bump or config change.

https://github.com/2i2c-org/infrastructure/pull/2730 is also relevant as it added long running time serires metrics at I think 5 per user on each hub.

https://last9.io/blog/how-to-manage-high-cardinality-metrics-in-prometheus/ has useful info on how to debug prometheus series counters. However, trying to use grafana for this was causing a lot of timeouts, so we need to get https://github.com/2i2c-org/infrastructure/issues/2934 fixed first.

Ok, now by directly accessing the prometheus server, I can look at series that have exploding cardinality! Am looking at the openscapes hub.
topk(10, count by (__name__) ({__name__=~".+"})) shows:

metric
count

apiserver_request_duration_seconds_bucket{}
11792

apiserver_request_slo_duration_seconds_bucket{}
8712

etcd_request_duration_seconds_bucket{}
5028

apiserver_response_sizes_bucket{}
2544

apiserver_storage_list_duration_seconds_bucket{}
1596

jupyterhub_request_duration_seconds_bucket{}
1365

apiserver_watch_events_sizes_bucket{}
1170

storage_operation_duration_seconds_bucket{}
952

container_tasks_state{}
935

kubelet_runtime_operations_duration_seconds_bucket{}
840

Looks like https://github.com/kubernetes/kubernetes/issues/110742 is part of the issue here.

http://localhost:9090/tsdb-status also produces very helpful information.

I wanted to understand what was using the most disk space. Unfortunately there's no easy mapping from series name to disk space.
I currently have two hypothesis:

apiserver_request_duration_seconds_bucket is the source of the problem, because https://github.com/kubernetes/kubernetes/issues/105346 and the fact it has so many metrics.
https://github.com/2i2c-org/infrastructure/pull/2621 is the source of our problem.

Am following https://faun.pub/how-to-drop-and-delete-metrics-in-prometheus-7f5e6911fb33 to gather some more information.
First, here's the output of promtool tsdb analyze /data/, showing what are the metrics with highest cardinality:
/prometheus $ promtool tsdb analyze /data/
Block ID: 01H78RMRJ355HMXCDN7B6V07WZ
Duration: 4m58.817s
Series: 79527
Label names: 297
Postings (unique label pairs): 5447
Postings entries (total label pairs): 1021265

Label pairs most involved in churning:
8951 job=kubernetes-apiservers
5103 component=apiserver
4808 instance=<IP_ADDRESS>:443
4608 version=v1
4142 instance=<IP_ADDRESS>:443
3048 topology_ebs_csi_aws_com_zone=us-west-2b
3048 k8s_io_cloud_provider_aws=4d6fc0cdc07fcc46278e3eae48a92044
3048 kubernetes_io_arch=amd64
3048 beta_kubernetes_io_arch=amd64
3048 failure_domain_beta_kubernetes_io_zone=us-west-2b
3048 kubernetes_io_os=linux
3048 failure_domain_beta_kubernetes_io_region=us-west-2
3048 topology_kubernetes_io_region=us-west-2
3048 alpha_eksctl_io_cluster_name=openscapeshub
3048 beta_kubernetes_io_os=linux
3048 node_lifecycle=on-demand
3048 topology_kubernetes_io_zone=us-west-2b
2930 job=kubernetes-service-endpoints
2874 app_kubernetes_io_managed_by=Helm
2848 node=ip-192-168-61-164.us-west-2.compute.internal

Label names most involved in churning:
15778 job
15778 __name__
15778 instance
8610 le
6152 component
5753 resource
5497 verb
5424 version
5286 namespace
5256 scope
3782 group
3553 node
3048 node_lifecycle
3048 alpha_eksctl_io_instance_id
3048 alpha_eksctl_io_cluster_name
3048 hub_jupyter_org_node_purpose
3048 kubernetes_io_os
3048 beta_kubernetes_io_arch
3048 topology_kubernetes_io_region
3048 topology_kubernetes_io_zone

Most common label pairs:
45479 job=kubernetes-apiservers
25927 component=apiserver
24429 instance=<IP_ADDRESS>:443
23412 version=v1
21050 instance=<IP_ADDRESS>:443
15414 kubernetes_io_arch=amd64
15414 failure_domain_beta_kubernetes_io_region=us-west-2
15414 kubernetes_io_os=linux
15414 beta_kubernetes_io_os=linux
15414 failure_domain_beta_kubernetes_io_zone=us-west-2b
15414 beta_kubernetes_io_arch=amd64
15414 topology_ebs_csi_aws_com_zone=us-west-2b
15414 alpha_eksctl_io_cluster_name=openscapeshub
15414 node_lifecycle=on-demand
15414 topology_kubernetes_io_zone=us-west-2b
15414 k8s_io_cloud_provider_aws=4d6fc0cdc07fcc46278e3eae48a92044
15414 topology_kubernetes_io_region=us-west-2
14720 job=kubernetes-service-endpoints
14435 app_kubernetes_io_managed_by=Helm
14423 node=ip-192-168-61-164.us-west-2.compute.internal

Label names with highest cumulative label value length:
43009 __name__
28847 id
22476 mountpoint
10136 name
6776 container_id
5211 directory
4210 type
4196 replicaset
3918 image_id
3718 resource
3561 secret
2700 uid
2098 image
1881 image_spec
1629 le
1506 pod
1489 handler
1352 owner_name
1337 device
1324 resource_prefix

Highest cardinality labels:
1207 __name__
546 directory
290 name
238 le
213 mountpoint
181 id
176 type
175 resource
145 replicaset
120 secret
88 container_id
81 device
76 method
75 uid
66 kind
65 cpu
64 resource_prefix
53 owner_name
52 address
52 pod

Highest cardinality metric names:
11792 apiserver_request_duration_seconds_bucket
8712 apiserver_request_slo_duration_seconds_bucket
5028 etcd_request_duration_seconds_bucket
2544 apiserver_response_sizes_bucket
1596 apiserver_storage_list_duration_seconds_bucket
1365 jupyterhub_request_duration_seconds_bucket
1170 apiserver_watch_events_sizes_bucket
952 storage_operation_duration_seconds_bucket
950 container_tasks_state
840 kubelet_runtime_operations_duration_seconds_bucket
760 container_memory_failures_total
714 apiserver_admission_controller_admission_duration_seconds_bucket
678 container_blkio_device_usage_total
672 apiserver_flowcontrol_priority_level_request_count_watermarks_bucket
580 apiserver_request_total
576 node_cpu_seconds_total
566 dirsize_latest_mtime
566 dirsize_last_updated_ns
566 dirsize_processing_time
566 dirsize_total_size_bytes

There's a lot of evidence for apiserver_request_duration_seconds_bucket being the problem here.
So, df -h shows me this to be disk usage:
/dev/nvme1n1            196.7G    105.3G     91.3G  54% /data

I'm now going to delete that metric, run a compaction and see.

I'm exec'd into the prometheus server container. There's no curl, so am running the following wget command. This is busybox's 'wget':
$ wget --post-data '' -S 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]=apiserver_request_duration_seconds_bucket'

This leads to pod restarts, usually with liveness probe failures (as seen from describe pod):
  Warning  Unhealthy  51s                 kubelet            Liveness probe failed: Get "http://<IP_ADDRESS>:9090/-/healthy": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I removed all the probes by editing the deployment and setting them to null to no effect, because it just goes out of RAM I think. Let me bump up memory limits as well.

Temporarily bumping memory limit to 16G (from 8G) to see how this goes. I primarily wanna see if deleting this time series brings down disk usage.

ok, that succeeded!
Connecting to localhost:9090 (<IP_ADDRESS>:9090)
  HTTP/1.1 204 No Content
  Date: Mon, 07 Aug 2023 20:33:40 GMT
  Connection: close

Now running compaction, with:
$ wget --post-data '' -S  http://localhost:9090/api/v1/admin/tsdb/clean_tombstones

btw, I have another terminal open exec'd into the same container, with top running to monitor memory & cpu usage.

The first clean tombstone api call failed with a wget timeout, and the df -h output was:
/dev/nvme1n1            196.7G    101.3G     95.3G  52% /data

So about a 4G drop. I'm running it again, let's see.

Interestingly, I don't see CPU usage go over 25%. iotop isn't present on the container image so I can't tell if it's bottlenecked on io, but wouldn't be surprised.

Based on http://tinycorelinux.net/12.x/armv6/releases/RPi/src/busybox/busybox-1.27.1-wget-make-default-timeout-configurable.patch, the default wget timeout is 900s, and that's where the timeout is coming from. Clearning tombstones is going to take more time than that, so am increasing it by passing -T 9000. It's still running.

ok, so clean-tombstones completed, and this is the size on disk now:
/dev/nvme1n1            196.7G     93.3G    103.3G  47% /data

That's about 8G data reduction. That's a far cry from the close to 60GB that have been used up since June, so I don't think this is the cause.
However, the output of promtool tsdb analyze is not very different:
/prometheus $ promtool tsdb analyze  /data/
Block ID: 01H7942W0GW468MZCC40T5GXNH
Duration: 4m59.828s
Series: 79930
Label names: 298
Postings (unique label pairs): 5486
Postings entries (total label pairs): 1029416

Label pairs most involved in churning:
9085 job=kubernetes-apiservers
5184 component=apiserver
4874 instance=<IP_ADDRESS>:443
4682 version=v1
4210 instance=<IP_ADDRESS>:443
3073 topology_ebs_csi_aws_com_zone=us-west-2b
3073 kubernetes_io_os=linux
3073 node_lifecycle=on-demand
3073 alpha_eksctl_io_cluster_name=openscapeshub
3073 topology_kubernetes_io_zone=us-west-2b
3073 beta_kubernetes_io_arch=amd64
3073 failure_domain_beta_kubernetes_io_region=us-west-2
3073 topology_kubernetes_io_region=us-west-2
3073 failure_domain_beta_kubernetes_io_zone=us-west-2b
3073 k8s_io_cloud_provider_aws=4d6fc0cdc07fcc46278e3eae48a92044
3073 beta_kubernetes_io_os=linux
3073 kubernetes_io_arch=amd64
2969 job=kubernetes-service-endpoints
2912 app_kubernetes_io_managed_by=Helm
2899 node=ip-192-168-61-164.us-west-2.compute.internal

Label names most involved in churning:
15919 instance
15919 job
15919 __name__
8689 le
6255 component
5843 resource
5584 verb
5509 version
5346 scope
5330 namespace
3835 group
3601 node
3073 topology_ebs_csi_aws_com_zone
3073 beta_kubernetes_io_arch
3073 failure_domain_beta_kubernetes_io_region
3073 node_kubernetes_io_instance_type
3073 hub_jupyter_org_node_purpose
3073 alpha_eksctl_io_cluster_name
3073 kubernetes_io_arch
3073 node_lifecycle

Most common label pairs:
45533 job=kubernetes-apiservers
25980 component=apiserver
24430 instance=<IP_ADDRESS>:443
23464 version=v1
21103 instance=<IP_ADDRESS>:443
15599 node_lifecycle=on-demand
15599 beta_kubernetes_io_os=linux
15599 failure_domain_beta_kubernetes_io_zone=us-west-2b
15599 topology_kubernetes_io_region=us-west-2
15599 beta_kubernetes_io_arch=amd64
15599 topology_kubernetes_io_zone=us-west-2b
15599 failure_domain_beta_kubernetes_io_region=us-west-2
15599 k8s_io_cloud_provider_aws=4d6fc0cdc07fcc46278e3eae48a92044
15599 kubernetes_io_arch=amd64
15599 topology_ebs_csi_aws_com_zone=us-west-2b
15599 kubernetes_io_os=linux
15599 alpha_eksctl_io_cluster_name=openscapeshub
14882 job=kubernetes-service-endpoints
14597 app_kubernetes_io_managed_by=Helm
14528 node=ip-192-168-61-164.us-west-2.compute.internal

Label names with highest cumulative label value length:
43081 __name__
29334 id
23708 mountpoint
10264 name
6930 container_id
5211 directory
4268 replicaset
4210 type
4017 image_id
3718 resource
3561 secret
2736 uid
2136 image
1909 image_spec
1629 le
1528 handler
1520 pod
1403 device
1352 owner_name
1324 resource_prefix

Highest cardinality labels:
1209 __name__
546 directory
292 name
238 le
225 mountpoint
184 id
176 type
175 resource
147 replicaset
120 secret
90 container_id
83 device
76 uid
76 method
66 kind
65 cpu
64 resource_prefix
53 address
53 owner_name
53 pod

Highest cardinality metric names:
11814 apiserver_request_duration_seconds_bucket
8734 apiserver_request_slo_duration_seconds_bucket
5028 etcd_request_duration_seconds_bucket
2544 apiserver_response_sizes_bucket
1596 apiserver_storage_list_duration_seconds_bucket
1395 jupyterhub_request_duration_seconds_bucket
1170 apiserver_watch_events_sizes_bucket
965 container_tasks_state
952 storage_operation_duration_seconds_bucket
840 kubelet_runtime_operations_duration_seconds_bucket
772 container_memory_failures_total
714 apiserver_admission_controller_admission_duration_seconds_bucket
702 container_blkio_device_usage_total
672 apiserver_flowcontrol_priority_level_request_count_watermarks_bucket
583 apiserver_request_total
576 node_cpu_seconds_total
566 dirsize_processing_time
566 dirsize_entries_count
566 dirsize_last_updated_ns
566 dirsize_latest_mtime

So am not entirely sure what to make of this now.

Exploring hypothesis 2, given that the total number of series stored did not explode (see https://github.com/2i2c-org/infrastructure/issues/2930#issuecomment-1666583674), it reasons that perhaps the amount of bytes required to store any particular series did explode. Given that the prometheus dirsize exporter was added right around the time disk space problems started, I've implemented https://github.com/yuvipanda/prometheus-dirsize-exporter/pull/3 and will attempt a deployment of that shortly. The hypothesis here is that by providing a new value for the time series in question at almost every scrape (due to it being 'amount of time it took to process this directory', which will not vary), compression is extremely poor. It's almost random data, which will compress very badly. It's also not a useful metric.
I'm going to remove providing that in the scrapes, and then delete that metric, and see what happens to the disk space.

Hmm, after this round of cleanup, I see:
/dev/nvme1n1            196.7G     93.6G    103.0G  48% /data

So that's not a lot. I'm not entirely sure now what caused the explosion.

@yuvipanda amazing work doing things and documenting what you do!!!
I got nothing conclusive, but looked into...
About changing min/max-block-size
Have you ruled out #2731?

Can we make this number even smaller? 10min?

I mean yes maybe, but I'm not able to say if its okay with 1m, 10m, 30m, or 2h (default for the max value I think). I have no real idea about the implications of changing this, but its a property I've understood prometheus maintainers prefer users don't fiddle much with through indications by the community when reading issues.

Looking back at this, I saw from https://www.percona.com/blog/prometheus-2-times-series-storage-performance-analyses/ the following claim without reference:

While the configuration knob exists to change the head block size, tuning this by users is discouraged. So you’re limited to providing Prometheus 2 with as much memory as it needs for your workload.

Overall just worried that we have entered unknown territory by tuning this.
About clearing WAL
We are clearing the WAL via #2706, and we did #2731 to avoid issues from doing that.
# Prometheus sometimes seems to run into bugs where the 'write ahead log'
# used for recovery from crashes and network failures gets massive

I read that the WAL is supposedly flushed every 10 seconds, and that would imply for me that its not important to have it around for so long. It seems that the issue may be that the WAL isn't cleaned up based on https://github.com/prometheus/prometheus/issues/7955.
Is there a setting to help clean irrelevant WAL without all WAL?

Copying https://github.com/2i2c-org/infrastructure/pull/2967#issuecomment-1673737352 here:

I looked into adjusting a scraping interval for certain metrics - specifically for the dirsize scraping that updates every 2 hours or anyhow. If we scraped that on an hourly basis instead it would make it fine to have finegrained details about individual users etc.

I've instead just temporarily disabled them completely in https://github.com/2i2c-org/infrastructure/pull/2968 to see if that's actually the cause.

A bunch were down again. I increased default disk space, and then also the disk space for the 2i2c shared one, and it's back up again now.
ls config/clusters | xargs -I {} -L1  deployer use-cluster-credentials {} 'kubectl -n support get pod -l app.kubernetes.io/component=server'
This lets me validate they're all running

This was basically solved by https://github.com/2i2c-org/infrastructure/pull/3093!!!!


Fix ExportMethodDlg layout

What about the Chinese files? Maybe this should wait until I merge the new localizations. Sorry to get you going on this, but doing this now will likely complicate my merge.

Sure, I will check again after the new localizations. I left the Chinese as-is, since it didn't look like there were any layout issues with it like on the English/Japanese ones.


Update CI to run tests on Windows & Mac

We recently encountered a bug in Scanner, tests passes on Ubuntu & Mac but doesn't on Windows.
The idea is to run tests on theses 3 OS to prevent issues like that.
test:
    runs-on: ${{matrix.os}}
    strategy:
      matrix:
        node-version: [16.x, 18.x]
        os: [ubuntu-latest, macos-latest, windows-latest]
      fail-fast: false

Here is an example PR
Tools

[x] CLI
[ ] scanner
[ ] RC
[ ] report
[ ] fs-walk

I think we should take a step back from this and wait a bit (from impact, issues we have with the test_runner not being stable yet etc).


🔧 Update React imports

This pr started out as an attempt to remove allowSyntheticDefaultImports and esModuleInterop from the config – but we already consume modules ourselves which require us to keep these settings.
For example, if we remove these, we have to change the lodash/uniqueId import to import createId = require('lodash/uniqueId') – which then results in eslint errors because eslint-plugin-import does not yet support this syntax.
See https://github.com/benmosher/eslint-plugin-import/issues/1244 for details.
However, since the React imports are all now on separate lines, it will be easier for us to remove these once we upgrade to React 17, so I propose we still merge this pr as it is.
I also updated all the lock-files, allthough strictly not part of this issue.
resolves #826

I ran to some edge-cases with tree-shaking and lodash aswell. Saw some people recommend using lodash-es instead. Maybe this would also help you. Suggest we make a separate spike changing lodash with lodash-es

If I understood correctly import * as React from 'react' will be removed with a script for React v17?

Yes there are scripts but a simple search and replace will do the job as well.

why don't we make our own uniqueId function

well that’s both the beauty and the curse of npm 😉 lodash is the swiss army knife of single purpose modules, so as long as they work, I don’t see why we should re-invent them, but in this case if it’s the only module holding us back then I agree.


Model Peview

Function name
PlayerTextDrawSetPreviewModel(playerid, text[], modelindex)
PlayerTextDrawSetPreviewRot(playerid, PlayerText:text[], Float:fRotX, Float:fRotY, Float:fRotZ)
PlayerTextDrawSetPreviewVehCol(playerid, text[], color1, color2)
Describe the function
PlayerTextDrawSetPreviewModel - Sets a player textdraw 2D preview sprite of a specified model ID.
PlayerTextDrawSetPreviewRot - Sets the rotation and zoom of a 3D model preview player-textdraw.
PlayerTextDrawSetPreviewVehCol - Set the color of a vehicle in a player-textdraw model preview (if a vehicle is shown).
Equivalent in MTA
-
Additional information
https://www.open.mp/docs/scripting/functions/PlayerTextDrawSetPreviewModel
https://www.open.mp/docs/scripting/functions/PlayerTextDrawSetPreviewRot
https://www.open.mp/docs/scripting/functions/PlayerTextDrawSetPreviewVehCol
THERE AREN'T PREPARED IMAGES ONLY IN-GAME VISUALIZATION OF OBJECTS

Probably can be implemented via https://wiki.multitheftauto.com/wiki/Resource:Object_preview

This needs CFont in order to be 1:1. Lots of issues revolving SA-MP portability are mainly related to the lack of CFont in MTA. I will try to do my own implementation in Lua, but I really don't know what the chances are of it looking remotely similar to SA-MP.


https://github.com/grafbase/grafbase/pull/1992

Description
Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context.
Type of change

[ ] 💔 Breaking
[ ] 🚀 Feature
[ ] 🐛 Fix
[ ] 🛠 Tooling
[ ] 🔨 Refactoring
[ ] 🧪 Test
[ ] 📦 Dependency
[ ] 📖 Requires documentation update

@callstackai review


chore: bdd-gh-1582908980 to 0.0.1

chore: Promote bdd-gh-1582908980 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  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:

OWNERS

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


Optimize string comparisons

Avoid doing the bulk compare if string hashes are initialized and unequal.
Let comparisons against literals take advantage of this optimization by initializing their hashes at import time.
The following benchmark yields a 10% speedup on the best case, and a 2% slowdown on the very worst case (albeit a somewhat contrived worst case). On average, I'd expect it to be an overall improvement in-between those numbers:
import timeit
import cython

@cython.ccall
@cython.locals(x=bytes)
def f(x):
   return x in (b'1234', b'4321', b'2321')

def main():
   print timeit.timeit(lambda:f(b'4242'), number=100000000)

While subtle, it could make a significant difference in string-heavy code.

Nice one. Thanks!


Exam-Msft-AZ-220-Self-Assessment-Build5Nines.xlsx File Corrupt

Can't open the Exam-Msft-AZ-220-Self-Assessment-Build5Nines.xlsx files
Excel Prompts as corrupt file

I have double checked the file download again, and there no problem with it I can see. Please try re-downloading the file again if you encounter this. Thanks!


BUG: Add GitHub Action permissions for the labeller

Attempt to enable the pull request labeler to work on forked pull
requests.
Background:

https://github.com/actions/labeler/issues/12
https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

The labeller is working fine for forked PRs, isn't it? Or is this a change to make the action consistent with PR #3571?

Yes, maybe this is not technically needed? At least for many cases? I was thinking it might help with cases of contributors that do not have permissions on the repository. From discussions in the linked issues, failures can occur.

Yes, maybe this is not technically needed? At least for many cases? I was thinking it might help with cases of contributors that do not have permissions on the repository. From discussions in the linked issues, failures can occur.

OK.


Feat: potentiometer

Close - #171

@seveibar Couple of things I noticed from the snapshots are, that if the schRotation is 0 the component is flipped to what it is in the schematic-symbols. And when 180 rotation is also not rotating it


Error in importing hdf5files

When importing hdf5files from striptease there is an error "No module named 'hdf5files'". Example:
import striptease  -> No error
from striptease import hdf5files -> Error (no module named etc)

Works for me:
$ python -c "from striptease import hdf5files; print('ok')"
ok
$

Might it be related to bug #26 ? I implemented a fix in commit 2db7856, try to update your copy and try again.

Updated copy, re-run setup.py install. From terminal it works. From Jupyter (opened from the same terminal where the command works) if I try to import striptease I get:
`ModuleNotFoundError                       Traceback (most recent call last)
 in
1 #import os
2 #os.chdir('/home/daniele/Documents/LSPE/testing_integration/system_level_tests/striptease')
----> 3 import striptease
4 from importlib import reload
5 reload(striptease)
~/miniconda3/envs/strip_env/lib/python3.6/site-packages/Striptease-0.1.0-py3.6.egg/striptease/init.py in
13
14 from urllib.parse import urljoin
---> 15 from web.rest.base import Connection
16
17 # List of all the board names: handy if you need to iterate over them,
ModuleNotFoundError: No module named 'web.rest'`

Update: the error appears also from a terminal if the folder is not the main striptease folder

One more update: see example code (run in terminal with python launched from striptease main folder)
In [1]: import striptease
In [2]: from striptease import hdf5files
In [3]: from hdf5files import DataFile
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-3-61bbc69d0483> in <module>
----> 1 from hdf5files import DataFile
ModuleNotFoundError: No module named 'hdf5files'

Still works for me:
Jupyter
$ (virtualenv tmp && \
    . ./tmp/bin/activate && \
    cd striptease && \
    pip install -r requirements.txt && \
    python setup.py install && \
    python -c "import striptease" && \
    pip install jupyterlab && \
    jupyter-lab)
[lots of output, then Jupyter starts]

From Jupyter, I can load striptease successfully:

Terminal
Still works for me:
$ cd /tmp && python3 -c "import striptease; print('Ok')"
Ok
$ which python3
/home/tomasi/Documents/work/LSPE/bologna/tmp/bin/python3
$

Does not work for me:
(strip_env) daniele@ladyday:~/Documents/LSPE/testing_integration/system_level_tests/striptease$ cd /tmp && python3 -c "import striptease; print('Ok')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/daniele/miniconda3/envs/strip_env/lib/python3.6/site-packages/Striptease-0.1.0-py3.6.egg/striptease/__init__.py", line 15, in <module>
    from web.rest.base import Connection
ModuleNotFoundError: No module named 'web.rest'
(strip_env) daniele@ladyday:/tmp$ which python3
/home/daniele/miniconda3/envs/strip_env/bin/python3
(strip_env) daniele@ladyday:/tmp$

We have to find a way to understand this. How can I help?

We have to find a way to understand this. How can I help?

It seems that some files were not copied in the strip_env environment. This was a bug (#26) that has been solved by commit 2db7856078f02651f4b9e0b3ddd4d8a421287523, so it seems that you are dealing with some old leftovers. Have you tried to completely wipe out strip_env and older copies of the striptease repository?

I have not tried. What should I do exactly?

I have not tried. What should I do exactly?

Run the following commands:
conda env remove strip_env
conda create -q -n strip_env
conda activate strip_env
conda install pyqt=5
pip install -r requirements.txt
python -m pip install -e .

Of course, if you need to use ipython and Jupyter, you must (re)install them within the strip_env environment.


Update Armenian version numbers for release.

Previously these were 2.900+, because the phase 2 versions had major
versions of 2.
This seems like a good time to unify the major version numbering to be
consistent across the noto phase, so we will keep the major version at
2 but bump the minor.  The minor of 040 was chosen so there's a bump
in the second digit, since we're also converting to a three-digit minor
with this phase of Noto.

LGTM


restful: print status when bad content type

LGTM!
No errors, no warnings. :shipit:

  Generated by :no_entry_sign: Danger

Codecov Report

Merging #762 into master will increase coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #762      +/-   ##
==========================================
+ Coverage   55.33%   55.34%   +0.01%
==========================================
  Files         272      272
  Lines       15691    15691
==========================================
+ Hits         8682     8684       +2
+ Misses       6275     6273       -2
  Partials      734      734

Impacted Files
Coverage Δ

util/restful/client.go
40.75% <0%> (ø)
:arrow_up:

lib/auto_resolver.go
89.55% <0%> (+1.49%)
:arrow_up:

Continue to review full report at Codecov.

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


ADAP-1051 - Temp Table Drop Fix

resolves #1036
resolves #1051
Problem
Temp tables created by DBT in BigQuery in incremental strategy were not dropped after successful execution.
Solution
I have added handling for two scenarios:

Drop the temp table after creation
Ability to provide which dataset the temp table will be materialized + drop after execution

Checklist

[x] I have read the contributing guide and understand what's expected of me
[x] I have run this code in development and it appears to resolve the stated issue
[x] This PR includes tests, or tests are not required/relevant for this PR
[x] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc)

Thanks for your pull request, and welcome to our community! We require contributors to sign our Contributor License Agreement and we don't seem to have your signature on file. Check out this article for more information on why we have a CLA.
In order for us to review and merge your code, please submit the Individual Contributor License Agreement form attached above above. If you have questions about the CLA, or if you believe you've received this message in error, please reach out through a comment on this PR.
CLA has not been signed by users: @vinit2107

I have signed the CLA. Please let me know if I need to do anything else.

Thanks @dbeatty10 for your input 👍🏻 I have made the recommended changes.

Hey @vinit2107 , thank you so much for this contribution. We had some time to assess this one and I think it looks great. I'm really happy we have this fix as opposed to one that just adds another flag on top of the already existing hours_to_expiration flag. This is all around great news. Thanks to you and Doug for getting this one in a well tested place.
I'll have this merged on Monday :)


interface logging handler duplication

The base interface does some logging setup, but in case there are two things of the same type or name, we can get duplicates of the handler, for example, if MySensor is descendent of BaseInterface
x = MySensor()
y = MySensor()
print(x.logger.handlers)
print(y.logger.handlers)

what we see is:
[<StreamHandler stderr (INFO)>, <StreamHandler stderr (INFO)>]
[<StreamHandler stderr (INFO)>, <StreamHandler stderr (INFO)>]

because a reconfigure creates new instances in a running process (so that the logger sticks around) , this will likely lead to a lot of increasingly duplicate logs.
It's nice to have the logger in there, but I suspect that most cases we'll want to set up the handlers/formatters in root a certain way and have the loggers derive from there, and otherwise they should probably be set explicitly by the user - so the BaseInterface could prob refrain from setting the handler at all.

Good catch! This can be handled by adding the appropriate code to remove the logger in BaseInterface.__del__.
Want me to quickly handle it?

Actually, I think it's more a question of not adding new handlers after getLogger etc.

yes, I would advocate for not adding handlers in the base

I think it's totally ok to add them in the base, just not if they already exist as desired.

Also, the point of the name attr is to differentiate between instances.


Add publish config

I have a few questions.

Does lerna patch versions of packages in their package.json? If so, then it conflicts with the existing changesets approach
Packages are planned to be published in the global npm registry?
Where it the build step? I think it should be defined at Jenkinsfile. It is defined implicitly?


Emit typescript definition file for #[js_export] functions

I found myself manually creating typescript definition files for my exported rust functions because my IDE will use them for static analysis. Then I thought it would be neat if typescript definition were emitted automatically.
I can take a stab at implementing this. I'm pretty unfamiliar with the code base. Where would this functionality live?

@bgourlie I'm curious: what do your TypeScript definition files look like? I would expect them to all be functions that accept number and return number

So for my first web assembly project I'm making an interactive float tutorial (enter a float, see the discrete parts that make up the value, show how they make up the final value, precision, etc...).
For the front end, I'm using React written in TypeScript (tsx) with noImplicitAny set to true, giving me strict type checking. The interfaces declared in the ts.d file map directly to the json serializable types defined in my WASM module, likewise with any #[js_export] functions declarations.
declare module 'interactive-float-tutorial' {
    export interface FloatValue {
        sign_bit: boolean,
        exponent_bits: [boolean],
        exponent_value: number,
        mantissa_bits: [boolean],
        mantissa_value: number,
        original_value: number
    }

    export function default_float_value(): FloatValue;
    export function update(val: Float64): void;
}

@bgourlie I see, thanks!

@Pauan As @bgourlie explained it's not about the raw functions exported from the .wasm file but about the properly-typed wrappers around those functions generated with #[js_export].
@bgourlie That would require modifyng both #[js_export] (which lives inside the stdweb-internal-macros crate) and cargo-web (more specifically wasm_js_export.rs). The TypeMetadata::Custom structure has a name field which is currently unused, but which I've meant to eventually use for something like this.

@koute Yup, I understand that now. It does sound useful to generate TypeScript .d.ts for the wrappers.


Batching improvements for GEMM/TRSM operators and full MKL usage docs.

Description
During some benchmarking I discovered that the CUDA internal batching implementations for trsm and gemm operators were slow for large matrices. For gemm, found that the gemmStridedBatch implementation is faster at all matrix sizes so we should use that when possible (cuda 8+) Otherwise, since most use cases for these operators use relatively large matrices, use a simple for loop for batch calls instead of the specific batched cuda implementation.
Also added instructions for how to compile with a full MKL installation instead of just the MKL2017 subset.
Checklist
Essentials

[ X ] Passed code style checking (make lint)
[ X ] Changes are complete (i.e. I finished coding on this PR)
[ X ] All changes have test coverage
[ X ] For user-facing API changes, API doc string has been updated. For new C++ functions in header files, their functionalities and arguments are well-documented.
[ X ] To my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

Changed GEMM operator to use gemmStridedBatch CUDA implementation when CUDA is version 8 or higher, otherwise to just do batching manually.
Changed TRSM operator to not use the CUDA batching functionality as it's slower for large matrices. Instead do batching manually.
Added instructions for using a full MKL installation instead of just MKL2017

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

Reviewers

@mseeger , @asmushetzel, @zhenwendai

Apologies for excess merge commits, not sure how to clean those up.

Hey, this was rebased against master just before pushing. I'm not sure why the pr-merge isn't building correctly, is this alright?

The pr-merge error seems fishy, i.e. not related to your changes. There should never any non-checked in changes in a build.


fix(core): export forwardTo action in index.ts

exports the forwardTo action in index.ts
updates actions.test.ts to import forwardTo from src/index to verify this change

Thanks!


[7.x] Speed up seeders

So I been working around seeding huge data and found out seeding thousands of models taking a little too long.
This PR aims to minimize time used on seeding data.
All I had to do was to create an extra method ::quickCreate() so this will not be a breaking change.
Below are the tests I ran using the current seeder vs the new (quick seeder).

Currently

This PR

However I haven't found a way yet to return the created models to use for creating other models. The result is just constructed model object without the model id so you can`t use it with extra seeding.
This quickCreate takes default params as the normal create

On a side note, I tried seeding 100k records and on my machine it took 76seconds

Ooooops, gotta fix those failing tests

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_ac5of94m6t/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_ac5of94m6t/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_ac5of94m6t/clone/recipe/meta.yaml:38: missing_description: The recipe is missing a description
ERROR: /tmp/abs_ac5of94m6t/clone/recipe/meta.yaml:38: missing_dev_url: The recipe is missing a dev_url
ERROR: /tmp/abs_ac5of94m6t/clone/recipe/meta.yaml:38: missing_license_family: The recipe is missing the about/license_family key.
Errors were found


Visual "jumping" on schema page

The scrollbar seems to jump in and out as the cursor enters and leaves the sidebar:

@zwass are you still seeing this? I'm having trouble reproducing.

This is on macOS Chrome
Version 66.0.3359.181 (Official Build) (64-bit)

@zwass if you go to your Mac preferences, general check to see if you have this setting on:

Firefox and Safari also exhibit this behavior with this setting on.

This appears to be caused by the following styling code:
  &.noscroll {
    overflow: hidden;
  }

from commit from #17.

@directionless Was there a reason for this issue being closed?
This is still present on Linux and Windows on Google Chrome.
On my Firefox the vertical scroll bar for the whole page disappears as soon as I stop moving the mouse, so it seems the style doesn't need to compensate for that appearing, but on Google Chrome the scroll bar is always there, taking space, and causes a recalculation of the page width when it disappears while hovering the table name list.
On macOS Google Chrome this doesn't happen because the vertical scrollbars automatically disappear.

I have no memory of why I closed this. Probably I thought it was fixed, if it's still present we can reopen.

I think the root cause problem is when "overscroll" the side list, will trigger schema page scroll. so for now, when hover in side list, added noscroll to prevent schema page scroll, but it cause this visual jumping issue.
FWIK setting overscroll-behavior for side list, and remove 'noscroll' classname toggle in  will solve such problem.
https://caniuse.com/css-overscroll-behavior


Improve liquibase-core pom.xml handling (DAT-14546)

Impact

[x] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Liquibase-core pom now correctly builds its pom within maven rather than than using a custom "relase.pom.xml".
This should confuse maven less in "install" and "deploy" operations
Things to be aware of

Ensure the pom file deployed to github package manager matches what was released in 4.21.1
Ensure the pom file directly deployed matches the one in the jar

Things to worry about

Nothing

Additional Context

Btw @nvoxland , would it fix our Maven 3.9.0 build issues related to javadocs?


Driver DynoCool: Add magnet setting with wait

Adding function to set magnetic field and wait until magnet is a setpoint.
This PR still needs to be tested.
@Dominik-Vogel

Maybe one can look at difference between present field and expected field rather than the magnet state for to determine if the sweep is done? This was actually my initial plan but magnet state seemed like at slightly easier way to implement the same thing.

That seems like a good plan. Maybe we can combine and wait until the current field has changed and then wait until we are no longer in the ramping state. I fully agree, using the state seems like a cleaner way of doing things.

I propose to close this PR in favour of #1586 . @ThorvaldLarsen and @Dominik-Vogel, what do you think?


Compile problem on 1ce0146

I just cloned the repo and could not compile.

This looks like you'll just need to run git submodule update --init, and that should do the trick!

Perfect, thank you.
Shouldn't that be on the install readme ?

Sure!


devel doc: document the cgroup/slices used by rkt

The processes of a rkt pod are grouped together in a cgroup. But which cgroup? It can be located in 3 different kind of cgroup paths:

/machine.slice/machine-rkt... when systemd v216+ is running on the host and rkt was not started from a systemd service (in a .service systemd file, or from systemd-run). Typically, started from the command line. The cgroup directory is created via registration through systemd-machined.
/system.slice/servicename.service when started as a systemd service.
if systemd v216+ is not running on the host:
on rkt <= 0.13.0: stays in the current cgroup
on rkt >= 0.14.0 (unreleased yet), $CALLER_CGROUP/machine-some-id.slice (recently changed in #1844)

This should be documented.
Tangentially related: the rules are not correctly followed on Fedora when the package "systemd-devel" is not installed. See #1867.

@alban I found on my machine the rkt is still in the machine.slice when running using systemd-run:
yifan@yifan-coreos:~$ sudo systemd-cgls
├─1 /sbin/init splash
├─machine.slice
│ └─machine-rkt\x2db191ea93\x2da0a7\x2d454e\x2da2ee\x2d30f143708b31.scope
│   ├─4150 /usr/lib/systemd/systemd --default-standard-output=tty --log-target=null --log-level=warning --show-status=0
│   └─system.slice
│     ├─etcd.service
│     │ └─4155 /etcd
│     └─systemd-journald.service
│       └─4151 /usr/lib/systemd/systemd-journald
├─system.slice
│ ├─avahi-daemon.service
│ │ ├─810 avahi-daemon: running [yifan-coreos.local
│ │ └─864 avahi-daemon: chroot helpe
│ ├─anacron.service
│ │ ├─ 816 /usr/sbin/anacron -dsq
│ │ ├─3527 /bin/sh -c run-parts --report /etc/cron.daily
│ │ ├─3528 run-parts --report /etc/cron.daily
│ │ ├─3536 /bin/sh /etc/cron.daily/apt
│ │ └─3571 sleep 1547
│ ├─thermald.service
│ │ └─846 /usr/sbin/thermald --no-daemon --dbus-enable
│ ├─dbus.service
│ │ └─880 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
│ ├─ModemManager.service
│ │ └─857 /usr/sbin/ModemManager
│ ├─cron.service
│ │ └─848 /usr/sbin/cron -f
│ ├─wpa_supplicant.service
│ │ └─951 /sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant
│ ├─systemd-machined.service
│ │ └─4102 /lib/systemd/systemd-machined

systemd 219, rkt 0.11.
rkt 0.13 works as expected (cgroups are within the service that launches it)

@yifan-gu this looks like #1867. Can you check ls -l /usr/lib64/libsystemd.so* and see if you have libsystemd.so or only libsystemd.so.0?

@alban I only have these:
/lib/x86_64-linux-gnu/libsystemd.so.0.6.0
/lib/x86_64-linux-gnu/libsystemd.so.0
ubuntu 15.04

@alban but when I built from the HEAD,  it works fine.

@yifan-gu not sure why it works on HEAD for you... but the rkt code is definitely wrong since it's trying to open libsystemd.so, which does not exist.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-26-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1935

Questions ?
Please refer to the Backport tool documentation


Add documentation

Add docs based on the system used in the Mantl project: https://microservices-infrastructure.readthedocs.org/en/latest/index.html
Besides that, we'll need to describe some use cases providing several examples how one could leverage Kubernetes.

It's not on our roadmap any more.


Deprecate SecureJava.fromBytes

This would have to be removed completely in one of the next releases. Related to #547 , but not a fix yet.
Review by @non or @tixxit

:+1:


docs: update featured article list

Fixes: #[Add issue number here]
Changes:

Screenshots of the change:

Did you all check the preview environment? This does not look right. @hf400159 @SylviaBABY

With this modification, both blog and Case Studies (which is also a part of blog) in en-us and zh-cn failed.
I'd suggest solving these failures before merging, otherwise this could be a huge problem. You can seek help from others in the community as well.

Hi, I found this problem yesterday; I will fix it today. @yzeng25

Hi @yzeng25, sorry to dismiss your Request Change, this PR has fixed that issue.

Hi @yzeng25, sorry to dismiss your Request Change, this PR has fixed that issue.

Yeah no problem.


PWA must add theme-color meta tag

So I have deployed a site developed using Nuxt 3 on Netlify, and I have Lighthouse installed as plugin.
The below image is from Netlify lighthouse

Version
"@vite-pwa/nuxt": "^0.1.1",

The below is my configuration
pwa: {
    registerType: "autoUpdate",
    manifest: {
      name: "Nuxt Nova",
      short_name: "NuxtNova",
      display: "standalone",
      theme_color: "#212529",
      background_color: "#212529",
      orientation: "portrait-primary",
      description: "Nuxt Nova Blog Template",
      icons: siteLogoIcons,
    },
    workbox: {
      navigateFallback: "/",
      globPatterns: ["**/*.{js,css,html,png,svg,ico}"],
    },
    client: {
      installPrompt: true,
      // you don't need to include this: only for testing purposes
      // if enabling periodic sync for update use 1 hour or so (periodicSyncForUpdates: 3600)
      periodicSyncForUpdates: 20,
    },
    // devOptions: {
    //   enabled: true,
    //   suppressWarnings: true,
    //   navigateFallbackAllowlist: [/^\/$/],
    //   type: "module",
    // },
  },

Since I have already added theme_color to the configuration, I think it would be redundant to manually add a theme-color meta tag separately.
This should be a part of VitePwaManifest
Another suggestion is to move VitePwaManifest code to a plugin so that it's automatically added to all pages.

@modbender sorry, but this plugin will not include any metadata to the page, that's something you can do once. For web manifest icons you can use https://github.com/vite-pwa/assets-generator

Alright, I'll try to add the support and maybe open a PR, it's rather simple actually so.

@modbender there is no need, I'm working to integrate the PWA assets generator api in pwa plugin https://github.com/vite-pwa/vite-plugin-pwa/pull/621 , integrations support will also coming soon


get_nncf_wrapped_model method is deleted in latest nncf

The get_nncf_wrapped_model method for NNCFNetwork in NNCF has been removed in https://github.com/openvinotoolkit/nncf/pull/1584
Corresponding changes in optimum needed.

fixed here:
https://github.com/openvinotoolkit/nncf/pull/1819/files

Thanks for the update @ljaljushkin !


msbuild link error: multiply defined symbols

This is on x64 win7 with system-wide vcpkg integration.
A project not using any vcpkg dependency now throws linker errors. I believe to have tracked it down to the autolink feature.
Verbose linker output:
1>------ Build started: Project: EntryPoints, Configuration: Release x64 ------
1>
1>Starting pass 1
1>Processed /DEFAULTLIB:msvcprt
1>Processed /DEFAULTLIB:uuid.lib
1>Processed /DEFAULTLIB:comsupp.lib
1>Processed /DEFAULTLIB:oleaut32.lib
1>Processed /DEFAULTLIB:MSVCRT
1>Processed /DEFAULTLIB:OLDNAMES
1>Processed /DEFAULTLIB:MSVCMRT
1>Processed /DEFAULTLIB:MSCOREE
1>
1>Searching libraries
1>    Searching C:\Tools\vcpkg\installed\x64-windows\lib\boost_atomic-vc140-mt.lib:
... snip ...
1>    Searching C:\Tools\vcpkg\installed\x64-windows\lib\cpr.lib:
1>      Found "public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ)
1>        Referenced in Something.obj
1>        Loaded cpr.lib(cpr.dll)
1>      Found __IMPORT_DESCRIPTOR_cpr
1>        Referenced in cpr.lib(cpr.dll)
1>        Loaded cpr.lib(cpr.dll)
1>      Found __NULL_IMPORT_DESCRIPTOR
1>        Referenced in cpr.lib(cpr.dll)
1>        Loaded cpr.lib(cpr.dll)
1>      Found cpr_NULL_THUNK_DATA
1>        Referenced in cpr.lib(cpr.dll)
1>        Loaded cpr.lib(cpr.dll)
1>    Searching C:\Tools\vcpkg\installed\x64-windows\lib\fmt.lib:
... snip ...
1>    Searching C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\lib\x64\MSVCRT.lib:
1>      Found "const type_info::`vftable'" (??_7type_info@@6B@)
1>        Referenced in Whatever.obj
1>        Loaded MSVCRT.lib(std_type_info_static.obj)
1>      Found _fltused
1>        Referenced in Whatever.obj
1>        Loaded MSVCRT.lib(fltused.obj)
1>      Found _DllMainCRTStartup
1>        Loaded MSVCRT.lib(dll_dllmain.obj)
1>      Found "void __cdecl operator delete(void *,unsigned __int64)" (??3@YAXPEAX_K@Z)
1>        Referenced in MSVCRT.lib(std_type_info_static.obj)
1>        Loaded MSVCRT.lib(delete_scalar_size.obj)
1>      Found __security_init_cookie
1>        Referenced in MSVCRT.lib(dll_dllmain.obj)
1>        Loaded MSVCRT.lib(gs_support.obj)
... snip ...

causing linker error
LNK2005	"public: virtual char const * __cdecl std::exception::what(void)const " (?what@exception@std@@UEBAPEBDXZ) already defined in cpr.lib(cpr.dll)	...
LNK1169	one or more multiply defined symbols found

Apparently we pick up symbols from vcpkg libraries that we should really pick up from the runtime, because vcpkg's autolink inserts itself before the system libraries by adding itself to the %AdditionalSomething% variables.
Workaround
This will cure the issue for this project, but I will hit this again once I decide to actually use a vcpkg dependency in this project. For posterity, this disables autolinking for the project:
In %ProjectName%.vcxproj add this flag
   <PropertyGroup Label="Globals">
+    <VcpkgAutoLink>false</VcpkgAutoLink>
   </PropertyGroup>

My Question
Is the search order vcpkg-before-msvcrt broken or is cpr.lib misbehaving?
It does not seem to be a statically-linked version, seeing as it pulls in cpr.dll, but then again with ~1MB it seems a bit "fat" for an import library. (Side note: if I remove cpr.lib from the equation, fmt.lib shows the same behaviour :frowning: so this may not be an isolated issue)

Hi @dlw42 , could you please help provide the project case that you used in vs and how the error occured?
Which version of vs ?
Thanks.

Thanks for posting this issue. Please open a new issue if this is still a problem for you.


Fix FWEO-1047 - Inverted shift and caps lock icons

Description
The goal of this PR is to fix https://ledgerhq.atlassian.net/browse/FWEO-1047
Changes include

[*] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)
[ ] Tests
[ ] Documentation
[ ] Other (for changes that might not fit in any category)

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

Project coverage is 59.65%. Comparing base (ff00a05) to head (9fd7b8d).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #577   +/-   ##
=======================================
  Coverage   59.65%   59.65%
=======================================
  Files          12       12
  Lines        1678     1678
=======================================
  Hits         1001     1001
  Misses        677      677

Flag
Coverage Δ

unittests
59.65% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Dataset

Coverage decreased (-0.06%) to 92.96% when pulling 971fcaf6034524b4b9b0d278bac282f3d1eff1d2 on dataset into 2d4fdfc215fb4fa40c3dc032098d10b28eacc1c6 on master.


Clarify scopes for private repositories

When attempting to publish private repositories using GitHub authentication in npme, the token needs the "repo" scope to query the GitHub API.

@cthierer Awesome, thanks for contributing!
Not sure if you're aware, but npm loves to give out "sock for docs". If you're interested in snagging a pair of our snazzy socks, you can either DM npmjs on Twitter or send an email to<EMAIL_ADDRESS>with your name and address. (If you require shipping overseas, please also include a phone number.)
Thanks again!

FYI, your changes are now live.
https://npme.npmjs.com/docs/up-and-running/auth/github.html
Thanks again!

"Socks for docs" - that's awesome! Thanks!


i cant dowload videos from XVideos for android phone ， version 12.29

./youtube-dl -v --user-agent "Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19" http://www.xvideos.com/video4588838/biker_takes_his_girl
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-v', u'--user-agent', u'Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19', u'http://www.xvideos.com/video4588838/biker_takes_his_girl']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2015.12.29
[debug] Python version 2.7.10 - Darwin-15.2.0-x86_64-i386-64bit
[debug] exe versions: none
[debug] Proxy map: {}
[XVideos] 4588838: Downloading webpage
ERROR: Unable to extract video URL; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "./youtube-dl/youtube_dl/YoutubeDL.py", line 665, in extract_info
ie_result = ie.extract(url)
File "./youtube-dl/youtube_dl/extractor/common.py", line 291, in extract
return self._real_extract(url)
File "./youtube-dl/youtube_dl/extractor/xvideos.py", line 39, in _real_extract
self._search_regex(r'flv_url=(.+?)&', webpage, 'video URL'))
File "./youtube-dl/youtube_dl/extractor/common.py", line 586, in _search_regex
raise RegexNotFoundError('Unable to extract %s' % _name)
RegexNotFoundError: Unable to extract video URL; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Hope to support android similar web sites o(////▽////)q， Thank you for all that you have done.，that‘s nice of you,thank you

Do NOT change the user-agent.


Fix use after free during creation of Promise reactions.

The ecma_enqueue_promise_reaction_job() function allocates memory, which might trigger a GC run. During this GC the objects in the reactions collection are not marked.
Fixes #2486.
Fixes #2506.

Do we have es2015 fail folder? If the answer is no, I would remove the test case because it is heavily dependent on the current allocator configuration and the other test doing it in a much nicer way (less sensitive to allocator configuration changes).

Right now, there is no es2015/fail folder under tests/jerry. However, this is not a technical limitation of the testing framework. In tools/runners/run-test-suite.sh, there is a code that automatically handles all .js files in directories named fail as expected failure:
for test in `cat $TEST_FILES`
do
    if [[ $test =~ ^\.\/fail\/ ]]
    then
        error_code=1
        PASS="PASS (XFAIL)"
    else
        error_code=0
        PASS="PASS"
    fi

So, if a test case needs to fail, this PR can create an es2015/fail directory under tests/jerry and put the test case there. The test framework should pick it up as expected. (At least I hope so.)

The biggest concern is that the test is too fragile, and the other test doing this much better way, so it is redundant.

Any more thoughts?

It seems this patch fixes #2541 as well. Please test it and add it to the PR if you're convinced of it.

Issue checket, it does fixes it. Thank you for the review.


FGA accidentally select support instead of refreshing

Before opening an issue:

[X] I tested the latest release
[X] I looked at other issues (even the closed ones)
[X] I read the Troubleshooting Guide
[X] I'll fill this template properly

I'm setting FGA to search for a pretty rare CE so it usually has to refresh quite a number of times. The quest's cost is really low too so FGA must run for 1h+ normally. I have noticed a few times instead of selecting the "Update list" button it accidentally select a support, then process to hang at the first turn of combat.
I will try to upload a recording later; the first recording's quite large at 3.3GB but when I tried to copy it to my computer it apparently got corrupted and couldn't be played.
Video:
https://youtu.be/h-LLBTrla68
FGA version: Canary 1274
Device Info:

Device model: Xiaomi Redmi 5 Plus
Screen size: 1080x2160
Android Version: Android 8.1.0
RAM: 4GB

Let it ran for half an hour tonight and everything's fine; I'm guessing what happened is that FGO had been left running for so long that it started being unresponsive enough for FGA to misclick. Closing this issue for now.

Let it ran for half an hour tonight and everything's fine; I'm guessing what happened is that FGO had been left running for so long that it started being unresponsive enough for FGA to misclick. Closing this issue for now.

Did you check if it clicked on the Fallback Option?
FGA is configured so that after a number of refreshes (can be changed in more settings), it automatically falls back to the fallback option, which can be Manual or First.
Check if that's the case and if so, you might want to make the number of refreshes larger, since like you said the target ce is rare.

Did you check if it clicked on the Fallback Option?
FGA is configured so that after a number of refreshes (can be changed in more settings), it automatically falls back to the fallback option, which can be Manual or First.
Check if that's the case and if so, you might want to make the number of refreshes larger, since like you said the target ce is rare.

@the3dsandwich
I set it to Manual so that's definitely not it, and have seen FGA changed to manual support selection mode a few times before so I know the setting's fine.

@the3dsandwich
I set it to Manual so that's definitely not it, and have seen FGA changed to manual support selection mode a few times before so I know the setting's fine.

Manage to snag a video again so I'm reopening this.

Manage to snag a video again so I'm reopening this.

Look closely at the red rectangle over the servant and CE location. It shifts down the moment you received a notification.
FGA's view of the screen becomes smaller if the Status bar shows up, which does for you when you're receiving a notification. It doesn't show on my phone though. So, instead of the click happening on Refresh button it happens slightly below it.
I think the only way around for you would be setting DND.

Look closely at the red rectangle over the servant and CE location. It shifts down the moment you received a notification.
FGA's view of the screen becomes smaller if the Status bar shows up, which does for you when you're receiving a notification. It doesn't show on my phone though. So, instead of the click happening on Refresh button it happens slightly below it.
I think the only way around for you would be setting DND.

That might have been me pulling the Notification Shade down manually to check the time :/ Can't remember if it was indeed the case tho. I'll try to be mindful of that and see if the problem still happens. Closing this again.

That might have been me pulling the Notification Shade down manually to check the time :/ Can't remember if it was indeed the case tho. I'll try to be mindful of that and see if the problem still happens. Closing this again.


Add log message to notify of database update status

Right now the database update script doesn't log its completion status anywhere, and the task itself is only available to review in AWS an hour after completion. Need to find a way to log whether the update was successful or not - although right now the only failures are due to one-off errors retrieving the docker image for the task.

Set up EventBridge notifications to alert if the DB update tasks fail (currently set to email)


Add steps for persistent mounts

The github page has the required steps to mount the filesystem on boot:
https://github.com/Azure/azure-storage-fuse/wiki/2.-Configuring-and-Running
These need to be added to this article

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

ID: cef87c25-d489-ed0c-c94f-c764b3fd2413
Version Independent ID: 7f8c5d56-2382-de90-dcaf-6fc87706a3be
Content: How to mount Azure Blob storage as a file system on Linux
Content Source: articles/storage/blobs/storage-how-to-mount-container-linux.md
Service: storage
GitHub Login: @normesta
Microsoft Alias: normesta

@msLinuxNinja, Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

#reassign:rishabpoh

#reassign: @dineshmurthy

Add a section to the microsoft docs - Persisting. Content is below
https://github.com/Azure/azure-storage-fuse/wiki/2.-Configuring-and-Running#persisting

T@msLinuxNinja - Thanks for your feedback. The article has been updated to point to the appropriate place.

#please-close


Remove hyphen in ISO 8601 in rubocops/deprecate_spec.rb

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Correct ISO-8601 to ISO 8601 in the rubocops/deprecate test.
CC: @reitermarkus

Thanks again @Rylan12!


Release stable version

Was wondering what is blocking the release of a "stable" 2.0.0 release?

Understandable 👍

Finally got this done.

👍👍


double click in text mode results in a broken state

I've noticed that sometimes when in text mode I get stuck in a state where I can't type text or change the mode on the left, and I have to refresh the page. Here's the error associated with clicking on the canvas or another mode button:

I can reliably reproduce this by double clicking really fast on the canvas while in text mode, but I think there are other ways to cause it too because it was happening before without double clicks (just not reliably).
Also, thanks so much for making this tool :) it's invaluable in a time like this...

Thanks for spotting this!  I was able to track down and (I believe) fix the bug.  "Conveniently", I encountered the same bug (even on single click) when tracking down some bugs on iOS.
Fixed version is deployed. Let me know if you see any other issues!


[add] inquiry form generation support

Coverage decreased (-0.06%) to 85.885% when pulling 777731a809f7a6055146bbf319d02b8278f892fa on sunny4381:features/generating-inquiry-form into f6e22005d56412f2f1e8927baf25e068ad9062ab on shirasagi:master.