[Question] How does it work?

ST version: 3208
No automatic trigger, and autocomplete works like 1/10 times.
My settings:
{
	"animation_enabled": true,
	"auto_complete_commit_on_tab": true,
	"auto_complete_with_fields": true,
	"bold_folder_labels": true,
	"caret_extra_bottom": 2,
	"caret_extra_top": 2,
	"caret_extra_width": 1,
	"caret_style": "phase",
	"close_windows_when_empty": false,
	"color_scheme": "Packages/Oceanic Next Italic Color Scheme/Oceanic Next Italic.tmTheme",
	"copy_with_empty_selection": false,
	"default_encoding": "UTF-8",
	"detect_indentation": false,
	"detect_slow_plugins": true,
	"dictionary": "Packages/Language - English/en_GB.dic",
	"drag_text": false,
	"draw_minimap_border": false,
	"draw_white_space": "all",
	"ensure_newline_at_eof_on_save": true,
	"fade_fold_buttons": true,
	"file_exclude_patterns":
	[
		"*.pyc",
		"*.scssc",
		"*.cssc",
		"*.tpl.php",
		".DS_Store",
		"*.tpl.cache.php"
	],
	"findreplace_small": true,
	"folder_exclude_patterns":
	[
		".sass-cache",
		".git",
		"node_modules",
		".bundle"
	],
	"folder_no_icon": false,
	"font_face": "Operator Mono Lig Book",
	"font_options":
	[
		"gray_antialias"
	],
	"font_size": 17,
	"highlight_line": true,
	"highlight_modified_tabs": true,
	"highlight_unicode_color_name": "comment",
	"ignored_packages":
	[
		"Markdown",
		"Vintage"
	],
	"line_padding_bottom": 1,
	"line_padding_top": 1,
	"one_dark_show_scroll_tabs": false,
	"one_dark_show_tabs_dropdown": false,
	"overlay_scroll_bars": "enabled",
	"preview_on_click": false,
	"show_css_completions": false,
	"show_definitions": false,
	"show_encoding": true,
	"show_full_path": true,
	"show_line_endings": true,
	"show_tab_close_buttons": true,
	"sidebar_xsmall": true,
	"status_bar_brighter": true,
	"tab_size": 2,
	"tabs_small": true,
	"theme": "One Dark.sublime-theme",
	"theme_font_options":
	[
		"gray_antialias"
	],
	"translate_tabs_to_spaces": true,
	"tree_animation_enabled": true,
	"trim_trailing_white_space_on_save": true,
	"use_tab_stops": true,
	"word_wrap": true
}

and no special settings for this plugin.

Hi kud.
Did you try following the tutorial  and adopting the settings to your purpose? Per default, the es6 imports work for me quite fine, but it does heavily rely on the current scope, syntax-definitions and trigger configurations.

It seems that https://github.com/TheSpyder/SyncedSideBar breaks insert_path. :)
Disabled it, and now that's better.

I'm not totally sure yet but it seems that there're some troubles with

https://github.com/TheSpyder/SyncedSideBar
https://github.com/ganemone/NodeRequirer

Still investigating.

It's really weird because I've got your autocomplete at first, with a list of files, and just after it says FFP didn't found any file for "" and shows me the classic autocomplete (variables, etc).

If you've got:
import test from ""

and you start autocompletion at between the "", it'll give you sometimes:
FFP	 Completion abort - not a valid context
FFP	 Completion abort - no auto trigger found

https://imgur.com/a/Aql5I1s

Yeah sometimes I've got Not filepath found for which replaces your autocomplete by a classic autocomplete and I've got to retrigger it to get your pluging. Sounds weird.


Fix unintended tool switch when typing

Resolves issue #1
Bug: Pressing the "b" key erroneously activates the build tool when user is attempting to type into a textbox.
Fix: Ignore "b" key presses when typing into <textarea> and <input> elements.

Thanks for the submission @SunnyHuangCodebase sorry I didn't notice it earlier. The "Delete" path also suffers the same problem but I'll merge this now and look into the logic where the handler is applied.

I think CI didn't run because of a setting on this repository. The docs make it sound like I should be able to "Approve and run" but that option doesn't appear. Maybe because I took so long to respond that it's gone?
https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks


Only keep int or uint constants for namespaced compilation

When creating modified solc input for extracting namespaced storage layout, we remove variable declarations where possible to prevent them from referencing other nodes (such as functions which we have deleted).
By "removing", we don't really delete the actual variables, but only convert them to dummy enums to avoid orphaning any preceding NatSpec comments.
However, we want to avoid converting certain constants to enums in case the constants are used in a struct, for example to allow this example to work:
int8 constant MAX_SIZE_C = 2;

contract StructArrayUsesConstant {
  uint16 private constant MAX_SIZE = 10;

  /// @custom:storage-location erc7201:uses.constant
  struct MainStorage {
    uint256 x;
    uint256[MAX_SIZE] y;
    uint256[MAX_SIZE_C] c;
  }
}

But aside from the above scenario, we want to remove other constants such as the ones in https://github.com/OpenZeppelin/openzeppelin-upgrades/issues/1045
This PR changes the modifed solc input to only keep constants that have type uint* or int*, but converts all other constant types and all non-constant variable declarations to dummy enums.
Fixes #1045

Here is some code that will present an issue with this logic:
address constant a = address(0);
uint constant c = uint160(a);

This would be fixed by removing the restriction to int or uint types so that all constants are passed through. Are we aware of issues that that could cause?
For constant variables Solidity seems to accept the subset of expressions that only reference other constant variables and that don't invoke user functions (not even pure ones). So it seems to me that it should be fine to let them through. That said, I wouldn't be surprised if this restriction is relaxed at some point and then the strategy would need to be revised, but I don't see that happening soon.

@frangio Constants can also reference function selectors, such as:
bytes4 constant CONSTANT_USING_SELECTOR = MyContract.myFunction.selector;

And since we delete functions, this reference would be broken.  Perhaps instead of deleting functions, we can consider replacing them with dummy functions so that their selectors can still be referenced.

Perhaps instead of deleting functions, we can consider replacing them with dummy functions

Or just erasing the body, is that what you had in mind? Yes I think this can work. I don't recall if we had tried this.

Updated to reconstruct an empty function and keep all constants, but reconstructing the function does not look like the right approach.  Will simplify it further to just keep the existing function and remove body and modifiers as suggested above.

keep the existing function and remove body and modifiers

I think there are two options. 1) Remove the bodies entirely so as to leave functions unimplemented, add virtual to all functions and abstract to all contracts. 2) Leave empty bodies, but to avoid compiler errors from uninitialized return values also remove all return types (returns (...)).

Here's an example that fails to compile with empty body:
contract A {
    struct S { uint x; }
    function foo(S calldata s) internal pure returns (S calldata) {
        return s;
    }
}

The key issue is that a calldata pointer can't be default-initialized.

@frangio Ready for re-review. We can't use virtual since free functions can't be virtual. Also can't completely remove return types since the returns statement in returns (...) does not appear to be a node in Solidity's AST. So we replace return types with (bool) which can be default-initialized.


The updater fails - "An error occured trying to install this [0.59.0] update." - and "Try again to download & install" fails.

Microsoft PowerToys version
0.59.0
Running as admin

[ ] Yes

Area(s) with issue?
Installer
Steps to reproduce
Install 0.59.0 update.
Get:

Click "Try again to download & install" which immediately fails
PowerToysReport_2022-06-08-14-13-13.zip
.
✔ Expected Behavior
The updater to work.
The "try again" to update to work, if the update fails.
❌ Actual Behavior
The updater fails.
The "try again" to update fails.
Other Software
Win11 Home 21H2 22000.708

I just tried running the stand-alone 0.59.0 installer to uninstall - that worked - and to then reinstall.
But reinstalling left me with the same issues as above, fixing nothing, I'm sad to say :-(

Looks like https://github.com/microsoft/PowerToys/issues/18652#issuecomment-1149100576
Does that help @Wizardling ?
@yuyoyuppe , is there someway we can prevent this, like checking current version to clear out the wrong state that seems to get stuck?

Looks like #18652 (comment) Does that help @Wizardling ?
@yuyoyuppe , is there someway we can prevent this, like checking current version to clear out the wrong state that seems to get stuck?

That sorted it, for now anyway. Thanks.

This was fixed with a hotfix with 0.59.1.  https://aka.ms/installpowertoys


Update Composer dependencies (2021-09-28-21-13)

Created multidev environment pr-6 for circleci-orb-demo-d82.

Visual regression test passed!
View the visual regression test report


Error code 218: No such handle in method keybase.1...

Opened keybase to this error: Error code 218: No such handle in method keybase.1.SimpleFS.simpleFSWait
Seems like something has gone wrong with displaying the file system information. I can still access the files via Finder once they've been decrypted, but I find it concerning. Running OSX High Sierra screenshot below

Can you run keybase log send?
Cc: @jzila / @songgao

Yes, sent. Do you need the log id?

It's here: 5c47e4758c7553a17222961c.  We'll take a look, thanks!

Whoa first Files bug! Looking ...

Looks like somehow the app didn't fully restart. The frontend is running the new version, but the service and KBFS daemons are still from April. @ACBullen would you mind try quiting the app and try again? After the app is quit, please do ps aux | grep -ie 'keybase\|kbfs' in command line and see if there's any Keybase processes hanging around.

In fact, if you haven't done it, would you mind sharing the output of ps aux | grep -ie 'keybase\|kbfs' before quiting the app?

