Reset DictClass.py Class Variable

file to refer:  https://github.com/blobcity/autoai/blob/main/blobcity/store/DictClass.py
Reset or Clear data initialized/allotted to Class variables in DictClass.py on each call to driver function train

Can I work on this issue?

@aadityasinha-dotcom there you go. Issue is assigned to you.

@aadityasinha-dotcom  Sorry to inform you a bit late the issue has been resolved for the initial release of the library on PyPi

Oh. It's okay.


Has anyone used karate calling a service who body is x-www-form-urlencoded?

I'm trying to test a service that requires this type of body using the key-value pairs.  I'm coding the keys-values in JSON format.  Is this correct or should it be done a different way?
Example:
headers { ContentType: 'application/x-www-form-urlencoded' }
Given url serviceUnderTest
and request {key1:'value1', key2:'value2'}
when method POST
Then status 200
I'm new to Karate so I don't expect that my code is perfect.  Anyway, this is not working.  Ideas/Suggestions?

please read the docs: https://github.com/intuit/karate#form-field
if you are still stuck use stack overflow please, thanks.


Shortcut ctrl+` fail after reactivate vscode window

Issue Type: Bug
File on: Visual Studio Code
Reproduce steps

Open vscode
now deactivate vscode window (switch to other program) and activate vscode window again.

Actual

Ctrl + ` no responce, not open nor close terminal
In Preference-->Keyboard Shortcuts-->Record Keys, when recording shortcut "Ctrl + `", "Ctrl + " appear and not seaching

Expacted

Ctrl + ` works fine, open terminal and close
In Preference-->Keyboard Shortcuts-->Record Keys, when recording "Ctrl + `", "ctrl+oem_3" should appear and begin to search

VS Code version: Code 1.39.2 (6ab598523be7a800d7f3eb4d92d7ab9a66069390, 2019-10-15T15:35:18.241Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 1800)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.81GB (2.52GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

Not able to create the bug. Can you verify the steps again, anything you have done before you got the issue?
With the steps, you mentioned to reproduce, the bug is not happening.

@illava I cannot reproduce. ctrl+` works reliably for me, even if I focus another application and return to VS Code later. Do you happen to use a specific keyboard layout where this reproduces?

I figure out the issue is related to IME(QQPinyin). Repaired after uninstalling.
Thanks for your help.

That‘s why it appears only my home and office PC.
Don't know what's the exact problem with IME. Since it is rare used and lacks feedback methods. Simply change to another IME will be fine.

Ok, it seems that you have a similar issue as #70482 . ctrl+` is simply reserved and used by the IME, therefore the keybinding does not reach VS Code.


zlib plugin problem

hey guys, I get some problems.
I can't detect zlib data, but my friends can do it.
I not sure where is the problem happen. Is the python or the binwalk?
My python version is 2.7.9 and binwalk version 2.0.0.
How can i check zlib plugin?
Thanks.

First, try the latest code from the repository and see if you have the same problems (v2.0.0 is pretty old): https://github.com/devttys0/binwalk/archive/master.zip


Add more information on answer.

Add more info about the Pokemon along with the images like links etc.

QR code maybe


feat: added flashTypePrefix variable

Enable the ability to not use the generic bootstrap or foundation class names, by adding flashTypePrefix which provides a way for the user to specify the flash type class name prefix.
Backwards compatibility is maintained with messageStyle, but if flashTypePrefix is set it will take priority.
{{#each flashMessages.queue as |flash|}}
  <FlashMessage @flash={{this.flash}} @flashTypePrefix="special-alert-" />
{{/each}}

would produce an element like
<div class="flash-message special-alert-success" > ... </div>

Rationale
I've been running a custom flash-message component for this addon for a while now, because;

the flash-message component in this addon was a bit old
the classes alert and alert-box are very overused and poorly scoped in our 15-20 frontend apps... we really needed to avoid using these class names, and this addon didn't provide a way to customize that (without resorting to a custom component)

I noticed that with v2.0.0 the component has been updated to be tagless, render modifiers etc so I thought I would contribute some of my workings back to the project, with the aim of being able to use the component in this addon again!

btw! I am participating in hacktoberfest this year so I would much appreciate it if this pull request could have the hacktoberfest-accepted label added to it, or if the repo could have hacktoberfest label/topic :100:

Any interest in merging this @sbatson5 ? It's a requirement for me to not need to use a custom flash component

Thanks @sbatson5 those are all great suggestions, implemented them all.


EditorToaster does not expose _popup_str anymore, regression in 4.3.dev3

Tested versions
v4.3.dev3.official [36e943b6b]
v4.3.dev4.official [df78c0636]
v4.3.dev5.official [89f70e98d]
System information
Godot v4.3.dev5 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 Ti (NVIDIA; <IP_ADDRESS>52) - AMD Ryzen 9 7900X 12-Core Processor (24 Threads)
Issue description
I try to use the EditorToaster from the editor by getting the node and _editor_toaster.call("_popup_str", message, severity, tooltip). Since v4.3.dev3.official [36e943b6b] the method is not callable anymore.
The last time it worked was in v4.3.dev2.official [352434668].
Steps to reproduce
Open the MRP and enable/disable the plugin, which will trigger the toster.
Minimal reproduction project (MRP)
toaster_example.zip

I would say this was never intended to be exposed, and was internal, it was removed when deferred calls switched to using callables, which was the only reason it was ever exposed in the first case, if callables had been used from the start it wouldn't have been bound
Undocumented methods aren't part of the API

I'd say there should be a discussion about if we should bind a method properly and officially, but most editor components are internal and not for general use, so it's not guaranteed to be done
I'd say this would be best suited as a proposal, as the removal of this was done as part of a cleanup, and was never exposed "officially", it was only accessible by necessity


docs: Updated Workflow Controller Architecture Image

Issue Details
Text written in the Workflow controller architecture image is not visible clearly. To see issue go to this link : https://argoproj.github.io/argo-workflows/architecture/#workflow-controller-architecture
Motivation
Documentation will look more clean.
Modifications
As the text in the image is not visible clearly so i deleted the previous Workflow controller architecture image and uploaded a new improved image having same content.
PREVIOUS IMAGE

UPDATED IMAGE

Thanks for commenting @agilgur5  :),Yes , i can improve the contrast.

The black arrows on the dark blue workers rectangle are also hard to see

Hey @agilgur5 does this work

Seems like this PR was replaced by #11932.
For future reference, please use the same PR when making modifications instead of opening a new one.


Running flutter test -d chrome silently runs non-web tests.

Description
When I run:
flutter test --verbose -d chrome

I can see in the output that it is running the host (Linux in this case) version of the unit test, not the web version, but it just happily runs the test and reports the result.
flutter test shouldn't accept the -d argument if it is going to ignore it, at least in this case. It should either run in chrome, or not allow the argument.
To run the test the way I wanted, I needed to supply this instead:
flutter test --verbose --platform=chrome

@gspencergoog FYI per the help page, --platform=chrome is deprecated. I will add a toolexit however when -d is used with flutter test, to inform users it will not do anything.

I realize now using the -d flag IS used when running an integration test, so I'm not sure how to fix this.

One way to fix this is to check if the device that matched on the -d option is a web device. If it is, throw a ToolExit.

Another possible solution is to just make -d support web devices, so that flutter test -d web would be equivalent to flutter test --platform=chrome.
But I'm a bit confused about how flutter test -d actually works today. What does it do if I specify a non-web target? Does it use a different mechanism than if it's not specified? Is it defaulting to -d flutter-tester?


Fix error in self testing bot

I have fixed the error in self testing bot as mentioned in this issue: https://github.com/wechaty/wechaty.js.org/issues/1146

@sbis04  Please make Github action green first :)

@sbis04 Thank you very much for the fix!


combo box

Epic tool but would benefit from a combo box grid field option where you can start typing and it autocompletes by either searching an array of options or make an ajax request to an external server

Thank you for the feedback.
Not sure it best to build in such a field in the jsGrid directly. Maybe provide sample for custom fields that uses some popular comboboxes like select2. Please, checkout this issue, I think it has a solution: https://github.com/tabalinas/jsgrid/issues/141


add-reference parses urls with & in it

Hello, when I try following command  to add reference URL (P854)  as the url has & in it, it doesn't accept it as a valid parameter.
wd add-reference 'Q29062$17048767-D192-4294-9B31-861DE5979A7A' P854 'http://www.tff.org/Default.aspx?pageId=30&kisiId=28050'

fixed! b93e37e
the patch was just published in v5.0.1


Grammar: units

_ Is refactor
x Is new feature
_ Concerns documentation

Description of suggestion:
Decide on formal syntax for units and specify them in grammar

Stale and similar to #125, which we closed.


Unfinished code execution reports as [finished with error]

Firstly - thank you for building this fantastic project! I recently tried several other terminal presentation tools, and I found presenterm to be best by far. In particular, for its of out-of-the-box and non-blurred image support and how great the default themes and styling look. Well done!
I have encountered an issue with the bash code execution feature. On one of my machines, executing any simple bash script from within a presentation yields the [finished with error] message in the execution output, nearly every time. Very occasionally the message does not appear. The bash script executes successfully when I execute it directly in the terminal.
E.g. for the script
echo "hi"

In the presentation, after executing it, the output would be:
hi
[finished with error]

FWIW, on another machine, I very rarely see the [finished with error] message, but it still comes up occasionally. Both machines have similar setups - both use iterm2 and zsh.
I did some debugging: I believe the child code execution process had not exited by the time the output from the process is extracted - this try_wait was returning Ok(None). I also made a change to pipe stderr and display that, but there was no stderr output.
So my suggestions/questions from this are:

We should modify the ProcessReader::run method to not update the status to ProcessStatus::Failure if the child process has not exited yet. (We could potentially use a new ProcessStatus::NotComplete variant?)
Could the try_wait be replaced by the blocking wait to ensure the process has completed? ProcessReader::run is called in a new thread.
I think seeing stderr output would be preferable to the [finished with error] message. Seeing the actual stderr output would also help debugging. Any thoughts on this?

I would be happy to make contributions.
Cheers!

Could the try_wait be replaced by the blocking wait to ensure the process has completed? ProcessReader::run is called in a new thread.

Actually using blocking wait (or wait_with_output) would mean the code execution output only appears in the presentation after all the code has finished executing - the presentation would not show the output line by line as soon as it is written to stdout.

Thanks for the report! I managed to reproduce consistently by doing
```bash +exec
echo "hi"
exec 1<&- sleep 1
```

I've never seen this locally unless I do that ^ but I guess it depends on how the OS handles things. I can imagine the race condition between closing stdout and the process dying is there and shouldn't be too rare to hit.
Anyway, talking about the fix, I'm not sure what you mean with using wait leading to the entire output being shown at once. I tried that and it seems to work just fine with the "echo / sleep" code snippet in examples/demo.md. The output is pushed into a shared vec so you can spit output and then wait for the program to finish. And this to me makes sense; this as you say runs in a separate thread so the presentation can keep going (you can change slides and all) and eventually the program will end and we'll get the done or "finished with error" depending on what happened. Could you clarify how using wait doesn't work? I may be missing something.
As for showing the stderr output on failure, I think that makes sense. I'm just not sure how to show it "nicely". The best we can do is something like "finished with error" and then the error message in some specific configurable color (e.g. a shade of red likely).

I tried that and it seems to work just fine with the "echo / sleep" code snippet in examples/demo.md.

Actually, I was mistaken and you are correct - the behaviour I described only appears when using wait_with_output, not when using wait.
The behaviour I was describing is demonstrated by the following recording:
https://github.com/mfontanini/presenterm/assets/79006698/f0dcdb7e-6a53-4604-b3db-9efee23feb87
Instead of seeing the each hi output with pauses in between, you only see the entire output at the end, once the child process exits.

As for showing the stderr output on failure, I think that makes sense. I'm just not sure how to show it "nicely".

To me, the ideal would be that you see the output from both stdout and stderr exactly as you would see it from executing the code directly in the terminal. As an example, see the recording in https://github.com/dmackdev/presenterm/pull/3 where the final output shows the stdout and stderr outputs interleaved. But that approach on that PR currently suffers from the same aforementioned behaviour where any output only appears once the child process exits. I think showing output exactly as it would appear in the terminal is ideal because it could be confusing for viewers of the presentation to see it presented differently. Perhaps there might also be use cases where the presenter intends to execute code snippets that deliberately fail or have stderr output?
Failing that, as a compromise, I think showing stderr output after stdout output would still be valuable as it could help the presenter debug snippets and still provide a way to make stderr visible in the presentation, if so desired. See https://github.com/dmackdev/presenterm/pull/2 for an example of that. Colouring that output in a configurable colour also sounds like a good idea, and maybe even an option to control whether to show stderr at all?

I appreciate that our discussion (and my initial suggestions) have grown beyond the crux of this issue, so perhaps as next steps:

We replace try_wait with wait to fix this original issue of seeing [finished with error] only because the process had not exited yet. I am happy to raise a PR for this.
We devise an approach for showing stderr output - happy to raise a separate issue to focus on this, if you so wish!

Sounds good! If you'd like to create a PR that'd be great. And yes, we should move the stderr handling to a separate issue. I like the idea of interleaving as long as it doesn't add other drawbacks (e.g. it still prints interactively). I left a comment on https://github.com/dmackdev/presenterm/pull/3 about that.

Great - I will raise that PR, raise a separate issue and have a look at your comment. Cheers!


DISCO hosting capacity reports database schema

It's worth to store the hosting capacity reports of DISCO into a database, as it facilitates the metrics query and result comparison dynamically among feeders.
The database schema is shown below,

Feel free to comment if any question or suggestions!

@jgu2 Can we close this?

Yes, the db schema already implemented and is now in use, it could be closed.

@jgu2 Can we close this?

Yes, the db schema already implemented and is now in use, it could be closed.


[R] Error: object 'is_eval_err' not found

Environment info
Operating System: Windows  Version	10.0.16294 Build 16294
CPU:  i7-5820K
C++/Python/R version: R 3.4.2
I have compiled OpenCl version for my system and Windows executable runs just fine. However I'm getting an error in R.
Error Message:
[LightGBM] [Info] Number of positive: 3140, number of negative: 3373
[LightGBM] [Info] Total Bins 128
[LightGBM] [Info] Number of data: 6513, number of used features: 107
Error: object 'is_eval_err' not found
traceback()
4: merge.eval.string(env)
3: f(env)
2: lgb.train(params, dtrain, nrounds, valids, verbose = verbose,
eval_freq = eval_freq, early_stopping_rounds = early_stopping_rounds,
init_model = init_model, callbacks = callbacks, ...)
1: lightgbm(data = train$data, label = train$label, num_leaves = 4,
learning_rate = 1, nrounds = 2, objective = "binary")

This seems to be caused by commit f90dfaf. @bfgray3 Can you take a look at this? I think there is a typo here: https://github.com/Microsoft/LightGBM/blob/master/R-package/R/callback.R#L135, is_eval_error should be is_eval_err?
@UpsideDownRide Can you change line 135 of R-package/R/callback.R into the following:
is_eval_err <- length(env$eval_err_list) > 0

and see if it works?

Yes @huanzhang12 you are correct.  Sorry for the inconvenience.

@huanzhang12 I'm about to put in a PR fixing #946 and #947.

@bfgray3 Thanks!

Fixed in ac2a914


content-type:diagram reports error

Command: csdx content-type:diagram -s "stackID" -o "contentstack/content-model.svg"
It reports error:
Requesting data... !
    ContentstackError: Bad Request

Hi @Always-Starter   We tried the same command which u shared and were unable to replicate this at our end.
We used latest contentstack-cli-content-type version of 1.1.1

Can you share which CLI and content type plugin version did u tried and does the stack you tried had branches enabled ?
cc: @netrajpatel  @cs-raj

Closing this issue as there was no further communication
cc: @netrajpatel @aman19K @AniketDev7 @shafeeqd959


Compatibility with Rails 4.2

:bullettrain_side::arrow_upper_right:
/cc @zendesk/zendesk-rails-upgraders
Description
Changed gemspec restriction
Add gemfile for travis
Setup ActiveSupport test order if possible
Steps to merge

[ ] :+1: of the team

@osheroff, @pschambacher, any progress on this one?

none from me; like I said, I'm ok disabling this functionality on later rails....

@pschambacher is on holiday, so I took over this branch :-)
Marked that failing test as pending, did a bundle update and rebased.
Oh, and the build is green!

