How does #[runtime_interface] convert trait methods into HostFunctions?

I'm researching substrate runtime, I found out that #[runtime_interface] is used to implement HostFunctions, but its implementation is too complicated.
Could you describe #[runtime_interface] implementation details？

Have you read the docs of the sp-runtime-interface crate? There is everything documented, with examples.


Imporve styles with support for hex colors

I have added short portion to handle hex colors in style.
It's my first time forking and creating pull request for merge in an opensource repository. If there are any non-standard actions kindly let me know.

Hey @Muhammad-Ijlal , thanks for making a PR for this. Looks good to me 😄
This repository isn't organised very well currently; suggestions for improvement welcome.


3.1.1 nuget package fails cert for Windows8.1 Store app

Building with 3.1.1 from nuget with VS 2015 Update 3 and latest tools fails with:
Supported APIs
Error Found: The supported APIs test detected the following errors:
This API is not supported for this application type - Api=D3D11On12CreateDevice. Module=d3d11.dll. File=SharpDX.Direct3D11.dll.
This API is not supported for this application type - Api=D2D1GetGradientMeshInteriorPointsFromCoonsPatch. Module=d2d1.dll. File=SharpDX.Direct2D1.dll.
Impact if not fixed: Using an API that is not part of the Windows SDK for Windows Phone Store apps violates the Windows Phone Store certification requirements.
I tried submitting officially just in case and it failed for the same reason.  I'm not actually calling either of these, so I have to think it's not related to my code.
edit:  If I remove those two externs from the Functions.cs of each assembly, my app passes.  It would sure be nice if the nuget package just worked though...

I'm sorry, but you will have to try to use an older version of SharpDX for now. There is no plan to re-introduce support for Windows Phone. Currently, SharpDX should only support desktop and UWP apps.
Keeping this issue open because while the D3D11On12CreateDevice is a certified API I'm not sure for D2D1GetGradientMeshInteriorPointsFromCoonsPatch... PR is welcome if not.


feature/force-token-refresh

Explain your changes
Addresses #30
Checklist

[X] I have read the “Pull requests” section in the contributing guidelines.
[X] I agree to the terms within the code of conduct.

🛟 If you need help, consider asking for advice over in the Kinde community.

@atifcppprogrammer After testing, I found that the forceTokenRefresh method simply returns the currently active token without any changes. Consequently, I'm left wondering what its purpose or usefulness is.

Hi @trunges21, new tokens will be returned if the "user details" are changed, (for e.g. you can see this after update the given_name or family_name of the current user).


How to inference the LVIS-trained model on other datasets, such as Objects365, COCO?

Hi,
You can find some references here.
Best,
Xingyi


Improving SEO

I will :

[ ] Add missing meta description keywords,
[ ] Follow  web.dev  seo recommandations

Good point!

@devnullone It is done!

Yes, I approve your PR! Thanks @roselam3


bug: alias lifting produces broken code when aliases conflict with other existing usages

Versions

Elixir: 1.17.1
Styler: 1.0.0

Example Input
Before running mix format:
defmodule SomeModule do
  def do_something(token) do
    # Guardian.Token.Jwt is a library module in the guardian library
    # MyApp.Guardian is a module defined inside my application
    Guardian.Token.Jwt.decode_token(MyApp.Guardian, token)
  end

  def do_something_else do
    Application.get_env(:my_app, MyApp.Guardian)
  end
end

Stacktrace / Current Behaviour
After running mix format:
defmodule SomeModule do
  alias MyApp.Guardian

  def do_something(token) do
    # elixir now can't find the Guardian.Token.Jwt module because it is
    # looking for MyApp.Guardian.Token.Jwt which is not a real module
    Guardian.Token.Jwt.decode_token(Guardian, token)
  end

  def do_something_else do
    Application.get_env(:my_app, Guardian)
  end
end

thanks for the report! definitely something styler's supposed to notice, sorry that it's got a bug there

hey @jsw800 , i wasn't able to reproduce the issue with the snippet you gave me:
https://github.com/adobe/elixir-styler/compare/me/fix-193?expand=1
tests still pass. is there more context you can provide?

Ah sorry about that - I had kinda changed it from my original code so as to not share my actual source code. It looks like the difference between my original code and the example I shared is that MyApp.Guardian was actually MyApp.Something.Guardian. When the code looks like this, the test fails as expected:
defmodule SomeModule do
  @moduledoc false

  def do_something(token) do
    # Guardian.Token.Jwt is a library module in the guardian library
    # MyApp.Guardian is a module defined inside my application
    Guardian.Token.Jwt.decode_token(MyApp.Something.Guardian, token)
  end

  def do_something_else do
    Application.get_env(:my_app, MyApp.Something.Guardian)
  end
end

ty, got it now :)


Is it possible to convert this shader into a standard shader graph?

Since shader graph is now supported for non-URP project, I've been trying to convert this URP shader into a non-URP shader graph. But I keep encountering error with the custom node in the shader graph.
Before I proceed even further, is it even possible to have this shader as a shader graph for non-URP project?

Assets\SimplestarGame\SimpleURPToonLitOutlineExample\Resources\Unity-Technologies\ShaderGraph-Custom-Lighting\Includes\CustomLighting.hlsl
#ifndef CUSTOM_LIGHTING_INCLUDED
#define CUSTOM_LIGHTING_INCLUDED

#define SHADERGRAPH_PREVIEW // added line

void MainLight_float(float3 WorldPos, out float3 Direction, out float3 Color, out float DistanceAtten, out float ShadowAtten)

I was able to resolve the build error, but I will not support it until Built-in since it has been built for URP.

I see. I'm not too familiar with shader programming. I'm more of a shader graph guy. So this should be a good challenge for me to take.
Would you mind if I ask a thing or two if I found some errors along the way?

It is my understanding that there is indeed shader code that works with both... but the shader code in this repository will not work without a drastic fix. I think it is a difficult task to tackle.
I am not sure I can answer your question.


Display a button to show if a lobby is public or not and to change between the two options.

https://github.com/sopra-fs23-group-40/Client/commit/8929941829b4f00b2390cee40f18d2dcc3c034c1


Clarify which versions of Python are supported

My sense is that this will work in Python 3.2 and later but not in Python 2.  Is that correct?  It would be useful if that was clearly stated in both the readme and in the pypi record.

I can confirm It works on python2.7.
@cclauss futures for python 2 o/ :D https://github.com/agronholm/pythonfutures

I can confirm that it doesn't pip install successfully in python 3.3. :(

Yup, I need to document that in the README -- it is not intended to work for python3 because it takes advantage of python2 specific features (namely old-style Python classes) to make the magic work. Sorry @chadgh and @cclauss

Added a few more characters to the README to specify Python 2.7+.  Hopefully that's sufficient.
Thanks for opening this issue @cclaus!


Update roadmap + instructions for assigning issues

@wtam2018 indicated that they were interested in working on an issue,
but weren't sure how to assign the issue to themselves. @vdemeester
helped out but it still wasn't clear what the process is.
This commit adds some info about the process - unfortunately we are
still limited by the groups the user is in - it would be nice if any
user could assign issues to themselves, but this will have to do for
now.
I also updated the roadmap since those docs were in the same place.
Removed the project board since we are using zenhub now.

Ready for another look! :D

/lgtm


[Relay][Frontend][ONNX] Support auto_pad in Conv

Support auto_pad attribute in ONNX Conv/ConvTranspose op converters, infer pads shape for auto_pad.
Fixes #3608.

please retrigger CI

Hi @abuccts
Please add a test case to let future testers run your test case when they need to.
many thanks,

ping @abuccts Could you please add a test when you have time?

would be great if someone can take over, @cchung100m perhaps?

Hi @tqchen
Sure, it is my pleasure to continue this work. :)

Close by #4563


url is undefined or null inside resolveUrl(url)

Just downloaded easyXDM-<IP_ADDRESS> - and created a simple socket based on the example showed on the documentation just changing the location of the "name.html" for some reason I get an error inside the function resolveUrl since url is null.
quick fix:
url = (url)? url.replace(reDoubleSlash, "$1/") : '';

I had the same issue while initializing easyXDM while being not inside an iframe...
I fixed it with the following if statement (check if inside iframe)
//check if inside iframe
if ( window.location !== window.parent.location ) {
     var socket = new easyXDM.Socket({
          onReady:  function(){
               socket.postMessage(document.body.scrollHeight)
          }
     });
}


How to use withUpdateValueCheck

Hi,
I'm trying to set up a system where it uses Google's priority recommendations:
- Minor UI improvements: Low-priority update; request neither a flexible update nor an immediate update. Update only when the user isn't interacting with your app.
- Performance improvements: Medium-priority update; request a flexible update.
- Critical security update: High-priority update; request an immediate update.

How do I use withUpdateValueCheck to accomplish this?

P.S. Why use breakers at all? Just to have your (base) activity run flexible updates every time (easier to set up) then use breaker to interrupt

I understand what the breakers are for.
How do I implement them with Kotlin? This is very new territory for me.

When flexible update runs it gets AppUpdateInfo from google and passes it to the callback. There you check the data and return true if you want to proceed with update.

Can you send some sample Kotlin of this implementation, please?

@CompuGenius, here you go. Check the sample code in the commit above ⬆

Mmm... Not by using this library, unfortunately. This one was intended to be used along with your own server logic.


constants

Description
Requires more investigation. Looks like openapi doesn't support 'const' like json-schema does. Instead probably only good option is to use an enum with a single value.

Might be good idea to look into: @openapi-contrib/json-schema-to-openapi-schema


Support for multiple param builder method

Could you give a code sample of what you were thinking this would support so that we know in the future what it is that you were thinking we could support.


update login-view for code service to submit the form

 update login-view for code service to submit the form


Night orders are wrong

Navigate to the night order on any script:

You'll notice that the evil team comes last in the night order, even though all evil players should act before most good players.

Looks like the nightsheet.json I was getting from https://script.bloodontheclocktower.com changed, fixing my code to handle this now.

Thanks for pointing this out! Should be fixed now.

Thank you!


Polyfills not working in prod-mode

We have multiple iPod Touch 4th Generation (with iOS 9.3.5) and wanted to release a new internal VueJS-Based mobile app. All tests worked on newer devices but failed on the old devices. I then found laravel-mix-polyfill as a possible solution.
I have a very unusual situation with laravel-mix 6 and the polyfills:

If I run npm run dev, all scripts are working on iOS 9 (in Safari 9):
If I run npm run prod, Vue.JS won't work