I shut things down and then restarted the application, but the error still appears. Grabbed output from this time:
root             28125   0.0  0.7 558499876 122188   ??  S    10:53AM   0:00.54 /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/8051E64E-9B53-4FFF-A279-73F686F5B601-1586-0000557C1B36D644/keybase-redirector /keybase
alexb            22914   0.0  1.3 558546424 213032   ??  S    Fri07PM   0:41.91 /Applications/Keybase.app/Contents/SharedSupport/bin/kbfs -debug -log-file=/Users/alexb/Library/Logs/keybase.kbfs.log -runtime-dir=/Users/alexb/Library/Caches/Keybase /Volumes/Keybase (alexb)
root              1586   0.0  0.0  4381092   3688   ??  Ss   Wed07PM   0:00.76 /Library/PrivilegedHelperTools/keybase.Helper
alexb            35239   0.0  0.0  4276984    924 s002  S+   11:51AM   0:00.00 grep keybase\|kbfs
alexb            35195   0.0  1.2 558514120 200552   ??  S    11:48AM   0:01.86 /Applications/Keybase.app/Contents/SharedSupport/bin/kbfs -debug -log-file=/Users/alexb/Library/Logs/keybase.kbfs.log -runtime-dir=/Users/alexb/Library/Caches/Keybase /Volumes/Keybase (alexb)
alexb            35118   0.0  0.5 558576464  86336   ??  S    11:48AM   0:00.96 /Applications/Keybase.app/Contents/SharedSupport/bin/keybase -d --log-file=/Users/alexb/Library/Logs/keybase.service.log service
alexb            35042   0.0  0.1 558468196   8832   ??  S    11:47AM   0:00.02 /Applications/Keybase.app/Contents/SharedSupport/bin/updater -path-to-keybase=/Applications/Keybase.app/Contents/SharedSupport/bin/keybase

Looks like there's a stranded kbfs process from Friday. Could you please do kill -ABRT 22914, then do another log send?

Did and sent. Keybase has booted up without error. Thanks for the assistance! For future reference, should I be deliberately closing out and shutting down keybase to avoid this kind of thing, or is this a kind of fluke edge case which the app should normally be able to deal with when updating?

Thanks Alex! You shouldn't have to do this every time. The updater is designed to take care of restarting all processes.

Awesome, thanks for the quick responses and take care.


[W6.1d][F11-B1]Se Hyun Park

@sofarsophie Some comments added. Please close the PR after reading comments.


Expose symbol locs in JSON output

Motivation
We can leverage Sorbet's LSP to generate documentation, potentially. This PR unblocks a potential avenue for that.
Test plan
I'll benchmark the Stripe script method that uses the symbol table and make sure there aren't any perf differences

done, @jez!

Two warm up runs, then averaged the next 5 runs on that internal script:
e2d57adc4f009575697cdada21b08a83b8cf946c: 867.09s
c56e938bea7894fa74a45f46fae09bf5c8c4ef3d: (running)

@jez it looks like this change does in fact slow down the full-symbol-table in JSON. However, I think that given this script isn't run super often AFAIK, this is an acceptable tradeoff. Thoughts?

I'm going to close this out for now. Please reopen when you have time to pick it back up.


Windows/Linux/MacOS/Web support

I am trying to compile an application for Windows. When running with debugging, I get the following error:

If I run it without debugging, the application starts, but the device list is empty.

Because internal flutter_reactive_ble library  https://github.com/vovagorodok/ble_ota_app?tab=readme-ov-file#bleota  supports only Android and iOS for this moment.
I'll think about this in future, perhaps by adding additional support of BLE libraries bluetooth_low_energy and flutter_web_bluetooth libraries

Initial implementation: https://github.com/vovagorodok/ble_ota_app/pull/20

Merged with support of couple of library from: https://fluttergems.dev/bluetooth-nfc-beacon/


Update swoole extension to 4.5.5

is it possible to update swoole extension to 4.5.5?
Thank :)

It's on my to-do list. Feel free to bump the version and open a pull request.


Targets list closes itself shortly after a completed build.

This comes up a lot when I have two build targets that I need to run.

ctrl-alt-t, build anything
ctrl-alt-t again within about a second of it finishing
targets list closes immediately.

Confirmed on Atom Beta
.atom-build.cson:
name: "sleep"
cmd: "sleep"
sh: true
args: [ "5" ]

Steps to reproduce:

Run build with CTRL-ALT-T,  CTRL-ALT-T + Enter, or F9
Open dialog with CTRL-ALT-T
Wait for build to be done
Dialog closes

Versions:
atom-build: 0.53.0
$ atom-beta --version
1.5.0-beta0
$ uname -a
Linux 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 GNU/Linux

I think this is when the panel closes closes it closes all panels. Definitely worth looking into to see if this can be fixed, but I think it is atom that does it when a panel (BuildView is closed).

I found the reason for this. It's actually when atom.views.getView(atom.workspace).focus(); is called when detaching the build panel after a successful build. It makes sense that it closes the targets view at this point - but unfortunate behavior in OPs described use case.
We reset the focus to the workspace because we "steal" it when opening the build panel (so that Esc can be pressed to terminate the build).
I'm thinking the best solution to this would be to only focus the workspace if this (i.e. the build panel) is in focus right now. Otherwise the user has made some other focus selection and we should honor that.

Easier than I though. Feel free to checkout #333 if you wanna test it before the next release.


[DRAFT] Add basic support for IDF Component Registry API client

Since 5.0, some components like mDNS are distributed separately from IDF. I've been exploring approaches to how this can be resolved and am looking for feedback on the general approach before I do more work here. An alternative solution would be to simply use the Python component manager bundled with the IDF build system, but I found that to be more challenging to integrate into the build, than writing one in Rust.
A proof of concept of the Cargo component manager client and download manager is included here in embuild and the integration into the Cargo driver is here: https://github.com/esp-rs/esp-idf-sys/pull/220.
This works for building a project depending on mDNS if ESP_IDF_COMP_MDNS_ENABLED is set in esp-idf-sys and the following is added to the project's Cargo.toml:
[[package.metadata.esp-idf-sys.extra_components]]
component_refs = [ { name = "espressif/mdns", version = "1.2" } ]

This is my first dive into the innards of the build system, so any guidance will be greatly appreciated. I have a lot more questions if the approach is considered sound.

@ivmarkov, perhaps you have thoughts on this?

In general, I think you need the feedback of @N3xed , as he is our expert in the ESP IDF build system.
With that said, and w.r.t. re-using the Python component manager vs re-implementing our own, the latter would make sense only if we expect the component manager not to change every now and then. I have no idea whether that's the case? If you could share your opinion?
I have a few nits w.r.t. Rust code organization that I'll add inline - if you could address.

As I mentioned - a few nits really. Nothing major.

Thanks, I've added some commits and will squash if this moves forward.

With that said, and w.r.t. re-using the Python component manager vs re-implementing our own, the latter would make sense only if we expect the component manager not to change every now and then. I have no idea whether that's the case? If you could share your opinion?

I do not think they will change it as the API seems pretty set. However, there are a few features built into the Python version that would require some more effort. E.g:

Lock-files with version resolution to ensure build reproducibility
Hash / checksums verification
Components can require specific versions of IDF and, transitively, other components.

Most of this should be pretty straightforward to implement (and I can take care of it). I personally find it to be easier to understand the build process when "all" of it is in the Cargo build, but I don't have a very strong opinion about it as long as it works.

Added checks for outdated managed dependencies using idf_component.yml metadata in the component tarballs to make it easier to change version dependencies. This now works well for my "mDNS use case" and a component lock-file for reproducible builds is the only remaining must-have feature I can think of right now.
Great if @N3xed could take a look!

I'm sorry for my inactivity on this issue. I'm all for implementing things in Rust, but I don't think it is worth it for the component manager, or any aspect that is already covered by the esp-idf for that matter. Though I completely understand your reason, as bridging the gap between the Rust and esp-idf cmake world is indeed tricky.

Most of this should be pretty straightforward to implement (and I can take care of it).

It may be straightforward to implement, but it would very much increase the complexity and amount of dependencies to embuild (which already has a good few) and indirectly to esp-idf-sys (as build dependencies). I think, having our own component manager doesn't come exactly cheap.

I personally find it to be easier to understand the build process when "all" of it is in the Cargo build, but I don't have a very strong opinion about it as long as it works.