:+1: then.

Pushing gem to https://rubygems.org...
You do not have permission to push to this gem.

:cry:


feat: Consolidate v1.3b

Codecov Report
Base: 64.16% // Head: 64.12% // Decreases project coverage by -0.04% :warning:

Coverage data is based on head (0937cfb) compared to base (dafe021).
Patch coverage: 60.46% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #141      +/-   ##
============================================
- Coverage     64.16%   64.12%   -0.05%
- Complexity      539      540       +1
============================================
  Files           102      102
  Lines          1850     1834      -16
  Branches        194      192       -2
============================================
- Hits           1187     1176      -11
+ Misses          598      596       -2
+ Partials         65       62       -3

Impacted Files
Coverage Δ

src/main/java/jeryl/fyp/MainApp.java
0.00% <0.00%> (ø)

src/main/java/jeryl/fyp/logic/LogicManager.java
60.00% <0.00%> (ø)

...a/jeryl/fyp/logic/commands/AddDeadlineCommand.java
93.33% <ø> (ø)

...va/jeryl/fyp/logic/commands/AddStudentCommand.java
100.00% <ø> (ø)

...eryl/fyp/logic/commands/DeleteDeadlineCommand.java
0.00% <0.00%> (ø)

...jeryl/fyp/logic/commands/DeleteStudentCommand.java
100.00% <ø> (ø)

...ain/java/jeryl/fyp/logic/commands/FindCommand.java
100.00% <ø> (ø)

...jeryl/fyp/logic/commands/FindStudentIdCommand.java
100.00% <ø> (ø)

...ain/java/jeryl/fyp/logic/commands/ListCommand.java
100.00% <ø> (ø)

...ain/java/jeryl/fyp/logic/commands/MarkCommand.java
56.52% <ø> (ø)

... and 23 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Not working for me

I was unable to get this working: https://jsfiddle.net/chrisjmartini/5ak4udgb/57/
Any ideas?

A couple things are wrong, first, you haven't created an angular app, in order to use angular directives, they have to be contained in an angular app.
Also, this directive is meant to be on the top of the scrollable container, I've updated your fiddle so it works.
https://jsfiddle.net/5ak4udgb/60/

Ahh ok thanks for the help. I didn't realize this is not the type of sticky header I needed. I thought the scroll-stop would allow it to start sticking once scrolling to a defined pixel value. So if I have a page header in my layout, and then a sticky panel under it, the sticky panel would not 'stick' until scrolling past the page header.

Currently it does not do that, it could however be implemented relatively
easily.  I'd be happy to accept the pull request if you want to implement
it.
On May 21, 2015 2:43 PM, "chrisjmartini"<EMAIL_ADDRESS>wrote:

Ahh ok thanks for the help. I didn't realize this is not the type of
sticky header I needed. I thought the scroll-stop would allow it to start
sticking once scrolling to a defined pixel value. So if I have a page
header in my layout, and then a sticky panel under it, the sticky panel
would not 'stick' until scrolling past the page header.
—
Reply to this email directly or view it on GitHub
https://github.com/FutureStateMobile/sticky-header/issues/17#issuecomment-104415219
.


Allow for cloud login to complete without a browser

Currently the cli assumes that it can open a browser on the user's behalf when running cloud login which almost always not available in CI environments. Unless I'm missing some configuration option, it seems a --open-browser=false flag would be desirable to facilitate CI workflows or other use cases where access to xdg-open or other ways of opening a user's browser is not available.

@rio you can set MCC_CLIENT_ID and MCC_CLIENT_SECRET to override this logic. If those are set it will authenticate on its own.  We run the CLI in the pipeline in the same way.
The credentials can be found on the MC Cloud Dashboard under settings. See https://docs.machcomposer.io/cloud/getting-started.html also

I knew I was missing something ;)
Still, it would be healthy to just print the URL and wait for the auth code if it was unable to open the browser.
I might whip up something but I'm a bit swamped currently.
I'll leave this open for now.

That is fair, if we have no creds set and don't open a browser we should just error out instead. That way at least the user knows what is going on. If you want to take a look feel free, I will otherwise set it on the backlog


Supply Test Data for Standardized Methods

Add dummy data set for each exchange and the implemented standardized methods. These can simply be queries made to the api, dumped as a raw json.
make sure you commit each query call and its response as a separate file.
An example:
let's say you'd like to submit Kraken's Ticker endpoint responses.
for the query at https://api.kraken.com/0/public/Ticker?pair=XXBTZEUR you've got this:
{"error":[],"result":{"XXBTZEUR":{"a":["1104.63000","1","1.000"],"b":["1103.80300","1","1.000"],"c":["1103.79200","0.02650517"],"v":["859.75830107","3612.58175590"],"p":["1103.68713","1108.83109"],"t":[4078,10045],"l":["1095.00000","1092.10000"],"h":["1109.00000","1120.00000"],"o":"1096.99500"}}}