Because of the old iOS version (no upgrade available) I can not debug Safari on Mac OS X Big Sur - so unfortunately there is no error log available. Otherwise I probably just can't get the setup right 😋
The package.json:
{
    "private": true,
    "scripts": {
        "dev": "npm run development",
        "development": "mix",
        "prod": "npm run production",
        "production": "mix --production",
        "watch": "mix watch",
        "watch-poll": "mix watch -- --watch-options-poll=1000",
        "hot": "mix watch --hot"
    },
    "devDependencies": {
        "axios": "^0.21.1",
        "bootstrap": "^4.6.0",
        "cross-env": "^7.0.3",
        "jquery": "^3.5.1",
        "laravel-mix": "^6.0.19",
        "laravel-mix-polyfill": "^3.0.1",
        "lodash": "^4.17.21",
        "popper.js": "^1.12",
        "resolve-url-loader": "^4.0.0",
        "sass": "^1.32.8",
        "sass-loader": "^12.1.0",
        "tailwindcss": "^2.1.4",
        "vue": "^2.6.12",
        "vue-loader": "^15.9.5",
        "vue-template-compiler": "^2.6.12"
    },
    "dependencies": {
        "@tinymce/tinymce-vue": "^3.2.8",
        "@trevoreyre/autocomplete-vue": "^2.2.0",
        "autoprefixer": "^10.2.5",
        "bootstrap-colorpicker": "^3.2.0",
        "bootstrap-vue": "^2.21.2",
        "dayjs": "^1.10.4",
        "echarts": "^4.9.0",
        "editor.md": "^1.5.0",
        "ext-json": "^1.0.1",
        "jquery-ui": "^1.12.1",
        "laravel-echo": "^1.10.0",
        "portal-vue": "^2.1.7",
        "pusher-js": "^7.0.3",
        "stream": "^0.0.2",
        "tinymce": "^5.7.0",
        "v-calendar": "^2.3.2",
        "vue-echarts": "^5.0.0-beta.0",
        "vue-organization-chart": "^1.1.6",
        "vue-router": "^3.5.1",
        "vue-simplemde": "^2.0.0",
        "vuex": "^3.6.2",
        "xml-js": "^1.6.11",
        "zepto": "^1.2.0"
    },
    "browserslist": [
        "defaults",
        "iOS 9"
    ]
}

The webpack.mix.json:
mix.js('resources/js/app.js', 'public/js')
    .vue()
    .sass('resources/sass/app.scss', 'public/css')
    .extract()
    .polyfill({
        enabled: true,
        useBuiltIns: "usage",
        targets: false
    });

Does anybody have a hint, how to resolve this error?
Thanks in advance. Kind regards,
Cris