Everything else of the C/C++ build uses the esp-idf build system though, and it's probably not a good idea to mix the two.
That's my opinion at least. I've been looking into integrating the esp-idf component manager, so that components, that contain an idf_component.yml, just work (see https://github.com/esp-rs/esp-idf-sys/issues/193 for example). I've wanted to do that since a while ago but haven't had the time until now.

Not a problem - I've found this experiment to be very useful way to learn the build system, so no time wasted! Let me know if there's anything I can do to help with the CMake integration.

One way or the other, I believe we do need this easy syntax supported soon-ish, and (obviously) without any patches to esp-idf-sys, as the original post here suggests, as requests for generating bindings (and linking against) components that now live in the ESP IDF Component Registry keep popping up. In other words, this syntax, as suggested by @daggerrz:
[[package.metadata.esp-idf-sys.extra_components]]
component_refs = [ { name = "espressif/mdns", version = "1.2" } ]

Reading the esp-idf-sys post from above, it amounts to adding a few simple changes to the CMakeLists.txt template, and then probably some glue in the esp-idf-sys Rust code so that it can pull the components' names and versions stuff these in the ESP_IDF_COMPONENTS environment variable?
@N3xed - are you saying you have some time to work on this these days? Otherwise, why don't we ask @daggerrz to work on that (if he is willing to, of course)? I don't want this topic to fall into oblivion again, given how important it is. And I'm swamped with other work ATM.

are you saying you have some time to work on this these days? Otherwise, why don't we ask @daggerrz to work on that (if he is willing to, of course)? I don't want this topic to fall into oblivion again, given how important it is. And I'm swamped with other work ATM.

Yes, I've been using https://github.com/esp-rs/esp-idf-sys/issues/193#issuecomment-1636900127 as a starting point, I'll make a PR today.

Reading the esp-idf-sys post from above, it amounts to adding a few simple changes to the CMakeLists.txt template, and then probably some glue in the esp-idf-sys Rust code so that it can pull the components' names and versions and then stuff these in the ESP_IDF_COMPONENTS environment variable?

The integration between Rust and CMake is a bit more tricky though, since we want the lock file in the Rust workspace, and a way to specify dependencies in the Rust side.
As with specifying components in the Cargo.toml, I'll do something similar as @daggerrz suggested.


Publish GCN Notices from VOEvent-formatted files

Description
This PR implements #43, to be able to publish GCN notices from VOEvent files in XML format. In doing this, I had put some thought into how the command line interface was going to look like as we allow more types of messages to be published (and subscribed from) without cluttering the API and hopefully making it a bit intuitive to use.
Here's what I came up with:
scimma publish kafka://hostname:port/notice example1.xml example2.xml

I thought a reasonable thing to do was to make the parsing based on the file extension until we have proper schema validation. VOEvents (which notices are formatted in commonly) reasonably expect to be in XML format and circulars stored on the NASA GCN website have the .gcn3 extension.
I also changed the broker URL to be a positional argument, since it's really required and I think it looks a little cleaner. I also expect once we have a canonical URL we can point to with well-defined topics, someone can drop most of the URL and it'll pick up defaults as needed. Something like:
scimma publish notice example1.xml example2.xml

which when entered, should fill in the default kafka://hostname:port combination expecting to publish to the "notice" topic.
I renamed a few things and edited some comments to reflect the broader nature of publish.py.
Checklist

[x] All new functions and classes are documented and adhere to Google doc style (3.8.3-3.8.6 of this document)
[x] Add/update sphinx documentation with any relevant changes.
[x] Add/update pytest-style tests in /tests, ensuring sufficient code coverage.
[x] make test runs without errors.
[x] make lint doesn't give any warnings.
[x] make format doesn't give any code formatting suggestions.
[x] make doc runs without errors and generated docs render correctly.
[x] Check that CI pipeline run on this PR passes all stages.
[ ] Review signoff by at least one developer.

NOTE: If this PR relates to a release, open and reference an issue with the Release checklist template.

So, first error was due to a new version of pytest released today that seemed to have caused some issues with how fixtures are defined. That was fixed in the second to last commit. I also forgot to actually include the models unit tests during the last PR so I added that in.
This error in the python 3.6 job is strange, and I'll have to investigate this further. My local version of python is 3.7 so I never caught this, but it seems to be some idiosyncratic behavior in one of the unit tests.

Well, I found the python 3.6 issue with the test. Mock open doesn't support reading in chunks, which was fixed for python 3.7+. See https://bugs.python.org/issue31855.
My solution is to just skip the test for this version of python for now, and when we figure out a better way of handling test files down the line, we can remove this condition.

@bfc5288, thanks for the review. Most of the functionality is covered in conftest.py but it would be helpful to not bake in this functionality and use the test files directly. @shereenElSayed has explored this in the slack app using a pytest extension and it'll be good to extend that to the client library as well.


lint: configure luacheck, fix some/most issues

Please feel free to pick it up - I'm likely not having time to finish it anytime soon.


Add ability to fade out videos

I don't see this in the config spec, so I'm guessing it doesn't exist. There isn't a way to fade out a video. In Brooks & Dunn, there are music videos running in each mode, and when the mode ends the videos just abruptly stop. I'd like to see something like the fade_in and fade_out in the sound player.
If this isn't a hackathon thing, maybe there's a workaround?

I assume we just need to add something for audio? Since video fading can happen with the standard widget/slide animations and transitions?

Actually, volume is just a property of a widget, so that should be animate-able. I'll try it now

Using the widget animation with the volume property works like a charm! I'm going to close this.
Here's what I added to the slide to fade out the video. Just the animations: section is new:
slides:
  world_tour_stage:
    widgets:
      - type: video
        video: wt_boot_scoot
        end_behavior: loop
        animations:
          world_tour_fade_out:
            - property: volume
              value: 0
              duration: 2s

Since there was already an event player to stop the mode, I just added another one to start the fade out:
event_player:
  shot_australia_hit:
    world_tour_done|5s
    world_tour_fade_out|3s


Unable to start thunder with Spark 1.4.0

Following the installation instructions here on Github, I downloaded spark-1.4.0-bin-hadoop1 and set SPARK_HOME. I then installed thunder using pip. When I run thunder I get the following error:
(thunder)$ ~ thunder
Exception in thread "main" java.lang.IllegalArgumentException: pyspark does not support any application options.
	at org.apache.spark.launcher.CommandBuilderUtils.checkArgument(CommandBuilderUtils.java:222)
	at org.apache.spark.launcher.SparkSubmitCommandBuilder.buildPySparkShellCommand(SparkSubmitCommandBuilder.java:239)
	at org.apache.spark.launcher.SparkSubmitCommandBuilder.buildCommand(SparkSubmitCommandBuilder.java:113)
	at org.apache.spark.launcher.Main.main(Main.java:74)

Additional information:
(thunder)$ ~ which thunder
/Users/naegelejd/.venvs/thunder/bin/thunder
(thunder)$ ~ echo $SPARK_HOME
/usr/local/spark-1.4.0-bin-hadoop1
(thunder)$ ~ python -V
Python 2.7.10

Ah it looks like this is fixed on the master branch, just waiting for an update to PyPI.

Thanks for the reminder on this! I just pushed a 0.5.1 maintenance release to PyPi including this fix.


Can we hook up the FHIR validator to validate the generated JSON?

This is a feature suggestion...I think it would add value to FSH Online if we could couple in the FHIR validator as an on-demand option.
This would be realized by a button on the RHS (e.g., "Validate JSON").
This would mainly help users who are creating instances to make sure those instances conform to the given profiles.

This is an interesting idea.  We'll have to see if any of the online validators provide an API that we can call (since we don't have our own backend server).


iframe or embed maps not show

thx you project very good . i try for showing embed or iframe from maps google but not work for me
here code
from FletifyHTML.converter import convert_html_to_flet
import flet as ft

html_content = """

Title

This is a paragraph.

    """
flet_code = convert_html_to_flet(html_content)

def main(page: ft.Page):
    page.scroll = "always"

    page.add(flet_code)
    page.update()

ft.app(target=main)

The package, will be fully released within 24 hours from now. The  tag was not supported when you PR, I think it'll be supported when the library will be fully released. Thank you!


Support rcea with independent states

Motivation:

RCEA's now only export the specified mdc's

Modifications:

Allow RequestContextExporterBuilder, RequestContextExporter to accept an extra parameter name
Modify the STATE AttributeKey used in RequestContextExporter to be generated per instance and use name as a distinguisher.
Modify to use logback appender name as RequestContextExporterBuilder.name
Checked that logback doesn't allow null/empty names to be passed (even for 1.2.3)

https://github.com/qos-ch/logback/blob/eb11f4070d4898010679f75d055729000e15fc90/logback-core/src/main/java/ch/qos/logback/core/joran/action/PreconditionValidator.java#L31

Result:

#3769

If exporter1 and exporter2 have the same name, this test seems to fail.
How about appending a unique number to AttributeKey.

Is there a case where a user would want to share the same attribute key? If not, we could remove this method and always make sure each RequestContextExporter has its own attribute key.

At least I can't think of any use cases where users would want to share the same key - updated!


LOD system does not recognize when camera enters AABB (solution provided)

Tested versions
4.x as of https://github.com/godotengine/godot/commit/2d0ee20ff30461b6b10f6fdfba87511a0ebc6642
System information
Any platform
Issue description
In the LOD system:
// Get the LOD support points on the mesh AABB.
Vector3 lod_support_min = inst->transformed_aabb.get_support(p_render_data->scene_data->cam_transform.basis.get_column(Vector3::AXIS_Z));
Vector3 lod_support_max = inst->transformed_aabb.get_support(-p_render_data->scene_data->cam_transform.basis.get_column(Vector3::AXIS_Z));

// Get the distances to those points on the AABB from the camera origin.
float distance_min = (float)p_render_data->scene_data->cam_transform.origin.distance_to(lod_support_min);
float distance_max = (float)p_render_data->scene_data->cam_transform.origin.distance_to(lod_support_max);

Both distances are always positive values, so the condition that checks if camera is inside AABB:
if (distance_min * distance_max < 0.0) {
	//crossing plane
	distance = 0.0;
}

Never triggers.
Video:  https://www.youtube.com/watch?v=j_rp_k5rDPA
Solution
To fix the issue - supplement distance_min with a sign, for example: https://github.com/roalyr/godot-for-3d-open-worlds/commit/afbdb543f6b18a79bd4cc61c597f9604421b042e
Video:  https://www.youtube.com/watch?v=LF21eYlb44Y
I am not opening a PR because I am not sure if this approach is the best.
Steps to reproduce
Set LOD bias to a really low value (0.1) and move camera inside AABB of a mesh, rotate the view.
Minimal reproduction project (MRP)
Irrelevant

Also
} else if (distance_max <= 0.0) {
					distance = -distance_max;

}

needs to be addressed in the same fashion, because distance_max doesn't get negative either.

Also
} else if (distance_max <= 0.0) {
					distance = -distance_max;

}

needs to be addressed in the same fashion, because distance_max doesn't get negative either.
In fact, it is questionable why distance_max is used at all. Why not origin?

Fixed by https://github.com/godotengine/godot/pull/79590


Ondat is migrating, breaking terraform init

Title says it all.
Tried today to setup a new cluster from scratch and can't get the code from the https://github.com/ondat/terraform-eksblueprints-ondat-addon/ repo, but it wont let me :(

Unable to do anything either, is this a Terraform issue with GitHub modules or that this module should not rely on unofficial third party modules?

Good question all around, I think this needs to be digested, @bryantbiggs is working on a fix. The code is sorted just need to merge and get out a new tag