dump this to a file, in raw json, named  bitex/tests/test_data/kraken_ticker_successful.json, and commit this file referencing this issue's number in the commit. A command line example would be like this:
git add bitex/tests/test_data/kraken_ticker_successful.json; git commit -m "#60 Added Kraken Ticker successful call".
If you get an error during a call, we want that too!
Let's say you queried https://api.kraken.com/0/public/Ticker?pair=XXEUR.
This results in {"error":["EQuery:Unknown asset pair"]}. Dump it to a file in the same directory as before and name it kraken_ticker_failed_invalidpair.json - be descriptive with failure messages!
We don't necessarily require each and every single error message for an endpoint - but at least one failure should be added per endpoint nonetheless - it helps us ensure that faulty requests are properly handled for each.
To do list

[ ] Add Bitfinex sample data for all standardized endpoints
[ ] Add Bittrex sample data for all standardized endpoints
[ ] Add Bitstamp sample data for all standardized endpoints
[ ] Add Bter sample data for all standardized endpoints
[ ] Add CCEX sample data for all standardized endpoints
[ ] Add CoinCheck sample data for all standardized endpoints
[ ] Add Cryptopia sample data for all standardized endpoints
[ ] Add GDAX sample data for all standardized endpoints
[ ] Add Gemini sample data for all standardized endpoints
[ ] Add HITBtc sample data for all standardized endpoints
[ ] Add itBit sample data for all standardized endpoints
[ ] Add Kraken sample data for all standardized endpoints
[ ] Add OKCoin sample data for all standardized endpoints
[ ] Add Poloniex sample data for all standardized endpoints
[ ] Add QuadrigaCX sample data for all standardized endpoints
[ ] Add Quoine sample data for all standardized endpoints
[ ] Add The Rock Trading LTD sample data for all standardized endpoints
[ ] Add Vaultoro sample data for all standardized endpoints
[ ] Add Yunbi sample data for all standardized endpoints

With 2.0, this is no longer an issue


CA_BUNDLE and CML_VERIFY_CERT should be converted to bool

There seems to be a bug with the way CA_BUNDLE and CML_VERIFY_CERT are handled, the docstring says:
https://github.com/CiscoDevNet/virl2-client/blob/5bf320f62214c39a5615d19fda9a932f67d332ce/virl2_client/virl2_client.py#L218-L220
For example, with the following .virlrc:
VIRL_HOST=cml-04
VIRL_USERNAME=user
VIRL_PASSWORD=password
CML_VERIFY_CERT=True
CA_BUNDLE=False

I get the following exception:
from virl2_client import ClientLibrary
client = ClientLibrary()
<snip>
OSError: Could not find a suitable TLS CA certificate bundle, invalid path: False

It appears that we get the strings "False" or "True" and they should be converted to a bool, ideally case insensitive.
    138     if ssl_verify is True:
    139         breakpoint()
--> 140         ssl_verify = _get_prop("CA_BUNDLE") or _get_prop("CML_VERIFY_CERT")
    141
    142     return host, username, password, ssl_verify

ipdb> interact
*interactive*
In [1]: _get_prop("CA_BUNDLE") or _get_prop("CML_VERIFY_CERT")
Out[1]: 'False'

In [2]: _get_prop("CA_BUNDLE")
Out[2]: 'False'

In [3]: _get_prop("CML_VERIFY_CERT")
Out[3]: 'True'

In [4]: _get_prop("CA_BUNDLE") or _get_prop("CML_VERIFY_CERT")
Out[4]: 'False'

Do we need two options for setting ssl_verify? I initially thought it was for backward compatibility, but it seems this is a relatively new addition (#40).
My concern is that this could lead to unexpected behavior in certain cases. For example, if a path is set with CA_BUNDLE and CML_VERIFY_CERT is set to False, one might expect ssl_verify will be set to False but CA_BUNDLE takes precedence.
In [6]: _get_prop("CA_BUNDLE") or False
Out[6]: '/tmp/blah'

Note the use of a bool here and not a str
CA_BUNDLE set to True and CML_VERIFY_CERT to a path could also lead to unexpected behavior:
In [7]: True or "/tmp/path"
Out[7]: True

Could we reconsider the need for both options to avoid potential confusion and ensure consistent/simpler behavior?
I understand it might be too late for this, in this case we should probably clarify in the doc.
Maybe not too late for #104 ?

@tmikuska please feel free to close the issue unless you are planning to modify the behavior (i.e. converting "False" to False), thanks again for all the explanations!


Uploading on mobile device needs smaller cloudinary_js

Yeah, My website has used cloudinary for a long time on pc and we paid for better bandwidth.
But we are working on mobile web pages right now which requires image upload function too. And the cloudinary_js requires jquery image upload stuff which is really huge to load.
I am just wondering if you nice guys could supply a version of cloudnary_js supported by zepto.js?

Hi @huanglong, we are using Blueimp File Upload as a reference implementation.
If your mobile web page requires streamlined upload code, I suggest that you use our jquery without upload library and implement a bespoke upload function.

Closing due to time passed

Closing this issue due to the time elapsed. Please feel free to either re-open the issue or contact our support at http://support.cloudinary.com


The Select An App Engine Region dialog reopens once closed

What did you do?
In the App Engine Run/Debug configuration wizard

select a GCP project that does not have an App Engine application
The Region field would show an error message with a link to a dialog to create an App Engine application
Select that link and the Select An App Engine Region dialog would open up
In the  Select An App Engine Region dialog, click the Cancel button

What did you expect to see?
The Select An App Engine Region dialog should close and the  Run/Debug configuration wizard should be in focus
What did you see instead?
The Select An App Engine Region dialog closes and opens again. If you click the "Cancel" button again, it closes and does not reopen

This bugs seems to occur only the first time you open the Run/Debug configuration wizard in an IDE session

that makes it even stranger

Fixed by #1718.


[Bug Report] Datepicker shown in incorrect position

Element UI version
2.0.3
OS/Browsers version
Mac, Chrome last
Vue version
2.5.3
Reproduction Link
https://jsfiddle.net/br7dwh8g/1/
Steps to reproduce

Click on datepicker
Wait picker shown
Close picker
Click toggle
Click on range picker
Wait range shown

What is Expected?
Popper shown after element
What is actually happening?
Popper shown at top left conner of the screen

You need to add keys to them to force a re-render.


Django 1.8: Consider using UUIDField

Django 1.8 introduces UUIDField, which should turn out to be a good choice for cleanerversion's primary keys. However, it's very unclear to me whether there might be migration issues (it should work) and how to maintain compatibility to Django <1.8.

I've started looking into this; it seems like there's a bug in Django at the moment, which made a cleanerversion test fail:
https://code.djangoproject.com/ticket/24912
As for migrations:
A UUIDField on non-PostgreSQL databases is defined as a 32 character CharField; we've currently got it defined as a 36 character CharField (without-hyphen size vs with-hyphen size).  Will have to look into how to do that.

Hm, there is the VERSIONS_USE_UUIDFIELD setting, allowing to use UUIDFields; So, I'm wondering, whether this issue is still of interest?
From my point of view, we can close it, since UUIDFields are productively used with CleanerVersion for some time now.
Opinions? ;)

Since I don't use cleanerversion any more, I don't really care, but I agree that this looks fixed.


Support for editing a single focused feature at any zoom level

Continuing from https://github.com/openstreetmap/iD/issues/2427.
Remaining tasks:

[x] Title/tooltip for focused feature checkbox should be the name of the feature itself (iD.util.displayName)
[x] "Zoom in to edit" button and feature editor should not both appear in the sidebar when zoomed out
[ ] Shouldn't do expensive intersect/filter of features when < minimum editable zoom
[x] Should work with relations

@jfirebaugh Just getting to finish this. I caught up with master. The tests pass in the browser but travis complains about 'simplify' being undefined. Something to do with the way @mourner's Simplify being exported I guess? Thoughts?
cc @aaronlidman

@geohacker it's JSHint complaining, because you reference simplify as a global variable JSHint doesn't know about. You need to add it to JSHint globals config.

Slowly switching from ops to dev mode.

"Zoom in to edit" button and feature editor should not both appear in the sidebar when zoomed out

Can't seem to reproduce this.

Shouldn't do expensive intersect/filter of features when < minimum editable zoom

@jfirebaugh - tell me more please?

Should work with relations

Just checked and seem to work. Any specific edge cases?
cc @aaronlidman

@geohacker -- This feature is not working at all for me right now. I load a page with an object ID in the URL, zoom out, and the feature is hidden along with everything else. Am I missing something or does f17fbf0b516efbab0a2317bbadb8ac4aeb338b56 basically disable this feature?

Shouldn't do expensive intersect/filter of features when < minimum editable zoom

This refers to this line specifically. This deserves benchmarking, but when zoomed very far out I expect this context.intersects(map.extent()) will be expensive and basically return everything that's currently loaded. Which then will turn around and be filtered down to just the focused feature anyway. If profiling confirms my hunch, "drawing zoomed out focused feature" should be a special case in drawVector.

Should work with relations

Try loading https://localhost:3000/#id=r162069

Am I missing something or does f17fbf0 basically disable this feature?

This is true. Sorry. I was a bit confused to see the return of editOff while merging from master. I see that we skipped those commits to keep it clean. To add to the confusion, I completely forgot how this feature worked during < minEditableZoom.
Fixing this right away.

Recapping from chat: main tasks to enabling editing for large feature relations are 1) modify the filter for focused feature to include child members and 2) ensure that the simplification step for large-feature rendering gets applied to the child members.

@jfirebaugh I'm filtering the relation, members and relations that are boundaries when focused. Nodes that make up the relation are being filtered and preserved but ways are not.
Tagging @bhousel here for some help as well -
What we are trying to do - Get relations to work with the "focused" feature, to let people edit large relations. But the member ways doesn't seem to get picked up. Where do you think this should go? Might gathering connections be useful? Thoughts or guidance?

@bhousel ping. Let me know when we can look at this? Thank you!

Hey @geohacker I'm adding a thing called iD.restrictions that will help us write a custom rule to prevent users from editing anything but the focused feature.
WIP on this: 8467433

Ooo that's great @bhousel. Thank you!

@geohacker we need to restart this PR anyway after the iD v2 refactor.  It's a useful idea and we should try to do it.
Per #3681, let's set very clear limits on what people should be allowed to do to large features.