I am also having this issue - my polyfills work fine (I'm trying to polyfill for IE11) in dev mode, but when compiling for prod, they stop working.

Removing .extract() worked for me - it was the vendor.js file that was not getting polyfills, so if I stop extracting the vendor code, the regular combined bundle works fine.  It is a shame not to be able to extract the vendor modules, but for now it's more important for me to be able to polyfill for IE11.
Hopefully this bug gets fixed, but I wanted to share our solution as it might provide more information or help others with the same issue.

On further tests I noticed that removing extract() worked as expected - but still only in dev-mode. Furthermore I completely removed the polyfill and the script still worked in dev-mode.
So this could be an issue in laravel-mix, removing some needed script parts while minifying. I will open an issue there 🙂


add zh-hans translator

Blitz is awesome!  I wish I had the opportunity to become a member of the Chinese document translators.
Thank you.

Welcome 😄


Active Directory Integrated Azure auth

ahh this is what i wanted in #4437 ! from microsoft:
# Connect to your database (Azure SQL database).
$serverName = "<Azure SQL server name>.database.windows.net"
$databaseName = "<database name>"
$connStr = "Server = " + $serverName + "; Database = " + $databaseName + "; Authentication = Active Directory Integrated"
$connection = New-Object Microsoft.SqlServer.Management.Common.ServerConnection
$connection.ConnectionString = $connStr
$connection.Connect()
$server = New-Object Microsoft.SqlServer.Management.Smo.Server($connection)
$database = $server.Databases[$databaseName]

We'd add this to Connect-DbaInstance somehow and I assume similar approaches can be used for:

We can add an Authentication parameter and also auto detect for .database.windows.net
So then if (-not $Authentication -and Sqlinstance -match database.windows.net)

also make sure that a user with teeny perms and no access to default db can login

As you already discovered the DEFAULT_DATABASE option is not available in SQL Azure. So if you cannot change the connection string of your application in which you would normally specify the database name, you are stuck to master.

Note that if you try to manually change a user's default database from sql via ALTER LOGIN <username> WITH DEFAULT_DATABASE = <database>, you'll get the error:
Msg 40517, Level 16, State 1, Line 1
Keyword or statement option 'default_database' is not supported in this version of SQL Server.
If you really want to still use that user and Invoke-DbaQuery, you can execute on Master db (to create a user with no default schema and no roles):
CREATE USER [<username>] FOR LOGIN [<username>]

detect if database.... then work from there.

In your client connection logic, override the default timeout to be 30 seconds. The default of 15 seconds is too short for connections that depend on the internet.

some notes for me..
sqlserver module & ssms looks like they use winforms for MFA but sqlcmd uses..odbc?

SQL Server Management Studio (SSMS) uses the Microsoft .NET Framework SqlClient for execution in regular and SQLCMD mode in Query Editor. When sqlcmd is run from the command-line, sqlcmd uses the ODBC driver. Because different default options may apply, you might see different behavior when you execute the same query in SQL Server Management Studio in SQLCMD Mode and in the sqlcmd utility.

maybe we can too?

hell yeah, this is done, except MFA which who knows how that'll be done. that's for 1.1 or 2.0


Root alias stuffs

Includes a fix (with test) for scanning root alias files and a new rule to detect the case of alias collision.

@coderanger Make sure to write a page for it on the foodcritic-site repo now


[DDW-1003]: Decentralization countdown, info, and staking epochs screens removal

This PR implemented removing decentralization countdown, info, and staking epochs screens for incentivized testnet.
YouTrack Ticket
Todos

[x] Remove decentralization countdown, info, and staking epochs screens for incentivized testnet

Screenshots

Testing Checklist

Slack QA thread
[x] Watch app to check if decentralization countdown, info, and staking epochs screens were removed for incentivized testnet

Review Checklist
Basics

[ ] PR has been assigned and has appropriate labels (feature/bug/chore, release-x.x.x)
[ ] PR is updated to the most recent version of the target branch (and there are no conflicts)
[ ] PR has a good description that summarizes all changes and shows some screenshots or animated GIFs of important UI changes
[ ] CHANGELOG entry has been added to the top of the appropriate section (Features, Fixes, Chores) and is linked to the correct PR on GitHub
[ ] Automated tests: All acceptance and unit tests are passing (yarn test)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in development build (yarn dev)
[ ] Manual tests (minimum tests should cover newly added feature/fix): App works correctly in production build (yarn package / CI builds)
[ ] There are no flow errors or warnings (yarn flow:test)
[ ] There are no lint errors or warnings (yarn lint)
[ ] There are no prettier errors or warnings (yarn prettier:check)
[ ] There are no missing translations (running yarn manage:translations produces no changes)
[ ] Text changes are proofread and approved (Jane Wild / Amy Reeve)
[ ] Japanese text changes are proofread and approved (Junko Oda)
[ ] UI changes look good in all themes (Alexander Rukin)
[ ] Storybook works and no stories are broken (yarn storybook)
[ ] In case of dependency changes yarn.lock file is updated

Code Quality

[ ] Important parts of the code are properly commented and documented
[ ] Code is properly typed with flow
[ ] React components are split-up enough to avoid unnecessary re-renderings
[ ] Any code that only works in main process is neatly separated from components

Testing

[ ] New feature/change is covered by acceptance tests
[ ] New feature/change is manually tested and approved by QA team
[ ] All existing acceptance tests are still up-to-date
[ ] New feature/change is covered by Daedalus Testing scenario
[ ] All existing Daedalus Testing scenarios are still up-to-date

After Review

[ ] Merge the PR
[ ] Delete the source branch
[ ] Move the ticket to done column on the YouTrack board
[ ] Update Slack QA thread by marking it with a green checkmark

@daniloprates @tomothespian please review this one 🙏


Fix the bug of window function bitmap_union_count

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #5697
Problem Summary(Required) ：

Current, window function don't support bitmap_union_count, so we should return msg of not supported instead of return invalid result.

[FE PR Coverage check]
:heart_eyes: pass : 0 / 0 (0%)


Error while loading scene

I get the following error whenever I load a scene containing any region (even regions that have nothing to do with terrain). When I try to load any scene after I have tried loading the offending scene, I again get the same error. Disabling the module resolves the issue.
Error: Failed drawing interface canvas group: "refreshTerrainMapperMesh" is not defined as a supported RenderFlag option.. "refreshTerrainMapperMesh" is not defined as a supported RenderFlag option.
at Hooks.onError (foundry.js:654:24)
at 🎁call_wrapped [as call_wrapped] (libWrapper-wrapper.js:507:22)
at 🎁Hooks.onError#lib-wrapper (listeners.js:138:11)
at 🎁Hooks.onError#0 (libWrapper-wrapper.js:187:52)
at #draw (foundry.js:25053:15)
at async Canvas.draw (foundry.js:24937:5)
at async ScenePF2e.view (foundry.js:21358:7)Caused by: Error: "refreshTerrainMapperMesh" is not defined as a supported RenderFlag option.
at #set (foundry.js:31605:23)
at #set (foundry.js:31609:47)
at #set (foundry.js:31609:47)
at RenderFlags.set (foundry.js:31587:16)
at foundry.js:26712:24

+1

same. I rolled back to 3.3

Same issue for me. Had to downgrade to 3.3

+1

Should be fixed in v0.4.1.


Include staging branch in parquet website

Including staging branch for live deploy as we upgrade the parquet website: https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-WebSiteDeploymentServiceforGitRepositories

@shangxinli tagging for review. After this change, we should be able to push the new website to the asf-staging branch of this repo and access the staged website at parquet.staged.apache.org

LGTM. Thanks for working on it!


Print usage to stderr rather than stdout to be more friendly to appli…

…cations that use unix pipelines.

Hmm... This might not be the right thing to do, actually... What if a application has exposed a '--help' flag which calls exitWithUsage... In this case, it should probably print to stdout...

I guess I should create the following new functions instead?:
exitWithUsageErr
exitWithUsageMessage and parseArgsOrExit will call this, rather than exitWithUsage as they are assumed to be called because of errors...

Oh yeah, you're right. Good call.

I've updated the pull request with the changes discussed above :P.

Sorry for not taking a look quickly! Been busy at work.
The two exitWithUsage{,Err} seem a little out of line with exitWithUsageMessage, since (a) the former has 2 variants for stdout/stderr, and the latter doesn't, and (b) exitWithUsageMessage prints to stderr, even though that's not immediately obvious given the name (docs help, but it could be more obvious).
One idea would be to change them to {exit,die}WithUsage and {exit,die}WithUsageMessage, where the die... versions go to stderr (or 'die' could be 'fail', idk). If we go down that route, we could also rename parseArgsOrExit to parseArgsOrDie, without (?) keeping around a stdout variant. People will have to update their code with the renaming, but if we need a major version bump anyway, may as well, right?
Happy to make these changes on top of your PR if you agree, but I may not get to it immediately.

No problem! Thanks for having a look.
Feel free to submit a pull request on the branch that my pull request is based on... Or merging and then making a new commit. Whatever you plan to do :P.

@ryanartecona I had a spare 15 minutes on the train and I went ahead and implemented the changes you suggested. They make sense to me. Let me know if it looks alright to you.
Do you think I've bumped the version in the right column?

Updates look great! :100:
I think that's the right version component to bump. I don't think this lib is quite 1.0+, but this is definitely a breaking change, so that looks right.
I made some inline notes. I expect to have some time this weekend to take care of them, make some other corresponding updates (examples, make sure the docs are all consistent, etc.), and I'll merge these in then. It will be a little while before I cut this release, since I want some other fixes to go out with it.

\o/
I made changes based on your inline comments. I've also attempted to update the documentation examples - let me know if I've missed anything!

Awesome.
Yeah, the README is the main one. There's also some stuff in examples/ that will probably need a couple of those functions renamed before they're compilable again.
If you get to it, great; if not, no sweat. I need to get in here soon (again, hopefully this weekend) to see if I can address the other open issues, and if I can I will update the changelog and release this and those fixes in a new version. I'll leave this PR open until I get to those anyway.

I updated the examples and made the function names in NoTH.hs (which I'd overlooked) consistent with the new conventions. Let me know if there's anything else :P.

All set! Sorry for the slow back-and-forth, but thanks for the changes @Happy0!

Hurray :D.
No problem at all. I've been busy as well! I'm glad we took the time to think about it and get it right :P.


Add ability for the user to change LED status

Original report by Brian Calder (Bitbucket: brian_r_calder, ).

This is required to allow the status to be more visible from the outside.
Please change to allow control of the LED from the outside using a button.

Original comment by Brian Calder (Bitbucket: brian_r_calder, ).

This has no implication for DCDB workflow.

Original comment by Brian Calder (Bitbucket: brian_r_calder, ).

Original comment by Brian Calder (Bitbucket: brian_r_calder, ).

Why would anyone want to do this?  Suggest that this gets knocked back or at least delayed.  Users shouldn’t be able to make changes to status indicators.


Create 20220720_OPI_Core_meeting_minutes

Signed-off-by: Paul Pindell<EMAIL_ADDRESS>

Closing as this is not needed anymore.


Change Fed C2C 1B address

Purpose of this pull request
In the #dochub Slack channel, Trent Driesler reported a problem with an static IP address. This pull request (PR) changes the IP address for Fed C2C 1B from <IP_ADDRESS> to <IP_ADDRESS> in the following article:
https://help.sumologic.com/docs/send-data/hosted-collectors/cloud-to-cloud-integration-framework/#static-ip-addresses
Issue number: None

Select the type of change:

[x] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions and updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

Thanks, @kimsauce!


Update init-interfaces.sh

Do not abort if the 2nd connection fails,
In our GS environment we have one of bond interfaces disconnected, and the script will fail on this line, and abort, which failed to set the description on the connection.

CI appears broken
Please check manually to see if it is originated by this PR change

/retest

@rabin-io I ran the ci locally on a clean simplify-networking branch:
make test

and the issue is still there.
We need to fix the CI before introducing this PR. I will update on that

[UPDATE]
I issued a PR to upgrade the go version, let's see how it goes.

IIUIC Rabin used this patched code on his real OpenShift BM environment and it worked there, correct @rabin-io ?
@RamLavi unless you have a hunch this patch may bring instability to the project, would you please consider merging it and resolving the CI issue in parallel?

IIUIC Rabin used this patched code on his real OpenShift BM environment and it worked there, correct @rabin-io ?
@RamLavi unless you have a hunch this patch may bring instability to the project, would you please consider merging it and resolving the CI issue in parallel?

@phoracek https://github.com/RHsyseng/rhcos-slb/pull/71 should fix it. I'm waiting to see the ci results.
@rabin-io if this change is urgent then we should split the effort as @phoracek suggests, is it?


Update README.md

Inspired by https://github.com/wagmi-dev/wagmi

the bug_report.yml and config.yml is meant to enable issue templates like wagmi
https://github.com/wagmi-dev/wagmi/issues/new/choose
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms


Issue 320/fix broken tests

Fixed issue with SQFormDropdown where the story name was changed. Also fixed issue where a component was added to SQForm stories.

There are a couple SQFormIconButton tests still failing, it's not a problem with the tests or stories though #322


convert all routes to lazy loading for serving pages faster

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
I would be willing to submit a PR to fix this issue
[ ] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

Fixed via https://github.com/ngx-builders/ngx-bulma/pull/327


add serviceexport controller with yacht

Signed-off-by: lmxia<EMAIL_ADDRESS>
What type of PR is this?
Feature Add
What this PR does / why we need it:
Service Export controller feature.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Assume service export has been labeled with subscription namespace.

Codecov Report

Merging #432 (e0b0e2e) into main (5ed3c54) will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #432      +/-   ##
==========================================
- Coverage   13.67%   13.60%   -0.07%
==========================================
  Files          60       61       +1
  Lines        6581     6613      +32
==========================================
  Hits          900      900
- Misses       5614     5646      +32
  Partials       67       67

Impacted Files
Coverage Δ

...ithub.com/clusternet/clusternet/pkg/agent/agent.go
1.67% <0.00%> (-0.08%)
:arrow_down:

...hub.com/clusternet/clusternet/pkg/utils/handler.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Fix alignment on non-optimized systems in tests.

This is the corollary of 003b2231ba0d9d3922054a3a4cc8a03ffb8148ab for the new similar line in tests.

Looks good to me.


Add support for NoSQL Databases {MongoDB especially}

Describe what you want
Life is always beautiful when people have options.
I've watched many comments about Drizzle and most of these comments agree in one thing-- Drizzle's approach to ORM means that Relational Database users feel at home, like they are actually writing raw SQL while using Drizzle.
This means that users still use their SQL Database knowledge and skills while using Drizzle.
But with Prisma, there is no nearness and closeness to the underlying NoSQL Database Language.
So Prisma is a complementary system that abstracts away your Database knowledge, and gives you no chance to use your Database language and skills directly in your application-- in which case debugging your database could then become problematic in edge situations.
THE REQUEST
Of all the NoSQL Databases, MongoDB is the most used and most popular.
It is so popular insomuch that it fused to form the MERN Stack--which is MongoDB, Express.JS, React and NodeJS.
This means that Drizzle should extend itself to support NoSQL Databases especially MongoDB -- so that MongoDB users can still use Drizzle, and still write MongoDB-like or NoSQL-like code in their Applications using Drizzle.
You can do this by adding a driver for MongoDB, and allow users to choose their Database Language Type at Set up-- whether SQL or NoSQL.
THE PROBLEM
By sticking with SQL-ish paradigm, it appears in the Developer Community as if Drizzle is taking sides, and looking with disdain upon developers who use NoSQL Databases like MongoDB.
THE SOLUTION
In order not to make it look like Drizzle is taking sides, and Drizzle is bigoted against the NoSQL Database paradigm, I am suggesting that Drizzle should support more than SQL-ish databases.
This means that Drizzle should extend itself to support NoSQL Databases especially MongoDB-- so that MongoDB users can still use Drizzle, and still write MongoDB-like or NoSQL-like code in their Applications using Drizzle.
CONCLUSION
While this is not a battle for dominance, I however believe that if Drizzle can do this, Drizzle could actually chase Prisma out of the race.
This is possible because the punchline could be something like "Write your Database Queries in your preferred Database with the language you already know".
And in my belief, this Unique Selling Point with the addition of MongoDB support, will give Drizzle a great edge.

drizzle is built somehow around sql
it has sql operators and sql stuff all around
so I don't think it's a good idea

Closed in favor of #2377.


Need to add some text in pop up of Custom filter.

Describe the bug
Need to add text like select or select field. And Vinod sir had some visibility issue on custom filter pop up drpdwn.

Kindly upload the screenshot of Custom filter pop up. @vinpahilwani

Need to add text like select or select field.
Where?

plugin do not support adding text. apart from that anything


added explicit override for the AMT port in case of SSH tunneling

I've noticed that ports are hardcoded to 16992 and 16993 depending on the TLS being used or not. In my use case I tend to access a AMT machine via SSH tunnel so I'd like to override the expected port with an explicit value for it.
I didn't change command line settings since I believe this is not a useful thing for general-purpose usage of your CLI application/server, only for specific library usage like mine

Codecov Report

Merging #1 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #1   +/-   ##
=======================================
  Coverage   41.43%   41.43%
=======================================
  Files           5        5
  Lines         823      823
=======================================
  Hits          341      341
  Misses        455      455
  Partials       27       27

Continue to review full report at Codecov.

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


IDSEQ-1132 - Command patterns refactoring

Refactoring of all command execution patterns: "SingleCommand"/"ShellScriptCommand"
Python native versions for basic operations (like rm, echo, cp, mv).
Improved logging for command execution
Removed some false error messages related to lz4 downloads

Test plan:

New classes unit tested
Tested 2 samples and compared the results folder

What are we doing about the version?

Bumping the minor version, since there is no difference on outputs files.


Run hugo server --disableFastRender failed

Expected Behavior

Run hugo server --disableFastRender successful
Actual Behavior

hugo --panicOnWarning
Start building sites …
hugo v0.101.0-466fa43c16709b4483689930a4f9ac8add5c9f66+extended darwin/amd64 BuildDate=2022-06-16T07:09:16Z VendorInfo=gohugoio
WARN 2022/07/28 23:55:47 The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.
WARN 2022/07/28 23:55:50 .Path when the page is backed by a file is deprecated and will be removed in a future release. We plan to use Path for a canonical source path and you probably want to check the source is a file. To get the current behaviour, you can use a construct similar to the one below:

  {{ $path := "" }}
  {{ with .File }}
	{{ $path = .Path }}
  {{ else }}
	{{ $path = .Path }}
  {{ end }}
ERROR 2022/07/28 23:55:59 render of "page" failed: "/Users/victory/vscode-prjs/dubbo-website/themes/docsy/layouts/docs/baseof.html:17:15": execute of template failed: template: docs/single.html:17:15: executing "docs/single.html" at <partial "page-meta-links.html" .>: error calling partial: "/Users/victory/vscode-prjs/dubbo-website/themes/docsy/layouts/partials/page-meta-links.html:1:6": execute of template failed: template: partials/page-meta-links.html:1:6: executing "partials/page-meta-links.html" at <.Path>: error calling Path: Warning trapped. Remove the --panicOnWarning flag to continue.
Error: Error building site: failed to render pages: render of "page" failed: "/Users/victory/vscode-prjs/dubbo-website/themes/docsy/layouts/docs/baseof.html:4:7": execute of template failed: template: docs/single.html:4:7: executing "docs/single.html" at <partial "head.html" .>: error calling partial: execute of template failed: template: _internal/google_news.html:1:4: executing "_internal/google_news.html" at <warnf "The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.">: error calling warnf: Warning trapped. Remove the --panicOnWarning flag to continue.
Total in 12364 ms

Steps to Reproduce the Problem
I follow the project README.MD.

https://www.docsy.dev/docs/get-started/docsy-as-module/installation-prerequisites/

This may be the issue of hugo.

Try use git submodule update --init --recursive.

Thanks a lot, but it's not work .
# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:13:07] C:130
$ git submodule update --init --recursive
remote: Enumerating objects: 38209, done.
remote: Counting objects: 100% (38182/38182), done.
remote: Compressing objects: 100% (7578/7578), done.
remote: Total 34101 (delta 29527), reused 30057 (delta 26486), pack-reused 0
接收对象中: 100% (34101/34101), 45.74 MiB | 3.47 MiB/s, 完成.
处理 delta 中: 100% (29527/29527), 完成 786 个本地对象.
来自 https://github.com/FortAwesome/Font-Awesome
 * branch              7d3d774145ac38663f6d1effc6def0334b68ab7e -> FETCH_HEAD
子模组路径 '.github/themes/docsy/assets/vendor/Font-Awesome'：检出 '7d3d774145ac38663f6d1effc6def0334b68ab7e'
remote: Enumerating objects: 126391, done.
remote: Counting objects: 100% (126391/126391), done.
remote: Compressing objects: 100% (40551/40551), done.
remote: Total 126126 (delta 84665), reused 125881 (delta 84420), pack-reused 0
接收对象中: 100% (126126/126126), 129.44 MiB | 4.23 MiB/s, 完成.
处理 delta 中: 100% (84665/84665), 完成 109 个本地对象.
来自 https://github.com/twbs/bootstrap
 * branch                043a03c95a2ad6738f85b65e53b9dbdfb03b8d10 -> FETCH_HEAD
子模组路径 '.github/themes/docsy/assets/vendor/bootstrap'：检出 '043a03c95a2ad6738f85b65e53b9dbdfb03b8d10'

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:14:57]
$ ls
404.html                     README.md                    assets                       config.toml                  layouts                      static
LICENSE                      archetypes                   baidu_verify_9ea1htgFIo.html content                      package.json                 themes

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:15:14] C:127
$ nvm ls
        v6.11.3
        v8.11.4
       v16.16.0