Here's the operative code from alexey's bugfix :
module "aws_eks_blueprints" {
  source             = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/kubernetes-addons?ref=v4.27.0"
  eks_cluster_id     = module.cluster.cluster_id


Popups

I already mentioned the dependency on font-awesome in #788
I recently ran into an issue where I tried to do 2 things, neither of which worked.

Wrap my custom popup (extended from SdkPopup) with Redux's connect in order to bring in an action via mapDispatchToProps.  This resulted in an error:

Wrap the same popup with Apollo-GraphQL's withApollo function (no longer trying to use redux connect). This resulted in an error:

In both cases, such errors are only happening with the Popup component.  All other components in the application work fine with the Redux and Apollo providers.
The Popups example makes use of an undocumented function map.addPopup(), so I checked it out.  Some things I noticed:
Line 1087 of the map component js file has this line:
const elem = document.createElement('div');
Which is direct DOM manipulation, a no-no in React, and I think gets to the crux of my issues.  The content of a popup is being rendering into a DOM that is separate from the rest of the application, and thus why my popup can't recognize the same Apollo provider that the rest of the application does.
After looking at this some, I'm considering trying to implement an alternative to the SdkPopup that uses a React portal instead of creating an openlayers Overlay.  But I'm not really sure how to attach it to the feature coordinates.
Any feedback/suggestions on anything popup related would be appreciated!
Edit: just to be clear, there is a workaround to this, using higher order components and passing things down as props, but technically that's what React Apollo is already, so it feels a little wrong.

yes we are aware of the issue and it was reported before by @milafrerichs who said he could not use material-ui components inside of the popup because the MuiThemeProvider could not be used.
I've also contemplated using portal.
So as I unfortunately cannot provide much guidance, we would be very interested to see what you can come up with.


Hive Metastore Client Cataloging for Delta

Hi guys, we here at CVCCorp have a limitation for Hive cataloging regarding Delta data.
This would be an example of what the cataloging model for data in Delta should look like.
CREATE EXTERNAL TABLE table_teste(
tabela STRING,
data_update STRING,
count BIGINT)
STORED BY 'io.delta.hive.DeltaStorageHandler'
LOCATION 's3://bucket-name/example/table_teste/';
Our motivations in using data in Delta are because we use Databricks and our Benchmark, Delta has better performance.
We also centralized all metadata in a Hive Cluster for integration with Databricks.
Any questions I will be in contact with Lucas on LinkedIn.

Hi @asafepy, thank you for opening this issue!
I see that Hive provides this STORED BY clause in its syntax, but after some diving into the code, I did not find any reference for the "STORED BY" clause in the Hive Metastore objects provided by the Thrift mapping.
My guess: or this is not supported by the Hive Metastore Server yet, or we should apply this clause in some different way.
For example, maybe you could try using the parameter key of the StorageDescriptorBuilder or SerDeInfoBuilder to achieve this (I am not sure it will work though) -  we do something similar for creating external tables (example).

If anyone comes across this issue as well, this is how I was able to create a table that uses delta:
field_schema = ColumnBuilder(name='col',
                             type='array<string>',
                             comment='from deserializer').build()
serde_info = SerDeInfoBuilder(serialization_lib='org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe',
                              parameters={'serialization.format': '1',
                                          'path': 's3a://{data_bucket}/{delta_folder'}).build()
storage_descriptor = StorageDescriptorBuilder(columns=[field_schema],
                                              location='s3a://{schema_bucket}/{db_name}/{table_name}-__PLACEHOLDER__',
                                              input_format='org.apache.hadoop.mapred.SequenceFileInputFormat',
                                              output_format='org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat',
                                              compressed=False,
                                              num_buckets=-1,
                                              serde_info=serde_info,
                                              bucket_cols=[],
                                              sort_cols=[],
                                              parameters={},
                                              #skewedInfo=SkewedInfo(skewedColNames=[],
                                              #                      skewedColValues=[],
                                              #                      skewedColValueLocationMaps={}),
                                              stored_as_sub_directories=False).build()

table = TableBuilder(db_name="{db_name}",
    table_name="{table_name}",
    owner="{owner_name}",
    storage_descriptor=storage_descriptor,
    partition_keys=[],
    parameters={'owner': '{owner_name}',
                'EXTERNAL': 'TRUE',
                'provider': 'delta',
                'spark.sql.sources.schema.part.0': '{"type":"struct","fields":[]}',
                'transient_lastDdlTime': '1642628681',
                'location': 's3a://{data_bucket}/{delta_folder}',
                'spark.sql.partitionProvider': 'catalog',
                'spark.sql.sources.schema.numParts': '1',
                'spark.sql.sources.provider': 'delta',
                'spark.sql.create.version': '3.1.1'},
   table_type='EXTERNAL_TABLE',
   temporary=False,
   rewrite_enabled=False,
   cat_name='hive',
   owner_type=1).build()

client.create_table(table)


feat: the RBAC extension

Fix for https://github.com/janus-idp/backstage-showcase/issues/303

This is merged because all the PRs to the branch were already reviewed.


[Feature Request] 进程判断

Checklist

[X] I searched exising issues and no one else requests similar feature.
[X] I think that 25%+ users are positive towards this feature.

Describe the feature
判断进程，如果存在则显示界面，不存在启动
Additional context
No response

https://blog.csdn.net/qq_43371897/article/details/128443221

https://cloud.tencent.com/developer/ask/sof/61558

https://blog.csdn.net/baidu_41803888/article/details/103364321


Custom Semantic Segmentations Tags

Is it possible to have your own semantic segmentation tags? And can we have more than 12 Tags? How do we have to prepare our Model to be seen as a new class for semantic segmentation?
I think its not very clear from the documentary.

Hi @tapirnaserich,
The current limitation of our semantic segmentation is 255 different tags (excluding the id 0).
You will find these tags here
https://github.com/carla-simulator/carla/blob/67684c5b0d56df1fe9fc54f59b650975afe6b759/Unreal/CarlaUE4/Plugins/Carla/Source/Carla/Game/Tagger.h#L13-L28
As explained in the docs:
Add a new label to the ECityObjectLabel enum in "Tagger.h", and its
corresponding filepath check inside GetLabelByFolderName() function in "Tagger.cpp".

You will need to modify these files and create the folder to store the meshes insithe the unreal engine.


scarab: <IP_ADDRESS> -> <IP_ADDRESS>

Release: https://github.com/fifty-six/Scarab/releases/tag/v<IP_ADDRESS>

Specify NuGet sources (@huantianad)
Update to net 8 (@gepbird)

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/), only tested whether the GUI opens
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 362727

x86_64-linux

:white_check_mark: 1 package built:

scarab

I saw deps.nix got formatted, did they change the output format of the script, or was it intentionally formatted?

I saw deps.nix got formatted, did they change the output format of the script, or was it intentionally formatted?

Yes, they did change it temporarily to make the GitHub check green: https://github.com/NixOS/nixpkgs/pull/361579


App Redirects

A number of apps redirect users to different origins from the origin submitted to app mining. (https://example.com is one origin, https://alice.example.com is a different origin).

Blockstack's security model is origin-based - a different origin is a different app. It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.
Proposal: App developers must submit the origin of the app they wish to review. Redirects to other origins will not be reviewed.

@larrysalibra about this issue, will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time.
Or you consider this as this issue?

App publishers should submit

a url for the landing page and
the app domain.

I agree with @friedger on this one.
Especially with TryMyUI testing, the audience needs to have context of the application use case.  Isn't this pretty standard practice of using the domain/subdomain?
Landing page is a separate repository a static page focused on SEO.
App page is a separate repository specific for the app use case.
What do you think about...
If TryMyUI -- Direct them to the landing page
If Nil -- Direct them to the app page

I agree with @friedger & @kkomaz's proposal as well.

the audience needs to have context of the application use case

This makes sense to me.

will you consider sharing auth between multiple apps? like x.app.com and y.app.com like what Microsoft or Google apps doing so users don't need to sing in every time.
Or you consider this as this issue?

@Walterion1 I know redirects are common in the existing web, I believe this is bad for users because they enter a url thinking they're going to one place and interacting with one domain and then get redirected to some other place entirely outside of their control. Wanting to have two apps accessing the same data seems like a perfect use for collections.

I agree with @friedger & @kkomaz's proposal as well.
I'm having second thoughts about this already.

Why can't you have marketing pages and other pages of an app on the same origin?
How you want to organize your development of the app doesn't seem necessarily connected to how it is presented to the user. It's not hard to do it all on one origin.
If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.
I think this makes more sense in a world where apps are distributed by blockstack names. With blockstack names, alice.example.id and example.id are not assumed to be controlled by the same party. The owner of example.id doesn't have any control over alice.example.id.

Yes, collections are on my waitlist.
So you prefer a mobile app way, every app using the separate set of permissions. I like it, but today users are not a fan as we had some angry emails or even TMUI testers that said: "Why I should sign in again?"
Maybe it needs a learning curve for users.

If a user a user visits example.com and is sold by that site on using the app and clicks the sign in button, they should sign in to example.com, not some other origin.

I think this is the issue of SSR vs. SPA.  SPA is horrible for SEO but great for application development.  SSR/Static is great for landing but can be either too simple or complex depending on the use case of your app.  Thus the separation.

Maybe it could be helpful to just submit a link to the web manifest. The app domain can be deduced from that. (and it would help to reuse the information for theblockstats.com or app-center.openintents.org)

I suggest a dry run to see how many apps this affects and @larrysalibra can you please follow up with specific instructions for how you will test and score.

If an app redirects away from the submitted origin (excluding the redirect to the Blockstack Browser), we'll stop review and provide scores only based on the content and behavior at the submitted app origin.
Example:
App developer submits https://landing.example.com and clicking Sign in with Blockstack sends the user to https://app.example.com. Review will stop when the user navigates away from https://landing.example.com and NIL’s score will be based only on the content that exists at the https://landing.example.com
During the dry run, we'll provide two sets of scores with and without the application of this policy. Only the set of course without the application of this policy will be used in calculating the final score.

It is important that users understand which app they are using and redirecting between multiple origins hurts that goal.

Not a big fan of this proposal.  Not sure how having redirects to the app url hurts the notion above.  Like I mentioned specific to my apps I use the landing page url to give users like PH and TryMyUI a better understanding of what the app does + education.  This is built using Server Side Rendering due to potential SEO gains.
However, the app itself is built using a Single Page Application which is not good for SEO but great for app development and speed.
If anything I propose that app developers are allowed 2 input fields when submitting an app for app mining.
One url for testing nil (app specific url)
One url for TryMyUI (landing page)
There are instances where this could be the same url.
@larrysalibra @jeffdomke

@kkomaz you still can redirect from example.com to example.com/app

Sounds like NIL has the dry run data for this anyhow, we can share that and get more feedback before deciding on next steps.

As we are growing, I have some thoughts to share:
Along with progress as any other young project, it involves rebranding or renaming some parts, products, or changing domain names.
And as the security model is origin-based, we can not ask all the users to rejoin; it cost a lot of trouble, moving data, etc.
So the way I can think of is to land the users to NewOrigin.com, on sign in, redirect her to OldOrigin.com, and after the process is done, go back to the NewOrigin.com.
I think we can not limit the apps to stick to the old address for a lifetime unless we have a feature to change the origin of the apps on a rename or likewise actions. We can have control over this move, but limiting it will limit the growth of apps.

@larrysalibra Could you share the dry run data?

@Walterion1 There is an open issue for data migration (including to new domains) for the Blockstack browser: https://github.com/blockstack/blockstack-browser/issues/1787

I think we can not limit the apps to stick to the old address for a lifetime unless we have a feature to change the origin of the apps on a rename or likewise actions.

I would try to push fixing the browser, then including a temporary rule to app mining.

We’ve seen a number of apps that submit one app origin to app mining and redirect users to one or more origins when the user tries to use the app. Blockstack app security is centered around an app origin - when a user authorizes access to Gaia storage for an app, they’ve giving access to a particular origin.  Redirecting users to different app origins without their permission is dangerous and confuses them as to which app they’re actually using.
We attempted to manually determine how many apps in app mining exhibit this behavior in the past couple months. In October 2019’s app mining session, we conducted a dry run and counted at least 27 apps that redirected users to other app origins besides the one that was submitted to app mining.
We also found that even when a user is proactively looking out for an origin change in the address bar, it was very easy to miss. Put another way, even well-educated users have trouble keeping track of where they are on the web.
We propose that going forward, our review of apps will conclude when the app navigates away from the submitted app origin (excluding any navigation to the Blockstack Browser/authenticator). we recommend this as a policy change instead of a scoring item.
There are two reasons for this. 1) it moves us closer to clearly defining what an app is - an app is some code distributed from a name. Right now that name is the app origin, in the future it will be a Blockstack name. Different name, different app. 2) Trying to treat this as a scoring item make is complicated: Testing manually is very challenging because the tester needs to pay very close attention to what’s in the address bar. Testing it automatically is also challenging because an extension performing the test needs to maintain state across arbitrary app origins and somehow determine that arbitrary collection of apps origins is part of one app.
This policy will take effect in the app review period that begins on December 1, 2019 (November 2019 cohort).

