wip implementation work based on 1.x branch

add coverage for most implemented non-npm install behavior
add a wallabyjs config file
add read-package-json for some normalization
rename test/index.js to test/index.spec.js because it changes the file icon in vscode
rename fixtures, reorganize tests somewhat
add a helper function to run createPackageJson in silent mode w/ barePrompt
change some assertions to use deepStrictEqual
add TODO list to README.md
better handling of scripts, keywords, and repository fields
update build matrix

should probably revert the rename of test/index.js cause the diff is bad.

should probably revert the rename of test/index.js cause the diff is bad.

@wesleytodd Object.fromEntries is not available in Node.js v10.x.  So if we want to support that version of Node (probably should...) we'd need to pull in a ponyfill or just punt.  I punted.

@wesleytodd Object.fromEntries is not available in Node.js v10.x.  So if we want to support that version of Node (probably should...) we'd need to pull in a ponyfill or just punt.  I punted.

Oh, also what does wallabyjs do?  I have not used it before.

Oh, also what does wallabyjs do?  I have not used it before.

wallabyjs.com - instant-feedback test runner integrated with IDEs. it’s very handy; better than any framework’s “watch” mode. config file is useful for those who use it, but i can rip it out if you’d rather not have the clutter

wallabyjs.com - instant-feedback test runner integrated with IDEs. it’s very handy; better than any framework’s “watch” mode. config file is useful for those who use it, but i can rip it out if you’d rather not have the clutter

config file is useful for those who use it, but i can rip it out if you’d rather not have the clutter

Doesn't matter much to me if it is useful to people.

config file is useful for those who use it, but i can rip it out if you’d rather not have the clutter

Doesn't matter much to me if it is useful to people.

Hey, I know this is marked as draft, but do you see any reason not to start merging this as the work is done?  I am going to integrate this into a project today, so figured it would be a good time for me to merge at least base on top of your work.

I added you as a collaborator here (I should have done that in the first place, but better late then never) and pushed your branch.  We can discuss what to do with the PR since I cannot find a way to just swap out the repo/branch in this way, but I will probably have a few additions today as I mess with it.


getItem() return type always contains null

Thanks for this library.
Consider the following usage:
const key = new LocalKey<Options>("mykey", { id: 'abc' }, {
  hasDefaultValue: true,
});

const savedOptions = LocalStorage.getItem(key);

Even though in this circumstance getItem() will never return null, we can't use savedOptions without checking for null first.
For example, the following function won't compile:

// TS error "null is not assignable to Options"
function getSavedOptions():Options {
   return LocalStorage.getItem(key);
}

We could use LocalStorage.getItem(key) ?? { id: 'abc' }, but this defeats the purpose of providing a default in the first place.

Yes, this can not easily be fixed.
Solution 1:
The Typescript type checker can't know if you have set hasDefaultValue to true and using Options as the return type might be dangerous. Solving this would require a split approach, like LocalKey for non-nullable keys with defaults and LocalKeyNullable for nullable keys. This would be a major breaking change and it would make this a lot more complicated with very little benefit imo.
Solution 2:
Maybe a second optional type parameter could be added as a sort of typescript variable to determine if the thing is nullable? That could work, in that case you'd need to write LocalKey<Options, Options>. The second Options would be the type of the default value returned if the first type isn't set. Maybe it's even possible to infer this. This would definitely be the best case solution here and the one I'd try first.
Either way, I have somewhat limited time right now, not sure I'll get to it in the near future. I'm open to PRs though.
For now, you could use exclamation marks and the linter will tell you to remove them once a proper solution is available.

@dxptqhtlutehvlyxcmtg This has been fixed with v3.1.0


Added the ability to copy art to clipboard

Fixed #1
TODO: Use a better way to notify the user of the copy rather than alert

@datawater If you still are working on showing a better version for the copy alert here let me know or else this is good to merge.

@datawater PLEASE RESPOND.
 OWO
GOD MORGON btw

@datawater If you still are working on showing a better version for the copy alert here let me know or else this is good to merge.