default -> v16.16.0
node -> stable (-> v16.16.0) (default)
stable -> 16.16 (-> v16.16.0) (default)
iojs -> N/A (default)
lts/* -> lts/gallium (-> v16.16.0)
lts/argon -> v4.9.1 (-> N/A)
lts/boron -> v6.17.1 (-> N/A)
lts/carbon -> v8.17.0 (-> N/A)
lts/dubnium -> v10.24.1 (-> N/A)
lts/erbium -> v12.22.12 (-> N/A)
lts/fermium -> v14.20.0 (-> N/A)
lts/gallium -> v16.16.0

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:15:22]
$ nvm use v16.16.0
Now using node v16.16.0 (npm v8.11.0)

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:15:28]
$ npm install

added 119 packages, and audited 120 packages in 22s

15 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:16:01]
$ hugo server --disableFastRender
Start building sites …
hugo v0.101.0-466fa43c16709b4483689930a4f9ac8add5c9f66+extended darwin/amd64 BuildDate=2022-06-16T07:09:16Z VendorInfo=gohugoio
WARN 2022/07/31 23:16:09 The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.
WARN 2022/07/31 23:16:09 .Path when the page is backed by a file is deprecated and will be removed in a future release. We plan to use Path for a canonical source path and you probably want to check the source is a file. To get the current behaviour, you can use a construct similar to the one below:

  {{ $path := "" }}
  {{ with .File }}
	{{ $path = .Path }}
  {{ else }}
	{{ $path = .Path }}
  {{ end }}

Re-run Hugo with the flag --panicOnWarning to get a better error message.
WARN 2022/07/31 23:16:18 The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.
WARN 2022/07/31 23:16:18 "/Users/victory/idea-prjs/pr/dubbo-website/content/en/latest/community/_index.md:1:1": duplicate menu entry with identifier "Community" in menu "main"
WARN 2022/07/31 23:16:18 "/Users/victory/idea-prjs/pr/dubbo-website/content/en/latest/facade-docs/_index.md:1:1": duplicate menu entry with identifier "Documentation" in menu "main"
WARN 2022/07/31 23:16:20 .File.UniqueID on zero object. Wrap it in if or with: {{ with .File }}{{ .UniqueID }}{{ end }}

                   |  ZH  | EN
-------------------+------+------
  Pages            | 1139 | 397
  Paginator pages  |   22 |   7
  Non-page files   |    1 |   1
  Static files     |  811 | 811
  Processed images |    2 |   2
  Aliases          |   10 |   3
  Sitemaps         |    2 |   1
  Cleaned          |    0 |   0

Built in 11495 ms
Watching for changes in /Users/victory/idea-prjs/pr/dubbo-website/{archetypes,assets,content,layouts,package.json,static,themes}
Watching for config changes in /Users/victory/idea-prjs/pr/dubbo-website/config.toml, /Users/victory/idea-prjs/pr/dubbo-website/themes/docsy/config.toml
fatal error: pipe failed

goroutine 1 [running]:
runtime.throw({0x5cf2455?, 0xc0004fe900?})
	/usr/local/go/src/runtime/panic.go:992 +0x71 fp=0xc02a6cf840 sp=0xc02a6cf810 pc=0x4035db1
runtime.sigNoteSetup(0xc02a6cf8a0)
	/usr/local/go/src/runtime/os_darwin.go:101 +0xc5 fp=0xc02a6cf868 sp=0xc02a6cf840 pc=0x4032e85
os/signal.signal_enable(0x2)
	/usr/local/go/src/runtime/sigqueue.go:202 +0x39 fp=0xc02a6cf888 sp=0xc02a6cf868 pc=0x4065219
os/signal.enableSignal(...)
	/usr/local/go/src/os/signal/signal_unix.go:49
os/signal.Notify.func1(0x5a64900?)
	/usr/local/go/src/os/signal/signal.go:145 +0x73 fp=0xc02a6cf8b0 sp=0xc02a6cf888 pc=0x5699693
os/signal.Notify(0xc01688f740, {0xc02a6cfb58, 0x2, 0x4065865?})
	/usr/local/go/src/os/signal/signal.go:165 +0x1ff fp=0xc02a6cf928 sp=0xc02a6cf8b0 pc=0x569955f
github.com/gohugoio/hugo/commands.(*commandeer).serve(0xc0003954a0, 0xc000051480)
	/root/project/hugo/commands/server.go:573 +0x509 fp=0xc02a6cfb90 sp=0xc02a6cf928 pc=0x56ce129
github.com/gohugoio/hugo/commands.(*serverCmd).server(0xc000051480, 0xc00030c780, {0xc000124500?, 0x4590620?, 0xc0009bfd00?})
	/root/project/hugo/commands/server.go:297 +0x3c8 fp=0xc02a6cfcd8 sp=0xc02a6cfb90 pc=0x56ca688
github.com/gohugoio/hugo/commands.(*commandsBuilder).newServerCmdSignaled.func1(0xc00030c780?, {0xc0002ca090?, 0x1?, 0x1?})
	/root/project/hugo/commands/server.go:96 +0x36 fp=0xc02a6cfd28 sp=0xc02a6cfcd8 pc=0x56ca156
github.com/spf13/cobra.(*Command).execute(0xc00030c780, {0xc0002ca070, 0x1, 0x1})
	/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:856 +0x67c fp=0xc02a6cfe00 sp=0xc02a6cfd28 pc=0x458fbfc
github.com/spf13/cobra.(*Command).ExecuteC(0xc0004faf00)
	/go/pkg/mod/github.com/spf13/cobra@v1.4.0/command.go:974 +0x3b4 fp=0xc02a6cfeb8 sp=0xc02a6cfe00 pc=0x4590274
github.com/gohugoio/hugo/commands.Execute({0xc0001940a0, 0x2, 0x2})
	/root/project/hugo/commands/hugo.go:92 +0xb4 fp=0xc02a6cff38 sp=0xc02a6cfeb8 pc=0x56b66d4
main.main()
	/root/project/hugo/main.go:23 +0x57 fp=0xc02a6cff80 sp=0xc02a6cff38 pc=0x56d3cd7
runtime.main()
	/usr/local/go/src/runtime/proc.go:250 +0x212 fp=0xc02a6cffe0 sp=0xc02a6cff80 pc=0x4038492
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1571 +0x1 fp=0xc02a6cffe8 sp=0xc02a6cffe0 pc=0x40692c1

goroutine 9 [select]:
go.opencensus.io/stats/view.(*worker).start(0xc000122c80)
	/go/pkg/mod/go.opencensus.io@v0.23.0/stats/view/worker.go:276 +0xad
created by go.opencensus.io/stats/view.init.0
	/go/pkg/mod/go.opencensus.io@v0.23.0/stats/view/worker.go:34 +0x8d

goroutine 1541 [select]:
github.com/gohugoio/hugo/watcher.(*Batcher).run(0xc012857770)
	/root/project/hugo/watcher/batcher.go:67 +0x11a
created by github.com/gohugoio/hugo/watcher.New
	/root/project/hugo/watcher/batcher.go:56 +0x1ed

goroutine 1540 [syscall]:
syscall.syscall6(0xc004ca94a0?, 0x4015426?, 0x35969200?, 0x5cc9cdd?, 0x359dcfff?, 0xc004ca9590?, 0x800?)
	/usr/local/go/src/runtime/sys_darwin.go:44 +0x6a
golang.org/x/sys/unix.kevent(0x203006?, 0x800?, 0x800?, 0x4000?, 0x359dcfff?, 0x35969400?)
	/go/pkg/mod/golang.org/x/sys@v0.0.0-20220520151302-bc2c85ada10a/unix/zsyscall_darwin_amd64.go:276 +0x52
golang.org/x/sys/unix.Kevent(0x40186ab?, {0x0?, 0x40670ce?, 0x4038907?}, {0xc004ca9678?, 0x4007c05?, 0xc004ca9588?}, 0x400c72b?)
	/go/pkg/mod/golang.org/x/sys@v0.0.0-20220520151302-bc2c85ada10a/unix/syscall_bsd.go:399 +0x3c
github.com/fsnotify/fsnotify.read(0xc000580000?, {0xc004ca9678?, 0xc006dc8000?, 0xa}, 0xc004ca9618?)
	/go/pkg/mod/github.com/fsnotify/fsnotify@v1.5.4/kqueue.go:525 +0x3f
github.com/fsnotify/fsnotify.(*Watcher).readEvents(0xc015d74960)
	/go/pkg/mod/github.com/fsnotify/fsnotify@v1.5.4/kqueue.go:288 +0xa5
created by github.com/fsnotify/fsnotify.NewWatcher
	/go/pkg/mod/github.com/fsnotify/fsnotify@v1.5.4/kqueue.go:63 +0x1c5

goroutine 1542 [select]:
github.com/gohugoio/hugo/commands.(*commandeer).newWatcher.func1()
	/root/project/hugo/commands/hugo.go:888 +0xf9
created by github.com/gohugoio/hugo/commands.(*commandeer).newWatcher
	/root/project/hugo/commands/hugo.go:886 +0x3ca

goroutine 1543 [select]:
github.com/gohugoio/hugo/livereload.(*hub).run(0x7368940)
	/root/project/hugo/livereload/hub.go:39 +0xec
created by github.com/gohugoio/hugo/livereload.Initialize
	/root/project/hugo/livereload/livereload.go:105 +0x3f

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:16:20] C:2
$ hugo --panicOnWarning
Start building sites …
hugo v0.101.0-466fa43c16709b4483689930a4f9ac8add5c9f66+extended darwin/amd64 BuildDate=2022-06-16T07:09:16Z VendorInfo=gohugoio
WARN 2022/07/31 23:18:55 The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.
WARN 2022/07/31 23:18:58 .Path when the page is backed by a file is deprecated and will be removed in a future release. We plan to use Path for a canonical source path and you probably want to check the source is a file. To get the current behaviour, you can use a construct similar to the one below:

  {{ $path := "" }}
  {{ with .File }}
	{{ $path = .Path }}
  {{ else }}
	{{ $path = .Path }}
  {{ end }}
ERROR 2022/07/31 23:19:06 render of "page" failed: "/Users/victory/idea-prjs/pr/dubbo-website/themes/docsy/layouts/docs/baseof.html:17:15": execute of template failed: template: docs/single.html:17:15: executing "docs/single.html" at <partial "page-meta-links.html" .>: error calling partial: "/Users/victory/idea-prjs/pr/dubbo-website/themes/docsy/layouts/partials/page-meta-links.html:1:6": execute of template failed: template: partials/page-meta-links.html:1:6: executing "partials/page-meta-links.html" at <.Path>: error calling Path: Warning trapped. Remove the --panicOnWarning flag to continue.
Error: Error building site: failed to render pages: render of "page" failed: "/Users/victory/idea-prjs/pr/dubbo-website/themes/docsy/layouts/docs/baseof.html:4:7": execute of template failed: template: docs/single.html:4:7: executing "docs/single.html" at <partial "head.html" .>: error calling partial: execute of template failed: template: _internal/google_news.html:1:4: executing "_internal/google_news.html" at <warnf "The google_news internal template will be removed in a future release. Please remove calls to this template. See https://github.com/gohugoio/hugo/issues/9172 for additional information.">: error calling warnf: Warning trapped. Remove the --panicOnWarning flag to continue.
Total in 11845 ms

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website on git:master o [23:19:06] C:255
$ cd themes/docsy/

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website/themes/docsy on git:db8f7a7 o [23:19:32]
$ ll
total 72
-rw-r--r--   1 victory  staff   1.2K  7 31 22:56 CONTRIBUTING.md
-rw-r--r--   1 victory  staff    11K  7 31 22:56 LICENSE
-rw-r--r--   1 victory  staff   3.1K  7 31 22:56 README.md
drwxr-xr-x   8 victory  staff   256B  7 31 22:56 assets
-rw-r--r--   1 victory  staff   617B  7 31 22:56 config.toml
drwxr-xr-x  22 victory  staff   704B  7 31 22:56 i18n
drwxr-xr-x   4 victory  staff   128B  7 31 22:56 images
drwxr-xr-x  11 victory  staff   352B  7 31 22:56 layouts
-rw-r--r--   1 victory  staff   464B  7 31 22:56 netlify.toml
-rw-r--r--   1 victory  staff   627B  7 31 22:56 postcss.config.js
drwxr-xr-x   6 victory  staff   192B  7 31 22:56 static
-rw-r--r--   1 victory  staff   384B  7 31 22:56 theme.toml
drwxr-xr-x  15 victory  staff   480B  7 31 22:56 userguide

# victory @ victorydeMacBook-Pro in ~/idea-prjs/pr/dubbo-website/themes/docsy on git:db8f7a7 o [23:19:34]
$

How about ask docsy community for help? I have tested hugo v0.87.0 and v0.101.0 and it works fine.

How about ask docsy community for help? I have tested hugo v0.87.0 and v0.101.0 and it works fine.

OK, Thanks.


Add Dockerfile and Makefile, expand README.md

This change adds some build tooling for the exporter.

Are you sure you want me to add govendor and promu to this tool for your team?
I should have mentioned when I made this commit that we use govendor and promu in our other exporters and projects, but for this PR I was trying to keep things thin, non-intrusive and generally not make any assumptions about how your team would want things done since the repo did not have any version info or contribution documentation.
Let me know your thoughts on the matter, if you don't care I'll add these I just wanted to double check.

So in our other exporters and projects we use govendor and promu, but because there was no version info or contribution documentation I wanted to keep this PR lightweight and non-intrusive.
@EdSchouten does the Kumina team want me to add all the configurations and documentation for this or would you guys rather do that your own way?

Ed is on honeymoon, so it may take a few weeks for him to respond. And we prefer him to do that, as he wrote the original code! Sorry about that.
That said, if you're willing to add the configurations and documentation, that will surely be appreciated.
Ed has been hesitant regarding adding Makefiles when a simple go build would suffice, to minimise outside dependencies. So you may want to explain why you want this functionality added to the project, in preparation for his response.

Thanks for the update @timstoop!

Ed has been hesitant regarding adding Makefiles when a simple go build would suffice, to minimize outside dependencies. So you may want to explain why you want this functionality added to the project, in preparation for his response.

Indeed. This was more about adding back what I added for myself, so if this is unwanted I will not be at all offended if this PR gets closed.

That said, if you're willing to add the configurations and documentation, that will surely be appreciated.

I'm not opposed to this necessarily, but I feel Ed and/or the organization here may want to do this different than I would ultimately implement it, and have further context on it specific to their production deployment so it might make sense for the owners to decide how they want things done.

Ed is on honeymoon, so it may take a few weeks for him to respond. And we prefer him to do that, as he wrote the original code! Sorry about that.

No worries, I'll wait to hear from him.

Sounds like this is unwanted, no worries! thanks!


Add common aspect ratio constants and improve documentation

Hello,
I'd like to contribute to this project by adding some useful constants and improving the documentation for the AspectRatio struct. Here's a summary of the changes I've made:

Added new constants for common aspect ratios:

SIXTEEN_NINE (16:9)
FOUR_THREE (4:3)
ULTRAWIDE (21:9)

Enhanced the overall documentation:

Improved module-level documentation with an overview and use cases
Expanded explanation of the AspectRatio struct with examples
Added detailed descriptions and examples for all methods (both existing and new)
Included explanations for the newly introduced constant values
Added clarifications for From trait implementations

These changes aim to make the AspectRatio API more user-friendly and easier to understand. The new constants provide convenient access to commonly used aspect ratios, which I believe will be helpful in many scenarios.

There's some potential overlap with https://github.com/bevyengine/bevy/pull/14158, FYI

Is there anything else we should do to avoid overlap with issue #14158 ?


Allow out of range float images

Description
Attempting to fix #449, but the tests added in this commit pass without any fixes!
@royerloic was naughty in his reporting and did not provide a minimum reproducible example. ;)
Assuming CI is happy, I suggest we merge these tests and wait for @royerloic to clarify his issues.
Type of change

[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 not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[x] example: the test suite for my feature covers out of range and out of range with no contrast floats for both float32 and float64
[x] example: all tests pass with my change

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

merging now - as noted in #449 this is now fixed


Explore us page not working

this page is linked to code of conduct ,. link to proper explore page

Hi @sanjay-kv sir, Can you please assign me this issue?
Also, tell me more descriptions to where the explore page should redirect to.

Assign me if still available

https://stream.recodehive.com/github


Selection should be used as an entry point

Issue
Issue #14
What I did
I used selection from active editor to pre-fill the value for command startEntry.
I also added better error handling when the user cancels the command StartExistingEntry
What it adds, solves and/or improves
User can use selected text as a value for new entry.
How to test
Select the text in the editor and invoke action `Toggl: Start with new entry
Selected text should appear in the InputBox

Hi @pavelsuk, it works like a charm. Thank you.
FYI: I pushed another commit covering the new feature in a test: https://github.com/natterstefan/vscode-toggl-extension/pull/15/commits/91b81a0e024495ad3a2a7d4be94c2478e077dae4. Additionally, I fixed remaining ESLint warnings and errors.

Resolves https://github.com/natterstefan/vscode-toggl-extension/issues/14.


[FIX] mobile: container details to article details

fix route (become 'get' routes):

/api/container/
/api/container/articleslist/
/api/article/

add tests for (front and back) :

container details
article list
article list data
article details

fix theme colors of the aforementioned pages


Hashing based private set intersection

Performs sha256 -> geohashing
The front end is not implemented yet as we do not have "authorized download" or "self-reporting features"
For efficiency of the scheme, I would lean towards storing the hash at the same time when data is logged as it will save us from batched hashing of a file.

We gotta update the safe-paths branch with develop so that file changes are small

Goes with #144

@tremblerz - I think this is likely a good candidate for something that we should first implement on the new private-kit repo.  Do you agree?

@kenpugsley agree. Anyway it looks like a mess right now with respect to the file changes. Closing


Clearing the canvas shouldn't affect the grid mode.

If there was a grid on before clearing the canvas, I would expect the grid to still be visible..

how about we merge this issue into https://github.com/excalidraw/excalidraw/issues/2358 (and rename)

@dwelle recursion

:D, I meant https://github.com/excalidraw/excalidraw/issues/2334


[Enhancement] Install-PowershellModulePath to modify PSModulePath

It would be nice if I could use something like Install-ChocolateyPath to modify $env:PSModulePath

This is exactly what I was looking for tonight. both Install and Uninstall

I know @jaykul had something he was working on for this kind of thing.


How to install?

Installation using composer could be more detailed.
Can in readme https://github.com/googlesamples/identity-toolkit-php be used for installation suggestion or any better way to let us know how to use this repo?

Please, read the follow documentation:
https://developers.google.com/identity/toolkit/web/quickstart/php


TouchRipple: configurable maximum ripple size

[X] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡
Proposal:

TouchRipple to expose property maxSize on TouchRippleProps. (Accessed by the developer via TouchRippleProps on ButtonBase, and potentially a dedicated parameter on ButtonBase like centerRipple has.)
Consider defaulting a maxSize.

Examples 🌈
Here's an example of how fast and jarring the animation can appear on a very large button area, since the ripple propagates across the entire surface:
https://codesandbox.io/s/material-demo-forked-kjfwl
Motivation 🔦
maxSize would allow the ripple animation to not be forced to ripple over the entire button surface within X ms (which appears too quick/jarring on the example above).
My main use case is an empty state where the user can click anywhere on the empty state to proceed.

@aeharding I think that it's a duplicate of #19664. We can solve the problem at its root.

@aeharding I think that it's a duplicate of #19664. We can solve the problem at its root.

Sounds great @oliviertassinari. I'll subscribe to that issue :)

Sounds great @oliviertassinari. I'll subscribe to that issue :)


Add Support for Delete Location History Endpoint

Add support for the Delete Location History endpoint of the Device API.

Fixed in PR #17


Support App Container images in the Docker Engine

Overview
This PR provides simple, functional support for the App Container Spec within the Docker Engine. Specifically, it implements the ability to natively run App Container Images (ACIs) and also to perform image discovery to retrieve images. It achieves this with a minimally invasive patch which preserves the Docker user experience.
Examples
The following examples demonstrate basic usage of Docker with ACI support.
An ACI can be directly pulled by Docker using image discovery:
  # docker pull --format aci coreos.com/etcd:v2.0.0

Alternatively, ACIs can be imported to Docker from a file on disk or directly from an http URL:
  # docker pull --format aci file:///tmp/aciexamples-1-linux-amd64.aci

  # docker pull --format aci http://example.com/aciexamples-1-linux-amd64.aci

Listing images, including ACI images, works as expected:
  # docker images

ACIs can be run directly; referencing an image by its name will transitively perform image discovery if necessary:
  # docker run --format aci coreos.com/etcd

ACIs can also be referenced by their Image ID:
  # docker run --format aci fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df

  # docker run --format aci fa1cb92dc276

Docker create/start is also supported:
  # docker create --format aci coreos.com/etcd
  b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc

  # docker start -i -a b2eb6289ced6506316b31daac101e3f3143f11ff96d046aca3338c9b9de934dc

Finally, deleting ACI images:
  # docker rmi --format aci coreos.com/etcd

How it works
An ACI image contains a rootfs directory and a manifest file. When an ACI image is pulled, the rootfs is converted to layer.tar. layer.tar and the manifest are then stored in the normal Docker graphstore. For example:
  # ls -l /var/lib/docker/graph/fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df/
  total 12364
  -rw-r--r-- 1 root root 12653824 Feb 13 11:24 layer.tar
  -rw-r--r-- 1 root root      228 Feb 13 11:24 manifest
  #

The directory name is the sha512sum of the ACI image (its imageID) truncated to 64 characters.
A new entry in the local image repository (/var/lib/docker/repositories-*) is created. For example:
  "ACIRepo" : {
      "coreos.com/etcd" : "fa1cb92dc276b0f9bedf87981e61ecde93cc16432d2441f23aa006a42bb873df",
      "github.com/endocode/aciexamples" : "e3cd06d49820d9457115536ddbf2f05c4247d22190abed8f1c70551149add72f"
   }

When creating a container based on an ACI image, its configuration file /var/lib/docker/containers/<container_id>/config.json is generated from the manifest file and the command line parameters. For example, when the manifest contains:
   "app": {
        "exec": [
             "/etcd"
        ],

Docker will generate config.json with the following entrypoint:
     "Entrypoint" : [
         "/etcd"
      ],

Known Limitations
The following are known limitations with the current state of this patch.

labels: the ACI discovery mechanism defines various labels (for example: version, os, and arch). They are not stored in the Docker repository, so two versions of an ACI image with the same name cannot be stored at the same time.

isolators: isolators specified in the manifest of an ACI are ignored. However, options such as --cap-add, --cap-drop, --privileged should still work when used on an ACI.

dependencies: an ACI image can depend on other images in a similar way to layers in Docker. This is not implemented yet. Only ACI images without dependencies are supported.

unix group: a manifest can specify to run the program in the container as a specific unix group. This is not implemented yet.

unix user or group referring to a file: instead of specifying a uid/gid or username/groupname, a manifest can request to use the owner and group of an file found at an absolute path inside the rootfs. This is not implemented yet.

mount points and ports specified in the manifest are ignored. This is not implemented yet.

We would really love to solve all of these limitations over time. But, before we put in a substantial amount of work we wanted to have a wider design proposal. So, please consider this in tandem with https://github.com/docker/docker/issues/10777 which more broadly discusses implementation of appc in the context of Docker.

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "aci_in_docker" git@github.com:coreos/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

@GordonTheTurtle oops, done - thanks for the tip!

Haven't looked at all yet but the first thing that jumps out at me as I scan the PR text is that this seems to have a lot of similar aspect to the issues we're seeing when we want to support non-x86 architectures. In other words, when I see things like:
docker run --format aci ...

I want to try to hide the --format flag from the user.  There's work going on to have arch and OS support for images and registries, and I hope, to keep that as hidden from the user as possible.  I wonder if something similar here could be done.  For example, could Docker/registry know that the image is in ACI format instead of Docker's and then take the appropriate actions.  I think keeping the end user unaware of the specific format would be a good thing from a usability perspective - if that's possible.

Having docker/registry know the image is an ACI and fetch it sounds horrible.  That's like changing the streams and not telling the end-user you just did something it didn't expect.
That almost comes close to a lie to the end user? unless you have output to tell them what your doing and then everything I said is moot.

Haven't looked into the proposal in depth, but naming this option --format might not be wise, given that Docker already has a --format option for other commands, with a different meaning (for reference, see docker inspect --format)

Can someone explain to me how the user benefits from this? Are we talking about improving the image distribution system with cryptographic signature and better mapping to the DNS namespace? Then send a patch to improve the existing image system, or even better, join the ongoing effort to do exactly that. If you don't think it's worth your effort to improve Docker's system, that's fine, just do it in your own project and let the best project win. But guys, you have to choose one or the other. This whole masquerade about "protecting the community" with made-up standards sounds great in the press, good for you. But here, we care about the users. And it makes no sense for the user to have to deal with 2 incompatible universes of images with the same tool. It creates artificial constraints and solves zero problems. These 2 formats are almost completely identical, and the differences will only diminish as we progress on our respective roadmaps.
Please, if you want to change my mind, walk me through a concrete user scenario where the user is better off dealing with 2 "standards" instead of simply continuing to improve the one we have.
Otherwise, I beg you, stop the charade, and let's go back to competing normally like the rest of the open-source world does.

Maybe there should be an open container summit or something to address all these issues in the open.

@shykes My, as in a users, advantage would be, that I would be able to run ACI images on docker.
If the image handling is properly abstracted (don't know enough about the code to judge) the ability to handle different image formats is an awesome feature, since it would allow/force different backends to compete (i.e. imagine a backend with cryptographically signed/encrypted images delivered via bittorrent - think something along the lines of twitters murder) - same goes for custom registries.
From a users perspective it then shouldn't matter if one runs an ACI or Docker image since that could be handled via the registry & dockers image handling layer.
IMHO this PR is really great (if it sucessfully manages to introduce some image layer) cause that would separate the image handling from the runtime and that separation is a great choice to have.
And if nothing else comes out from it, than a merge of ACI & Docker image formats, then even better.
So, if this PR introduces an acceptable start of an image handling layer, which is good for above reasons, why should it be bad?

I wasn’t clear.  Let me try this way…when I see:
docker pull --format aci http://example.com/aciexamples-1-linux-amd64.aci
what I would prefer to see is just:
docker pull http://example.com/aciexamples-1-linux-amd64.aci
and via the metadata around what is downloaded the Docker daemon would detect that it needs to convert it into a Docker image format. From them on the user can do:
docker run
and it would be run just like any other Docker image/container.  That’s what I meant by its hidden from the user.  The daemon knows what it can support and it should know what is being downloaded (if not then there’s something wrong with the incoming data). No real need for the user to get involved via --format flags.
My point is that I viewed this as more like an import feature, but perhaps I was over simplifying it or missing something.
-Doug

On Feb 13, 2015, at 4:43 PM, Scott M. Likens<EMAIL_ADDRESS>wrote:
Having docker/registry know the image is an ACI and fetch it sounds horrible. That's like changing the streams and not telling the end-user you just did something it didn't expect.
That almost comes close to a lie to the end user? unless you have output to tell them what your doing and then everything I said is moot.
—
Reply to this email directly or view it on GitHub https://github.com/docker/docker/pull/10776#issuecomment-74332053.

perhaps --format is overloaded in Docker; --type would be just as much of a winner (imo).
You shouldn't hide it from the end user however @duglin.  If you are going to run a container in a different format than the typical it should require extra work to get there.
It's not what your typical end users are going to be doing; and you don't want to make it too hard to start up as a new user as well.  The balance typically is in a 'custom' setting(knob?) somehow achieved.
but docker pull ubuntu:12.04 should still work like normal but docker run --format aci http://example/influxdb.aci should tell it that it's not the default and it may need to 'load' something for it to work.
As I said --format is overloaded so maybe a different name or a different way to achieve it.  But it should not be transparent or magical.

If one format has advantages over another, it would be nice to be able to use that new format without having to use yet another application, rewrite scripts, test scripts, etc. It seems there could be an advantage to being able to run multiple formats. As a user, pretty much the last thing I want to be dealing with is trying to figure out how start a program. It looks like Docker is being given an opportunity to be that platform, and the code is coming for free.
I haven't read through the 38k+ lines of code here, but if it works, I would appreciate the merge. If you it is preferred that people use standard Docker format, throw up a big banner warning for the user when they run an image with the contributed code. It sounds like the --format flag might need to be changed. I also agree with @duglin that the user shouldn't need to do anything different to run images in different formats.
I don't see being able to run even more software as something that Docker should be trying to avoid. Is there something deficient with the images that this PR allows to be run?

As an end user, I'd really prefer people (including me) just convert ACIs to Docker images if they really want to use them with Docker and the publisher doesn't provide a Docker image themselves.
This PR is like giving yum the ability to install deb packages or apt-get the ability to install RPMs, rather than working on making it easier for software publishers to easily provide both formats, so we as end users can choose the ecosystem we prefer without needing to worry about the competition as part of the day-to-day operation of our systems.
A registry PR to translate ACIs to Docker images on upload might make sense, but please don't let the argument over image format details propagate to my servers by adding ACI support directly to the Docker client. If I actually want to run ACIs myself, I'll install Rocket.

@ncoghlan  :+1:
I guess the mirror tool to docker2aci would have to be created.

Agreed with @ncoghlan
I don't think Docker (community, maintainers and organisation behind it) should have any responsibility with plugging in and maintaining another technology which is about the same.
At first, CoreOS strongly criticise many aspects of Docker, but still want to use it's establishment to promote alternative solution out of the box. I don't see here any benefit for end user.
If one day I fall in love with AppContainer and put some effort to port part of my services there, I wouldn't mind to much installing Rocket

As a user and clustering guy, I would like this capability.
In clustering it would be ideal to just have one tool that ran many formats, this would be in a similar vein to libvirt.

@timothysc — I agree with you 100%. But do you think it's Docker's responsibility to provide that abstraction layer?

I've browsed to the changes in this proposal and am -1 on this;

This change brings a lot of additional dependencies (38000 new lines of code!), which doesn't benefit the standard Docker user in any way.

I don't like the way it's implemented; having "if format is aci then ..." sprinkled throughout the code is (imo) just messy. If it would be implemented, I think some refactoring is required to better separate the code paths. Right now, it feels like a "quick hack".

Given that there's no full feature parity between ACI and Docker, this will not be a good user experience for people trying to run ACI images in Docker. People encountering such issues ("my image doesn't run properly") will easily blame Docker, whereas it's just because both formats have different features. I think it's highly unlikely that Docker will have full feature-parity with ACI because that would imply ACI "dictating" what features to implement in Docker. Also, that would require a lot more contributions of the App Container/CoreOS developers to Docker and a dedication from them to maintain the code.

Looking at the commits, the code for this was created 18 days ago (assuming GitHub shows this correctly), but (afaik) not discussed, nor was an actual pull-request created until the accompanying "press release" was published on the CoreOS website. I'd like to be proven otherwise, but if the App Container/CoreOS team really wanted this implemented, it would have been better to discuss this first and check what the posibilities were of having this integrated, before "going public".

To summarise my thoughts/opinion;

I don't think this belongs in the core functionality of Docker, especially because it's an incomplete implementation that would create more issues thank it would solve.

If App Container/CoreOS wants to bring support for ACI to Docker, implementing  a counterpart to docker2aci (as suggested by @jcfr) is a good alternative that would directly benefit users that have a need to run ACI images on Docker.

There are still plans to implement a "plugin" system in Docker. I'm not sure if this area will be part of this, but possibly this could be implemented as a plugin. This would keep a clear separation of responsibilities and enable users to run ACI images without requiring code changes to the Docker core.

As a user, what appeals to me with this is getting the DNS based federation and content-addressability, as well as signed images. I don't care about the image formats. But the suggestions of conversion tools in particularly does not address the federation support, which is the most important one to me.

I'm also :-1: on this change for many of the same reasons as @thaJeztah. As far as @vidarh's comment about DNS based federation and content-addressability; I agree those pieces of functionality are much needed in Docker but they should be handled in a different way in my opinion. Forcing App Container on people isn't the answer. Docker is docker and CoreOS Rocket is Rocket stop trying to build a bridge that no one is requesting.

@preillyme until Docker actually has that functionality, I for one am requesting this bridge.

@vidarh but couldn't it be handled in a different way with less modification to Docker itself?

@preillyme It certainly can, and if that can be added in a similar timeframe to getting this PR or the associated proposal to an acceptable state, then that may very well be the best situation. But the presence or absence of federation and content-addressability is likely to be a large part of the deciding factor for me on whether to deploy Docker or another tool on future projects. Much more so than which image format it's based on.

@vidarh I know there's a lot of ongoing work to improve this. Partly, this will also depend on changes to the registry, because that's the distribution mechanism used by Docker; Keeping backwards-compatible with older Docker clients is an important issue here, so those changes cannot be done "overnight".
If you're not doing so already, you may be interested in subscribing to the docker/distribution repository, because that's where a lot of these changes are currently taking place. A number of goals for that project are outlined in the Kick-off document, which you may want to read as well.
I think the Docker maintainers are well aware there are improvements to be made in that area, but it takes time to make sure it's implemented the right way. Docker has a large use base; they don't want to break their setups because if this, and want to offer a fluent migration-path to them.

This PR is meant to be a proof-of-concept to help the discussion of a shared standard in the #10777 proposal.
The appc spec does have a number of desirable attributes that people have asked for in Docker including: DNS based federation and content-addressability. The docker/distribution Dec 29th kickoff doc shows that our goals are similar.
We have similar technical goals and the appc code is here so we can play with the ideas. Ideally we get to a place where the standard is shared and useful for everyone.

@preillyme

@timothysc https://github.com/timothysc -- I agree with you 100%. But do
you think it's Docker's responsibility to provide that abstraction layer?

I interpret that as "everyone who cares about any aspect of ACI should use
a wrapper that hides docker".  That seems bad for docker.  Here I see a
chance for docker to answer some of the issues that rocket brings up, while
continuing to own the UX.
I did not review the code, but conceptually this makes two layers - the UX
and the image format.  That is a pretty nice split.
Without such a change (perhaps not literally this one, if actual technical
issues exist), a wrapper will emerge, and docker loses a (small) bit of its
position.
On Feb 14, 2015 9:15 AM, "Sebastiaan van Stijn"<EMAIL_ADDRESS>wrote:

@vidarh https://github.com/vidarh I know there's a lot of ongoing work
to improve this. Partly, this will also depend on changes to the registry,
because that's the distribution mechanism used by Docker; Keeping
backwards-compatible with older Docker clients is an important issue here,
so those changes cannot be done "overnight".
If you're not doing so already, you may be interested in subscribing to
the docker/distribution https://github.com/docker/distribution
repository, because that's where a lot of these changes are currently
taking place. A number of goals for that project are outlined in the
Kick-off
https://github.com/docker/distribution/blob/master/doc/opensprint/kickoff.md
document, which you may want to read as well.
I think the Docker maintainers are well aware there are improvements to be
made in that area, but it takes time to make sure it's implemented the
right way. Docker has a large use base; they don't want to break their
setups because if this, and want to offer a fluent migration-path to them.
--
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10776#issuecomment-74383355.

I think there is too much negativity in this issue and not enough collaboration or trying to work together.  In a way it's like looking at a bunch of Teenagers nitpicking someones outfit instead of saying it looks nice.
I would like to see more constructive criticism and helpful suggestions.

I suspect the following parts are items folks can agree on:

DNS based federation is good, and we'd like to see that in Docker itself
content addressability is good, and we'd like to see that in Docker itself
decoupling the container format from the container management UX is at least potentially beneficial to end users

It doesn't follow that accepting this PR is the correct way to address those needs, as the negative consequence for long term usability and maintainability may be significant. What the PR does show is that it's at least possible to do that within the context of Docker as it exists today, even if the implementation details and the UX consequences make this specific approach a bad idea.
For users that want this kind of capability in the near future, a higher level container orchestration system like Kubernetes can probably abstract away the details of Docker invocation more easily than Docker can abstract away the details of its image format (Note: a container abstraction at the k8s layer will cover my own use cases if the need to use ACIs directly came up for some reason, so it's worth factoring that in when I say that I consider direct support for Rocket-in-Docker to be redundant and not something I want on my servers)
I'd personally prefer that the Docker and Rocket teams take the time to focus on the hard work of collaborating on a shared image format standard in the interests of their respective users. Let folks that decide they really need to run both in the interim be the ones that incur the maintenance overhead of doing so, rather than inflicting it on the core Docker project.

@ncoghlan I agree with the first parts of what you write. A couple of comments: I use Docker, and I want these features, but tools like Kubernetes tends to make a lot of architectural assumptions. If they work for you, great, but Kubernetes for example is not at all attractive for me for the same reasons that Docker is: It's way too complicated for my typical use cases. I think that will apply for a lot of Docker users.
Being able to get this functionality in a more focused tool is a large part of the appeal with support for the mentioned functionality directly in Docker. I also don't think it'd be good for Docker for the default choice for a large part of user to be to either consume Docker containers via Rocket (Rocket has added support for Docker images), or wrap Docker in a higher level interface just to get this functionality.
(Also, just to avoid confusion: this PR is about adding support for ACI, specifically not Rocket, which is one of multiple implementations of ACI.)
But even if this PR is not suitable, together with the associated proposal it provides workable example code of how to achieving this. I would hope that that at least gets a serious look. For starters, there are elements there that ought to be fairly simple and possible to to agree on a shared approach with ACI/Rocket, such as a content signature.
Even just having Docker and ACI images share the same algorithm for determining a content hash, and for Docker to make it possible to operate on images (run, reference from Dockerfile etc.) by hash would be a big step forwards on it's own. That, coupled with an interface to importing layers into Docker from the file-system (possibly lifted from this PR) would seem to be sufficient to make it possible to implement your own pull mechanism for ACI images "on the side" of Docker.
So perhaps it might be possible to extract some very limited pieces of functionality here that would add real benefits in the short term, and allow those who want it to interop more easily with ACI (or other tools/formats) without taking the whole thing.

FWIW work has already begun (also by CoreOS folks) to make kubernetes
support ACI, so that will soon be an option for many people.  But for those
people who don't want/need Kubernetes something else will be needed.
On Feb 14, 2015 8:01 PM, "ncoghlan"<EMAIL_ADDRESS>wrote:

I suspect the following parts are items folks can agree on:

DNS based federation is good, and we'd like to see that in Docker
itself
content addressability is good, and we'd like to see that in Docker
itself
decoupling the container format from the container management UX is
at least potentially beneficial to end users

It doesn't follow that accepting this PR is the correct way to address
those needs, as the negative consequence for long term usability and
maintainability may be significant. What the PR does show is that it's at
least possible to do that within the context of Docker as it exists today,
even if the implementation details and the UX consequences make this
specific approach a bad idea.
For users that want this kind of capability in the near future, a higher
level container orchestration system like Kubernetes can probably abstract
away the details of Docker invocation more easily than Docker can abstract
away the details of its image format (Note: a container abstraction at the
k8s layer will cover my own use cases if the need to use ACIs directly came
up for some reason, so it's worth factoring that in when I say that I
consider direct support for Rocket-in-Docker to be redundant and not
something I want on my servers)
I'd personally prefer that the Docker and Rocket teams take the time to
focus on the hard work of collaborating on a shared image format standard
in the interests of their respective users. Let folks that decide they
really need to run both in the interim be the ones that incur the
maintenance overhead of doing so, rather than inflicting it on the core
Docker project.
--
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10776#issuecomment-74403112.

Posturing aside, I would love to see an impartial breakdown of the differences in Appc vs Docker's  image spec, and the changes they are making in docker/distribution, and pro/cons of the technical merits of choices.
I don't mind seeing differences where companies are forging around with using their UX to add value.  I don't want to see meaningless differences about things like how to hash a tarsum because no-one wanted to discuss the options, since then every toolmaker has to compensate for the differences, and you slow down the entire ecosystem unnecessarily

@wyaeld This is a good suggestion. There are a number of outstanding proposals against Docker that appc might be able to show a concrete implementation for and that is described in the proposal on #10777.
To start a discussion I wrote-up a description of how the image manifests differ between appc and Docker v1 just now: https://github.com/docker/docker/issues/10777#issuecomment-74608134

@philips As you stated that this is a proof of concept and not intended for merging it doesn't really make sense as an open pull request. I would like to suggest you close this and we continue to have a discussion on the proposal issue #10777. As a closed PR it can still serve as a good reference for the proposal which you stated was the intent in the first place.

@spf13 seems reasonable. Looking forward to continuing the discussion in #10777.

Sorry, didn't acknowledge that @jonboulle opened it initially. @jonboulle can you close?
Appreciate it @philips & @jonboulle and likewise looking forward to the discussion in #10777.

They say you can judge how free a society is by how it's treating it's dissidents, how free are you docker? When someone submit a PR containing 38,000 lines of code you show gratitude - quality and if it solves some problem doesn't matter - you show gratitude! The hostility and shitkid attitude in some of the comments are just embarrasing.
My two cents.

@tlyng I wish people would quit quoting that '38kloc' number like it was anything close to correct.
That's just so large because of how Go code vendoring works. If you run git diff --stat 8b010d9f $(ls | grep -v 'vendor') on this PR, you get a much clearer picture of "14 files changed, 942 insertions(+), 24 deletions(-)".
Just because he pulled in 37kloc of dependencies (and testdata with those dependencies) does not mean the code is instantly worthy of gratitude.
The discussion above about why this PR should not really be open is fine and logical; the code indeed is not something that is worth merging in its current state, and if someone improves it sufficiently a new PR could be opened.
The real crime docker is committing here, IMO, is the complete lack of discussion on the proposal #10777... That's where things could actually begin to change, but they appear to just be stonewalling it.

It doesn't matter the thousands of lines of code; what matters is how people respond to a pull request.
I wish I could get the Docker team to read this and follow it.
http://www.defmacro.org/2013/04/03/issue-etiquette.html

They just closed an issue where a container failed to restart between 0.10.0 and 1.0.0 as it's pre 1.0.  If we cannot guarantee the container restarting between major and minor versions; why are we using Docker?

@TheDong the LOC doesn't really matter. If you manage an opensource project and third party people / organizations -choose- to contribute (shit or not) you show gratitude for their efforts. That's my opinion atleast.
I can understand that developers may be somewhat sensitive to this PR, both Docker developers and the CoreOS team. Anyway for me as an end user I want support for those images atleast, I don't want to be locked in to any particular technology. I utilize docker for running images, not scheduling and similar - not orchestration and on-demand server creation. I'm basically looking for a tool which does one thing really good, launch images. There will be many container formats in the coming years, a tool that understand several will be a better  choice than a tool that understand one.

@tlyng (and others) I'm not sure why trying to push for cross-framework image standardization now should be expected to result in a better container ecosystem down the road. Perhaps it's premature to try to standardize these things up front, given how raw the ecosystem still is and how many gotchas likely still lurk.
There seems to be some assumption by a few of the commenters on this issue that there is malice or intentional neglect behind the lack of discussion on this proposal, but my opinion is that people are just busy with more important stuff.
Personally, I don't feel like choosing to work with Docker is locking me in to anything. I'm confident that the work I'm doing now with Docker will translate easily to future container systems and I see this PR as a bit of a distraction, particularly due to the peanut gallery sniping by people who aren't doing anything productive to address the problem they're complaining about themselves. Honest discussion toward actually advancing this proposal is one thing, but questioning people's motives is an entirely different thing.

Given the great work that the clusterhq guys have been doing with
Powerstrip to make plugins possible to the core docker engine, I wonder if
@philips could provide a pluggable (via powerstrip) way for people that
want to test out app container support.
On Fri, Feb 27, 2015 at 3:38 AM, Mike Dillon<EMAIL_ADDRESS>wrote:

@tlyng https://github.com/tlyng (and others) I'm not sure why trying to
push for cross-framework image standardization now should be expected
to result in a better container ecosystem down the road. Perhaps it's
premature to try to standardize these things up front, given how raw the
ecosystem still is and how many gotchas likely still lurk.
There seems to be some assumption by a few of the commenters on this issue
that there is malice or intentional neglect behind the lack of discussion
on this proposal, but my opinion is that people are just busy with more
important stuff.
Personally, I don't feel like choosing to work with Docker is locking me
in to anything. I'm confident that the work I'm doing now with Docker will
translate easily to future container systems and I see this PR as a bit of
a distraction, particularly due to the peanut gallery sniping by people who
aren't doing anything productive to address the problem they're complaining
about themselves. Honest discussion toward actually advancing this proposal
is one thing, but questioning people's motives is an entirely different
thing.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10776#issuecomment-76188257.

As a side note, instead of using --format I suggest using --foreign or something  similar.


Sub-form: Fix Summary2 TaskId bug

Use component-library app for testing. Validate that submit works as expected.

The issue was caused by TaskStore -> TaskState.overriddenDataModelUuid defaulting to an empty string, which caused incorrect logic flow in https://github.com/Altinn/app-frontend-react/blob/feature/subform/src/features/datamodel/useBindingSchema.tsx#L49, resulting in getDataModelUrl to be called with an empty (but not null) argument.
Resolution was implemented by not providing empty-string default values, as opposed to changing the logic check in the above file.


[Search v2.3] [App] Update the mobile menu for Saved Searches

We need to update the mobile menu for Saved Searches.
More details here
Issue OwnerCurrent Issue Owner: @lakchote

Done


Minor invoker fix

Deleted annoying info msg
Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

@JosepSampe does this change affects the external API used by the consumers?

@gilv No, it doesn't affect external API. It only contains minor internal changes.


Maven build failed

I'm trying the sample code here and cannot get the first step succeed i.e. ./mvnw clean package failed.
Error as the snapshot.
How to get around that?
Regards,
Nam

Looks the same as #254  you should first install jetcd-core at least

Hi @lburgazzoli,
I expect the maven to install that for the sample code.
Or I may misunderstand maven usage here?
Nam

It does if the version required is available from on a maven repository but jetcd 0.1.0-SNAPSHOT is not so you need to install it from sources.


[BUG] Read Parquet does not ignoreCorruptFiles

Describe the bug
On a CPU cluster when we set the following:
spark.conf.set("spark.sql.files.ignoreCorruptFiles", true)
Parquet files are then read and corrupt files are skipped over.
On GPU cluster with the same config corrupt files cause an exception to occur:
java.lang.RuntimeException:
... is not a Parquet file expected magic number at tail 80 65 82 49 but found 00 00 00 00
Steps/Code to reproduce bug
Please provide a list of steps or a code sample to reproduce the issue.
Avoid posting private or sensitive data.

Add a corrupt file to a directory of parquet files
Try and read directory of parquet files with ignoreCorruptFiles=true

Expected behavior
A clear and concise description of what you expected to happen.
Corrupt files should be ignored.
Environment details (please complete the following information)

Environment location: [Standalone, YARN, Kubernetes, Cloud(specify cloud provider)]
Spark configuration settings related to the issue

Databricks: 9.1 LTS ML (includes Apache Spark 3.1.2, GPU, Scala 2.12)
Init Script:
#!/bin/bash
sudo wget -O /databricks/jars/rapids-4-spark_2.12-21.12.0.jar https://repo1.maven.org/maven2/com/nvidia/rapids-4-spark_2.12/21.12.0/rapids-4-spark_2.12-21.12.0.jar
sudo wget -O /databricks/jars/cudf-21.12.2-cuda11.jar https://repo1.maven.org/maven2/ai/rapids/cudf/21.12.2/cudf-21.12.2-cuda11.jar
spark config:
spark.task.resource.gpu.amount 0.0625
spark.sql.files.ignoreCorruptFiles true
executor.extraJavaOptions -Dlog4j2.formatMsgNoLookups=true
spark.plugins com.nvidia.spark.SQLPlugin
fs.s3a.acl.default BucketOwnerFullControl
spark.locality.wait 0s
fs.s3n.impl.disable.cache true
driver.extraJavaOptions -Dlog4j2.formatMsgNoLookups=true
spark.rapids.memory.pinnedPool.size 2G
spark.sql.adaptive.enabled false
fs.s3.impl.disable.cache true
fs.s3a.impl.disable.cache true
spark.databricks.delta.optimizeWrite.enabled false
spark.rapids.sql.concurrentGpuTasks 2
Additional context
Add any other context about the problem here.

Thanks for the report, @chawkm!  Yes, this is a missed requirement in the Parquet read code.  Should be relatively easy to address by wrapping the access in a try block as the Spark code does.


[AVM Module Issue]: Location is set in variables as optional (default = null), but it is required by the module

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Module specific issue

[X] I confirm that this issue is about this AVM module and not about the resource itself, or how to use Terraform.

Issue Type?
Bug
(Optional) Module Version
0.1.4
(Optional) Correlation Id
No response
Description
Title says it all. It should default to the resource group if it is not specified as per AVM guidelines

Hi @bryansan-msft ,
Thanks for the feedback. I have resolved this issue by removing the null value on the location variable.