Regardless of how I feel about this, before imposing this new rule you need to make sure app developers are given ample time to be allowed to change the origin.  It seems like 12/1 is a bit aggressive. No email or notification is sent out prior to this change.  Usually @GinaAbrams sends out an email with the change log and should provide a link for app developer to change the desired url.

I'm sorry, I just don't get this. I use apps constantly that have a different origin for their "app". I've never thought that it's a problem if someone uses a subdomain like app.x.com.
But that's my personal opinion on the issue. I definitely think we should not push this change through without giving developers more warning. I just don't think lots of apps will even know that their app will be disqualified.

You should sign-in from the auth domain, not from anywhere else and then arrive at the auth domain.
I think landing pages are still valid and should be used. @larrysalibra Can you clarify this?

In Blockstack, an app is a name. A different name is a different app. Unlike ICANN DNS, Blockstack Name System doesn't have an ownership or control relationship between "subdomains" and parent "domains". Example: larry.id.blockstack is a "subdomain" of both "id" and "blockstack" but it is not controlled or owned by the owner of the id.blockstack name or the creator of the blockstack namespace. This is different than landing.app.example.com. The controller of app.example.com has the power to unilaterally decide what content.

You should sign-in from the auth domain, not from anywhere else and then arrive at the auth domain.

Yes - and you shouldn't navigate away from that name in the process of using the app. If your app navigates away from the name you submit to app mining, it is a different app.

I think landing pages are still valid and should be used. @larrysalibra Can you clarify this?

I don't have a problem with landing pages. If your app is https://app.example.com and you have a bunch of landing pages at https://landing.example.com and https://example.com - this is fine. Submit https://app.example.com to app mining, don't submit https://landing.example.com or https://example.com.

I don't get this @larry. The issue is mainly about SSR vs. SPA and the choice wrt how it effects app's seo, positioning, marketing and complexity of app logic. The choice should be with the developers. When we have plenty of centralized apps that provide much better performance technically, it means we need to work hard to give our users extra context and awareness about the app and SSR helps us in doing so. Having said that many of us choose SPA for the obvious reasons of speed and complexity for the app itself. I don't think forcing developers to choose one over other is a better way forward. If at all you think this is fundamentally against Blockstack ethos, which I strongly differ, the more sensible thing to do is to allow developers submit two different urls and NIL reviews app page. Why should that be a problem?

If app publishers can submit both a landing page url and the auth domain
than there shouldn't be a problem for web apps.
Any comments on mobile apps?
Neha03G<EMAIL_ADDRESS>schrieb am Do., 28. Nov. 2019, 06:39:

I don't get this @larry https://github.com/larry. The issue is mainly
about SSR vs. SPA and the choice wrt how it effects app's seo, positioning,
marketing and complexity of app logic. The choice should be with the
developers. When we have plenty of centralized apps that provide much
better performance technically, it means we need to work hard to give our
users extra context and awareness about the app and SSR helps us in doing
so. Having said that many of us choose SPA for the obvious reasons of speed
and complexity for the app itself. I don't think forcing developers to
choose one over other is a better way forward. If at all you think this is
fundamentally against Blockstack ethos, which I strongly differ, the more
sensible thing to do is to allow developers submit two different urls and
NIL reviews app page. Why should that be a problem?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/blockstack/app-mining/issues/147?email_source=notifications&email_token=AALBYWPBAAWSVXKACVSXAZDQV5KQTA5CNFSM4ITGGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFLQANA#issuecomment-559349812,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALBYWKDANTSOSTPZ3R45QDQV5KQTANCNFSM4ITGGGBQ
.

Any comments on mobile apps?

The origin submitted to app mining that has the link to the ios or android app store should also be the origin that the app uses for sign in.
@friedger do you have any other thoughts about mobile?

@larrysalibra Lately i've submitted dclouds in October to app mining program as https://app.dclouds.online, and the landing page was https://dclouds.online, but the authenticaiton process and the redirection was fine i guess, cuz i was logging in from https://app.dclouds.online, and the redirection takes me back to https://app.dclouds.online,  but i had a bad review in trymyui, cuz people couldn't reach to understand what is the app doing, cuz everything is explained in landing page. So what's your thoughts should a developer do, to go with the right flow, and give the user better quality apps? Should we make the login page has more details and landing page for SEO and marketing things?

I don't have a problem with landing pages. If your app is https://app.example.com and you have a bunch of landing pages at https://landing.example.com and https://example.com - this is fine. Submit https://app.example.com to app mining, don't submit https://landing.example.com or https://example.com.

The origin submitted to app mining that has the link to the ios or android app store should also be the origin that the app uses for sign in.

@larrysalibra Agree on that!

Should we make the login page has more details and landing page for SEO and marketing things?
@uonuon Sounds like a good approach. If in the future app publishers can provide more urls then this approach could be reviewed.


Linking works even when the component being linked hasn't completely started/pushed

/kind bug

What versions of software are you using?

Start backend component with:
$ odo config view --context ~/src/Wild-West-Backend
COMPONENT SETTINGS
------------------------------------------------
PARAMETER         CURRENT_VALUE
Type              java
Application       app
Project           myproject
SourceType        binary
Ref
SourceLocation    target/wildwest-1.0.jar
Ports             8080/TCP,8443/TCP,8778/TCP
Name              backend
MinMemory
MaxMemory
DebugPort
Ignore
MinCPU
MaxCPU

$ odo push
Validation
 ✓  Checking component [14ms]

Configuration changes
 ✓  Initializing component
 ✓  Creating component [82ms]

Pushing to component backend of type binary
 ✓  Checking files for pushing [1ms]
 ◒  Waiting for component to start

The backend component above is still waiting to start but the below frontend component was pushed successfully:
$ odo config view
COMPONENT SETTINGS
------------------------------------------------
PARAMETER         CURRENT_VALUE
Type              nodejs
Application       app
Project           myproject
SourceType        local
Ref
SourceLocation    ./
Ports             8080/TCP
Name              frontend
MinMemory
MaxMemory
DebugPort
Ignore
MinCPU
MaxCPU

Link the frontend component with the backend component:
$ odo link backend --port 8080
 ✓  Component backend has been successfully linked to the component frontend

The below secret environment variables were added to the 'frontend' component:

· COMPONENT_BACKEND_HOST
· COMPONENT_BACKEND_PORT

You can now access the environment variables from within the component pod, for example:
$COMPONENT_BACKEND_HOST is now available as a variable within component frontend

Actual behavior
Linking the components works fine
Expected behavior
I'm not 100% sure. Should the linking work fine when backend component is still in the stage Waiting for component to start?
Any logs, error output, etc?

I'm not 100% sure. Should the linking work fine when backend component is still in the stage Waiting for component to start?

Why do you think that this would be problem if link works correctly?

/triage needs-information