I'm ok with someone editing a single selected feature zoomed to around z10 or z11 or so, but probably no lower.
As long as the features are z11-tile-sized features, no larger.  This is like the size of Manhattan.
I'm ok with people moving nodes if we limit the distance that the nodes can be moved.

Tile sizes for example:

Hi everyone, I'm closing this since it's fallen very far behind. I separately implemented the basic functionality of viewing single selected features at any zoom level: see https://github.com/openstreetmap/iD/issues/5001#issuecomment-510131936. It doesn't cover the full scope of this PR—you can edit the tags but not the geometry—but at this point I think we should move on and create new issues for the other components if needed.
Thanks for all your work on this, sorry it never got merged!


How to insert touchscreen buttons

Hey there,
I want to make my presentation to work on a touchscreen TV.
Now the problem is that I need to insert some sort of arrow keys left/right on the screen which appear all the time (also a key which replaces the ESC function), so that I  won't need to use the keyboard at all.
The normal "swipe"-function doesn't really work, which on tablets/phones/touchscreens,replaces the arrow keys. Some times it zooms in to the slides/steps which are for example in the background (further behind on the Z-axis)
Does somebody have a solution? Will I need to insert those keys with a link to the next slide on everyslide, if I want to replace the right-arrow-key from my keyboard. (i.e. in Step1 a link to step2, in step2 a link to step3...etc.)
or do you know any possibility, maybe some sort of application for Firefox/Chrome where it exists already to have those keys, independently from the programmation of the html/css, in the foreground of my "desktop".
Thanks.

On line 766 of impress.js it says that there are touch event handlers bound to the right and left third of the screen, doing exactly what you want.
Have you checked that out yet?

By default touch events are bound to left and right side of the screen (without any buttons).
So if the touchscreen TV properly triggers touch events it should already work.
In case it doesn't - you don't need to create buttons on every slide.
You should create your buttons somewhere outside the impress root element and position them absolutely. Then you have to bind a function on click on these buttons to call next() or prev() API on impress.

Thank you  very much guys.
Since this time I found a solution similar to the second possibility from Bartaz.
But Yes I haven't seen the line 766, I was always trying to slide for the next step.
Good Work!


refactor(vm): Move event types to VM interface and multivm crates

What ❔
Continuing from https://github.com/matter-labs/zksync-era/pull/2645, this PR moves VM event types to VM interface / implementation crates.
Why ❔
So that types are separated by domain rather than all collected in zksync_types.
Checklist

[x] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[x] Tests for the changes have been added / updated.
[x] Documentation comments have been added / updated.
[x] Code has been formatted via zk fmt and zk lint.

@joonazan I'm not entirely sure what performance degradation of legacy VMs is caused by. I haven't been able to reproduce it locally; there are minor changes in estimated cycles on some benches, but they are order of 0.1%. AFAIU, iai / cachegrind output still depends on architecture-specific factors like binary layout etc., so it could be a reason (evidence that arm64 architecture is better than x86_64 🙃). I suspect that moving types around disabled some previously used optimizations because they would be cross-crate now (which AFAIU, are not always performed unless LTO is enabled).

A difference this small is probably just a random change in compilation. Iai does not correspond 1:1 to real-world performance so it is unclear if it is better or worse.


The FileTransformV2 task does not correctly escape XML values

Required Information
Entering this information will route you directly to the right team and expedite traction.
Type: Bug
Enter Task Name: FileTransformV2
Environment

Server - Azure Pipelines

If using Azure Pipelines, provide the account name, team project name, build definition name/build number:  N/A

Agent - Hosted or Private:

If using Hosted agent, provide agent queue name: Azure Pipelines

Issue Description
The FileTransformV2 task does not correctly escape attribute values when updating an XML file.
If you try to update a settings variable with a value such as "Apples & Oranges" invalid XML will be generated. Values written to XML should be escaped correctly.
Notes
I can't really tell what is going on from reading the code but I suspect that a direct text replacement is being made after a placeholder token of some kind is inserted, instead of manipulating the XML document directly and allowing escaping to take place. This indicates to me that avoiding the correct XML escaping was intended behavior which is troubling. If that is the case perhaps there should be a toggle to allow users to select between normal behavior and corner-case behavior. I feel it would be common for a user to expect XML to be generated correctly as a default and direct text replacement should be an explicit override, that is just my opinion though.
https://github.com/microsoft/azure-pipelines-tasks/blob/12273b195c3477d3bd9eb0d482ee55d7b25c7e99/Tasks/Common/webdeployment-common-v2/xmlvariablesubstitutionutility.ts#L216

Can somebody confirm if this is expected behavior or a bug? Obviously this is going to be a breaking change for any users if you wanted to change the default behavior, so it would be a big deal to change. I am asking because I am curious if I should be making my own task to update XML app.config files.

@aarondandy I cannot reproduce the issue. I am able to successfully substitute a value containing & in my sample xml.
Original Content:

Transformed content:

Can you help me with steps on how to repro the issue.

We used to handle special characters but it was causing issues in case of connectionstring/ other passwords. Hence we removed the support and expect the user to provide escaped value in the variable itself. You can try this as a workaround.
This is duplicate of #12320. Please follow the issue for more info. Closing this as dupe.

I found another related issue (not a dupe) that seems to be the root cause of this problem: #4001

Can we reopen this issue? It should escape special xml characters when doing substitutions in an xml file. We have variables that need to be fed to xml and json files so preescaping a variable doesn't work.


maybeSingle throws exception when no results returned

When using maybeSingle and no results are found the below exception is thrown.  I was under the impression if no rows were found then a null result would be returned.  Am I interpreting the documentation properly?  I noticed the unit tests in the repo only check the condition where a result is returned.
How I'm using it:
var userProfile = await _supabaseClient!.from("user_profiles").select().eq('id', id).maybeSingle();

Exception:
PostgrestException (PostgrestException(message: {"message":"JSON object requested, multiple (or no) rows returned","details":"Results contain 0 rows, application/vnd.pgrst.object+json requires 1 row"}, code: 406, details: Not Acceptable, hint: null))

I am almost sure this is expected. maybeSingle requires at least one row to be returned

What's the difference between single and maybeSingle if that's expected?

Isn't there .single() as well? I thought that would throw and maybeSingle() catches the exception.


🐛 Bug Report: 403 error while registering location in catalog

📜 Description
When registering a new location in the catalog plugin, I encounter a 403 Forbidden error. This issue began after upgrading from backstage version 1.11.0 to 1.15.0-next.1. The configuration for our GitHub integration remains unchanged, including the token and its permissions. Additionally, the catalog configuration remains the same.
Interestingly, when attempting to register a single component referenced in the location YAML, everything works fine.
Location yaml:
apiVersion: backstage.io/v1alpha1
kind: Location
metadata:
  name: ecosystems
  description: A collection of all domains and systems
spec:
  targets:
    - ./domains/*.yaml
    - ./systems/*/*.yaml

Catalog configuration:
catalog:
  import:
    entityFilename: catalog-info.yaml
    pullRequestBranchName: backstage-integration
  rules:
    - allow:
        - Component
        - API
        - Domain
        - System
        - Resource
        - Location
        - User
        - Group
        - Template

  locations:
    - type: url
      target: ${BACKSTAGE_ECOSYSTEMS_GITHUB_PATH}
      rules:
        - allow: [Domain, System, Location]
    - type: url
      target: ${BACKSTAGE_RESOURCES_GITHUB_PATH}
      rules:
        - allow: [Resource, Location]
    - type: url
      target: ${BACKSTAGE_TEMPLATES_GITHUB_PATH}
      rules:
        - allow: [Template]

  providers:
    github:
      superologyApps:
        organization: superology-backend
        filters:
          branch: develop
        catalogPath: "/catalog-info.yaml"
        validateLocationsExist: true
      superbetApps:
        organization: superbet-group
        filters:
          branch: develop
        catalogPath: "/catalog-info.yaml"
        validateLocationsExist: true

I tried playing with configuration, token permissions etc. but nothing worked. While debugging I found that function runSpecialLocationStep to be only difference when registering single component opposed to location component, but I couldn't figure out what is exactly happening.
👍 Expected behavior
Registering location should register all components that are referenced in that location.
👎 Actual Behavior with Screenshots
403 error:
{"error":{"name":"InputError","message":"Error: Unable to read url, Error: Request failed for https://api.github.com/repos/superbet-group/engprod.backstage-ecosystems/commits/master/status?per_page=0, 403 Forbidden, Error: Unable to read url, Error: Request failed for https://api.github.com/repos/superbet-group/engprod.backstage-ecosystems/commits/master/status?per_page=0, 403 Forbidden","stack":"InputError: Error: Unable to read url, Error: Request failed for https://api.github.com/repos/superbet-group/engprod.backstage-ecosystems/commits/master/status?per_page=0, 403 Forbidden, Error: Unable to read url, Error: Request failed for https://api.github.com/repos/superbet-group/engprod.backstage-ecosystems/commits/master/status?per_page=0, 403 Forbidden\n at DefaultLocationService.processEntities (/Users/petarklenovic/Work/engprod.backstage-happening/node_modules/@backstage/plugin-catalog-backend/dist/cjs/CatalogBuilder-99a535c6.cjs.js:1896:15)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async DefaultLocationService.dryRunCreateLocation (/Users/petarklenovic/Work/engprod.backstage-happening/node_modules/@backstage/plugin-catalog-backend/dist/cjs/CatalogBuilder-99a535c6.cjs.js:1927:22)\n at async /Users/petarklenovic/Work/engprod.backstage-happening/node_modules/@backstage/plugin-catalog-backend/dist/cjs/CatalogBuilder-99a535c6.cjs.js:3532:22"},"request":{"method":"POST","url":"/locations?dryRun=true"},"response":{"statusCode":400}}
👟 Reproduction steps

Go to software catalog
Click on "CREATE"
"REGISTER A NEW COMPONENT"
Enter full url to location yaml
Click on "ANALYZE"

📃 Provide the context for the Bug.
The only difference between when this was working and is not is backstage version.  It works fine on version 1.11.0 but I get 403 error on version 1.15.0-next.1.
🖥 Your Environment
OS:   Darwin 22.2.0 - darwin/arm64
node: v18.14.2
yarn: 1.22.19
cli:  0.22.8-next.1 (installed)
backstage:  1.15.0-next.1