We could use something like sweetalert, but I feel like it would bloat the webpage too much (it's about 55KBs). I pass the decision to you, if you want me to implement a better way, LMK, else you can merge it.

@datawater I'll add a better implementation for the message if I find any. For the time being,


'improve docs' link leads to 404

Clicking on Improve this Doc  on page https://scottplot.net/doc/v4/api/ leads to github 404

Thanks for reporting this @tombohub!
I'll probably fix the url so we know how for the future, then temporarily disable the API website because it's overwhelmingly complex. I'd like to make the API docs with something custom/simpler, and in the meantime we can lean on FuGet if we really need to refer to a method signature or something like that https://www.fuget.org/packages/ScottPlot/


Parameter from missing in eth_sendTransaction on the web

The JSON spec mentions the from parameter but I cannot find on the web. Is this intentional?

eth_sendTransaction isn't formally specified in this spec. What exactly are you referring to?

I am referring to this method: https://github.com/ethereum/execution-apis/blob/53c28e14e912a2d642cec6ea19bac87cadf82c13/src/eth/submit.yaml#L1-L11
with the schema defined here: https://github.com/ethereum/execution-apis/blob/53c28e14e912a2d642cec6ea19bac87cadf82c13/src/schemas/transaction.yaml#L16-L159
TransactionWithSender specifies required parameter from for all transaction types, but I cannot find it on the web:

should be okay now


gltf2 export of simple skin instanced twice fails

Godot version
aceaf39
System information
Win10, Vulkan, Nvidia 3000 series GPU
Issue description
gltf2 fails to export with instanced mesh animations.
Steps to reproduce

When you create a new 3d scene
Instance https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/SimpleSkin/glTF-Embedded/SimpleSkin.gltf twice.
Move one of the instances away from the other
Export scene as gltf
Open the scene again
Fails to export one of the animated mashes

Minimal reproduction project
Todo.

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


Solutions detail: when you copy out json it's not formatted correctly

For example if you tried copying this

you will get:
{

-

"wids"
:
[

474102
,

474105
,

474104
,

474106

]
,

"Name"
:
"cryptpad"
,

"Domain"

..........

Suggestion: add a copy to clipboard function

will be addressed in https://github.com/threefoldtech/js-sdk/issues/1632

will be addressed in https://github.com/threefoldtech/js-sdk/issues/1632

will be addressed in https://github.com/threefoldtech/js-sdk/issues/1632

will be addressed in https://github.com/threefoldtech/js-sdk/issues/1632


[Feature Request] SVG to SF Symbols

Hi just tried s2c and it is awesome..is it possible you could write a converter similar to this but for iOS SF Symbol?

Hi @koolfreak, I'm glad that you liked this repo!
Although having the same parse for SF Symbols would be very nice, I have no knowledge of the iOS ecosystem, thus I won't be able to help with that.
If the SF Symbols follow the same principle of creating an ImageVector in compose, it won't be too much trouble to implement it, but I would require some research to understand if that is feasible or not, and sadly I'm having limited time to work on this.
Also, if you already know how SF Symbols are built, feel free to contribute to this repo! I would be more than happy to help with it :)

Ok thanks....unfortunately i don't know also SF Symbols are built but they can be exported and modified in sketch


Gremlin raise an exception when feed string with carriage return

When I send the following over HTTP POST in Rexster 0.6 git master:
v = g.addVertex();v._element_type = 'Message';v.message = 'a thread with a break\r\n\r\nbreak now';v.creation_date =<PHONE_NUMBER>;v.public = 0;v.id;

Gremlin raises the following error:
GremlinException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script206.groovy: 51: expecting ''', found '\r' @ line 51, column 87. = 'a thread with a break ^ 1 error

edit: I'm using Rexster 0.6

One thing of note, underscore var names are reserved and underscore properties are filtered out in the code.

This is a Groovy thing as it doesn't like the /r ... ? ... Has to do with Groovy ScriptEngine implementation I believe which GremlinGroovyScriptEngine extends.


please support laravel octane

octane can boots bagisto
https://laravel.com/docs/9.x/octane#introduction
to support is, the key is dependency injection.
right now, error occures when visiting a product page
Illuminate\Contracts\Container\BindingResolutionException
Target [Webkul\Attribute\Contracts\Attribute] is not instantiable. (View: /vagrant/bagisto/resources/themes/velocity/views/products/view/attributes.blade.php)

Linking here,
https://github.com/bagisto/bagisto/issues/3846


Consider adding OS X instructions

If https://github.com/gabrielelana/awesome-terminal-fonts/issues/7#issuecomment-236417688 works for more than just me; it would probably we worth adding to the README.

@leoj3n: Wow, nice work! Thanks! Since it's so detailed I'm thinking to put it in a wiki page, what do you think?

https://github.com/gabrielelana/awesome-terminal-fonts/wiki/OS-X

Thanks! ❤


Fix from Ben for include/MAPL_ErrLogMain.h

Description

I am currently trying to build GEOSadas-5_27_0 inside Git. And as such I'm pulling in work that @bena-nasa did previously with an old test with MAPL 2.
This is a duplicate of code from the  feature/bmuaer/adas_with_mapl2 branch. He figured out that the ASSERT_ statement in MAPL_ErrLogMain.h can't have the message. My guess is at some point I added it there in an aggressive sed command or something.
But I'm doing my test with MAPL develop (e.g. 2.3) as that will probably be the MAPL basis when we get to the final integration and figured let's just get this in.
Note that MAPL_ErrLogMain.h is really used only in a couple GSI_App files so this is trivially zero-diff for the GEOSgcm.
Related Issue

Motivation and Context

Let's the GEOSadas build (well, one program).
How Has This Been Tested?

Code builds with it, doesn't without.
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist:

[ ] I have tested this change with a run of GEOSgcm (if non-trivial)
[X] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[X] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

ETA: I also deleted base/MAPL_base.mk. That's an old GNU Make file and I don't think we care about it anymore.

Adding blocking tag. More edits are needed in MAPL. Will consult with @bena-nasa


Add repository to HACS

Is your feature request related to a problem? Please describe.
Everyone who wants to use our integration has to find it and add it to hacs,
Describe the solution you'd like
Add our integration to hacs so everywone using hacs can find it
Describe alternatives you've considered
Leave it as is.
Additional context
All files required for the integration to run must be located inside the directory ROOT_OF_THE_REPO/custom_components/INTEGRATION_NAME/.
The kennfeld Files are NOT. Maybe all "kennfelder" in one file? A dropdown?
update info.md
https://hacs.xyz/docs/publish/start/#my-links
https://hacs.xyz/docs/publish/integration/

All in one file would it make more difficult for users to create new files..

I agree.
Maybe a template.json for local edit and send to us and one file where we define the known curves.
Dropdown with known curves and custom for the template.json.
But for now this is perfectly fine. We fullfill the requirements for beeing listed in hacs.
Do create a pull request? (You are the owner)

Yes, will do. But what version should we use?

The latest stable (1.0.1). Then we should wait pushing ne versions until we got merged.

I see you pushed the file moves to the translation branch. Should we wait for the translaiton to finish, merge to main and publish 1.0.2 before we push to hacs?

No, I can transfer them to version-1.0 and introduce it in HACS. But I have to debug finding always the right config dir before..

Version 1.0.2 is out, temporarily without translation, because there was an issue that I found quite late on my production system:
Since we had to set _attr_has_entity_name = True, the names of the entities now contain the device name, too. This breaks statistics.
We have to find a solution for 1.0.3, either overloadeing _friendly_name_internal() or let the names change and do something like this as a repair step:
https://community.home-assistant.io/t/merge-statistics-of-old-entity-to-new-entity/467816/42

https://github.com/hacs/default/pull/2855
for easier finding.

This is new, istnt it?

@OStrama ?

I had a look at the conflict. It's not related to our integration:
"zigul/HomeAssistant-CEZdistribuce",
<<<<<<< patch-1
"ZsBT/hass-w1000-portal",
"zweckj/acaia"
"ZsBT/hass-w1000-portal"

master
]

I have no write access to solve it..


Revisit sensitive window split / group behavior on drag and drop

Issue Type: Feature Request
I have noticed what seems like a recent change in the behavior for grouping/splitting windows when dragging and dropping files into the main editor. I often use this method to open files.
I am now frequently splitting the window at unintended times when I open new files. I believe the target area that triggers a split window is too large, especially when not using VSCode maximized, or on smaller screens.
VS Code version: Code - Insiders 1.25.0-insider (11b0f3a40be055e02b721abbb93cb0012818f99e, 2018-06-14T05:17:21.496Z)
OS version: Windows_NT x64 10.0.15063

The current threshold is 30% of width with is a lot more compared to stable (10%). I also think we should optimize for the preferred direction of the user. E.g. when the configured to split to the right, we should maybe make the hitzone for splitting into that direction larger and vice versa.

Pushed 2 changes to improve this:

reduced the threshold where we account for a split to 20% (making the center as large as 60% to add the file into the group as opposed to causing a split
making the hitzone for vertical or horizontal split larger depending on the workbench.editor.openSideBySideDirection

"workbench.editor.openSideBySideDirection": "right"

"workbench.editor.openSideBySideDirection": "down"


Feature to Goto a page directly

Is your feature request related to a problem or area of OpenRefine? Please describe.
We can go to the first, the last, a next or previous page, but we can't jump to any page.
A simple link, with a prompt, telling you your current page, the max # of pages, and asking to what page you want to go would be a nice feature.
Describe the solution you'd like

Describe alternatives you've considered
Clicking many times the next button. I works.

Relates to #571

@wetneb & @thadguidry: this is the last feature I see that would be simple, not prone to breaking, and very useful for our user.
I coded it, it works well. I didn't do validation yet (range & number), but for the rest, you can try it.
Regards,
Antoine

A background color could also be added to clarify a bit the interface and it's choices:

Regards, A.

@antoine2711 Appreciate you working on this!
I think the popup display approach for our users is overly complex and I think we can make this easier and similar to other grids.  The numbers themselves currently display the Row range.  That's fine, but what we really want to improve and begin to integrate like other grids is the notion of Pages of Rows.
Therefore I think we should do a number of things here:

Keep the Row range (Rows per page) display (folks are used to that)
Show a new Page range display
Allow direct entry of the current page to view on the Page range display, rather than a popup

Look at this beautiful Example Demo that allows all 3 of those needs we have, but using simple control & display of them (Try it out!):
https://xaksis.github.io/vue-good-table/guide/configuration/pagination-options.html#mode

I know you can make this look and work amazing if you iterate on this over a few days.  Looking forward to testing that out!

I know you can make this look and work amazing if you iterate on this over a few days. Looking forward to testing that out!

Thanks for the carrying compliment! ;-)

Therefore I think we should do a number of things here:

Keep the Row range (Rows per page) display (folks are used to that)
Show a new Page range display
Allow direct entry of the current page to view on the Page range display, rather than a popup

So @thadguidry, do I go

« First
< Previous
Page [1] of 3
or
Page [1] of 3 (Rows 1 to 10)
and
Next >
Last »

Regards,
Antoine

Page [1] of 3

Reasoning is that showing 1-10 or 1-50 etc. is redundant.
Folks already know the Rows per page via the existing selector:

Is it easy enough to calculate the max pages however?  Do we already have integer value stored somewhere in our current architecture?  Or do you have to add functionality to calc that?  Is Java or JS the best place to calc that?  What does the future look like for calculating that with @lisa761 's upcoming work?

Is it easy enough to calculate the max pages however?

It’s coded in the PR, I would say very easy since it’s done! ;-)

How well would the update perform for the max pages count whenever users click and change the value Rows per page to Show: ?
Do we already have the max pages integer value stored somewhere in our current architecture?
Or do you have to add functionality to calc that?

In JS. It was semi-coded for the Goto LastPage.

What does the future look like for calculating that with @lisa761 's upcoming work?

No use with infinite scrolling, and we would keep it as long as we keep Paging functionality.
Regards,
Antoine

@thadguidry: you can try it, It's now coded with an  tag instead of the prompt. Much harder to code, less robust, but better user interface I would say.
Tell me if you like it.
Regards,
Antoine

And I also did this little change… subtle, but stil, effective I would say.

Regards, A.

On you last screenshot, I think we could reduce the padding around rows and records.  Unless that also increases the clickable area for them to make clicking on each easier, then I'd keep it as is.

@thadguidry: @wetneb made me change the weak mechanism, and now, it works flawlessly on FF as on Chrome! I just committed the code.
Try that when you're available.
Regards,
Antoine


Hyprbars: Change configuration key "col.text" to "bar_text_color"

The hyprland col. keywords could use a change as well.

yes but then we pointlessly break the config

Any change for the better is worth a breakage. Plus we can just deprecate the old col. for a release or two.

this is very marginally better, I am not convinced


Flags enum still doesn't work

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
#5186  merged, but enum flags still doesn't work. @PascalSenn

this is but
Steps to reproduce

Exec following query:
[Flags]
public enum Example { First, Second, Third }
public Example Loopback(Example input)
{
var val = Example.Second | Example.First | Example.Third;
return val;
}

Relevant log output
No response
Additional Context?
No response
Product
Hot Chocolate
Version
13.0.0-preview7.0

you have to enable the flags enum on the request builder:
server.AddGraphQLServer()
  ...
 .ModifyOptions(x => x.EnableFalgsEnum = true);

The input is no longer a enum though but is an input object
input ExampleFlagsInput {
  isFirst: Boolean
  isSecond: Boolean
  isThird: Boolean
  }

.ModifyOptions(x => x.EnableFalgsEnum = true);

I don't see EnableFlagsEnum - property. Why input doesn't support enum flags?  Should I need write manualy transformation from bools to enum?

@spqr911  what version are you on?

preview 13 version seems to have lost this setting. Is there another way of enabling enum flags?

It works for me in 13.5.1 once you add the EnableFalgsEnums setting
server.AddGraphQLServer()
  ...
 .ModifyOptions(x => x.EnableFalgsEnums = true);


Artifacts on JPGs greater than 640 pixels wide

Thanks for this wonderful library! It's incredibly useful and performant!
I'm seeing artifacts on JPGs greater than 640 pixels wide, at the 640 pixel mark. The attached image explains better, what with a picture being worth a thousand words :) On the right side of the image, a thin strip at the 640 pixel mark, about 6 pixels wide. It appears to be a strip of pixels that need to appear at the right hand edge of the frame. The rendered image is the correct width on screen.
I'm using<EMAIL_ADDRESS>(and also tried master from GitHub) running on a Teensy 4.1, and I'm using these two calls to open from RAM and decode:
jpeg.openRAM(jpgBufPtr, nb, &JPEGFlushBuffer);
jpeg.decode(0, 0, 0);
My display driver is pretty mature (untouched now for a couple of years) and works with my own rendering and also output from LVGL and other libs, etc. and there doesn't appear to be an issue there. Calls to jpeg.getWidth() and getHeight() confirm the jpg is the size I expect it to be (and set my screen address window to constrain display updates in). If I insert a delay between the buffer flush calls and write x, y, w, h to the console, the dimensions provided from the decoder are correct, it is sending 128x16 pixel blocks,  it's just that next chunk after 5 * 128 pixel blocks (640 pixels total) contains the slight corruption of data, although it's x, y, w, h parameters are correct so I can't be overflowing the screen. For the image below (746 pixels wide), I get:
x:0 y:0 w:128 h:16
x:128 y:0 w:128 h:16
x:256 y:0 w:128 h:16
x:384 y:0 w:128 h:16
x:512 y:0 w:128 h:16
x:640 y:0 w:106 h:16 <- the left side of this chunk has the corruption
JPGs are created via ffmpeg (-f mjpeg option) so there is a (small) chance it is related to that, as well, but If I scale the image via jpeg.decode options, I see no artifacts on the scaled-down images, which lead me to believe the source JPG is fine?
Any pointers would be wonderful! Hopefully it's something I'm doing wrong and can fix easily :)

Can you email me one of these failing images? I believe I know how to correct the problem, but it would help to confirm it with a failing image. You can email it to<EMAIL_ADDRESS>

Thanks for the prompt reply! I'll send you an image shortly - I'm currently using ffmpeg to decode an mp4 and create a file of jpgs, then interleaving that with audio and playing that back in my software, so I don't explicitly have single jpg files. I'll figure how to use the command line to get a solo jpg from ffmpeg, and test that by itself in my code first, to see if it has the same problem, then shoot it to your email.

Image was sent via email....thanks!

Thank you for the sample image - it helped me locate the problem(s). I just pushed new code which seems to solve the problem. I tested it on a ESP32-S3 board and on MacOS.

Just tested on 3 existing MJPEG files (so, technically on 15k+ JPGS) on my Teensy 4.1, and it's solved! Regenerated a couple of test files at different sizes > 640px, and those work without issue, too.
Thanks for the rapid turnaround and thanks again for this library!


fix(connection-settings): Update connection lifetime

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.931%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
466

Relevant Lines:
583

💛  - Coveralls


yarn flow failing on the Page component

I've got an issue while running flow on a base generated project.
Indeed, noNavBar and noMargin props of the Page component are typed as required, but I don't think they should be.
If you agreed, I can do a Pull Request !

Please do :)


add compiler functionality to the NW.JS app

@JJ made a quite good progress last time compiling the binary offline. Let's start integrating it in the NW.JS app (Miniblip studio)

I'll take a look.


Update to webpack@^3

Initial testing shows better performance and faster compile time. Going to wait a little bit more just in case any unknown bugs are resolved.
Also waiting on https://github.com/webpack-contrib/extract-text-webpack-plugin/pull/543

Done in #310

Added in https://github.com/SimulatedGREG/electron-vue/commit/0ee26cbc561bce8184e0b9e46524c025328337d0


IMPORTANT: This repository is archived.

THIS REPOSITORY IS NOW ARCHIVED.
All iModel.js samples have been consolidated in the iModel.js samples repo. You can expect future updates to the simple-viewer-app right here.
Additionally, we just released a light-weight version called the basic-viewport-app. For details, check out this blog post.

In addition, all open issues will be transferred over to the iModel.js samples repo.


Do you support using configuration under folders?

for example：
/resources/seata-config/registry-test.conf
/resources/seata-config/file-test.conf

Not support.


[FR]: Investigate moving SettingsViewModel into plain state holder

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the problem
Context: https://github.com/android/nowinandroid/pull/330/files#r1001243734
Describe the solution
As above
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

The problem with ViewModel here is that if you show multiple SettingsDialog under the same ViewModelStoreOwner / scope, they all will get the same instance of the ViewModel.

Hi @dturner, can we resolve @manuelvicnt's concern by providing key to ViewModel? It'll help creating unique instances of ViewModel under the same ViewModelStoreOwner / scope.
KeyedHiltViewModel


Tugup/containerruntime

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

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

#sign-off


Full View is not Rendered

When the cell size of the grid is very large, there is space left on the right.  The problem could be in the bleed values.

I believe 2.2 section of Documentation explains this this 2.2 Details of Bleed and Grid dimensions

@suyashmahar the 2.2 section states that the total area visible is (gridHeight + bleedY)*(gridWidth + bleedX). The app has the gridHeight and width set to match parent. There is a padding of 16dp and margin of 8dp.  BleedX and BleedY have been set to 50dp. Hence, there should not be any space left.

@dakshitagrawal97

Bleed: Bleed defines the dimensions of extra size that TrianglifyView view generate so that triangles on the edge doesn't appear to be chopped off. In most of the cases min{bleedX, bleedY} > cellSize would ensure that the view is completely filled.

I was referring to this part emphasized, It says when cell size is large such that above inequality doesn't holds true, view will show white spaces. However we can make sure that above inequality holds true in our demo app.

@dakshitagrawal97 I think the issue has been addressed.

Yes, I overlooked that part. We should add the inequality checker on our part though.

@dakshitagrawal97 I don't think that would be a good idea we should not control every aspect of trianglify behavior. User should be in control of every thing, though we can make it optional.

The user would want that the view is filled completely into the space that is designated to the view. We can give a toast message to notify the user of the problem so that he can rectify it on his own. For the app, we should take care of it from our side.

@dakshitagrawal97 Showing toast notification or messages from library is a bad idea, however handling in our app seems right.


Issues loading on galaxy tab e device (and others?)

Received from part of email:
"I cant get them to load up at all on my Samsung tablet. It a galaxy tab E not that it should make much of a difference but your page just wont load at all."

I'm not really sure what to do with this.  I don't have access to this device, all the devices I use work (with some minor style issues sometimes).  I'm going to close this but ask the community to report and devices that don't work and I may reopen.


vayu-coltos-bibarub

Don't use personal manifest in init line. Use rom manifest. And use local manifest for using personal repos


Readme needs to be updated

many things have changed since, most of the stuff just needs to be deleted so people aren't led astray :wink:

done and done


Update saving-repositories-with-stars.md

Issue #16949

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

👋 @vedant205 Thanks for opening a PR! Can you make a few changes to make sure this new section fits a little better with the existing content? Can you:

[ ] move the new section to be under the Starring a repository section?
[ ] use a similar format as the Organizing starred repositories with lists section. I don't think you need a screenshot though. Include an  explanation of why someone would want to use this feature. You could rework the explanation from your issue, that was great!

Let me know when that's done and I'll give it another look 💖

I wasn't able to figure out how to make the edits within this pull request, so I opened a new one at #18577 with the edits you requested.


HBASE-28923 Prioritize "orphan" blocks for eviction inside BucketCache.freespace

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 33s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m 49s

master passed

+1 :green_heart:
compile
3m 22s

master passed

+1 :green_heart:
checkstyle
0m 41s

master passed

-1 :x:
spotbugs
1m 58s
/branch-spotbugs-hbase-server-warnings.html
hbase-server in master has 1 extant spotbugs warnings.

+1 :green_heart:
spotless
0m 53s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 27s

the patch passed

+1 :green_heart:
compile
3m 37s

the patch passed

+1 :green_heart:
javac
3m 37s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 44s
/results-checkstyle-hbase-server.txt
hbase-server: The patch generated 1 new + 10 unchanged - 0 fixed = 11 total (was 10)

+1 :green_heart:
spotbugs
1m 39s

the patch passed

+1 :green_heart:
hadoopcheck
11m  1s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 41s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 10s

The patch does not generate ASF License warnings.

39m 29s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6373

Optional Tests
dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless

uname
Linux 1955bd0a90ef 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8ea1b82bc3631568384c0a548b65390b3cffbff0

Default Java
Eclipse Adoptium-17.0.11+9

Max. process+thread count
84 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/1/console

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 28s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
3m 13s

master passed

+1 :green_heart:
compile
3m 12s

master passed

+1 :green_heart:
checkstyle
0m 35s

master passed

-1 :x:
spotbugs
1m 32s
/branch-spotbugs-hbase-server-warnings.html
hbase-server in master has 1 extant spotbugs warnings.

+1 :green_heart:
spotless
0m 44s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 57s

the patch passed

+1 :green_heart:
compile
3m  8s

the patch passed

+1 :green_heart:
javac
3m  8s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 36s
/results-checkstyle-hbase-server.txt
hbase-server: The patch generated 1 new + 10 unchanged - 0 fixed = 11 total (was 10)

+1 :green_heart:
spotbugs
1m 40s

the patch passed

+1 :green_heart:
hadoopcheck
11m 36s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 45s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 54s

the patch passed

+1 :green_heart:
compile
0m 56s

the patch passed

+1 :green_heart:
javac
0m 56s

the patch passed

+1 :green_heart:
javadoc
0m 30s

the patch passed

+1 :green_heart:
shadedjars
5m 10s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
235m  7s

hbase-server in the patch passed.

259m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6373

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux<PHONE_NUMBER>db 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 41a9744ad27ef4818320d94ce3142aade39a8a89

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/2/testReport/

Max. process+thread count
4583 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/2/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 42s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
4m 59s

master passed

+1 :green_heart:
compile
4m 49s

master passed

+1 :green_heart:
checkstyle
0m 55s

master passed

+1 :green_heart:
spotbugs
2m 11s

master passed

+1 :green_heart:
spotless
1m 10s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
4m 33s

the patch passed

+1 :green_heart:
compile
4m 41s

the patch passed

+1 :green_heart:
javac
4m 41s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 43s

the patch passed

+1 :green_heart:
spotbugs
2m  5s

the patch passed

+1 :green_heart:
hadoopcheck
16m 30s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
1m 11s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 54s

the patch passed

+1 :green_heart:
compile
0m 58s

the patch passed

+1 :green_heart:
javac
0m 58s

the patch passed

+1 :green_heart:
javadoc
0m 30s

the patch passed

+1 :green_heart:
shadedjars
5m 12s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
230m 18s

hbase-server in the patch passed.

254m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/3/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6373

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux bf4bb794aee9 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 95f7c965c7c2e2c1517c369090dab839b9cc2937

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/3/testReport/

Max. process+thread count
4610 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/3/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 41s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ master Compile Tests _

+1 :green_heart:
mvninstall
2m 58s

master passed

+1 :green_heart:
compile
2m 57s

master passed

+1 :green_heart:
checkstyle
0m 38s

master passed

+1 :green_heart:
spotbugs
1m 36s

master passed

+1 :green_heart:
spotless
0m 45s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 49s

the patch passed

+1 :green_heart:
compile
3m 19s

the patch passed

+1 :green_heart:
javac
3m 19s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 50s

the patch passed

+1 :green_heart:
spotbugs
2m 14s

the patch passed

+1 :green_heart:
hadoopcheck
12m  8s

Patch does not cause any errors with Hadoop 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 52s

patch has no errors when running spotless:check.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
2m 51s

the patch passed

+1 :green_heart:
compile
0m 57s

the patch passed

+1 :green_heart:
javac
0m 57s

the patch passed

+1 :green_heart:
javadoc
0m 30s

the patch passed

+1 :green_heart:
shadedjars
5m 20s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

+1 :green_heart:
unit
224m  9s

hbase-server in the patch passed.

250m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/4/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/6373

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux ef782f6a8bc5 5.4.0-195-generic #215-Ubuntu SMP Fri Aug 2 18:28:05 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 5e3918884105aab9d1d196b17c6afa9bd7df37f4

Default Java
Eclipse Adoptium-17.0.11+9

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/4/testReport/

Max. process+thread count
4568 (vs. ulimit of 30000)

modules
C: hbase-server U: hbase-server

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-6373/4/console

versions
git=2.34.1 maven=3.9.8

Powered by
Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.


support more redirect op

support the following op

[n]<&-, [n]>&- close file descriptor n
[n]<>expr open file descriptor with read-write mode

support <> op in commit 50b594e

support <&-, >&- op in  commit ccea3d9


Add hasSameSlotsOf method to RedisClusterNode for a quick slots comparison

This PR is related to the issue #1011.
What
Added the hasSameSlotsOf method to the RedisClusterNode class so it can be used by the TopologyComparators class while is comparing the node slots.
Added unit tests to verify the behaviour of the new method.
Why
Solve the performance issue #1011

Thanks a lot. That's merged, polished, and backported now.


cache responses from /api/orchestrator

Necessary for us to survive crashes of the Kubernetes control pane, which we should be able to do.

@iameli I believe was done in 431389aca0772067e0fe8917b69f57275a0f4fff, so should be closed?

@iameli Should this be closed?


Add option to disable the radar

The current radar imlementation has issues: #141
I would like to use the native CS2's radar. An option in the settings would be nice.
Console commands needed for this:
cl_draw_only_deathnotices 1
cl_obs_interp_enable 0
cl_drawhud_force_teamid_overhead 1
cl_teamid_overhead_always 2
cl_drawhud_force_radar 1

The cl_drawhud_force_radar 1 is the important one.

I think I'd rather spend time on finding a solution to the radar issues themselves (#113).
Under normal circumstances this would be too niche of a use case for official support in my opinion, so it should be handled via a theme. See https://github.com/drweissbrot/cs-hud/issues/120#issuecomment-1887734612 for instructions.


Added HD-ready and changed description for Full-hd

Added HD-ready selection and changed description for FULL-HD for bether understand.

Thanks. Just want to check if silvan is happy with change of wording

Thanks too. I think it would be better to change the order to full-hd, then
hd-ready and to add the Std-FOV into the Name. Something like this could be
good:
16:9 1080p Std FOV
16:9 720p Std FOV
What do you guys think?

Change order sounds good
Here would be my suggestion
"1920 1080 25 25 2592 1944">Select option...
"1920 1080 25 25 2592 1944">Full HD 1920p 16:9 FOV
"1280 0720 25 25 2592 1944">HD-ready 720p 16:9 FOV
"1296 730 25 25 2592 1944">Medium   730p 16:9 FOV
"1296 976 25 25 2592 1944">Max View  976p  4:3 FOV
"768 576 25 25 2592 1944">SD TV 576p  4:3 FOV
"1920 1080 01 30 2592 1944">Full HD Timelapse (x30) 1920p 16:9 FOV
Where I added in a standard def TV which seems to work and may be useful for those who want to trade res / storage.
If we have HD Ready should we lose what I call Medium which exists today but is very close to HD Ready

Sounds good, I agree in removing Medium. Additionally, the FOV is also not
really necessairy and could be removed i suppose.

since this came up, maybe I'm confused about the 1296 976 mode, I saw a mention here (https://www.raspberrypi.org/documentation/hardware/camera.md), but querying the hw seems to suggest the mode should be1296x972, no 976.
See this for example:
https://www.raspberrypi.org/new-camera-mode-released/
sorry if I'm missing the point.

I hadn't noticed that. 972 would be correct for true 4:3. I tried that out and seems OK so I've changed to that. Just in time too; I was about to push it.

Merged in manually with additions


fix(prisma): add useDefineForClassFields option to default ts compilation option

Summary by CodeRabbit

Chores

Updated configuration options for TypeScript class field definitions.
Reformatted code for improved clarity in the project instantiation section.
Adjusted test coverage thresholds for Vitest.

:tada: This PR is included in version 8.3.2 :tada:
The release is available on:

v8.3.2
GitHub release

Your semantic-release bot :package::rocket:


How do I use the pathClass setting correctly?

I want to inject my own class for dealing with paths.
This is a part of my Model initialize function:
...         $this->addBehavior('Proffer.Proffer', [             'image' => [                     'root' => WWW_ROOT . 'img',                  'dir' => 'image_dir',                   'pathClass' => 'App\Lib\Proffer\MyProfferPath', ...
My class is located here: src/Lib/Proffer/MyProfferPath.php
But it doesn't work.
Error: Class 'App\Lib\Proffer\MyProfferPath' not found
File /my_cakephp_project/vendor/davidyell/proffer/src/Model/Behavior/ProfferBehavior.php
Line: 78
What am I doing wrong?

AH! Sorry, I missed the namespace.
namespace App\Lib\Proffer;


Refactoring on the RISCV modules and other things

Hello @aenrbes,
just wanted to let you know that I made the new RISCV modules visible in the sysfs filesystem.
For that, I also needed to rename them because the module name in Tilck is taken directly from the directory name inside modules and the old names were too generic.
In other words, while it looked great to have modules/rtc and then in riscv/ all the drivers for RISCV, the problem is that the module directory is one thing for the build system / config and the $ARCH sub-directory is just a way to compile only $ARCH-specific code inside it, not as a convenient way to have a different variation of the same module on different architectures. In other words, most of the modules' code should not be in modules/<name>/<arch> but just in modules/<name>.  And the $ARCH subdirectory is supposed to be for the special cases, for example when the same HW device have differences across architectures or assembly code etc.
The reason for that design is to allow unit tests to compile and test that noarch code, as they cannot have arch-specific stuff. And, in general, making the C code portable pushes the introduction of the correct abstractions in the whole project.
Said that, I see and fully understand where the confusion comes from: I placed myself multiple drivers in generic_x86 because I was too lazy to abstract the C code and because I knew that things like kb8042 will never be available for the other architectures anyway.
In conclusion, this is just a FYI for you to understand the reasoning behind my changes. I'll take care of re-organizing the code around and will probably introduce a special file like modules/<name>/module_archs to specify the list of architectures for which the module should be compiled, even most of its C code can be compiled (but not run) everywhere if the HAL is implemented somehow. I'm still thinking about what's best. The goals are:

as much as portable C code as possible (even if it uses HAL macros of funcs)

as much as possible C code testable with unit tests, mocks etc.

don't compile/link modules and code that does not apply to a given architecture into the kernel, even if it's portable, because it's useless. But compile and link it in the noarch "kernel" for unit tests

Vlad

Thank you for explaining this in detail.
At the moment all my work has been merged. This was the first time I had contributed to an open source project in such depth, and it helped me a lot in my career. Thank you for your patience and careful review. Next I'll start trying to port tilck to a real-world chip.

@aenrbes Thank you for contributing!
Your work has been incredibly valuable to this project and to me. I'm sure that will also boost your career as well because it's a remarkable contribution to an operating system project. Very few people could have done it like that, almost completely independently, with little to no guidance.
Any of your work is always welcome here, anytime you want.
Great job!
Cheers,
Vlad


Fixes #RHIROS-1269 - feature flags for backend

PR Title :boom:
Please title this PR with a summary of the change, along with the JIRA card number.
Suggested formats:

Fixes/Refs #RHIROS-XXX - Title
RHIROS-XXX Title

Feel free to remove this section from PR description once done.
Why do we need this change? :thought_balloon:
Please include the context of this change here.
Documentation update? :memo:

[ ] Yes
[ ] No

Security Checklist :lock:
Upon raising this PR please go through RedHatInsights/secure-coding-checklist
:guardsman: Checklist :dart:

[ ] Bugfix
[ ] New Feature
[ ] Refactor
[ ] Unittests Added
[ ] DRY code
[ ] Dependency Added
[ ] DB Migration Added

Additional :mega:
Feel free to add any other relevant details such as links, notes, screenshots, here.

Codecov Report
Patch coverage: 62.29% and project coverage change: -0.56% :warning:

Comparison is base (fb79e9e) 74.07% compared to head (3d36968) 73.51%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #354      +/-   ##
==========================================
- Coverage   74.07%   73.51%   -0.56%
==========================================
  Files          30       31       +1
  Lines        1462     1518      +56
==========================================
+ Hits         1083     1116      +33
- Misses        379      402      +23

Flag
Coverage Δ

unittests
73.51% <62.29%> (-0.56%)
:arrow_down:

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

Files Changed
Coverage Δ

ros/lib/config.py
51.66% <10.00%> (-3.79%)
:arrow_down:

ros/lib/app.py
80.95% <46.66%> (-19.05%)
:arrow_down:

ros/lib/feature_flags.py
73.91% <73.91%> (ø)

ros/api/common/add_group_filter.py
100.00% <100.00%> (ø)

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

I have few questions,

We are using fallback value for unleash flag, this means that if unleash is enabled and for some reason unleash service does not response then we fallback to some value. Now this value is True. This means if unleash is enabled anyhow we are going to consider its enabled even when the unleash service itself is not able to respond. This is what I can see inventory is following as well. Is this fine?
Inventory has bypassed the unleash in the test env, however for us at least I want to execute the groups related unit tests and so I have not bypassed it. This is why we are mocking the unleash enablement. Is this fine?
Locally by default unleash has been bypassed. Is this fine?
If unleash is available and for some reasons rbac ended up not giving us the group details, in that case the current scenario is we show the systems which are not in any group, is this acceptable?

@upadhyeammit do we know why the PR checks are failing or do we want QE to look into it?

/retest

@upadhyeammit do we know why the PR checks are failing or do we want QE to look into it?

Its failing for cache dir permissions, I am having a look!

@upadhyeammit do we know why the PR checks are failing or do we want QE to look into it?

Its failing for cache dir permissions, I am having a look!

I removed it, its not mandatory however I was expecting that it would work
https://docs.getunleash.io/Flask-Unleash/

@upadhyeammit do we know why the PR checks are failing or do we want QE to look into it?

Its failing for cache dir permissions, I am having a look!

I removed it, its not mandatory however I was expecting that it would work
https://docs.getunleash.io/Flask-Unleash/

It seems this doesn't work either, now its creating it under /.cache, checking with appsre

/retest

/retest

/retest

/retest

@upadhyeammit can you please rebase this branch?

@upadhyeammit here are my thoughts 💯

I have few questions,

We are using fallback value for unleash flag, this means that if unleash is enabled and for some reason unleash service does not response then we fallback to some value. Now this value is True. This means if unleash is enabled anyhow we are going to consider its enabled even when the unleash service itself is not able to respond. This is what I can see inventory is following as well. Is this fine?  According to me Yes 👍🏻
Inventory has bypassed the unleash in the test env, however for us at least I want to execute the groups related unit tests and so I have not bypassed it. This is why we are mocking the unleash enablement. Is this fine? +1 with this
Locally by default unleash has been bypassed. Is this fine? +1 with this, I don't see any need of using unleash locally
If unleash is available and for some reasons rbac ended up not giving us the group details, in that case the current scenario is we show the systems which are not in any group, is this acceptable? I have added comments regarding how I think we need to use unleash feature flag, have a look and lets continue the discussion in that thread.

/retest


Type issues

I have tested it recently and found out some issues with types. They seem to be simple so maybe you just didn't went up to fix them

Here it outputs 'a' but cannot the array's elements. When it comes to do it the program waits for up around 5 seconds and exits. When use emit=jit it shows certain error

let arr: Array<any> = [1, 2, 3, 4];
function main() {
    let a: any = "Hello, World!";
    print(a);
    for (let i: int = 0; i < arr.length; i++) {
        print(arr[i]);
    }
}

C:\programming\tsc>tsc --emit=jit
let arr: Array<any> = [1, 2, 3, 4];
function main() {
    let a: any = "Hello, World!";
    print(a);
    for (let i: int = 0; i < arr.length; i++) {
        print(arr[i]);
    }
}
^Z
Hello, World!
PLEASE submit a bug report to https://github.com/ASDAlexander77/TypeScriptCompiler/issues and include the crash backtrace.Stack dump:
0.      Program arguments: tsc --emit=jit
Exception Code: 0xC0000005
#0 0x00007ff9cfa4a6e0 (C:\WINDOWS\System32\ucrtbase.dll+0x5a6e0)
#1 0x00007ff9cfa4a762 (C:\WINDOWS\System32\ucrtbase.dll+0x5a762)
#2 0x0000029e8d94015b

Caused the compiler waite also for around 3-5 seconds and just quit with no messages. It occurs just if insert that line even without main function.

let arr: Array<number> = "";

I will improve it for "any" type.
try this code:
let arr: any[] = [1, 2, 3, 4];
function main() {
    let a: any = "Hello, World!";
    print(a);
    for (let i: int = 0; i < arr.length; i++) {
        print(<string>arr[i]);
    }
}

I would recommend to write something like the following:
const arr : TypeOf<1>[] = [1, 2, 3, 4];
function main() {
    let a = "Hello, World!";
    print(a);
    for (const i of arr) {
        print(i);
    }
}

Caused the compiler waite also for around 3-5 seconds and just quit with no messages. It occurs just if insert that line even without main function.

let arr: Array<number> = "";

this one is working in my latest git version

IDK
C:\programming\tsc>tsc --version
TypeScript Native Compiler (https://github.com/ASDAlexander77/TypeScriptCompiler):
  TSNC version v0.0-pre-alpha46

LLVM (http://llvm.org/):
  LLVM version 17.0.2
  Optimized build.
  Default target: x86_64-pc-windows-msvc
  Host CPU: alderlake

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_32 - AArch64 (little endian ILP32)
    aarch64_be - AArch64 (big endian)
    arm        - ARM
    arm64      - ARM64 (little endian)
    arm64_32   - ARM64 (little endian ILP32)
    armeb      - ARM (big endian)
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    wasm32     - WebAssembly 32-bit
    wasm64     - WebAssembly 64-bit
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64

C:\programming\tsc>tsc --emit=jit
let arr: Array = "";
^Z
C:\programming\tsc>

i used the prebuild release. Possibly you're using own build release and therefore missmatches. And possibly you've already fixed it. Also you could run on linux while i do on windows.

C:\programming\tsc>tsc --emit=jit let arr: Array = ""; ^Z
C:\programming\tsc>

here is missing
function main() {}

it should show the error:
tsc: error: JIT invocation failed, error: Symbols not found: [ _mlir_main ]
Program aborted due to an unhandled Error: ...

idk when i add to the release i installed it always aborts without depend what's more is there

and even no matter what type is within Array<>

in other words you can cast "any" type into any but you can't cast from any into other type that type was stored. for example
const v1: number = 1;
const any1: any = v1; // it is OK
const v2: number = any1; // it is still OK
const s1: string = any1; // it is ***NOT OK***;
const s2: string = <string>any1; // it is OK

here is example of unboxing from any:
function __as<T>(a: any) : T
{
    if (typeof a == 'number') return <T>a; \
    if (typeof a == 'string') return <T>a; \
    if (typeof a == 'i32') return <T>a; \
    if (typeof a == 'class') if (a instanceof T) return <T>a; \
    return <T>null;
}

so u can use it as
const s3: string = __as(any1);

improved code in the latest commit, it will be included in the next release

in the next release unboxing any type from any will be OK.
	let a = 1;
	let any1 = a;
	let s: string = any1;

	print(s);


Convenience methods for deep iterations over OpenAPI

Lots of our in-house rules involve deeply iterating over the model and filtering down to the elements we need to raise violations for. Prior to the OpenAPI 3 change we used some extension methods to make life easier but I got pushback when I suggested porting them here. Now that we've migrated to the Context based checks I thought I'd offer up the latest evolution of our extension methods and see whether they might be deemed useful here.
For example here's the guts of a rule which ensures that collections return a JSON array:
@Rule(
        ruleSet = InHouseRuleSet::class,
        id = "CollectionsReturnArrays",
        severity = Severity.MUST,
        title = "Collection Resources Return Arrays"
)
class CollectionsReturnArrays {
    @Check(Severity.MUST)
    fun validate(context: Context): List<Violation> =
        context.api.paths.orEmpty()
            .filter { (path, item) ->
                detectCollection(context.api, path, item)
            }
            .flatMap { (_, item) ->
                item.readOperationsMap()
                    .filter { (method, _) ->
                        method == PathItem.HttpMethod.GET
                    }
                    .flatMap { (_, op) ->
                        op.responses
                            .filter { (status, _) ->
                                status != "default" &&
                                        Integer.parseInt(status) in 200..299
                            }
                            .flatMap { (_, response) ->
                                response.content
                                    .filter { (_, mediaType) ->
                                        mediaType.schema == null || mediaType.schema !is ArraySchema
                                    }
                                    .map { (_, mediaType) ->
                                        context.violation("expected 'array' but found '${mediaType.schema.type}'", mediaType)
                                    }
                            }
                    }
            }
}

Which can be rewritten to be much more focused and concisely, without the error prone nesting, as:
@Rule(
        ruleSet = InHouseRuleSet::class,
        id = "CollectionsReturnArrays",
        severity = Severity.MUST,
        title = "Collection Resources Return Arrays"
)
class CollectionsReturnArrays {
    @Check(Severity.MUST)
    fun validate(context: Context): List<Violation> =
        context.validateResponseContents(
            pathFilter = { (path, item) -> detectCollection(context.api, path, item) },
            operationFilter = { (method, _) -> method == PathItem.HttpMethod.GET },
            responseFilter = { (status, _) -> status != "default" && Integer.parseInt(status) in 200..299 },
            contentFilter = { (_, mediaType) -> mediaType.schema == null || mediaType.schema !is ArraySchema }
        ) { (_, mediaType) ->
            listOf(context.violation("expected 'array' but found '${mediaType.schema.type}'", mediaType))
        }
}

Assuming the following methods are added to Context:
private fun Context.validateResponseContents(
        pathFilter: (Map.Entry<String, PathItem>) -> Boolean = { true },
        operationFilter: (Map.Entry<PathItem.HttpMethod, Operation>) -> Boolean = { true },
        responseFilter: (Map.Entry<String, ApiResponse>) -> Boolean = { true },
        contentFilter: (Map.Entry<String, MediaType>) -> Boolean = { true },
        action: (Map.Entry<String, MediaType>) -> List<Violation?>
): List<Violation> = validateResponses(pathFilter = pathFilter, operationFilter = operationFilter, responseFilter = responseFilter) { (_, response) ->
    response.content
            .orEmpty()
            .filter(contentFilter)
            .flatMap(action)
            .filterNotNull()
}

private fun Context.validateResponses(
        pathFilter: (Map.Entry<String, PathItem>) -> Boolean = { true },
        operationFilter: (Map.Entry<PathItem.HttpMethod, Operation>) -> Boolean = { true },
        responseFilter: (Map.Entry<String, ApiResponse>) -> Boolean = { true },
        action: (Map.Entry<String, ApiResponse>) -> List<Violation?>
): List<Violation> = validateOperations(pathFilter = pathFilter, operationFilter = operationFilter) { (_, operation) ->
    operation.responses
            .orEmpty()
            .filter(responseFilter)
            .flatMap(action)
            .filterNotNull()
}

private fun Context.validateOperations(
        pathFilter: (Map.Entry<String, PathItem>) -> Boolean = { true },
        operationFilter: (Map.Entry<PathItem.HttpMethod, Operation>) -> Boolean = { true },
        action: (Map.Entry<PathItem.HttpMethod, Operation>) -> List<Violation?>
): List<Violation> = validatePaths(pathFilter = pathFilter) { (_, path) ->
    path.readOperationsMap()
            .orEmpty()
            .filter(operationFilter)
            .flatMap(action)
            .filterNotNull()
}

private fun Context.validatePaths(
        pathFilter: (Map.Entry<String, PathItem>) -> Boolean = { true },
        action: (Map.Entry<String, PathItem>) -> List<Violation?>
): List<Violation> = api.paths
        .orEmpty()
        .filter(pathFilter)
        .flatMap(action)
        .filterNotNull()

Would such an addition be welcome here upstream in Zally or should I keep them downstream in house? Alternate acceptable suggestions also welcome. @maxim-tschumak @netme @fmueller @mkulak

I like your proposal @roxspring. Let's do this!

btw, @roxspring, how specific are your in-house rules? Does it make sense to include them into the open source version of Zally (as a separated Rule Set)? I think every additional rule/check is beneficial for potential Zally users.

Current progress in checklist for:

[x] fun Context.validatePaths(): List
[x] fun Context.validateOperations(): List
[x] fun Context.validateResponses(): List
[ ] fun Context.validateResponseContents(): List

TBH I'm tempted to close the issue now - the 3 implemented methods clearly establish the suggested pattern and there are plenty other variations that could be written after the 4th so other than the opening example there's no particular reason for 4 to be deemed critical.


📝 Nested arrow functions are split on multiple lines

Environment information
main

Configuration
No response
Playground link
https://biomejs.dev/playground/?indentStyle=space&quoteStyle=single&trailingComma=none&code=YwBvAG4AcwB0ACAAbQBlAHMAcwBhAGcAZQBzACAAPQAgAHMAdABkAG8AdQB0AAoACQAJAC4AcwBwAGwAaQB0ACgAJwBcAG4AJwApAAoACQAJAC4AZgBpAGwAdABlAHIAKAAoAGwAbgApACAAPQA%2BACAAIQAhAGwAbgAuAHQAcgBpAG0AKAApACkACgAJAAkALgBtAGEAcAAoACgAbABuACkAIAA9AD4ACgAJAAkACQBsAG4ACgAJAAkACQAJAC4AcgBlAHAAbABhAGMAZQAoAC8AWwA92IDeAyVdAC8AZwAsACAAJwAnACkACgAJAAkACQAJAC4AcgBlAHAAbABhAGMAZQAoAC8AXABzACsALwBnACwAIAAnACAAJwApAAoACQAJAAkACQAuAHQAcgBpAG0AKAApAAoACQAJACkAOwA%3D
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

FYI the issue comes from here: https://github.com/withastro/adapters/pull/79/files#diff-1d2a2b56ad20e7e5b13936929d10bebf30d56ffa7cdc64f686dff4ae6cfafb60

I can take a look at this one. This does not seem to have anything to do with nested arrow function but rather something with call chains.
https://biomejs.dev/playground/?indentStyle=space&quoteStyle=single&trailingComma=none&code=YQAuAHMAKAAvAD3YgN492IDeLwApAC4AcwAoACkALgBzACgAKQA%3D


vcpkg crashes on missing license post-build lint warning

Describe the bug
Fail to build private package without copyright/license on the new 2023.01.09 release
Environment

OS: Ubuntu 22.04
Compiler: gcc-12 and clang-15

To Reproduce
Steps to reproduce the behavior:

have a private package from a private registry, without a copyright/license
Upgrade to the new release (previous release 2022.11.14 works). (Only need to have the checkout newer, the builtin-baseline does not affect the result)
Run cmake configure step, and use the VCPKG_TOOLCHAIN to consume the library mentioned above.

Expected behavior
To have the package build.
Failure logs
For our coverage build we use GCC:
Preset CMake variables:

  CMAKE_BUILD_TYPE="Debug"
  CMAKE_CUDA_ARCHITECTURES="all-major"
  CMAKE_CXX_COMPILER_LAUNCHER="ccache"
  CMAKE_CXX_FLAGS="-std=c++20 -ffold-simple-inlines -pedantic -pedantic-errors -Wall -Wextra -Wpedantic -Wunreachable-code -Wuninitialized -Wcast-qual -Wshadow -Wformat=2 -Wundef -Wdeprecated -Wdouble-promotion -Wold-style-cast -Wno-ctad-maybe-unsupported -fno-common -Wno-unused-local-typedefs -Wno-unknown-pragmas -Winvalid-pch"
  CMAKE_CXX_FLAGS_DEBUG="-g -Og --coverage"
  CMAKE_CXX_STANDARD="20"
  CMAKE_C_COMPILER_LAUNCHER="ccache"
  CMAKE_EXE_LINKER_FLAGS_DEBUG="--coverage"
  CMAKE_EXPORT_COMPILE_COMMANDS:BOOL="TRUE"
  CMAKE_INSTALL_PREFIX:PATH="/opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/bin"
  CMAKE_MAP_IMPORTED_CONFIG_DEBUG="RelWithDebInfo;Release;Debug;"
  CMAKE_SHARED_LINKER_FLAGS_DEBUG="--coverage"
  CMAKE_TOOLCHAIN_FILE="/opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg/scripts/buildsystems/vcpkg.cmake"
  CMAKE_UNITY_BUILD:BOOL="TRUE"
  CMAKE_UNITY_BUILD_BATCH_SIZE="16"
  THREADS_PREFER_PTHREAD_FLAG:BOOL="TRUE"
  LINKER_VARIABLE="lld"

Preset environment variables:

  CC="gcc-12"
  CUDAHOSTCXX="gcc-11"
  CUDA_PATH="/usr/local/cuda-11.7"
  CXX="g++-12"
  VCPKG_ROOT="/opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg"

-- Running vcpkg install
Fetching registry information from https://github.com/our_company/vcpkg-registry (main)...
Detecting compiler hash for triplet x64-linux...
The following packages will be built and installed:

...

Installing 130/131 our_lib:x64-linux...
Building our_lib[core]:x64-linux...
-- Installing port from location: /home/runner/.cache/vcpkg/registries/git-trees/b0c2acb052eadf59044b4618921b798b663a2e85
-- Using cached /opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg/downloads/our_lib-aacef56df5ae3706481bc5bb8c4fe880bd8f0ee7.tar.gz
-- Cleaning sources at /opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg/buildtrees/our_lib/src/80bd8f0ee7-a93f7f24c0.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg/downloads/our_lib-aacef56df5ae3706481bc5bb8c4fe880bd8f0ee7.tar.gz
-- Using source at /opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/vcpkg/buildtrees/our_lib/src/80bd8f0ee7-a93f7f24c0.clean
-- Configuring x64-linux
-- Building x64-linux-dbg
-- Building x64-linux-rel
-- Building x64-linux-dbg
-- Building x64-linux-rel
-- Performing post-build validation
INTERNAL ERROR: failed to format default format string for index 649
format string: The software license must be available at ${CURRENT_PACKAGES_DIR}/share/{spec}/copyright
-- Running vcpkg install - failed
CMake Error at vcpkg/scripts/buildsystems/vcpkg.cmake:883 (message):
  vcpkg install failed.  See logs for more information:
  /opt/actions-runner/_work/our_consuming_lib/our_consuming_lib/build/vcpkg-manifest-install.log
Call Stack (most recent call first):
  /usr/local/share/cmake-3.25/Modules/CMakeDetermineSystem.cmake:124 (include)
  CMakeLists.txt:8 (project)

(I have changed the names of our consuming library and the library we consume)
Additional context
My guess is that its failing at injecting {spec} here.
I was told to tag @vicroms :)

Easiest repro is to try to install a package without a license. The localized string contains an unescaped sequence that vcpkg fails to format properly when trying to print the warning.

@vicroms Shouldn't this issue stay open until a new tool release is maded (available to boostrap)?

Yes, it should. It auto-closed due to being referenced on the tool PR.

@vicroms @FrankXie05 What is the expected ETA for a new tool release?  I just ran into this and am now in a bit of a build mess... Forced to move forward because of #28896 but now this fails...

@senstar-nross
I'd say soon. But in the meantime, you could modify the port to install a dummy copyright file as a workaround.

@vicroms Thanks, it was not my port but then I went and looked I found that the copyright issue was fixed in the latest port.  The baseline in vcpkg is also updated to that port version.
I thought if the baseline was updated then I would get that version.  I guess I am still a bit confused as to how baselines work.
The port in question is quirc. I do not depend on it directly it is a dependency of opencv. OpenCV does not specify a version>= or override AFAIK.  When I build with the lastest vcpkg with the baseline hash set to the latest commit it chooses to build quirc 1.1#2 not 1.1#3 (which is the version specified in the baseline). If I add quirc 1.1#3 to my vcpkg.json it uses that version.

vcpkg-tool was updated 4 days ago, so I think we can close this 👍 Ill verify fix tomorrow

It works 🎉 Feel free to close 👍


Enhance Top-Level API Endpoints with Count, Search, and Pagination Functionality for Improved User Experience

Current Behavior

We need top-level api endpoint to be able to search resources, paginate the results, and aggregate resources.
For eg. /api/meshmodels/models do not return the models count, and search for models particularly.

We need an api endpoint that returns relationships across all models.

Desired Behavior

All the top-level endpoints need to return resource counts, allow resource to be searched and results be paginated.

Contributor Guides and Handbook

🛠 Meshery Build & Release Strategy
📚 Instructions for contributing to documentation

Meshery documentation site and source

🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@UsmanDev09 can I work on this?

I would like to work on this issue

@anj20 sure.

@anj20 this item is listed as a blocker for progress on the MeshModel Browser effort. I'm reaching out to inquire as to how you're progressing. Given the urgency of this item and it being your first contribution, I wonder if we might need to bring some additional support to bear. What do you think? How far along are you on this?
@meshery/maintainers


Does not work on Windows 10 with type: sshfs enabled

Hello,
I just downloaded and installed, on Windows 10 64bit, all the tools needed for Homestead Improved:

VirtualBox 5.2.8
Vagrant 2.0.3
Homestead Improved
the laravel/homestead box
But when I run vagrant up I get this error and the machine does not start:

vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'laravel/homestead'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: Setting the name of the VM: Homestead_default_1521969553735_85762
==> default: Destroying VM and associated drives...
C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/mixin_synced_folders.rb:137:in `block in synced_folders': Internal error. Report this as a bug. Invalid: sshfs (RuntimeError)
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/mixin_synced_folders.rb:125:in `each'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/mixin_synced_folders.rb:125:in `synced_folders'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/synced_folder_cleanup.rb:19:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/synced_folders/nfs/action_cleanup.rb:19:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/destroy_unused_network_interfaces.rb:18:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/destroy.rb:14:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/forced_halt.rb:20:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/discard_state.rb:15:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/env_set.rb:19:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/provisioner_cleanup.rb:25:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/import.rb:90:in `recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:67:in `block in recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:64:in `each'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:64:in `recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:61:in `recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:67:in `block in recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:64:in `each'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:64:in `recover'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:53:in `rescue in call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:28:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/box_check_outdated.rb:79:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/match_mac_address.rb:19:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/discard_state.rb:15:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/import.rb:74:in `import'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/import.rb:13:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/prepare_clone_snapshot.rb:17:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/prepare_clone.rb:15:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/customize.rb:40:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builtin/call.rb:53:in `call'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/plugins/providers/virtualbox/action/check_virtualbox.rb:26:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/warden.rb:34:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/builder.rb:116:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `block in run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/util/busy.rb:19:in `busy'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/action/runner.rb:66:in `run'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/machine.rb:227:in `action_raw'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/machine.rb:202:in `block in action'        from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/environment.rb:592:in `lock'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/machine.rb:188:in `call'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/machine.rb:188:in `action'
       from C:/HashiCorp/Vagrant/embedded/gems/2.0.3/gems/vagrant-2.0.3/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

For it to work, I have to open the Homestead.yaml file and remove (or comment) the type: sshfs part, like this:
folders:
    - map: .
      to: /home/vagrant/Code
      #type: sshfs

Am I wrong in something? Do I need to install some plugin?
Thanks

My bad, sorry. That's a recent addition. It can be solved with a plugin but on Windows it's better to just remove it. I'll remove it from the file.

Resolved


.NET Core support

both existing .NET Fulll Framework 4.x and .NET Core 2.x are side-by-side supported.

Have tested this code and works well.


Where and forEach method missing in Get-member

I am not sure if it's a bug.
Steps to reproduce
$Array = 1,2,3,4,5
Get-member -inputobject $Array
Expected behavior
I expected the Where and the ForEach method would show in a Get-member
Actual behavior
Where and ForEach method don't show in a Get-member
Environment data

$PSVersionTable
PSVersion                      6.1.0-preview.4
PSEdition                      Core
GitCommitId                    6.1.0-preview.4
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

These methods are PSv4+ and it took a while to even get them documented - now they are, as part of Get-Help about_Arrays
Similarly, the implicit .Count and .Length properties are mentioned there.
What these have in common is that they're part of the plumbing, if you will: PowerShell makes them available on instances of any type, so as to facilitate unified handling of collections and scalars; e.g.:
# Invoke .ForEach on string *scalar*
PS> 'foo'.ForEach({ "Hi, $_." }
Hi, foo.

# Invoke .Count on an integer *scalar*
PS> (666).Count
1

So there is some justification in omitting them from reflecting on a given type's members, given they're not really members of any individual type.
That said, perhaps they could be discovered via new -View mode, such as Get-Member -View Universal - though discovering that view mode may in itself be a challenge.
I guess showing them by default is an option, but I wonder if that introduces too much noise.


iOS app: Paper key screen silently disappears when switching to another app

The paper key process after the initial login is broken.
Because I didn't have an actual piece of paper with me when I tried the app (and writing down things like that on paper is a weird idea anyway) I opened 1Password to create a secure note there. Unfortunately, when I returned to Keybase the app had already silently moved on to the next screen without me having confirmed anything.

Same on Android.


How to send non-collapsible message via Firebase console?

I understand that at present the Firebase console can only send notification messages which are collapsible by default. How to make them non-collapsible, or how to unset the collapse_key parameter?

Hi,
If I understand correctly, you want to treat Notifications as non-collapsible messages, right?
Well, data messages are non-collapsible as far as I know.  So if I were you, I would remove notification part, and deliver everything to the data.
Then from your OnMessageReceived method, you can produce a custom notification.

Thank you for your answer ioannisa, that's exactly what I'd like to do.
But afaik, and according to the documentation, the firebase console, that is the notification composer, cannot send pure data messages at the moment.
Leaving "message text" field empty and putting everything into the custom data fields would be great but the send button is grayed out then, which is the correct behaviour according to the docs.
Yet, I'd like to use this notification composer in the firebase console which is great except for this one missing checkbox ala "make this a data message" and/or "make this message non-collapsible".

Ok, I see...
Well in that case, you can address the problem by sending yourself the messages, without using the actual dashboard.  One good method is to do that with PHP, or if you are confident, you can use the firebase cloud functions.
I will give you the "easy" method with the php approach.  By utilizing this php approach, you can send messages that contain only data....
`<?php
#API access key from Google API's Console
define( 'API_ACCESS_KEY', 'YOUR_API_KEY_HERE' );
define( 'PROJECT_ID', 'YOUR_PROJECT_ID_HERE' );
#to find the api key and project id, click the "gear" next to the "overview'.
Then go to the "Project Settings"->"Cloud Messaging"
your api key will be the "Server Key" (yes, that long thing)
your project_id will be the "sender id"
#by  defining those values above, you have connected your php script to your firbase project

little later on, at the "to" section I send to a topic called "my_topic"
if you want to target a topic follow the pattern: 'to' => '/topics/whatever_topic_you_want'
#if you want to target individual device then follow: 'to' => 'whatever_device_token_you_have'

hope this helps :)
#prep the bundle
$fields = array
		(
			'to'		=> '/topics/my_topic,
			'data' => array(
				'title' => 'my_title',
				'message' => 'my_message',
			),
			'time_to_live' => 0
		);

$headers = array
		(
			'Authorization: key=' . API_ACCESS_KEY,
			'Content-Type: application/json',
			'project_id: ' . PROJECT_ID
		);

#Send Reponse To FireBase Server
$ch = curl_init();
curl_setopt( $ch,CURLOPT_URL, 'https://fcm.googleapis.com/fcm/send' );
curl_setopt( $ch,CURLOPT_POST, true );
curl_setopt( $ch,CURLOPT_HTTPHEADER, $headers );
curl_setopt( $ch,CURLOPT_RETURNTRANSFER, true );
curl_setopt( $ch,CURLOPT_SSL_VERIFYPEER, false );
curl_setopt( $ch,CURLOPT_POSTFIELDS, json_encode( $fields ) );
$result = curl_exec($ch );
curl_close( $ch );
#Echo Result Of FireBase Server
echo $result;`

Thank you for the help and the codesample. Probably I have to do something like that although the point was that I'd like to use the console cause in the end, non-it colleagues must be able to send the messages on their own.
It's a bit disappointing having to rebuild the firebase console just to add that extra option to send data messages. The more so since the devs know about the issue and might add that feature to the console at some point. Would be great to know if there is an update planned in the near future.

@ioannisa thanks for jumping in!
@accursedm0 we hear you, we also want to add more capabilities to the console.  For now though the information above is correct, you'll need to use the API if you want to send data messages.  I hope you get something working!


Add license headers and check/update via Maven

Build triggered. sha1 is merged.

Build triggered. sha1 is merged.

Build started sha1 is merged.

Build started sha1 is merged.

Build finished.

Build triggered. sha1 is merged.

Build triggered. sha1 is merged.

Build started sha1 is merged.

Build finished.

License headers all applied properly - thanks!

Build started sha1 is merged.

License headers all applied properly - thanks!

Current coverage is 33.33% (diff: 100%)

Merging #26 into master will not change coverage

@@             master        #26   diff @@
==========================================
  Files            16         16
  Lines           219        219
  Methods           0          0
  Messages          0          0
  Branches         20         20
==========================================
  Hits             73         73
  Misses          134        134
  Partials         12         12

Powered by Codecov. Last update 9de3f68...822a210

Build triggered. sha1 is merged.

Build triggered. sha1 is merged.

Build started sha1 is merged.

Build started sha1 is merged.

Build finished.

License headers all applied properly - thanks!