Because there's a chance that the component might fail to start. In our (most) widely used multi-component example (https://github.com/openshift-evangelists/Wild-West-Backend & https://github.com/openshift-evangelists/Wild-West-Frontend), the backend component fails to come up sometimes. This, in turn, causes the frontend component to not function as expected.
While replying this, I was wondering what state does odo show for a component that failed in Waiting for component to start (because I thought that we can use the component's state as reported by odo list as a check for odo link and fail the linking for components that have not been "Pushed"). So I reduced the PushTimeout and did this:
$ odo create nodejs frontend
 ✓  Validating component [686ms]

Please use `odo push` command to create the component with source deployed

$ odo push
Validation
 ✓  Checking component [925ms]

Configuration changes
 ✓  Initializing component
 ✓  Creating component [2s]

Pushing to component frontend of type local
 ✓  Checking files for pushing [1ms]
 ✗  Waiting for component to start [1s]
 ✗  waited 1s but couldn't find running pod matching selector: 'deploymentconfig=frontend-app'

$ odo list
APP     NAME         TYPE       SOURCE        STATE
app     frontend     nodejs     file://./     Pushed

odo shows "Pushed" for a component that failed to start.
I get it that I might be getting into something that's not entirely relevant to this issue but should the component's state be "Pushed" in this scenario?

odo link has two flags that you can use if you want to wait for component to be deployed.
  -w, --wait               If enabled the link will return only when the component is fully running after the link is created
      --wait-for-target    If enabled, the link command will wait for the service to be provisioned (has no effect when linking to a component)

odo shows "Pushed" for a component that failed to start.
I get it that I might be getting into something that's not entirely relevant to this issue but should the component's state be "Pushed" in this scenario?

yes, as it is Pushed. It is supposed to be an indicator if the source code was uploaded to the cluster or not. not if the component is running or not.
Not relevant to this, but it is a good observation. We might want to create more status fields or have more states to reflect other possible stats in which the component can be.

We have more states for a component now. Does it make sense to work on this one? WDYT @kadel @girishramnani ?

Actually, linking soon will work like odo create - odo push. The links will be stored on devfile/env. So I would suggest that once we have that then we can move forward on this.

It looks like this was related to the old style of linking that was done in odo.
Now we are suing SBO and this should not be an issue anymore


move docker back to docker dir

revert #41 (and ensure it works :) ) and also adjust build.yml filters (as the repo name changed)
P.S. after current PRs are merged
P.P.S just in case "why": files at root levels makes it a bit cluttered, and may become more cluttered if more compose scenarios are introduced. E.g. abaplint+nginx+ssl certs

notes:  jq<EMAIL_ADDRESS>-r package-lock.json to extract version from package lock without installing all the deps

agree: should try to have less files at root level

improve todo:

fix run/scripts
add build&run script
add cleanup script
maybe link them to npm scripts (not sure, mixing things) ???

@larshp Are you using docker password or docker token as a secret ? Well, tokens are available now (I think it was not so before) - https://docs.docker.com/docker-hub/access-tokens/

tokens,


puppet: Add PostgreSQL 15 support.

Instead of copying over a mostly-unchanged postgresql.conf, we transition to deploying a conf.d/zulip.conf which contains the only material changes we made to the file, which were previously appended to the end.
While shipping separate while postgresql.conf files for each supported version is useful if there is large variety in supported options between versions, there is not no such variation at current, and the burden of overriding the entire default configuration is that it must be keep up to date wit the package's version.

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

The structural change to do a conf.d sounds great to me; it'll make it much easier for end users to add some extra configuration on top of our own if they please. I think my only other question is whether we need extra documentation adjustments other than the usual changelog entry to advertise that you can add extra postgres configuration by doing X if you're on postgres 15; the answer might be no.

@alexmv I assume you're leaving this as a draft pending further testing of some sort?
I think I'd be happy to include this in -beta2 tomorrow in that I don't think it'll get much passive testing just by being in main.


why i can not load model from llama-2-7b,

the error are as follows:

conver

sorry,i do not know how to conver from pth to bin,can you help me. think you.
the file with postfix pth is obtained from download.sh in llama repo.

@QJShan Can you please try giving full absolute path for the local model copy?

@QJShan
Install HuggingFace Transformers from source
pip install git+https://github.com/huggingface/transformers
cd transformers
python src/transformers/models/llama/convert_llama_weights_to_hf.py
--input_dir /path/to/downloaded/llama/weights --model_size 7B --output_dir models_hf/7B

Can you please try giving full absolute path for the local model copy?

I have tried using absolute paths as follows:

the error is same with above

@QJShan wondering if it would be easier to pick up models from HF, you can checkout this link https://huggingface.co/meta-llama/Llama-2-7b first apply through "Meta" form then request access for HF on the same link. Its fairly quick. This way you dont have to think of conversion.

try to revise the folder name of "llama-2-7b" to "7B"?

@QJShan this seems to be solved as converted weights are already available on the hub, https://huggingface.co/meta-llama

@HamidShojanazeri I saw you can now use llama-2 directly with HF but there is no method to use the downloaded models on your local computer ? I couldn't see any response about this as I'd like to use local weights and not on the hubs (as I'd like my colleagues to also use easily these models)


server2: disable cdc and resolved_ts as they are not fully implemented

What is changed and how it works?

Issue Number: ref #14542
What's Changed:

Disable cdc and resolved_ts as they are not fully implemented

Check List
Tests

Unit test
Integration test

Release note
None

/merge


Enhance go doc comments for RateLimitFilter

Description:
address follow up comments shared in https://github.com/envoyproxy/gateway/pull/706 for enhancing the documentation for the rate limit API

https://github.com/envoyproxy/gateway/commit/4fdbb22e78bcec6c6d17ddeee22868241c29bd3c#r94976226 should be resolved in the PR that fixes this issue.

fixed by #922


Video quality change options

I want to add Video quality change options. Can anyone help me ?

@anwarpro Hello! Can you please provide me with the network URL that you are streaming? If ExoPlayer is able to adjust video quality, such as DASH streaming, the controller will automatically display the UI.

@anwarpro Hello! Can you please provide me with the network URL that you are streaming? If ExoPlayer is able to adjust video quality, such as DASH streaming, the controller will automatically display the UI.
exoplayer only implement audio quality change option.

@anwarpro Hello! Can you please provide me with the network URL that you are streaming? If ExoPlayer is able to adjust video quality, such as DASH streaming, the controller will automatically display the UI.

It's not working only shows audio track change options.
This one I tried. https://storage.googleapis.com/shaka-demo-assets/sintel/dash.mpd

@anwarpro
Could you check the link below?
https://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest
I think the UI to adjust the video quality will be shown while playing via this link.


crypto: Use Base64 and Hex from fastcrypto instead of sui

unfortunately this PR has some trivial changes on map_err from eyre::Report to anyhow. There is an issue here that we want to prefer eyre over anyhow to get backtrace for free, https://github.com/MystenLabs/sui/issues/3895 it is a bit tedious and invasive, that I decide to leave it for a follow up PR after this.

It makes sense to split the conversion anyhow -> eyre separately. Do we have test vectors besides the (happily unbroken) snapshot testing for those values we serialize in config files?

the base64 encoding tests themselves live in fastcrypto https://github.com/MystenLabs/fastcrypto/blob/main/fastcrypto/src/tests/encoding_tests.rs Base64 is how we encode data across the wire, since we already have typescript tests that goes from typescript bytes passing to RPC endpoints, I consider the e2e testing is done as well


Text Not Auto-Sending to All Chats and Display Issues

Issue Description:
Text Not Auto-Sending to All Chats:
The current behavior of the application is that the entered text is not automatically being sent to all chats. Instead, the text is only inserted into the text fields of each individual chatbot. Users are required to manually click the send button for each chat individually in order to send the entered text. This results in a cumbersome and time-consuming process, especially when dealing with multiple chats simultaneously.
Display Issues:
Issue Viewing Content Properly: There seems to be an issue with the way content is displayed within the application. Some users are reporting difficulties in viewing the chat content as it should appear. Messages may be cut off or not fully visible, leading to an incomplete understanding of the conversation.
Inability to Resize or Maximize/Minimize: Users are experiencing problems with resizing the application window. It appears that the application is not allowing them to adjust the window size according to their preference. Additionally, the inability to maximize or minimize the application window further restricts users from managing the application's interface to suit their needs.
Expected Behavior:
Text Auto-Sending: The application should automatically send the entered text to all active chats without requiring users to manually click the send button for each chat. This would significantly improve the efficiency of using the application, especially when engaging in multiple chat conversations.
Proper Content Display: The chat content should be displayed correctly and completely within the application. Users should be able to see the full conversation without any messages being cut off or hidden.
Resizable and Minimize/Maximize Window: Users should have the ability to resize the application window according to their preferences. Additionally, they should be able to maximize or minimize the application window as needed for optimal use of screen space.
Operating System: Windows 10

i dont have a windows machine to test. PR welcome please!


Fix documentation for --caskroom default

As explained in #24888, the documentation is incorrect around the default value of --caskroom

I see you also opened https://github.com/Homebrew/brew/pull/1159, so you might as well delete the whole man page here, as this isn't actually used anymore to generate it.

Thanks!


Failed test 'should duplicate a boundary element'

This now fails, and this is associated with an error when duplicating a boundary in the diagram edit view.
This is a corner case, in practice it is very rare that a boundary is duplicated, but the test is quite rightly picking this up.

Interesting, do you want me to look into that instead?

Yes, thanks - I had a quick look and it may be centred round function duplicateElement()


docs: improve documentation and add #[warn(missing_docs)]

Closes #65

This PR is based on the work of #60. Which can be closed


Improve TypeScript Definitions

Fixes #787.
Fixes #826.
I'm unclear of how the additional parameters for ProcessServerConfigFunction are used exactly, so the jsdoc for those are incomplete. If anyone has any suggestions, happy to add them in.

Hey! Thanks so much.
It looks like only the transfer param comment is missing.
It's basically a way to know/store the current file chunk transfer id so we can track where we're at in the complete file upload.

@rikschennink Would the following suffice as a comment for the transfer parameter, then?

Let Filepond know and store the current file chunk transfer id so it can track the progress of the whole file upload

I think that's fine 👍

@rikschennink Cool, updated the PR branch


Provide an option to print the delomboked source files

This could be a command line flag, e.g. -p, that tells the action it should delombok and print the delomboked code to standard out.
The following command can be used to print the files: find src-delombok -type f -exec cat {} \; (from this sample code)

Not sure it's worth it, but could create a very simple action dedicated to printing the delomboked code, e.g. turning this:
- name: Print the Delomboked code
  run: find src-delombok -type f -exec cat {} \;
  shell: bash

into this:
- name: Print the Delomboked code
  uses<EMAIL_ADDRESS>
The above assumes there is an action named print-delombok with a version v0.1.0. While the find command is simple, it would be annoying to have to repeat that anywhere you want to print the delomboked code.
The print-delombok action must rely on the delomboked code being located in the src-delombok directory, which this action currently hard codes. If we parameterize the output location for the delomboked source code (in this action), then the print-delombok action could also accept that as input, e.g. in a workflow:
- name: Run Delombok
  uses<EMAIL_ADDRESS>  with:
    delombokSourcePath: delombok-source-code

- name: Print the Delomboked code
  uses<EMAIL_ADDRESS>  with:
    delombokSourcePath: delombok-source-code

The delombokSourcePath input variable would need to be added to this action. I think I read in the Actions documentation there is some way to have an action produce output variables, but can't remember and would need to research that.

Here's the documentation on outputs: Defining outputs for jobs


HyperV module detection in docker-machine create command

I was struggling to successfully create a docker-machine using Hyper-V provider. The command would fail with "PowerShell module not found". (Similar to some of the issues in 512.
I think there's a bug somewhere in the code that detects the Hyper-V module.
When running with -D I could see that docker-machine was executing @(Get-Command Get-VM).ModuleName. However, instead of returning the expected "Hyper-V", the command was outputting:
Warning: ssh-agent not found
Hyper-V

I then just added the Git\bin folder to my path (so that the ssh-agent warning wasn't splashed) and the docker-machine create command then started working.

Thanks for the report.  The recommended way to use docker machine on Windows is to install MSYSGIT.  I believe that sets up the paths for you.  Thanks for the feedback in case anyone wants to set it up manually.  Closing.  Thanks!

Ok - but I did try from the bash prompt of Git (which uses MSYSGit as far as I know) and got the same error.


Need to customize where Ghidra puts CParser temporary file (libil2cpp.sh_CParser.out)

By default Ghidra puts in home directory from GUI, puts in working directory for headless. Would prefer in temporary directory.

Script places the file in working directory (see CParserUtils.java in Ghidra source), should be fixable by simply running the Ghidra instances from temporary directory in autoanalyze.sh


Update testing-SFCs-with-jest.md

Rename jest-vue to vue-jest because above we installing npm install --save-dev vue-jest

Thanks 🙂


[Bug] Abstract class SqlmeshAdapter can't be instantiated when trying to start recce server

Current Behavior
This command fails
recce server --sqlmesh --sqlmesh-envs prod:dev
with the following error
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/recce/adapter/sqlmesh_adapter.py", line 90, in load     return cls(context=context, base_env=base_env, curr_env=curr_env)            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: Can't instantiate abstract class SqlmeshAdapter without an implementation for abstract method 'select_nodes'
Expected Behavior
Recce server should run without error.
Steps To Reproduce

Install recce in a virtualenv (3.12.3)
Install sqlmesh[duckdb] in virtualenv
Create prod and dev environments in sqlMesh
Run command above

Relevant log output
(recce) *[main][~/Projects/recce]$ recce server --sqlmesh --sqlmesh-envs prod:dev
────────────────────────────────────────────────────────────────────────────────────────────────────── Recce Server ──────────────────────────────────────────────────────────────────────────────────────────────────────
INFO:     Started server process [86865]
INFO:     Waiting for application startup.
WARNING:  SQLMesh adapter is still in EXPERIMENTAL mode.
ERROR:    Traceback (most recent call last):
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/starlette/routing.py", line 693, in lifespan
    async with self.lifespan_context(app) as maybe_state:
  File "/Users/ssciortino/.pyenv/versions/3.12.3/lib/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/fastapi/routing.py", line 133, in merged_lifespan
    async with original_context(app) as maybe_original_state:
  File "/Users/ssciortino/.pyenv/versions/3.12.3/lib/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/fastapi/routing.py", line 133, in merged_lifespan
    async with original_context(app) as maybe_original_state:
  File "/Users/ssciortino/.pyenv/versions/3.12.3/lib/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/recce/server.py", line 48, in lifespan
    ctx = load_context(**kwargs, state_loader=state_loader)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/recce/core.py", line 247, in load_context
    recce_context = RecceContext.load(**kwargs)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/recce/core.py", line 40, in load
    context.adapter = SqlmeshAdapter.load(**kwargs)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ssciortino/.pyenv/versions/3.12.3/envs/recce/lib/python3.12/site-packages/recce/adapter/sqlmesh_adapter.py", line 90, in load
    return cls(context=context, base_env=base_env, curr_env=curr_env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Can't instantiate abstract class SqlmeshAdapter without an implementation for abstract method 'select_nodes'

ERROR:    Application startup failed. Exiting.

Environment

recce: 0.39.0
OS: MacOS Sequoia 15.0
Python: 3.12.3
Data Warehouse: DuckDb
sqlMesh: 0.130.0

Additional Context
No response

Hello, I've fixed this issue!
This is what I've done:
I've implemented the missing select_nodes method in the SqlmeshAdapter class. This method is required as it's an abstract method in the BaseAdapter class. The implementation returns an empty set as SQLMesh doesn't have a concept of selecting nodes like dbt does. This should resolve the TypeError when instantiating the SqlmeshAdapter.
I also created pull request: https://github.com/DataRecce/recce/pull/474

[!CAUTION]
Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code!

This bug was fixed for free by Latta AI - https://latta.ai/ourmission


doc: releases: 4.0: Add LVGL capture sample to Video

The LVGL pull request was started before v3.7 release but merged after, so needs to be included in v4.0 release notes.
This was an omission in commit 467f31190e6e111edf7ee204ecd3de27c3ff9c9a.

@josuah please stop blaming yourself every time someone is asking you to change something :) you can't always get everything right the first time :)

or the N-th time.  It's part of why we have reviews :-)

Hmm right, no reason to be nervous.


Notice: Undefined variable: remote_user in /var/www/index.php on line 265

I am getting this error in my logs (only this RPi_Cam_Web_Interface is installed there). Having turned the Display Errors on (obviously not in production environment), I see this error displayed just above the preview video.
I looked at the source code, and the relevant block is (right before closing the start of the PHP, and starting the HTML output):
if(stripos($serverSoftware, 'apache') !== false) {
	   $user = apache_getenv("REMOTE_USER");
} else if(stripos($serverSoftware, 'nginx') !== false) {
	   try {
		$user = $remote_user; //<--- Offending line
	   } catch  (Exception $e) {
		$user = '';
	   }
} else {
	   $user = '';
}

I also did a quick look through the code but do not find anything that sets the "$remote_user" variable. Thinking that it may be user based, I created a new basic_auth user (since I did not enable it on install), and still the remote_user variable is not populated.
I am using Nginx for the server, as it handles proxy features on another port.
While I can disable the error display and log, I don't usually like doing so, as notices becomes errors and errors can become fatal errors.

$remote_user is supposed to be a nginx embedded variable when authentication is used. http://nginx.org/en/docs/http/ngx_http_core_module.html
This is also why it is in a try exception clause to catch the exception if not present.
I don't normally use nginx myself so I am not an expert on its config, but I thought I tried out the $remote_user some time back. I'll have to check whether the syntax to access it from php is correct.
You would still get the caught exception without a user. It may be possible to config nginx logging to ignore the caught exception. Maybe catch_workers_output

Maybe it should be
$user = $_SERVER['REMOTE_USER'];
If you have a running nginx system could you try that?

That helped, but in my own research I also found that by default, it seems, nginx does not provide the variable. So in addition to this change, I had to add the following to either the server configuration (inside the /etc/nginx/sites-available, inside the location for PHP files) or the /etc/nginx/fastcgi_params file:
fastcgi_param REMOTE_USER $remote_user;
After this change, Nginx needs to be restarted, to take effect, and then the PHP can find it using the $_SERVER['REMOTE_USER'] as mentioned above.

Thanks. I have changed it to use the $_SERVER['REMOTE_USER'] and the nginx sites-available has the extra parameter added.


Fix type definitions for greater type safety.

Hello!
I'm new to redux-saga and trying it for the first time with TypeScript. I hope this PR is helpful, but please let me know if anything should be changed.
It looks like there are a few issues with the type definitions that keep typescript from making good use of the types to detect user errors (or I'm just missing something).
In particular:

SagaRest is compatible with e.g. Saga1, such that typescript will fall back on it if the argument to a Saga1 to run does not match, thereby not flagging an error.
The same goes for call – the ...args case is not mutually exclusive with the prior cases, so typescript will not flag argument type errors.
Same thing with apply.

This PR addresses the first two cases, but I couldn't figure out a way to resolve apply.
Side note about apply: I suspect it can't be fixed. If that is the case, it's a little surprising to see a static type for apply in a correct case, without any hint that this will not catch errors statically due to the fallback to the any[] case. Perhaps apply should not pretend to type its args and just use any?
Example
I discovered the issue with my very first exploration of redux saga in Typescript:
function foo(x:number) : string {
  return null as any;
}

export function* rootSaga() : SagaIterator {
  const x : string = yield call(foo, 3)
}

Inspecting the type of call to see which type overload was selected, VSCode shows me
(alias) call<number>(fn: ((arg1: number) => any) | [any, (arg1: number) => any] | {
    context: any;
    fn: (arg1: number) => any;
}, arg1: number): CallEffect (+5 overloads)
import call

Great! Just as hoped, it knows that my function takes an argument that my argument is a number.
I then purposefully introduced a type error, by changing argument from a number, to a string:
  const x : string = yield call(foo, 'bar')

Much to my surprise, this did not introduce a type error! The type inferred for call in this case was:
(alias) call(fn: ((...args: any[]) => any) | [any, (...args: any[]) => any] | {
    context: any;
    fn: (...args: any[]) => any;
}, ...args: any[]): CallEffect (+5 overloads)
import call

With the updated definitions in this PR, I get the following type error, as desired:
The type argument for type parameter 'T1' cannot be inferred from the usage. Consider specifying the type arguments explicitly.
  Type argument candidate 'number' is not a valid type argument because it is not a supertype of candidate '"3"'.
(alias) call<T1>(fn: ((arg1: T1) => any) | [any, (arg1: T1) => any] | {
    context: any;

Please have a look at https://github.com/redux-saga/redux-saga/pull/740

Oh, thanks! Looks like my searching was too narrowly focused on call.


Polygons in layergroups disappearing from map bounds

How to reproduce

Leaflet version I'm using: 1.31
Browser (with version) I'm using: Google Chrome 63.0.3239.132, Firefox 58.0.2
OS/Platform (with version) I'm using: W10
I have created a fiddle here: http://jsfiddle.net/nbvhz85a/6/
Create the map
Add a new layergroup to that map.
Add a new polygon to that layergroup.
Now draw the map to wherever and zoom in.
While zoomed in, drag the map a few times in any direction.
Zoom out again and return to the POI.
There's a change that the polygon is not rendering.

Screenshots:

Polygon is drawn outside of map: https://imgur.com/T6sTVWq
Polygon is not drawn at all: https://imgur.com/lZi32pE

What behaviour I'm expecting and which behaviour I'm seeing
We expected that the polygon would still be there. Like the marker icon. Even after zooming and dragging the map.
Now the polygon is not drawn, or is not drawn on the map.
Minimal example reproducing the issue
Please see http://jsfiddle.net/nbvhz85a/6/

Can't reproduce it, can you record a gif?

I've recorded a .gif : https://imgur.com/I7IL2CZ
We have the issue in aprox. 1 in 3 times we try to reproduce

Confirming.
Here is original path:
<path class="leaflet-interactive" stroke="Blue" stroke-opacity="1" stroke-width="1" stroke-linecap="round" stroke-linejoin="round" fill="Blue" fill-opacity="0.2" fill-rule="evenodd" d="M342 200L342 158L300 158L300 200z"></path>

The same after disappearing:
<path class="leaflet-interactive" stroke="Blue" stroke-opacity="1" stroke-width="1" stroke-linecap="round" stroke-linejoin="round" fill="Blue" fill-opacity="0.2" fill-rule="evenodd" d="M0 0"></path>

Ok, I've found culprit:
var polygon = new L.Polygon(poi.Points, { 'weight': '1', 'fillColor': poi.TypeColor, 'color': poi.TypeColor })

Here weight is string, instead of number.
Then we come here: https://github.com/Leaflet/Leaflet/blob/0f904a515879fcd08f69b7f51799ee7f18f23fd8/src/layer/vector/Polygon.js#L124-L129
And see what is happening:
https://github.com/Leaflet/Leaflet/blob/0f904a515879fcd08f69b7f51799ee7f18f23fd8/src/geometry/Point.js#L53-L58
Fix: 7432


Parse '\' and '"' as char literals

Fix #5.  I believe this makes it see all the character literals that are valid in rust.

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


Incorrect side effect ordering in destructuring transform

TypeScript Version: Nightly

Search Terms: side effect ordering destructuring transform lowering spread rest binding pattern
Code
I recently implemented object rest properties for esbuild, a new TypeScript transpiler. When doing this I noticed several bugs with TypeScript's destructuring transform.
These bugs were identified by a fuzzer for JavaScript destructuring that I wrote while developing the transform code for esbuild. The fuzzer generates random test cases and compares the execution of the transpiled code with the execution of the original JavaScript. You can see example output from the fuzzer here.
This issue is for tracking bugs where expressions with side effects are accidentally reordered. There may be more than one individual bug in this class of bugs, and the fuzzer could be a good tool for finding them all.
Here's an example ordering issue:
let trace = []
let order = n => trace.push(n)
let [{ [order(1)]: x } = order(0)] = []
console.log(trace)

Expected behavior:
This should always print [0, 1]. Default values must always be evaluated before computed property keys.
Actual behavior:
The TypeScript transpiler generates code that correctly prints [0, 1] when targeting ES6 and above but generates code that incorrectly prints [1, 0] when targeting ES5 and below.
Playground Link: link
Related Issues:
This ordering issue can also come up when targeting ES6, although the reproduction is a little more complicated:
let trace = []
let order = n => trace.push(n)
let { [order(0)]: { [order(2)]: y } = order(1), ...z } = {}
console.log(trace)

This prints [0, 1, 2] when run natively and prints [0, 2, 1] when transpiled with TypeScript targeting ES6.
Another ordering bug was mentioned in #39181:
var [{ ...a }, b = a] = [{ x: 1 }]
console.log(b.x === 1) // true

This should print true but crashes with Uncaught TypeError: Cannot read property 'x' of undefined when transpiled with TypeScript targeting ES6.
As I mentioned above, there may also be more ordering bugs like this depending on if these all have the same root cause or not. Hopefully the fuzzer will be a useful tool for getting to the bottom of these bugs.

@evanw is correct. Per https://tc39.es/ecma262/#_ref_12742, step 4 evaluates the Initializer and step 6 performs evaluation of the destructured object. I'm looking into our emit here.


[BUG] The Spring Key Vault integration (spring-cloud-azure-starter-keyvault-secrets) does not work with local test doubles

Describe the bug
The Spring Key Vault integration (spring-cloud-azure-starter-keyvault-secrets) does not work with local test doubles because the disableChallengeResourceVerification option is not configurable.
Exception or Stack Trace
Add the exception log and stack trace if available
java.lang.IllegalStateException: Failed to configure KeyVault property source
	at com.azure.spring.cloud.autoconfigure.implementation.keyvault.environment.KeyVaultEnvironmentPostProcessor.buildKeyVaultPropertySource(KeyVaultEnvironmentPostProcessor.java:131)
	at com.azure.spring.cloud.autoconfigure.implementation.keyvault.environment.KeyVaultEnvironmentPostProcessor.buildKeyVaultPropertySourceList(KeyVaultEnvironmentPostProcessor.java:116)
	at com.azure.spring.cloud.autoconfigure.implementation.keyvault.environment.KeyVaultEnvironmentPostProcessor.postProcessEnvironment(KeyVaultEnvironmentPostProcessor.java:89)
	at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEnvironmentPreparedEvent(EnvironmentPostProcessorApplicationListener.java:109)
	at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEvent(EnvironmentPostProcessorApplicationListener.java:94)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:143)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:131)
	at org.springframework.boot.context.event.EventPublishingRunListener.multicastInitialEvent(EventPublishingRunListener.java:136)
	at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:81)
	at org.springframework.boot.SpringApplicationRunListeners.lambda$environmentPrepared$2(SpringApplicationRunListeners.java:64)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:118)
	at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:112)
	at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:63)
	at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:356)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:307)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1306)
	at org.springframework.boot.SpringApplication.run(SpringApplication.java:1295)
	at com.github.nagyesta.example.sbkvdemo.SpringBootLocalKeyVaultDemoApplication.main(SpringBootLocalKeyVaultDemoApplication.java:10)