Dependencies:
  @backstage/app-defaults                          1.3.1, 1.4.0-next.1
  @backstage/backend-app-api                       0.4.3, 0.4.4-next.1
  @backstage/backend-common                        0.18.5, 0.19.0-next.1
  @backstage/backend-dev-utils                     0.1.1
  @backstage/backend-plugin-api                    0.5.2, 0.5.3-next.1
  @backstage/backend-tasks                         0.5.2, 0.5.3-next.1
  @backstage/catalog-client                        1.4.1, 1.4.2-next.1
  @backstage/catalog-model                         1.3.0, 1.4.0-next.0
  @backstage/cli-common                            0.1.12
  @backstage/cli-node                              0.1.0, 0.1.1-next.0
  @backstage/cli                                   0.22.7, 0.22.8-next.1
  @backstage/config-loader                         1.3.0, 1.3.1-next.1
  @backstage/config                                1.0.7
  @backstage/core-app-api                          1.8.0, 1.8.1-next.0
  @backstage/core-components                       0.12.5, 0.13.1, 0.13.2-next.1
  @backstage/core-plugin-api                       1.5.1, 1.5.2-next.0
  @backstage/dev-utils                             1.0.15
  @backstage/errors                                1.1.5, 1.2.0-next.0
  @backstage/eslint-plugin                         0.1.3
  @backstage/integration-aws-node                  0.1.3, 0.1.4-next.0
  @backstage/integration-react                     1.1.13, 1.1.14-next.1
  @backstage/integration                           1.4.5, 1.5.0-next.0
  @backstage/plugin-api-docs                       0.9.4-next.1
  @backstage/plugin-app-backend                    0.3.46-next.1
  @backstage/plugin-auth-backend                   0.18.4-next.1
  @backstage/plugin-auth-node                      0.2.14, 0.2.15-next.1
  @backstage/plugin-catalog-backend-module-github  0.2.7
  @backstage/plugin-catalog-backend                1.9.1, 1.9.2-next.1
  @backstage/plugin-catalog-common                 1.0.13, 1.0.14-next.0
  @backstage/plugin-catalog-graph                  0.2.31-next.1
  @backstage/plugin-catalog-import                 0.9.9-next.1
  @backstage/plugin-catalog-node                   1.3.6, 1.3.7-next.1
  @backstage/plugin-catalog-react                  1.6.0, 1.7.0-next.1
  @backstage/plugin-catalog                        1.11.1-next.1
  @backstage/plugin-events-node                    0.2.6
  @backstage/plugin-github-actions                 0.6.0-next.1
  @backstage/plugin-org                            0.6.9-next.1
  @backstage/plugin-permission-backend             0.5.20
  @backstage/plugin-permission-common              0.7.5, 0.7.6-next.0
  @backstage/plugin-permission-node                0.7.8, 0.7.9-next.1
  @backstage/plugin-permission-react               0.4.12, 0.4.13-next.0
  @backstage/plugin-proxy-backend                  0.2.40-next.1
  @backstage/plugin-scaffolder-backend             1.15.0-next.1
  @backstage/plugin-scaffolder-common              1.3.0, 1.3.1-next.0
  @backstage/plugin-scaffolder-node                0.1.4-next.1
  @backstage/plugin-scaffolder-react               1.5.0-next.1
  @backstage/plugin-scaffolder                     1.13.2-next.1
  @backstage/plugin-search-backend-module-catalog  0.1.1, 0.1.2-next.1
  @backstage/plugin-search-backend-module-pg       0.5.7-next.1
  @backstage/plugin-search-backend-module-techdocs 0.1.2-next.1
  @backstage/plugin-search-backend-node            1.2.1, 1.2.2-next.1
  @backstage/plugin-search-backend                 1.3.2-next.1
  @backstage/plugin-search-common                  1.2.3, 1.2.4-next.0
  @backstage/plugin-search-react                   1.6.1-next.1
  @backstage/plugin-search                         1.3.1-next.1
  @backstage/plugin-tech-radar                     0.6.5-next.1
  @backstage/plugin-techdocs-backend               1.6.3-next.1
  @backstage/plugin-techdocs-module-addons-contrib 1.0.14-next.1
  @backstage/plugin-techdocs-node                  1.7.2-next.1
  @backstage/plugin-techdocs-react                 1.1.7-next.1
  @backstage/plugin-techdocs                       1.6.3-next.1
  @backstage/plugin-user-settings                  0.7.4-next.1
  @backstage/release-manifests                     0.0.9
  @backstage/test-utils                            1.3.1, 1.4.0-next.1
  @backstage/theme                                 0.2.19, 0.3.0, 0.4.0-next.0
  @backstage/types                                 1.0.2
  @backstage/version-bridge                        1.0.4

👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

Hi @pklenovic, pretty sure this is permission related, you are getting the same error as this issue just in a different place: https://github.com/backstage/backstage/issues/17465
You just need to add the Commit statuses: Read-only to your GitHub App as per: https://backstage.io/docs/integrations/github/github-apps#app-permissions

@awanlin that resolved our issue. We had permission but not the "For anyone else struggling with this, don't forget to have the account owner approve the new permissions after giving it read-only access to the commit statuses (an email should be sent out)." par.
Thanks a lot!

@awanlin do we know why and since when this permission is required? Earlier the entity ingestion worked fine without this permission. The latest doc also doesn't explicit mention that this permission is required for catalog entity ingestion.

@zinizhu, honestly it's be a long time since I've though about this so I might not have all the details but from what I remember there was a new feature added to the UrlReader to get some commit details which needed this permission. The UrlReader is a pretty foundational tool used for interactions across many plugins. I'd say looking back this should probably be moved up in the docs to be under "Reading software components". Feel free to submit a PR to make that adjustment 👍


streaming is not working with titan model (amazon.titan-text-express-v1)

import { userHashedId } from "@/features/auth/helpers";
import { CosmosDBChatMessageHistory } from "@/features/langchain/memory/cosmosdb/cosmosdb";
import { ConversationChain } from "langchain/chains";
import { BufferWindowMemory } from "langchain/memory";
import {
PromptTemplate,
} from "langchain/prompts";
import { Bedrock } from "langchain/llms/bedrock";
import { initAndGuardChatSession } from "../chat-services/chat-thread-service";
import { PromptGPTProps } from "../chat-services/models";
import { transformConversationStyleToTemperature } from "../chat-services/utils";
import { LangChainStream, StreamingTextResponse } from "ai";
const templates: { [key: string]: string } = {
//gpt-4 titan gpt-3.5 claude
"gpt-3.5": `\n\nHuman:The following is a conversation between a human and an AI.
The AI is responsible to answer questions related to cpg,retail,industrial,mathematical,bfsi,analytical,finance,engineering,general knowledge,logical,reasoning,network, security,safety,companies etc.
The AI is talkative, knowledgeable helpful assistant and provides lots of details from all the domains .
The AI should provide information about anything you want.
If the AI does not know the answer to a question, it truthfully says it does not know.

The AI is talkative, knowledgeable helpful assistant and provides lots of details from all the domains .
The AI should provide information about anything you want.
Current conversation  :
{history}
{input}
AI:\n\nAssistant:`
}
export const ChatSimple = async (props: PromptGPTProps) => {
const { stream, handlers } = LangChainStream();
const { lastHumanMessage, id, chatThread, model } =
await initAndGuardChatSession(props);
console.log("model", model);
//const { stream, handlers } = LangChainStream();
const userId = await userHashedId();
const llm = new Bedrock({
model:
model == "gpt-4"
? process.env.BEDROCK_MODEL_TITAN
: process.env.BEDROCK_MODEL_CLAUDE,
region: process.env.BEDROCK_REGION ?? "",
credentials: {
accessKeyId: process.env.BEDROCK_AWS_ACCESS_KEY_ID ?? "",
secretAccessKey: process.env.BEDROCK_AWS_SECRET_ACCESS_KEY ?? "",
},
temperature: transformConversationStyleToTemperature(
chatThread.conversationstyle
),
maxTokens: 800,
streaming: true
//  modelKwargs: getKwargs(model),
});
const memory = new BufferWindowMemory({
k: 100,
returnMessages: true,
memoryKey: "history",
chatHistory: new CosmosDBChatMessageHistory({
sessionId: id,
userId: userId,
}),
});
const chatPrompt = new PromptTemplate({
inputVariables: ["history", "input"],
template: templates[model]
})
const chain = new ConversationChain({
llm,
memory,
prompt: chatPrompt,
verbose: false
});
//const result = await chain.call({ input: lastHumanMessage.content });
chain.call({ input: lastHumanMessage.content }, [handlers]);
// let answer = result["response"];
// return new Response(answer);
return new StreamingTextResponse(stream);
};

Not all models support streaming in multiple chunks unfortunately - I believe Titan is currently one of them. Will leave open for now but can't fix until Bedrock supports it.

Looks like on their docs, titan supports streaming through the invoke-with-response-stream method
https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html

I am also facing same issue. Streaming works fine with claude model but not with titan model. Tried directly using bedrock apis of titan streaming works fine.


Add STM_domain.stress_test_par test

This is something that I found myself wanting for testing the concurrency-sensitive module Stdlib.Dynarray. The new function allows to get a more intensively parallel test without much additional effort, which helps to test for parallelism-related crashes.

Thank you for the review, I updated the PR accordingly.

CI summary: All 36 workflows passed :tada:
Thanks again - I'll merge now


PHPLIB-473: Ensure read concern is inherited for transactions

https://jira.mongodb.org/browse/PHPLIB-473

PR was reworked to fix all failing tests. I found a couple of occurences where we still applied readConcern and writeConcern options even when in a transactions, those where fixed.
readPreference is now also no longer inherited when in a transaction. Since using the transaction's read preference has upstream dependencies on libmongoc and the PHP extension, this was extracted to PHPLIB-476. For now we fall back to a primary read preference, as that is the only read preference currently allowed in a transaction.


Orphaned server processes when VS Code client process is killed

I've been trying to figure this out for a while, and I'm running out of ideas. I've read through this related thread: https://github.com/microsoft/vscode/issues/35196
When I start the server from the client, I use a withProgress to monitor the progress. If close the VS Code client window right after the client start process begins, before client.onReady() returns, the server process is left orphaned/running.
    vscode.window.withProgress({
        location: vscode.ProgressLocation.Notification,
        title: "my title",
        cancellable: false
    }, (_progress, _token) => {
        return client.onReady();
    });
    client.start();

My extension's deactivate function looks like this:
function deactivate(): Promise<void> | undefined {
    // ... other unrelated cleanup code
    if (lspClient) {
        return lspClient.stop();
    }
}