Caused by: java.lang.RuntimeException: The challenge resource 'https://localhost:10543/.default' does not match the requested domain. If you wish to disable this check for your client, pass 'true' to the SecretClientBuilder.disableChallengeResourceVerification() method when building it. See https://aka.ms/azsdk/blog/vault-uri for more information.
	at com.azure.security.keyvault.secrets.implementation.KeyVaultCredentialPolicy.authorizeRequestOnChallengeSync(KeyVaultCredentialPolicy.java:281)
	at com.azure.core.http.policy.BearerTokenAuthenticationPolicy.processSync(BearerTokenAuthenticationPolicy.java:135)
	at com.azure.core.http.HttpPipelineNextSyncPolicy.processSync(HttpPipelineNextSyncPolicy.java:41)
	at com.azure.core.http.policy.RetryPolicy.attemptSync(RetryPolicy.java:164)

To Reproduce
Steps to reproduce the behavior:
Please check the failing branch of the example project I have created here: https://github.com/nagyesta/spring-boot-local-key-vault-demo/tree/failing
Code Snippet
com.azure.spring.cloud.autoconfigure.implementation.keyvault.secrets.properties.AzureKeyVaultPropertySourceProperties does not have a disableChallengeResourceVerification field (and the related getter-setter).
Therefore, the com.azure.security.keyvault.secrets.SecretClientBuilder#buildInnerClient method cannot set it as true in this line:
policies.add(new KeyVaultCredentialPolicy(credential, disableChallengeResourceVerification));