I've also made sure not to add the returned disposable from client.start() to the extension context subscriptions as noted in the linked thread.
If I wait for the client to fully start, then close the VS Code window, the server is shutdown fine. The problem is only when VS Code is closed right after the server begins to start. I see in the server logs that shutdown is called in this case, but exit is never called. It seems the VS Code client process is terminated before the response from shutdown is received, therefore exit is never called.
The server's shutdown method isn't doing anything time-consuming. My only other suspicion is that the server's startup functionality causes the incoming shutdown request's processing to be delayed, so while shutdown doesn't take long to return, it may be a while before it's called. I have no proof of this though, just a guess.
Is there anything else I can try from the client's perspective?

There are two things:

VS Code crashes / gets killed: servers need to protect themselves against this. This is why VS Code adds the process id of the process starting the server to the command line. It is also send in the initialize request. That allows a server to monitor the editor process and if it disappears exit gracefully.
the other behavior sounds like a bug.

There are two things:

VS Code crashes / gets killed: servers need to protect themselves against this. This is why VS Code adds the process id of the process starting the server to the command line. It is also send in the initialize request. That allows a server to monitor the editor process and if it disappears exit gracefully.
the other behavior sounds like a bug.

We've noticed this behaviour as well and it leads to orphaned processes. The problem is that the code queues up an exit notification to send, but then closes the connection before the notification is actually sent. I've opened #776 to fix this issue.

Thanks for the fix!


Having problem with formatting ECMAScript 6

Hi, I followed the format demo, it didn`t work pretty good with es6 grammar, eg:
function dealWithPromise() {
  return new Promise((resolve, reject) => {
    getListCount().then(res => {
      totalNum = res;
      console.log('Get count', res);
      if (pageSize * (curPage - 1) > totalNum) {
        curPage = 1;
      }

      return getListData()
    }).then(resolve).catch(reject);
  });
}

when I clicked autoformat button, it showed like this:
function dealWithPromise() {
  return new Promise((resolve, reject) => {
                     getListCount().then(res => {
                                         totalNum = res;
                                         console.log('Get count', res);
  if (pageSize * (curPage - 1) > totalNum) {
    curPage = 1;
  }
  return getListData()
}
  ).then(resolve).catch(reject);
  }
  );
  }

Hi, I followed the format demo, it didn`t work pretty good with es6 grammar, eg:

That's because that feature hasn't been part of CodeMirror since 2012 (note the /2/ in the URL). We're no longer providing it, because it was too much work to maintain. Use a separate code formatter if you need this.

Hi, @marijnh  , How to use a separate code formatter with codemirror?


Loading Files Not Validated

Summary
Any file can be loaded. Even ones that do not exist. They default to a new project layout. I would expect an error message in that case.

For this question to be answered we need to know more about the loading process itself. For .bin and .dat formats, especially .bin, are there any magic characters, specific bytes, data structures etc. that need to be valid? Or is it just waiting for errors to be thrown when trying to parse the level files?
For the legacy .png format, are there any validations we can use? Like colors, size etc.?

Started looking into this.


Mate layer pulls to token authorization

Only allow layer pulls for the repository authorized
by the token provided by the user.
This is not a security vulnerability, but is a hardening to
protect against abuse of a token.
Signed-off-by: Eric Windisch<EMAIL_ADDRESS>

Was sitting in private review for a long while. Looking for more eyes. @NathanMcCauley @diogomonica @dmp42


cmd+example: update with Status server access

Pinging @ellemouton as I can't request a review from her, as she's the author of the PR :)! Would really appreciate if you'd be able to take a quick glance to see that the changes looks good!

Reworded the commit as it now only edits example/index.html.


fix: url parsed cursh should be catched

解决如：http://localhost:8080//
这种 URL 解析会失败的 case。
原因

error 打印日志的时候，引用了 this.url 导致报错

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


Problem taking my debit card

I'm trying to update my pro account payment with a new debit card and it tells me that the number is incorrect.  I've tried using my wife's debit card as well and I'm getting the same error.  Suggestion: implement Paypal payment services.  Please advise as to how to best set up my payments.

Possibly related to #2810?

I think I know what's going on here. @alexoviedo999 can you confirm that the card you're using does not end with ···· 2087? I believe this was an old card, but you're trying to use a new card, but behind the scenes Stripe is never making use of the new details (due to a bug on my side).

This issue has been auto-closed with a commit I just landed, but I'm 99% sure that the update will fix this issue entirely (I hope!).
If you want to give it another go, I believe it'll go through. Let me know how you get on.


osmomath: mutative Dec conversion with variable precision

Part of: #6257
Extends PR: https://github.com/osmosis-labs/osmosis/pull/6261
What is the purpose of the change

Adds mutative DecMut and DecWithPrecisionMut
Modifies assertMutResult of decimalTestSuite to assert comparison between different numerical types (Dec, BigDec, Int, etc)

Testing
One new test added, existing modified
Documentation and Release Note
Changelog added in base of this PR

@pysel please ping me once ready for review!

will be marking this as draft since I just found a bug in this one: since I was scaling all numericals to osmomath.Int's precision (aka smallest possible between all osmomath's numericals), values of Dec and BigDec were truncated. It meant that if we compared Dec{1000000000000000001} (1.<17 zeros>1) with Dec{1000000000000000000} it would pass, since below the hood it compared scaled (aka truncated) big.Ints 1.0 and 1.0.
solution I will go with: scale to BigDec's precision (aka biggest) rather that (U)Int's (aka smallest), so no precision will be lost


Add "to" and "href" props to Avatar component

Description
We should be able to add a link prop to the avatar component. This is especially useful for avatar groups.
When rendering a single avatar, you could just wrap it in a NuxtLink or ULink. But with an AvatarGroup, this is not so easy.
<UAvatarGroup>
  <!-- Avatar classes will be applied to the NuxtLink / <a> tag -->
  <NuxtLink v-for="items in items" :key="item.id" :to="item.path">
    <UAvatar
      :src="item.image.url"
      :alt="item.name"
    />
  </NuxtLink>
</UAvatarGroup>

The cleanest way to handle this, would be to implement it in the Avatar component itself. When using a "to" prop, the Avatar image tag should not be nested in a <span> but an <a>.
<UAvatarGroup>
    <UAvatar
      v-for="items in items"
      :key="item.id"
      :to="item.path"
      :src="item.image.url"
      :alt="item.name"
    />
</UAvatarGroup>

Additional context
No response

Here is how I did it on nuxt.com, you can just put the <NuxtLink> inside the <UAvatar> 😊
https://github.com/nuxt/nuxt.com/blob/main/pages/blog/index.vue#L89

Thanks for the quick reply! Would not have thought this was possible based on the docs, which has nothing on slots. But maybe that's just me.


Android 'elevation' style property causes YellowBox to render behind elements with elevation > 0

Description
Android 'elevation' style property effects the z-index of components. Therefore, even if the YellowBox component is rendered last, it is still hidden by other components with a elevation > 0.  I noticed this when trying to render a persistent bottom bar in my app. The worst part is that the bottom bar displays above the 'dismiss' / 'dismiss all' buttons of the yellow box inspector.
Reproduction
import React, { Component } from 'react';
import {
  AppRegistry,
  StyleSheet,
  Text,
  View
} from 'react-native';

export default class AwesomeProject extends Component {
  render() {
    console.warn('row 1');
    console.warn('row 2');
    console.warn('row 3');
    console.warn('row 4');
    return (
      <View style={styles.container}>
        <Text style={styles.push}>
            Push next view to bottom
        </Text>
        <Text style={styles.hideYellowBox}>
            I hide a yellow box row (and the dismiss button once the yellowbox inspector is opened)
        </Text>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1
  },
  push: {
    flex: 1
  },
  hideYellowBox: {
    flex: 0,
    elevation: 5,
    padding: 10,
    backgroundColor: 'green'
  },
});

AppRegistry.registerComponent('AwesomeProject', () => AwesomeProject);

Solution
https://github.com/facebook/react-native/pull/11777
Give the YellowBox the maximum possible elevation.
Additional Information

React Native version: 0.39
Platform: Android
Operating System: Windows

Ok I've landed the fix. Please re-open if the issue isn't fully resolved!


Code refactoring: apis cleanup

Signed-off-by: Shlomit Koyfman<EMAIL_ADDRESS>This PR replaces definitions used in manager/apis that are not a part of CRDs. Examples:

Error messages
Connection types/formats used in tests/mockups
Names of labels

I'm struggling a bit to understand (1) what problem this is solving, (2) why put all the labels in utils, rather than with their related CRDs?   Utils were meant for things used by multiple components.

I'm struggling a bit to understand (1) what problem this is solving, (2) why put all the labels in utils, rather than with their related CRDs? Utils were meant for things used by multiple components.

When we create a new CRD version, we copy the old one and add required changes. When all constants and helmValues are there, we will need or to remove them from old version or have double values.

FybrikAppUUID was defined in utils, other labels in manager/apis - not very consistent.


Unions 1.2

The existing implementation, guarantees and tradeoffs are described in more detail.
Future directions are outlined.
Few corner cases are permitted (empty unions, union patterns with zero fields and ..).
This RFC also provides documentation necessary for stabilization of the feature.
The "Overview" section can be copy-pasted into the book and "Detailed design" into the reference.
The section about guarantees may be written a bit hastily, I just wanted to submit this today to start stabilization process for Copy unions.
Rendered

Your is_zero example needs to place the whole match into an unsafe block, when only the accesses to U are unsafe.  Is there any way to avoid this?  I suppose you could call safe closures.  Would it make any sense to push the unsafe keyword inside the pattern?  Say maybe:
fn is_zero(v: Value) -> bool {
    match v {
        Value { tag: I, u: U { unsafe i: 0 } } => true,
        Value { tag: F, u: U { unsafe f: 0.0 } } => true,
        _ => false,
    }
}

cc @joshtriplett @retep998

Re the technical details, this is wonderful. I didn't follow the original thread very closely, and had no idea this much static analysis was in the works.
There's a lot of "unions are like structs" phrasing however, which makes me worried. Don't get me wrong, I'm perfectly happy with the current syntax of unions as a intentional legacy homage / enabler of basic "copy-paste" FFI, but I fail to see how the semantics of union are at all like structs, except in that they are both "aggregate things" (and so are enums). To anyone learning Rust before C, I think this would be quite confusing.

This feels... weird, as an RFC. There's a lot of language that makes me feel like it is supposed to be written in a standardese-y sort of way, and then it says stuff like

Reading a fragment f having type T from of a union value u is permitted if and only if the bit pattern of u contains a valid value of type T starting from offset(t) and this value has no uninitialized bits (except for maybe in padding), otherwise such read results in UB. (Note that writes may require reads too if destructor is called.)

which... okay, I get what you're trying to go for here, but it's not well specified at all. I'd much rather go the C++ route of saying you can read the common initial subset, but otherwise you get unspecified behavior.

And I realize most of that is due to the unsafe code guidelines team not having finished very much, but... this feels a bit like overstepping the bounds of guarantees. At most, we should guarantee what C or C++ guarantee, and we may add more guarantees later as part of the unsafe code guidelines team.

And I realize it may have been in the original, but in the cases where the f2 field is active,
unsafe {
    match u {
      MyUnion { f1: 10 } => { println!("ten"); }
      MyUnion { f2 } => { println!("{}", f2); }
    }
}

will always read an invalid member in cases where u = MyUnion { f1 : (not 10) } or u = MyUnion { f2 : (anything) }.

The section "Active fragment and active field" absolutely squicks me out. This is nowhere near the rules that I would write:
There should be one active variant of a union. There are two ways to change the currently active variant;
The general case: u = MyUnion { d: 0 }. This works for all types, including !trivially_destructible types.
A specific case, for trivially destructible types: u.d = 0.
Writes into a non-active variant (like u.a.x = 0; from the proposal) are undefined behavior. (This may be changed later by the unsafe code guidelines team).

Writes into a non-active variant (like u.a.x = 0; from the proposal) are undefined behavior.

If I understand what you mean by that correctly (which I may well not have): making that UB would break well-established use cases for unions.

@joshtriplett If the current active variant is b, then writing into a is UB, unless a is trivially destructible and you write to the whole thing at once. We might slowly ease up on this, but for now, I would rather not. We may add an exception for compatible initial sequences.

Also, this RFC requires an editor to go over the language used. It's unclear and ambiguous in some parts.

@ubsan I agree about the "trivially destructible" part.  However, I think this needs to work:
#![feature(untagged_unions)]

struct X {
    a: u32,
    b: u32,
}

union U {
    full: u64,
    halves: X
}

fn main() {
    let mut value = U { full: 0x0123456789ABCDEF };
    unsafe { value.halves.a = 42; }
    println!("{:#x} {:#x}", unsafe { value.halves.b }, unsafe { value.full });
}

Runnable playground version: https://is.gd/GNHHgL
Rough sketch of what makes that safe: every field impls Copy, none implement Drop, nothing reads padding, and all the types involved are "total" (every possible bit value has a safe interpretation without UB).