Expected behavior
The client configuration should allow disableChallengeResourceVerification to be freely configured for tests.
Screenshots
N/A
Setup (please complete the following information):

OS: Any (tried on Kubuntu 22.04 LTS)
IDE: Any (tried with IntelliJ)
Library/Libraries: com.azure.spring:spring-cloud-azure-starter-keyvault-secrets:5.5.0
Java version: Any (tried with 17)
App Server/Environment: Any
Frameworks: Spring Boot 3.1.2

Additional context
Related to https://github.com/Azure/azure-sdk-for-java/issues/29651
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Hi @nagyesta , thanks for reaching out.
We have received your submission and will take it into consideration. We appreciate your input and will review this matter as soon as possible.
Please feel free to provide any additional information or context that you think may be helpful. We'll keep you updated on the progress of our review.
Thank you for your contribution to improving our project.

Hi @Netyyyy ,
thank you! I have prepared a PR as well (https://github.com/Azure/azure-sdk-for-java/pull/36603). I hope it will help!

close it for fixed


#238 Add 4 relationships, subject area definition and a sample

Signed-off-by: David Radley<EMAIL_ADDRESS>

I want to change the way that reltinships are exposed in the API, this PR is not quite right. I am closing this PR and will resubmit with the correct API.


Documentation for FreeConsole API is wrong (for case when console is already attached)

Ported from MSFT:9194124
The documentation says:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683150(v=vs.85).aspx
A process can be attached to at most one console. If the calling process is not already attached to a console, the error code returned is ERROR_INVALID_PARAMETER (87).
But the code actually says and does:
//
// We succeed the free console request even if there's nothing to be freed
// to maintain compatibility with previous releases.
//

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

ID: 6b013865-fcaf-8009-6c6f-cf358d98914e
Version Independent ID: 33211ae1-fe61-845c-040c-b92ea8b0e25f
Content: FreeConsole function - Windows Console
Content Source: docs/freeconsole.md
Product: console
GitHub Login: @miniksa
Microsoft Alias: miniksa

A process can be attached to at most one console.
/* Second paragraph content */
If the calling process is not already attached to a console, the **FreeConsole** request still succeeds.


Dependencies and Readme Updates

Changes

Readme looks a bit nicer!
Dockerfile will now utilize hydrogen-alpine as it is smaller and now will utilize the latest of NodeJS 18.

Notes

We might just remove nodemon from the project as utilizing the latest of NodeJS will reduce vulnerabilities in the codebase.
Vulnerabilities were removed because of the project being upgraded to the latest NodeJS version (18+).

I believe so, Ollama is fairly fast though and it will only abandon if it loses connection to the container.
@JT2M0L3Y