@ubsan Both the C and C++ standards allow reading from the "wrong" field of a union as long as the memory contains a valid bit pattern for the type in question.  (Whether it does depends on type representation, which is implementation defined, but that's no different from the case in this RFC.)   There's no good reason for Rust to be stricter than C on the matter, especially given that the feature's main use case is FFI.  The common initial subset rule in C that you allude to is separate, and kind of a mess / not actually implemented by compilers, but has to do with aliasing pointers to the field types in the union, not accesses through the union type itself.  Though even there, I can't imagine a world where the Rust unsafe code guidelines end up forbidding pointer transmutes, given the amount of existing code that relies on them.
Implied destructor calls should be treated no differently from any other call: valid if the memory has a valid bit pattern for the type being destructed.
However, your point about match patterns is well taken.  Also, there is one area where this RFC would make stronger guarantees than C: the effect of writes to union fields on unused bits (i.e. bits that correspond to other fields but not the field in question).  This RFC says they're unaffected; C says they take unspecified values.  It may be worth weakening the guarantee to match C for now.

Sigh, again I have to correct myself about the C++ standard.  It does arguably prohibit reading anything other than the common initial subsequence, a concept it uses in a totally different way from the C standard…  Though IMO only arguably.  In any case, C explicitly allows it, and in practice it's common for code written in both language to depend on it as one of the "blessed" ways to perform bitcasts (the other is memcpy).

@comex I'll be honest, I care very little about C. My interest is in C++.

@joshtriplett mmmmmmmmhhhhheeehghhgiheghe
I can... kinda see how that might be useful, but it at least should be implementation defined. I'm made uncomfortable by it, but I can see the use for things like microsoft's LARGE_INTEGER type.
// note: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383713(v=vs.85).aspx

@ubsan

Therefore, I write from a C++ mindset.

Specifically for people with C++ mindset I wrote the Type punning section and listed examples that should work and should not be UB.

Discussing stuff like compatible initial sequences and other layout compatibility at type level is the dead end IMO.
Of course, it's interesting and provides endless food for language lawyering, but it's not necessary if we have better ownership based aliasing information and don't have to rely on TBAA like C++.
If the piece memory is initialized and contains a valid value of T, then we can read it as T. Simple and intuitive.

@ubsan Put it another way: The main reason not to allow it would be if a compiler can make optimizations based on treating it as UB, which matters if either (a) it can improve performance of Rust code, or (b) Rust may want to use existing compiler backends that bake in those optimizations.  The fact that ~every C++ compiler is also a C compiler, along with the fact that union type punning is common in C++ code too (even if possibly unsanctioned by the standard), strongly suggests that (b) does not apply.  (a) is dubious to start with for a FFI- and low-level-focused feature, and is even less likely given that the C standard is mostly designed to maximize optimization potential (with exceptions that don't apply here).  Further, as I said, allowing type punning through unions pretty clearly seems to be 'easier' than allowing it through pointer transmutes, yet the latter are effectively guaranteed in Rust at this point due to existing code depending on them.
I suppose another reason to forbid it could be to allow sanitizers to complain about it, which could help code that uses unions for general storage purposes (not FFI) and doesn't intentionally type pun.  But for that purpose, accesses of inactive variants should be prohibited altogether, without exceptions for initial common subsequences and such; and such a rule should be possible to opt out of, or more probably should be opt-in.

“Trivial destructible” relies on Copy being mutually exclusive with Drop, but the wording of E0184 is not quite affirmative:

Explicitly implementing both Drop and Copy for a type is currently disallowed. This feature can make some sense in theory, but the current implementation is incorrect and can lead to memory unsafety (see issue #20126), so it has been disabled for now.

All point to that the restriction will be dropped if the implementation is fixed.
I think we should spell out the assumption that Copy means Copy + !Drop in this RFC, or make the restriction E0184 permanent.

Type punning through unions has to be legal enough for stuff like LARGE_INTEGER to work, but beyond that doesn't really matter to me.

@burdges

the whole match into an unsafe block, when only the accesses to U are unsafe. Is there any way to avoid this?

Unsafety in pattern matching, unlike unsafety in expressions, is a new thing (unions are recently implemeted and unsafe borrowing of packed struct fields is still unimplemented) so it doesn't have any conveniences like unsafe blocks.
Maybe it's reasonable to add unsafe blocks to pattern syntax as well, but this is an idea orthogonal to unions. I think it needs to wait though, I'm not sure it will be used often enough to pull its weight, at least for now.

@Mark-Simulacrum

This feels somewhat inconsistent to me. Is there a specific reason for it?

Mostly limitations of current const eval, it cannot reinterpret memory.
Changing this is listed in future directions (the last paragraph).

@kennytm
Yes, I assume Copy -> trivially-destructible -> !Drop. The wording in E0184 is strange (and also pre-1.0).
I believe this property is used in other places for optimization, like skipping drops for collection elements.
I guess unsafe impl Copy is still possible to add in the future if people are ready for ownership surprises, resource leaks and potential UB.

@Ericson2314

There's a lot of "unions are like structs" phrasing

It is surprising how many language language properties are tied to something as "insignificant" like syntax, but unions are indeed mostly like structs, at least specification-wise. The differences are crucial, but they are few.
The idea is to take structs as a baseline and specify the "diff", because everyone knows what structs are and what they do, while unions are a sufficiently advanced topic.

@retep998
LARGE_INTEGER is really demanding actually, it's equivalent to the "History of assignments" example.
Partial assignments to inactive fields, reads from fields layout incompatible with the active fragment, all have to be well defined. The guarantee about not overwriting bits outside of the assigned field (https://github.com/rust-lang/rfcs/pull/1897#discussion_r100723787) should be provided as well.

@comex

Both the C and C++ standards allow reading from the "wrong" field of a union as long as the memory contains a valid bit pattern for the type in question.

This is false. The C standard allows this, but in C++ reading a non-active member of an union is undefined behavior.
For example, @joshtriplett 's halves example would be undefined behavior in C++.

@gnzlbg

It would be interesting to know why C++ makes it undefined behavior

If the example with halves were legal and u32 could coexist at the same address with u64, this code would be well defined and printed a: 0 b:<PHONE_NUMBER> forcing C++ compilers to abandon strict aliasing and pessimize code unrelated to unions.
#include <cstdint>
#include <iostream>

union U {
    uint64_t full;
    uint32_t halves[2];
};

void __attribute__ ((noinline)) f(uint64_t& arg_a, uint32_t& arg_b) {
    auto a = arg_a;
    arg_a = ~0;
    auto b = arg_b;
    std::cout << "a: " << a << " b: " << b << "\n";
}

int main() {
    U u = { .full = 0 };
    f(u.full, u.halves[0]);
}

GCC, for example, makes use of strict aliasing as expected and prints a: 0 b: 0 when optimizations are enabled (http://coliru.stacked-crooked.com/a/380b17badc7d206a).
Even in C type punning through unions is allowed only if the fields are directly accessed and no pointers are involved.
In Rust if you have fn f(a: &mut T, b: &mut U), then a and b are guaranteed to not alias regardless of T and U as a consequence of ownership rules.

Can we disallow taking a reference to union fields? Would that be too constricting?

@archshift Yes, that would be too constricting.  If you have a C-style struct-of-union-of-structs, where the top-level struct contains a discriminant that you can manually check in unsafe code, then as part of wrapping that in safe code, you want to match on the discriminant and then provide safe code with a reference to the correct variant.

@petrochenkov Please consider an alternate solution when C/C++ unions are implemented in Rust as a library.
Assuming that Rust has additional type traits for tuples (tuple split, tuple cons, check if tuple has one element), and for type pairs (if two types are the same, if size of one type is less than another, if alignment of one type is less than another), it seems that C/C++ unions are a variation of Rust Cell that allow different types for the interior value.
The gist at https://gist.github.com/pkou/5697682ad4cc17f4392e6e7e3301c3ff demonstrates the idea in Rust pseudo code.
It is worth noticing that this idea can be implemented in nightly Rust (with some limitations of course). You may play with the proof of concept at https://play.rust-lang.org/?gist=04246784c46147c926038701187eecca&version=nightly&backtrace=0
It would be interesting to know if this is a possible alternate, or if this approach has some drawbacks that have not been taken into account.

@petrochenkov

The differences are crucial, but they are few.

Reading what you have written, unions strike me as no closer semantically to structs as they are to enums.

@pkou
Library solutions were discussed in detail in Unions 1.0 thread https://github.com/rust-lang/rfcs/pull/1444 and ultimately rejected.
Now I consider the matter settled and don't return to that discussion.

@Ericson2314
That's probably because similarities are omitted as uninteresting ("yep, type inference work with unions as usual, etc") and differences are highlighted. What would you suggest to change in the text?

cc me

Hi, i think by the "raw storage" approach, it means users can (unsafely) build and transmute some part of this union into something else, it is actually fulfilled by placement_new, drop_in_place, and transmuting by offset and size, not necessarily within a union (rfc1444) context, but also possible within a [u8] one, or somewhere else.
By the "enum with unknown discriminant" approach, it means user can choose the discriminant under his own control. I believe it is more viable (using a trait marker) to mark this type and allow user to actually choose the discriminant somehow (implement his own discriminant_value if the user wants to, and a must if one of the variants is not trivially destructible). I think the keyword "unsafe enum" would describe it better.

@petrochenkov

PSA: I'm going to update the "Unions 1.2" RFC with one more change affecting FFI-style unions - I'll move safe assignments to trivially-destructible fields of unions from "Future directions" to the RFC proper.

I'm puzzled by this.  I agree that it's sound for the assignment to be safe, but I don't follow how the trivially-destructible-ness of the field being assigned is relevant.  Overwriting a Vec<String> active fragment in a union with an i32 (as this would allow) doesn't feel any more safe than overwriting an i32 active fragment with a Vec<String> (which this wouldn't).
What if, instead, it was "safe assignments to fields in unions with only trivially-destructible fields"?  That still makes the FFI case ergonomic, but removes the odd asymmetry.

@petrochenkov
How do unions behave when you use them like "raw storage":
union Xyz {
    a: Foo,
    b: Bar
}

unsafe fn example() -> Xyz {
    let u: *mut Xyz = malloc();
    memset(u, 0, mem::size_of::<Xyz>());
    *u.offset(42) = 5;
    *u
}

@arielb1
Seems like there are no reasons for unions to differ from structs or enums in this regard.
If some value is constructed through unconventional means (e.g. unsafely from raw bytes), but it's a valid value (for Xyz it means that either Foo or Bar is valid), then it can be used further as usual (or what is the consensus of the unsafe guidelines team currently).

Yeah, I would like it to be that way, as a member of the unsafe guidelines team. C++'s whole object lifetime thing is incredibly confusing and overcomplicated, imo.

In the explanation about referencing most recently referenced field of union, you showed:
union U {
    s: String,
}
impl Copy for U {}

let u1 = U { s: String::new("Hello!") };
let u2 = u1;
drop(u2.s);
let s = u1.s;

Would it not be the case that this would be a compiler error regardless due to the fact that ownership of the union was transferred from u1 to u2 and u1 is no longer usable anyway?

I feel bad about how little attention this has gotten from the lang team so far. Could use some help, so I'm raising the bat signal: @joshtriplett, @whitequark, @solson, @scottmcm, @ixrec, any of you have time to catch up on this thread and summarize the status?

I have absolutely no experience with anything FFI-related or union-related, but here goes nothing...
With regards to making type punning legal, the high-level design presented here seems like the correct one. @joshtriplett's and @retep998's comments make it pretty clear that we need to "make unions like LARGE_INTEGER work" for FFI, and that seems to entail exactly the requirements listed by the RFC and no more.
The problems I see are:

This PR also contains so many smaller amendments, and changes so much of the original RFC's text, that I'm honestly not sure what changes are intended and what is meant to be "just cleanup" (e.g., was the union_field_drop lint supposed to get renamed to unions_with_drop_fields?).
The wording and organization of the RFC leaves a lot to be desired. I had to do a lot of back-tracking and double-checking in order to convince myself I understood what it was trying to say, and I'm fairly sure a lot of it could be more clearly written or even removed.

To expand on 2 a bit:

The notion of "trivially destructible" appears to only be used when proposing that some union field assignments should be made safe. I think it could be defined in one or two sentences within the same section as that feature.
I strongly suspect I'm missing something here, but all the parts of this RFC that talk about "fragments" seem like they could be rewritten to only talk about active/inactive union fields, and they'd mean the same thing in far fewer words. I couldn't find a place where the notion of an "active fragment" (of arbitrary "depth") seemed useful in specifying the guarantees. I understand that the implementation needs a more complex notion of fragment to deal with unions-in-structs-in-unions, but even the current wording of this RFC explicitly handwaves away much of that, so it's clearly not trying to be a formal specification. If there is a place where we need the notion of "fragments", it needs to be much more obvious, and "fragments" probably need to be defined much closer to it.
There are a number of places where it's not entirely clear whether the RFC is proposing something, suggesting something we might do in the future but isn't proposing yet, or merely describing something that we're unlikely to ever do.
I'm not even sure the wording is up to date anymore, since a) the line "All accesses to union fields (both reads and writes, and also borrows) require unsafe blocks" seems to be contradicted both by the proposal later in the RFC to make some of them safe and by the recent comments on https://github.com/rust-lang/rfcs/issues/2095 b) There's a reference to NoDrop which I'm guessing is an old name for ManuallyDrop? c) we just stabilized a subset of unions, so the original PR comment that "This RFC also provides documentation necessary for stabilization of the feature." seems no longer correct?
In general I agree with the comments that a lot of the wording is too "standardese-y" (i.e. hard to follow in a way that doesn't necessarily make it more precise) and some of it seems to be trying to specify things better left to the unsafe code guidelines project.

Currently, I think the type punning issue would be better off as its own self-contained RFC. In particular, the "Requirements and desirable properties" section of this PR is really good, but the fact that it's 2/3rds of the way down means that a lot of the RFC feels unmotivated or doesn't make much sense until you get there. I'd rather see an RFC where "Motivation" describes the LARGE_INTEGER use case, then "Guide-Level Explanation" is mostly the same text as "Requirements and desirable properties", then "Reference-Level Explanation" lists exactly the requirements/guarantees we're adding to support these use cases and nothing else. Right now I think I know what those requirements are, but I'm not entirely sure because they're scattered throughout the RFC, and I'm not at all clear on whether they're supposed to apply to all unions or just #[repr(C)] unions.
If we do that, the smaller changes like allowing empty unions, .. syntax, making trivially-destructible assignments safe, the clarification that any union field becoming (un)initialized makes all sibling fields (un)initialized, and the clarification that dynamically-sized types are not allowed in unions (those are all the smaller changes in this PR I'm confident are intentional) seem like they'd only be a few dozen lines in total, so we can probably handle that all of that as a single amendment. As far as I know, the only objection to any of them is the semver compatibility hazard pointed out on the union tracking issue, which seems like something we can hash out here.

Smaller questions, some of which may become irrelevant if we do break this up:

This was in the original unions RFC, but the examples in the pattern matching section don't make any sense to me either. The first example seems like guaranteed UB unless the second match arm is dead code. The second example seems like guaranteed UB unless we provide some kind of "short-circuiting" guarantee that we do not attempt to read the union part of the pattern until the tag has been read and compared (do patterns already have these guarantees? does this make UB-ness of patterns depend on whether you write the tag field first or last?)

Is defining the term "layout-compatible" as "whatever C does" good enough for FFI purposes?

What's the motivation for allowing empty unions? I've got nothing against it, but it seems weird to add it without at least saying "this makes macros simpler" or something.

I'm also confused by the wording about deriving Eq without PartialEq. I thought that was a logical contradiction?

@aturon

I feel bad about how little attention this has gotten from the lang team so far.

I feel bad about how little attention this RFC has gotten from me in the recent months. I still need to incorporate the feedback given so far and address unresolved questions.

@petrochenkov Honestly, I do feel like the feedback about this feeling like a full rewrite in a way that makes it hard to compare to the original is accurate. It's difficult to walk through this RFC and figure out what has changed, what is the same but clarified (e.g. things you discovered while implementing, or nuances that came up later), and what is just rewritten/reworded without any clear rationale for doing so.
I feel like those are three independent goals, and doing them all in one giant change/rewrite makes it a challenge to review. I do absolutely think there's value in clarifying/strengthening the specification to match the code; that's one goal. I also think there's value in adding additional union features that haven't yet been implemented; that seems like it should be a separate step, and reviewed separately.

Oh wow, I had no idea there's a discussion about type punning happening for, like, a year now! This is clearly unsafe-code-guidelines related but somehow it didn't appear on my radar, sorry for that.
My two cents: AFAIK, union type punning restrictions in C(++) are closely tied to type-based alias analysis. Essentially, there are two ways to get a "bad" pointer (pointing to data "of the wrong type") In C: Pointer manipulations (like casting or arithmetic), and unions. Both have to be restricted to make type-based alias analysis legal. Rust doesn't (want to) use TBAA, so we shouldn't need any magic type punning rules.
I see type punning as being equivalent to a transmute. The full rules for transmute aren't written down yet, but I feel like standardizing that union type punning does the same thing makes a lot of sense. Given that the unsafe code guidelines team hasn't made a single decision yet, I'm not sure what kind of process we'd go through to see if the entire team can agree on that :D

@RalfJung that seems entirely reasonable to me - although it's more equivalent to transmute_copy.

Closing as postponed. Thanks again @petrochenkov for your extensive work here; we look forward to a revised RFC!


Lexical > Blocks > Labels disappear when zoom level changes in Safari

Describe the Bug.
When changing the browser zoom level the block dropdown stops rendering labels in Safari:

Reproduction Steps

Add lexical editor to Payload
Open Safari
Zoom in our out
Try to add a block

Environment Info
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 9.14.2
Relevant Packages:
  payload: 3.8.0
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10

Oh, sweet Safari! 🫠😆
Fixed in https://github.com/payloadcms/payload/pull/10072, thanks for reporting!


Typo in Sample

The sample:
Get-AzLog -MaxRecord 10
Should read:
Get-AzLog -MaxRecord 1000
Or change the text to read:

The following command retrieves the last 10 events from the activity log

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

ID: 7a61965d-1bdf-b581-71df-28becc9c1d72
Version Independent ID: 2221d554-1d19-5eee-5797-55cdd0c49e86
Content: Azure Monitor PowerShell samples - Azure Monitor
Content Source: articles/azure-monitor/samples/powershell-samples.md
Service: azure-monitor
Sub-service: ****
GitHub Login: @bwren
Microsoft Alias: bwren

@MatthewMcD Thanks for bringing this to our attention. We will review this request with the content owner and update as appropriate.