Security: HTTPS profile should be selected, not HTTP

related: #5416
VSC should follow security best practices and launch the the HTTPS profile like VS does.
VS output has:
Using launch settings from 'C:\tmp\TodoApi\Properties\launchSettings.json' [Profile 'http']...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5072
warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
      Failed to determine the https port for redirect.

Follow the instructions at the Microsoft Web API tutorial-Create a web project
dotnet new webapi -o TodoApi
cd TodoApi
code -r ../TodoApi

^F5 and it launches a browser to http:localhost::<port> not  HTTPS from launchSettings.json

I am not able to reproduce this, but it doesn't sound like an issue with VS Code or this extension.
When I try to launch the app I see the following in the debug console:
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Using launch settings from 'C:\proj\net6\TodoApi\Properties\launchSettings.json' [Profile 'TodoApi']...
...
 Press Ctrl+C to shut down.

It binds to both http and https because this is what launchSettings.json says to do:
...
  "profiles": {
    "TodoApi": {
      "applicationUrl": "https://localhost:7038;http://localhost:5255",
...

VS Code will then launch a web browser against whatever endpoint is printed first. If you want to only hit https, the right fix would be to have dotnet new only generate the https endpoint in launchSettings.json.

Can you keep this open until I get the security folks opinion? Why can't you check if there's a HTTPS profile and use that or an HTTPS endpoint? VS does it right because when you open a VS issue the VS folks don't kick the can down the road to extensions and the extensions folks kick it further.

@Rick-Anderson when you launch an app from VS if the app URLs contain https and http it will launch with both but the default browse URL is the https endpoint.
Here is the output for a new web app in VS
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:7264
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5189
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\Users\sayedha\source\repos\WebApplication51\WebApplication51\

@Rick-Anderson when you launch an app from VS if the app URLs contain https and http it will launch with both but the default browse URL is the https endpoint.

Right, I'd like VSC to do the same thing, launch the browser at the HTTPS endpoint.

VS Code doesn't understand ASP.NET. It will launch a browser against whatever URL shows up first that matches this pattern:
            "serverReadyAction": {
                "action": "openExternally",
                "pattern": "\\bNow listening on:\\s+(https?://\\S+)",
                "uriFormat": "%s/swagger"
            },

I couldn't reproduce this problem -- for me the browser is always launched against https. If you can, what do you see in the debug console? Regardless, I don't see how there is anything that the C# extension or VS Code could fix short of a major rewrite to how launch works.

what do you see in the debug console?

Using launch settings from 'C:\tmp\yy\TodoApi\Properties\launchSettings.json' [Profile 'http']...
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5230
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: C:\tmp\yy\TodoApi
warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
Failed to determine the https port for redirect.

VS Code doesn't understand ASP.NET. It will launch a browser against whatever URL shows up first that matches this pattern:
            "serverReadyAction": {
                "action": "openExternally",
                "pattern": "\\bNow listening on:\\s+(https?://\\S+)",
                "uriFormat": "%s/swagger"
            },

But you added that, customers won't add that.

@gregg-miskelly  this is what dotnet new webapi -o TodoApi generates. You're saying the dotnet team should list the HTTPS profile first and then VSC will launch the HTTPS endpoint - right?
{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:12238",
      "sslPort": 44339
    }
  },
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "http://localhost:5230",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "launchUrl": "swagger",
      "applicationUrl": "https://localhost:7126;http://localhost:5230",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Correct. I think this bug should move to the .NET SDK repo. The .NET CLI has the same problem:
C:\proj\TodoApi> dotnet run
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5271
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\proj\TodoApi

@sayedihashimi do you know what the right repro is for bugs in the webapi template?

@gregg-miskelly  it's not just Web API's, it's all the web projects
dotnet new mvc -o MvcMovie
code -r MvcMovie

dotnet new web -o TodoApi
cd TodoApi
code -r ../TodoApi

dotnet new webapp -o RazorPagesMovie
code -r RazorPagesMovie

The code for all the web templates is in https://github.com/dotnet/aspnetcore so I believe that’s the correct place for web template issues.

Per @sayedihashimi  transferred to https://github.com/dotnet/aspnetcore/issues/44722

I am reopening this, as, once https://github.com/OmniSharp/omnisharp-vscode/issues/3187 is fixed, we should consider matching Visual Studio rather than the CLI experience on Mac and Windows. Linux will stay the same.


Delete manifests/e/EMOJI-FZCO/VoiceHotKey/1.4.9 directory

This version is no longer available
Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

URL: https://app.voicehotkey.com/releases/win-x64/VoiceHotKeySetup-v1.4.9.exe
Status Code: 200
(Automated message - build 887)

At the moment, it can be downloaded because this version is available in Winget. Once it is removed, the setup.exe will also be deleted. This version is no longer supported, so clients should not have the ability to download it.


[Tachyon-681] Balance the data over local and remote workers when writing or copyFromLocal

Modification of the code allowing to choose the strategy when copying from local. The 2 proposed strategies are:

the initial one: copy on the local worker if there is one or  otherwise on a remote worker choses randomly
the balance one: copy on the worker with the more free space

Can one of the admins verify this patch?

ok to test

Thanks for the patch! I left a few comments. Also, what about putting balancer directory into master instead of worker since the logic of choosing a worker seems to be master's responsibility, worker is only to manage blocks.

Jenkins, test this please.

@fannyn7 Thanks for update! Left a few minor comments.

Concerning the changing of the interface to NetAddress getWorker(String host, Map<Long, MasterWorkerInfo> mWorkers, Map<NetAddress, Long> mWorkerAddressToId), in common/src/main/java/tachyon/thrift/MasterService.java, the attribute "random" is said required. However, as you said it seems we can remove it from the interface above. What is the reason for the requirement of this boolean attribute "random" at the MasterService.java level ?

@fannyn7 If you would like to change the interface, you need to change the thrift service design in common/src/thrift/tachyon.thrift and regenerate the common/src/main/java/tachyon/thrift package.

Hi @fannyn7 , thanks for this patch! I left some comments and questions in the code.

I would like to consider Blocks and not the file entirely when balancing the data over the nodes. For this purpose, I was looking at the close() method in the WorkerClient class. When is, actually, the connection with the worker closed ?

Choosing a new worker for every block is not supported right now, and would be a new feature.
I left a question in the code because I still don't understand why the outstream needs to know what kind of balancer was used. Thanks!

Has this new feature for choosing a new worker for every block already been started to be implemented ?  If so, could you let me know please the link for the development of this feature ?

Thanks @fannyn7 ! I left some questions and comments in the review.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/Tachyon-Pull-Request-Builder/4303/Build result: FAILURE[...truncated 2323 lines...][JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/s3/target/tachyon-underfs-s3-0.8.0-SNAPSHOT.jar to org.tachyonproject/tachyon-underfs-s3/0.8.0-SNAPSHOT/tachyon-underfs-s3-0.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/s3/target/tachyon-underfs-s3-0.8.0-SNAPSHOT-sources.jar to org.tachyonproject/tachyon-underfs-s3/0.8.0-SNAPSHOT/tachyon-underfs-s3-0.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/s3/target/tachyon-underfs-s3-0.8.0-SNAPSHOT-javadoc.jar to org.tachyonproject/tachyon-underfs-s3/0.8.0-SNAPSHOT/tachyon-underfs-s3-0.8.0-SNAPSHOT-javadoc.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/pom.xml to org.tachyonproject/tachyon-clients/0.8.0-SNAPSHOT/tachyon-clients-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/unshaded/pom.xml to org.tachyonproject/tachyon-client-unshaded/0.8.0-SNAPSHOT/tachyon-client-unshaded-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/unshaded/target/tachyon-client-unshaded-0.8.0-SNAPSHOT.jar to org.tachyonproject/tachyon-client-unshaded/0.8.0-SNAPSHOT/tachyon-client-unshaded-0.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/unshaded/target/tachyon-client-unshaded-0.8.0-SNAPSHOT-sources.jar to org.tachyonproject/tachyon-client-unshaded/0.8.0-SNAPSHOT/tachyon-client-unshaded-0.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/unshaded/target/tachyon-client-unshaded-0.8.0-SNAPSHOT-javadoc.jar to org.tachyonproject/tachyon-client-unshaded/0.8.0-SNAPSHOT/tachyon-client-unshaded-0.8.0-SNAPSHOT-javadoc.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/servers/pom.xml to org.tachyonproject/tachyon-servers/0.8.0-SNAPSHOT/tachyon-servers-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/hdfs/pom.xml to org.tachyonproject/tachyon-underfs-hdfs/0.8.0-SNAPSHOT/tachyon-underfs-hdfs-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/hdfs/target/tachyon-underfs-hdfs-0.8.0-SNAPSHOT.jar to org.tachyonproject/tachyon-underfs-hdfs/0.8.0-SNAPSHOT/tachyon-underfs-hdfs-0.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/hdfs/target/tachyon-underfs-hdfs-0.8.0-SNAPSHOT-sources.jar to org.tachyonproject/tachyon-underfs-hdfs/0.8.0-SNAPSHOT/tachyon-underfs-hdfs-0.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/hdfs/target/tachyon-underfs-hdfs-0.8.0-SNAPSHOT-javadoc.jar to org.tachyonproject/tachyon-underfs-hdfs/0.8.0-SNAPSHOT/tachyon-underfs-hdfs-0.8.0-SNAPSHOT-javadoc.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/pom.xml to org.tachyonproject/tachyon-parent/0.8.0-SNAPSHOT/tachyon-parent-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/client/dependency-reduced-pom.xml to org.tachyonproject/tachyon-client/0.8.0-SNAPSHOT/tachyon-client-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/client/target/tachyon-client-0.8.0-SNAPSHOT.jar to org.tachyonproject/tachyon-client/0.8.0-SNAPSHOT/tachyon-client-0.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/client/target/tachyon-client-0.8.0-SNAPSHOT-sources.jar to org.tachyonproject/tachyon-client/0.8.0-SNAPSHOT/tachyon-client-0.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/clients/client/target/tachyon-client-0.8.0-SNAPSHOT-javadoc.jar to org.tachyonproject/tachyon-client/0.8.0-SNAPSHOT/tachyon-client-0.8.0-SNAPSHOT-javadoc.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/shell/pom.xml to org.tachyonproject/tachyon-shell/0.8.0-SNAPSHOT/tachyon-shell-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/glusterfs/pom.xml to org.tachyonproject/tachyon-underfs-glusterfs/0.8.0-SNAPSHOT/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT.pom[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/glusterfs/target/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT.jar to org.tachyonproject/tachyon-underfs-glusterfs/0.8.0-SNAPSHOT/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/glusterfs/target/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT-sources.jar to org.tachyonproject/tachyon-underfs-glusterfs/0.8.0-SNAPSHOT/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT-sources.jar[JENKINS] Archiving /home/jenkins/workspace/Tachyon-Pull-Request-Builder/underfs/glusterfs/target/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT-javadoc.jar to org.tachyonproject/tachyon-underfs-glusterfs/0.8.0-SNAPSHOT/tachyon-underfs-glusterfs-0.8.0-SNAPSHOT-javadoc.jarchannel stopped
Test FAILed.

I don't understand why this error appears, it worked before... Moreover I don't have any issues when building on my local repository.
The error I get during the build says that no suitable method found for getClass(java.lang.String,java.lang.Class<tachyon.master.balancer.LocalFirstBalancer>). However, I have the method "public  Class getClass(String key, Class defaultValue)" in TachyonConf.
Have you an idea why this error occurs ?
[ERROR] /home/jenkins/workspace/Tachyon-Pull-Request-Builder/servers/src/main/java/tachyon/master/balancer/Balancer.java:[47,13] no suitable method found for getClass(java.lang.String,java.lang.Class<tachyon.master.balancer.LocalFirstBalancer>)
method tachyon.conf.TachyonConf.getClass(java.lang.String) is not applicable
(cannot instantiate from arguments because actual and formal argument lists differ in length)

You may have to merge changes from master, since there were changes to TachyonConf. More specifically, the defaultValue for the getClass() call is no longer used.

Can one of the admins verify this patch?

Hi @fannyn7, are you still planning on working on this feature? If not, do you mind closing this PR?

@fannyn7 the data balancing can be achieved by a roundRobinPolicy introduced by https://github.com/amplab/tachyon/pull/2284. So I'll close this PR.


Dont continue past pregame if you cant start

Maybe this is unnecessary, I am trying to rethink about the stages of the game. Possibly there doesn't need to be these 'game states' and we can just reset the game when the timer runs out. Or, Just the mid-game state and post-game.
Ideas are welcome, I am trying to rethink it myself.

Fixed more or less.


CI: observed frequency of failures differs depending on Jenkins job

The Ginkgo-CI-Tests-Pipeline vs. the Cilium-Master-Ginkgo-Tests-Validated jobs appear to have differing rates of failure.
This was referred to during the Cilium community meeting notes:

Frequency of failures for builds of master is different depending on Jenkins Job?!?!?

Maybe we can inject truly random seeds per-job.
We need longer job history in Jenkins to assess this.
Can we “fake” what’s going on locally?
We should look into what is going on before trying to assert what the fix is.

anything else? cc: @raybejjani . I created this issue to track this so we don't lose information deep in the Cilium Community Meeting notes.

@raybejjani you had mentioned this a while back - is this still a concern?

This is inactive, closing.


Make is_layout_rtl() translation domain aware

Fixes #97893
This PR is mostly extracted from my #96921:

The edited scene root is now using the main translation domain.
Locale can be overridden per TranslationDomain.
In the editor, main translation domain's locale is overriden to use the fallback locale (en).

For now, if users do want to use RTL in the edited scene, they can set project settings like force_right_to_left_layout_direction, root_node_layout_direction, or the fallback locale.

is_layout_rtl() is now translation domain aware.

The translation domain's locale of current node is used instead of global TranslationServer.get_tool_locale().
When using inherited layout direction, the search stops at the last parent sharing the same translation domain.

Currently, this locale override behavior is available to engine code only, and is only used by the edited scene root. So it's relatively safe. API exposing and proper runtime switching will be implemented by a follow-up #96921.

Some further changes needed related to this PR:
It seems that TranslationServer.get_tool_locale() should be avoided in most places now because locale is potentially node-dependent. I did not touch those usages in TextServer because I don't know what's the best way to handle this change. For example:
https://github.com/godotengine/godot/blob/db66bd35af704fe0d83ba9348b8c50a48e51b2ba/modules/text_server_adv/text_server_adv.cpp#L1760
CC @bruvzg

It seems that TranslationServer.get_tool_locale() should be avoided in most places now because locale is potentially node-dependent. I did not touch those usages in TextServer because I don't know what's the best way to handle this change.

There are two cases:

get_tool_locale used as fallback if locale is not specified when setting up text, in this case controls can properly set it (currently most of them do not).
It's used to read font feature names when loading font (names are used by the editor), not sure what's the best way to fix it. I guess TextServer can read all available languages, and editor UI select one it wants to use.

I converted as much of the get_tool_locale() in the first case as possible to the actual locale.
It's submitted as a separate commit for easier review.


Globber exception when path has ampersand

An expresion like:
var tools = GetFiles("C:/Tools & Services/*.dll");
fails with a NotSupportedException - "Unknown token"
PR soon...

Fixed via https://github.com/cake-build/cake/commit/a655e02acfab6ce11ee63a97b1a25282cd9ecbb8


Automated smoke test for caikit serving

@Xaenalt could you add relevant labels and complexity etc and updates too please?

Yep, currently working on this, also requires some debugging of the current issues with the image builds

https://github.com/opendatahub-io/text-generation-inference/issues/8

https://github.com/opendatahub-io/caikit-tgis-serving/pull/25

Had a discussion with testing folks, working on moving tests into openshift-ci so we can have testing earlier in the code pipeline

For testing, one can use make docker-test it'd be good to put that into CI


add forums analytics

https://openedx.atlassian.net/browse/MA-1068

@aleffert Please review
@miankhalid FYI

I'm not sure the additionalInfo approach to adding extra properties makes sense. We want to be able to view as much information as possible on the GA website. By passing in nil for the value field in trackScreen we're wasting a field. We should instead be using that field to surface the most interesting piece of information that users of GA will actually want to see. If we have other information we want to capture for an event, then we should maybe define an explicit separate event for it, since that gives us more fields to work with.

@aleffert please review

It looks like we're still using nil for the value field? Maybe you and Usman should circle back on that? Since we'll need to do the same thing with android anyway

@symbolist FYI

@aleffert I was under the impression that GA supported arbitrary attributes for events but now looking at the docs I realize there are restrictions on that.
Thinking about this again, the attributes we are collecting are course_id, topic_id, thread_id and response_id (the last three of which are present only in specific events). course_id is an available custom metric in GA, so that can go through. For the other three attributes I can think of two options for setting the value:

Something like <topic_id>/<thread_id>/<response_id>.
The most specific of these ids. For example, for the "View Thread" event, send the thread_id and for "View Response" send the response_id.

For the "Search" event the search string can be the value.
What do you think?

@symbolist If I recall correctly the ids aren't very human friendly, so we'd have to do a look up on them anyway and at that point we can probably look up their parents anyway, so maybe just do the most specific one? For GA, the titles might actually be more useful than the ids. But we should make sure the ids get sent as side properties so we can eventually do something useful with them in the tracking logs.

@aleffert If we are sending side properties to the tracking logs we might as well send all the attributes that we are sending now in additional info.
For the action attribute sent to GA, I agree we can use the title instead.

@aleffert please review

I'm a little concerned about the threadTitle stuff, just because at some point we will deal with deeplinks directly to a thread or comment, and so we won't just be able to pass titles between screens. @symbolist thoughts?

Beyond that there are just a few small style nits :+1:

@aleffert I see. In that case we are restricted to the data that is available at the level. And is there any attribute besides the id of the relevant object which we are displaying which it makes sense to pass? I cannot think of any.

@symbolist That may be the only thing that makes sense, or we may decide that it's better to sometimes show nothing in exchange for getting more useful data sometimes. But my inclination is to do the thing we can be consistent about

Current coverage is 47.21%

Merging #646 into master will decrease coverage by -0.01% as of 19b7dae

@@            master    #646   diff @@
======================================
  Files          419     419
  Stmts        28044   28108    +64
  Branches         0       0
  Methods
======================================
+ Hit          13243   13272    +29
  Partial          0       0
- Missed       14801   14836    +35

Review entire Coverage Diff as of 19b7dae

Powered by Codecov. Updated on successful CI builds.

@aleffert I removed the threadTitle from constructor because now we have thread object on all screens. Follow the new style of defining keys. Please review

@aleffert Please review.

There are a couple minor style things that need to be fixed. Otherwise looks good. :+1:  @saeedbashir did you go and compare these to what android has? It's good for us to cross check in addition to looking at the spec


correct spelling mistake

Change "Github" to "GitHub"

Thank you for catching that @Omar8345 ! And creating this PR

You're welcome!

Found another one, I am a great inspector 🔎


fieldViolation : safetyState

Hello,
The "fieldViolation" parameter is TRUE if the field is violated at the time the "STATE" message is sent?
The AGV does not send the information if a violation of the field has occurred? With the id of the edge on which the event occurred.
Thanks,

Correct: a "field violation" isn't a trigger; maybe the vehicle sends a new state, but you cannot rely on.
Events that trigger the transmission of the state message are:
- Receiving an order
- Receiving an order update
- Changes in the load status
- Errors or warnings
- Driving over a node
- Switching the operating mode
- Change in the "driving" field
- Change in the nodeStates, edgeStates or actionStates


Random Crash in propagateLatestMessages

@ekazaev  #71
I am still facing same issue,I am unable to reopen issue so i added reference please find reference #71.

I reopened your issue and replied there.


update ci with pocl and test

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@61e92b2). Click here to learn what that means.
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@          Coverage Diff           @@
##             main     #53   +/-   ##
======================================
  Coverage        ?   1.95%
======================================
  Files           ?      17
  Lines           ?     715
  Branches        ?       0
======================================
  Hits            ?      14
  Misses          ?     701
  Partials        ?       0

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

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

This should be ready to merge.
What to remember from this PR:

We can make CMake search for OpenCL first in the Conda env by populating the CMAKE_PREFIX_PATH var.
POCL provide an OpenCL ICD against which CLIc and pyclesperanto can build on. More test in future should be done on if this ICD can see or not the devices outside the conda env.
The compiled pyclesperanto.so lib could not find the libOpenCL even though it was used for compilation. Dynamic links where not saved. Filling the LD_LIBRARY_PATH was an option (not great), better alternative is to update the RPATH of the library in CMAKE. Full detail on how this works was not clear.

Lets merge this and see where it goes :rocket:


Cloudwatch Metrics are published with a timestamp of several minutes in the future

This sample application have been affected by a conversion error on the cloudwatch_metrics_collector node. We have detected the problem, and we are working on deploying a fix, that should be available by the end of next week.

The code fix was merged to the master and release-v1 branches of cloudwatchmetrics-ros1. We are keeping this issue open until the fix is also available in our Apt packages

cloudwatch_metrics_collector is actually not used in the launch file for this sample app, see #9. So this was a false positive, closing this issue as this sample app is not affected


Update README.md

Fix broken link.

If you don't mind, use http://www.w3.org/TR/CSP2/ and update the 1.1 reference to "level 2"

@oreoshake made those changes and squashed.


feat(RingTheory/LaurentSeries): finishes the proof that LaurentSeries are the X-adic completion of Rational Functions

We add two sections to the file RingTheory/LaurentSeries:

Dense, proving that the rational functions are dense in the Laurent Series
Comparison, providing the isomorphism between the X-adic completion of rational functions with Laurent Series, and then specializing this to an isomorphism between the unit ball in the former with power series.

Co-authored-by: María Inés de Frutós Fernandez @mariainesdff

@riccardobrasca OK, this erw business opens a worms can. I have tried to dig a bit, and it really seems related to the interplay between IsLocalization.lift and IsLocalization.sec which sometimes require erw instead of rw. I am willing to get a better perspective and to work on this, but I believe this is out of the scope of this PR, so I'd prefer to have it go (at least insofar this erw business is concerned) and then come back later with some modifications if I can figure out how to improve the state of affairs.

Sure, don't worry too much about it.

@riccardobrasca OK, this erw business opens a worms can. I have tried to dig a bit, and it really seems related to the interplay between IsLocalization.lift and IsLocalization.sec which sometimes require erw instead of rw. I am willing to get a better perspective and to work on this, but I believe this is out of the scope of this PR, so I'd prefer to have it go (at least insofar this erw business is concerned) and then come back later with some modifications if I can figure out how to improve the state of affairs.

Sure, don't worry too much about it.

Thanks! Are there then any comments, either from you or from @jcommelin ?

Thanks!
bors merge


Update instructions in README

Because new versions of npm no longer automatically run prepublish on install, we should

[x] update the instructions for running iD in README.md to include a npm run all step.
[x] remove prepublish hook from package.json

cc @JamesKingdom

@bhousel
Readme.md states Node.js version 4 or newer as a prerequisite. This needs to be updated.
I don't know which version is really required for iD. I had updated my system to the newest version due a failing 4.x.x version.

Readme.md states Node.js version 4 or newer as a prerequisite. This needs to be updated.
I don't know which version is really required for iD. I had updated my system to the newest version due a failing 4.x.x version.

That's strange - we actually do matrix builds on travis against node 4, 6, and 8, and they have been succeeding:  https://travis-ci.org/openstreetmap/iD
@slhh if it happens again, can you open a new issue?  Node does occasionally get messed up and a clean reinstall of all dependencies (rm -rf node_modules then npm install) could fix things.


Performance issues when Target batch records are drained too often

Migrated from GitLab: https://gitlab.com/meltano/sdk/-/issues/172
Originally created by @pnadolny13 on 2021-07-23 16:22:56

When using the target sdk in batch mode the default behavior is to drain batches any time a new state message arrives regardless of the batch settings provided by the target. A specific case is that tap-snowflake emits a currently_syncing state message after every 1000 records but on the target side I may have a batch size of >1000. In this case my batch is getting drained more frequently than I'd like. There is a private property _DRAIN_AFTER_STATE that is set to true but theres no way to override this without changing private variables.
Proposed Changes:

making _DRAIN_AFTER_STATE a public property that can be overridden like max_parallelism
default behavior should be to check the new state message against the existing state and only drain if the state has changed
log a warning or info message letting the user know that their batch was drained prior to being full and for what reason especially if this ticket implements some other optimizations. Something like Batch draining prior to being full due to a state message change: batch 1000, max size 10000

Thoughts? I'm happy to make these proposed changes if theyre accepted.
Related to https://gitlab.com/meltano/sdk/-/issues/135.

View 18 previous comments from the original issue on GitLab


code already running .but not print program

my program not print in output or terminal

give me solution

/needsMoreInfo


Input datetime: Align validation icons in firefox

https://percy.io/3f971362/design-system/builds/34995814/changed/1912830934?browser=firefox&browser_ids=47%2C59%2C60%2C62&group_snapshots_by=similar_diff&subcategories=unreviewed%2Cchanges_requested&viewLayout=overlay&viewMode=new&width=1024&widths=320%2C375%2C400%2C600%2C780%2C1024%2C1280%2C1440
### Tasks
- [ ] Align validation icons on the baseline of the input value in Firefox
- [ ] Check other types like date or time

Closing as done


How to create mat file of VOC selective search regions

Hi Georgia, I reviewed your code and find that the selective search region proposals are load from cached matlab files directly (155 line, in RStarCNN_ROOT/lib/dataset/pascal_voc.py). And as far as I know, the code of selective search (like in here: https://github.com/sergeyk/selective_search_ijcv_with_python) doesn't give a matlab file output. So could you give me the code that generated matlab files of ss region because I want to use RStarCNN in another dataset,  thanks!

The selective search regions for all datasets were computed with the source code of Selective Search. For example look here.
Then the regions are stored (in mat files) and loaded from datasets/pascal_voc.py.

Thanks for explaining, that's useful, and I think this will solve my problem.


Support Arrow list arrays

This is needed for spiral, I will move this forwards

Looks like @joseph-isaacs merged something in https://github.com/spiraldb/vortex/pull/1524
I'll let him close out this issue if it's considered sufficiently complete


Backlight through gpio not working

I have tried setting my parameters like so for my raspberry pi zero 2 w running retropie and my generic ili9341 display (https://www.amazon.ca/Module-daffichage-ILI9341-fonction-tactile/dp/B07BDML7LM/ref=sr_1_1_sspa?crid=DZH96OQAU1ZC&keywords=ili9341&qid=1649884052&sprefix=%2Caps%2C180&sr=8-1-spons&psc=1&smid=A36ZH2MCHPKXUA&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUExNjlDMFUxWjNEOTlKJmVuY3J5cHRlZElkPUEwNTA5NjYwM0lUNVlFWTlJSkEwQyZlbmNyeXB0ZWRBZElkPUEwNzk0MzYyMTVPMUw1RVNUSFRCMiZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU=):
cmake -DILI9341=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DGPIO_TFT_BACKLIGHT=12 -DSPI_BUS_CLOCK_DIVISOR=6 -DSTATISTICS=0 ..
But, the backlight doesn't work I know the rest works, because when I plug the led pin of my display to 5v instead of gpio12 the whole screen works. However, when I plug led into the assigned backlight pin as mentionned in my settings (-DGPIO_TFT_BACKLIGHT=12) it doesn't work and I get a black screen.
Any idea on what I should do?

Hi @Leolechameau, I just re-read the readme and you can see this:

Just add: -DBACKLIGHT_CONTROL=1 to your cmake command. That was what was missing for me...
I hope it helps...

Thanks!!!


ImportError: cannot import name 'OpenAI' from 'openai'

Confirm this is an issue with the Python library and not an underlying OpenAI API

[X] This is an issue with the Python library

Describe the bug
Exactly this:
ImportError: cannot import name 'OpenAI' from 'openai'

Seems like is just a silly mistake that you didn't notice you had removed such an important part of the package, I had to pin my version to 1.7.1 to avoid this.
To Reproduce
Just update to the latest version (1.7.2) and then try to import using the examples described in the documentation.
Code snippets
No response
OS
Ubuntu
Python version
Python v3.10.12
Library version
openai v1.7.2

Hmm, I can't reproduce this:
Python 3.9.18 (main, Oct  2 2023, 20:16:14)
[Clang 16.0.3 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import openai
>>> openai.version.VERSION
'1.7.2'
>>> from openai import OpenAI
>>> OpenAI
<class 'openai.OpenAI'>

Can you try reinstalling 1.7.2 and try again? If you run into an error again, can you share your code and the full traceback?

I am having the same issue on 1.9.0. The import is simply not existing:

I had the same problem as OP. It turned out to be a problem with my own management of python version and packages.
When I checked the version of openai with this command, I was on a very, very old version. I was on 0.23. I was also running 2 different versions of python: 3.10.8 when I checked the version of which python3, but 3.10.6 when I checked the version of which python. This is just another reminder to be very careful when managing multiple versions of techs!
Here is how you fix the problem:

Uninstall all versions of openai:

python3 -m pip uninstall openai

Docs on pip uninstall command:
https://pip.pypa.io/en/stable/cli/pip_uninstall/

Install the latest version of openai:

python3 -m pip install openai==1.23.6

Always make sure you append the python3 -m pip ... prefix. This will prevent you from installing packages on versions of python that you aren't actually usually.
Also, it's usually a good idea to peg your version number, just to make the debugging process easier.
Check here for the latest version:
https://github.com/openai/openai-python/releases
If you want a more global, automated solution, try running this code inside a conda env:
https://conda.io/projects/conda/en/latest/user-guide/getting-started.html


CustomScalar usage as resolvers

Hi,
I use a Type language schema, and I'm trying to implement custom scalar resolving.
In the graphqljs implementation, the custom scalar type is just a standard resolver like for other types, but it doesn't seem to be the case in graphql-php.
I've seen a previous issue that @vladar said to use the typeConfigDecorator option, and to handle it by hand.
I actually don't understand why this can't be considerated like a standard resolver, this should simplify the process, and this follow the graphqljs api.
Thanks.
Some links about that:
https://uptoskill.com/graphql-custom-scalars/
https://www.apollographql.com/docs/apollo-server/schema/scalars-enums/#date-as-a-scalar
https://www.graphql-tools.com/docs/scalars/

Types are just something else then resolvers, even in GraphQL. I see how the example in https://uptoskill.com/graphql-custom-scalars/ would be misleading you into thinking that - they have confusing variable naming. Their variable resolvers should really be called types.
That said, you can use custom scalars with SDL, as mentioned.


Remove old iso build script from quickstart (fixes rancher/elemental#516)

Removing the about-to-be-deprecated elemental-iso-build script. The current way to build installer ISOs is the elemental-iso-add-registration script.
Also adding a small clarification on downloading the registration info from Rancher.

sorry @timirnich new docs are located at https://github.com/rancher/elemental-docs :/

wrong repo 😞


unable to build when using  dev.gitlive:firebase-auth dependency

Task :shared:linkDebugFrameworkIosX64 FAILED
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld invocation reported errors

The /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld command returned non-zero exit code: 1.
output:
ld: framework not found FirebaseAuth
error: Compilation finished with errors
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':shared:linkDebugFrameworkIosX64'.

Compilation finished with errors

Try:

Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 8s
2 actionable tasks: 1 executed, 1 up-to-date
Here is an example project that demonstrates the issue: https://github.com/iamthearm/FirebaseKMMTest

Same happens to me, but for firebase-config.

Ok I managed to build by modifying the shares build gradle file.
I just added cocoapods.framework.isStatic to true
As per the file below.
`
plugins {
kotlin("multiplatform")
kotlin("native.cocoapods")
id("com.android.library")
}
@OptIn(org.jetbrains.kotlin.gradle.ExperimentalKotlinGradlePluginApi::class)
kotlin {
targetHierarchy.default()
android {
    compilations.all {
        kotlinOptions {
            jvmTarget = "1.8"
        }
    }
}
iosX64()
iosArm64()
iosSimulatorArm64()

cocoapods {
    summary = "Some description for the Shared Module"
    homepage = "Link to the Shared Module homepage"
    version = "1.0"
    ios.deploymentTarget = "14.1"
    podfile = project.file("../iosApp/Podfile")
    framework {
        baseName = "shared"
        isStatic = true // TODO setting this true solves this err --> ld: framework not found FirebaseAuth
    }
}

sourceSets {
    val commonMain by getting {
        dependencies {
            //put your multiplatform dependencies here
            // Firebase
            implementation("dev.gitlive:firebase-auth:1.8.1")
        }
    }
    val commonTest by getting {
        dependencies {
            implementation(kotlin("test"))
        }
    }
}

}
android {
namespace = "com.brentsys.dev.myapplication"
compileSdk = 33
defaultConfig {
minSdk = 24
}
`

Why would I use isStatic anyways? What if the iOS app already imports firebase? There will be conflicts because of the redefinition of the Firebase libs.


Please update documentation

In the Usage section, the callback for FCMEvent.Notification has a comment for iOS platform usage. It is regarding the notif.finish() function and it is said to check the documentation link provided above. Except there is no link 😔 or other info, for that matter.
Please provide some links to better understand the behaviour on iOS or what to expect, as it can get confusing

link added


Better GusterFS Plugin

File: engine/extend/legacy_plugins.md
This GlsterFS Plugin ist maintained:
https://github.com/trajano/docker-volume-plugins/tree/master/glusterfs-volume-plugin

Updated version of GlusterFS Plugin is at: docker-volume-plugins
Including S3 Volume Plugin.
Docker Hub Download:

GlusterFs
S3 FS
ARM Versions soon.

Thanks for sharing this issue. This particular topic is maintained in an upstream repo. If the issue is still applicable, please help create an issue or a PR in the source repo at https://github.com/docker/cli/tree/master/docs/extend
Closing this issue as unable to fix in this repo.


Intellisense does not work for large projects and also when multiple files are opened.

Language: Javascript (React)
Disabling all the extensions doesn't work the problem still persists.
It takes usually 5 sec and it happens every time not only first load.
The project is 11mb excluding node_modules.
It is bit faster when you open only one tab at a time, multiple tabs slows it down

VSCode Version: Code 1.15.0 (8b95971d8cccd3afd86b35d4a0e098c189294ff2, 2017-08-09T20:16:06.988Z)
OS Version: Windows_NT ia32 10.0.10586
Extensions:

Extension
Author (truncated)
Version

html-snippets
abu
0.1.0

project-manager
ale
0.19.0

run-current-test
asv
0.0.2

npm-intellisense
chr
1.3.0

path-intellisense
chr
1.4.2

vscode-eslint
dba
1.2.11

githistory
don
0.2.3

gitlens
eam
4.3.3

prettier-vscode
esb
0.22.1

flow-for-vscode
flo
0.7.1

auto-close-tag
for
0.4.3

auto-rename-tag
for
0.0.14

vscode-flow-ide
gca
1.2.0

beautify
Hoo
1.1.1

webpack
jer
2.0.0

chai-snippets
nwh
0.1.0

vscode-icons
rob
7.12.0

code-settings-sync
Sha
2.8.2

es6-mocha-snippets
spo
0.0.2

react-redux-es6-snippets
tim
2.1.0

vscode-react-native
vsm
0.4.1

JavaScriptSnippets
xab
1.4.1

ReactSnippets
xab
1.4.0

(2 theme extensions excluded)

Steps to Reproduce:

Language: Javascript (React)
Disabling all the extensions doesn't work the problem still persists.
It takes usually 5 sec and it happens every time not only first load.
The project is 11mb excluding node_modules.
It is bit faster when you open only one file at a time, multiple files open slows it down

Reproduces without extensions: Yes/No

Hey sorry this fell off my radar.
Please let me know if you are still seeing this issue in VS Code 1.18


Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
It's currently impossible to uninstall Google Chrome using winget uninstall Google.Chrome --silent, except as administrator. However, it's possible to uninstall normally without --silent and using interactive mode
Steps to reproduce
Install Google Chrome
Try to uninstall it using Winget --silent
Try to uninstall without --silent
Actual behavior
Error 1603 when uninstalling with --silent (except as admin)
Expected behavior
Be able to uninstall Google.Chrome (and other packages) using --silent.
If --silent fails, shouldn't Winget try to uninstall without this tag automatically?
Environment
Copyright (c) Microsoft Corporation. Todos os direitos reservados.

Windows: Windows.Desktop v10.0.19044.2006
Arquitetura do Sistema: X64
Pacote: Microsoft.DesktopAppInstaller v1.18.2691.0

Screenshots and Logs

Related to
* [Manifest fields for custom uninstall arguments and return codes winget-cli#1885](https://github.com/microsoft/winget-cli/issues/1885)

What do you think about this idea: If --silent fails, shouldn't Winget try to uninstall without this tag automatically?

One of our key design criteria has been supporting "unattended" installations to support things like winget import packages.json. We might consider a fallback approach to "non-silent" installs once we have some user driven settings or arguments to allow users to select that behavior.


[Nice-to-have] Shorthand for relative copy key references

Problem
For easier readability and maintenance, it is good practice to break-up large sections of copy.
However, as a copy file grows and becomes more nested, key interpolation can become quite verbose.
Here's an example demonstrating this 'keep it manageable' pattern. Several paragraph copy keys are combined together by pages.contributions.sections.copyService.description.primary:
{
  "pages": {
    "contributions": {
      "sections": {
        "copyService": {
          "content": "${pages.contributions.sections.copyService.title}${pages.contributions.sections.copyService.description.primary}",
          "title": "
Copy Service
",
          "description": {
LONG -->    "primary": "${pages.contributions.sections.copyService.description.firstParagraph}${pages.contributions.sections.copyService.description.secondParagraph}${pages.contributions.sections.copyService.description.thirdParagraph}",
            "firstParagraph": "
Waves crash all around
",
            "secondParagraph": "
Comp calmly hums in the breeze
",
            "thirdParagraph": "
Sand in my keyboard
"
          }
        }
      }
    }
  }
}

But the primary value above is long and adds noticeably ugly clutter - in a way, violating the pattern the key was meant to implement.
Solution Proposed
It would be easier to read something like this instead:
"primary": "${.firstParagraph}${.secondParagraph}${.thirdParagraph}"

So I propose a shorthand syntax, where a . prefixing the interpolated key causes a key lookup relative to the parent.
e.g., "primary": "${.firstParagraph}" above would tell the parser to lookup firstParagraph key relative to primary's parent: pages.contributions.sections.copyService.description, resulting in the full key:
pages.contributions.sections.copyService.description.firstParagraph

Going Further
From conversations with @NC-piercej , the syntax could also allow key references relative to ancestors (beyond the immediate parent).
For example, a key apples.buhnaynays.coconut.watermelon.cake => "...copyKey.path"
would attempt to lookup apples.buhnaynays.copyKey.path.

To implement this, we'd need:

A fourth argument to evalAST, namely the copy key currently being evaluated.
A new getAstForKey method on the evaluator that:

Takes two arguments:

the key, potentially with relative syntax
the root key to evaluate relative to

Calculates the key from the relative key (if necessary), and then defers to copyService.getAstForKey

I figured it could be handled at a lower level, in CopyService, as to not disturb public interfaces and have to bump a major version. But if it's somehow better to implement this in Evaluator I can revise the current PR

That works as well, I guess.


Shared gallery VM deployment CLI extension request

Resource Provider

Azure compute
Description of Feature or Work Requested

Gallery team currently has a feature called shared gallery, user can directly share their gallery to another subscription/tenant. This request is to allow user to deploy VM from these shared gallery.
The proposed CLI extension cmd for this new parameter is like:
az vm create -g MyResourceGroup -n MyVm -–image sharedGalleryImageUniqueId
(I believe currently “--image” is already an overloaded parameter which targets to different api model parameters according to https://docs.microsoft.com/en-us/cli/azure/vm?view=azure-cli-latest).
Minimum API Version Required

2021-03-1
Swagger Link

https://github.com/Azure/azure-rest-api-specs/pull/14922
Target Date

private preview - August 1st, 2021

Compute

@kangsun-ctrl l Hi,  at present, there seems to be no extension related VM deployment in CLI. Do you need us to develop based on an existing extension or build a new extension?

@kangsun-ctrl Hi, at present, there seems to be no extension related VM deployment in CLI. Do you need us to develop based on an existing extension or build a new extension?

Hi Xing Zhou, yes, there was no extension. So this is the first time we try the path of CLI extension. We want to try it for this small feature and see how much it improves our experience. I think you guys can build a new extension. And when our swagger goes to stable folder, you can just merge the CLI extension to official CLI. Thanks!

@kangsun-ctrl  Hi, in fact, our extension is usually used to implement new command groups or sub commands that are different from official CLI. Because this can avoid storing the same code logic both in CLI and CLI extension, otherwise it will increase our workload and make the subsequent code maintenance and bug fix more difficult. (Because it needs to keep the new logic on both sides in sync)
We usually use extension for several purposes:

To support breadth coverage, add new RP, new command groups, and new commands to extension.
There are huge modifications that may cause an unstable experience for users, such as Track 2 SDK migration
If only modify the logic for an existing parameter, we recommend updating it based on the previous logic in CLI.

Moreover, I also have some concerns about creating a new extension just to increase the value range for a parameter, because this may not be convenient for users:
If users install an extension only for the sake of more support for a parameter, it will cost them cognition and introduce more operation steps.
If users finds that shared gallery image id is not supported after uninstall this extension, he is more likely to be confused by mistaking it as a bug.

So may I ask do we have some reasons that it must need to be implemented in CLI extension? If not, I personally suggest that it be implemented in CLI.

So may I ask do we have some reasons that it must need to be implemented in CLI extension? If not, I personally suggest that it be implemented in CLI.

Hi Xing, I understand what you were meaning above. For my team, we never used cli extension before and we want to know how it works by trying it on a very small change. That's why we are targeting CLI extension for current change before we use it for any big changes you mentioned above.
Another reason is that we have a tight schedule and CLI extension can be released by our own pace(that's what I heard), the swagger for this change has not been merged, so that's another reason we want to use CLI extension for this time.
Let me know if you have any suggestion, thanks!

Because it's just a small change of the existing parameter logic, I personally suggest putting it in the normal CLI. Otherwise, we will create and maintain an new extension containing az vm create command, which is high maintenance cost


Update MAGIC-LST scripts to ctapipe v0.12.0

Here the combined analysis scripts are updated to be used in the ctapipe v0.12.0 environment.

Sorry for taking time but I found some mistakes in the scripts about the subarray descriptions, and so I modified them. I also updated the script for merging HDF files. I tested the script and confirmed that now it works fine.

@aleberti, if it is fine for you, could you merge this branch to update-ctapipe-v0.12, and merge update-ctapipe-v0.12 to master, please? And probably create a new tag (v0.1.0 ?) for the current version?

Sure, give me some time and I do it :)

Thanks a lot! I will delete my branch then…


Unable to read csv from google docs

After making a copy of the Google Sheet from the charted example and making it public, I've only been able to generate this wonky chart:

When accessing the Sheet's export link directly, I am able to download a CSV. However, when the request is routed through charted.co, it returns html.
Hopefully it's something I can fix on my end and add to the documentation! Any thoughts appreciated.

Hm, that's usually how the chart looks when a google doc is not public (it receives back data without returning an error, but the data looks wrong). Can you double check that the google doc is shareable to anyone with the link? (And if you can, include the link here) I'll also add an issue for better Google Docs verification—maybe we can detect whether or not it has the write setting and improve the messaging.

Oh, I see you already included the link. I suspect the issue is that this is a special "copy" format —when I visit the url without the CSV export part, it looks different than a normal google spreadsheet. It also has a slightly different url format ending with `/pub', which Charted doesn't support yet. If you create a new google doc from scratch, copy/paste the same data in, and make it pubic, it should work.

Thanks @mikesall. I created a fresh doc, pasted the data in, and made it public. Unfortunately the only url format that exports publicly as a csv is the .../pub version. The ../export version always requires a login.
I noticed that your example url uses the .../export so I can only guess it's a Google Doc versioning issue or something else?

FWIW, using /pub in my fork fixes my issue but breaks the official charted example.
Not sure if there is one url format that will work across all cases.
Side note, I spun up a heroku instance that works for my use case.

I'm running into this issue as wel, it seems like there are different URL format between sharing a doc and publish a doc.
When publishing a doc, the URL is in this format:
https://docs.google.com/spreadsheets/d/e/{someID}/pub?gid=0&single=true&output=csv
And the sharing URL is actually like this:
https://docs.google.com/spreadsheets/d/{someID}/edit?usp=sharing
I had to merge the 2 to make it work into this format:
https://docs.google.com/spreadsheets/d/{someid}/export?usp=sharing&gid=0&format=csv
I think google might have change the publishing doc URL from /export to /pub, and format param to output
@eeeschwartz maybe you can do a PR?


Feature/72 uri without cs

Coverage increased (+0.005%) to 99.732% when pulling dd37b2b4c1efcb7898ca2924f7935beed7d5d187 on feature/72_uri_without_cs into 56c74e9c0bdfbb80a16d0d2765ce49d5fc83e805 on develop.


Add Project Landing Page so USEP doesn't open to collections page

This is a multipart task - the only real develeper task is to make the new page.
we may also need a designer to help make it match the rest of the site. This could be related to the implementation of Zak's "new" interface.

@emylonas -- this is easy to do -- and I can use the same base-template as the rest of the site. The question, though -- what should the landing page have on it? If you get me a napkin sketch I can add the page with a url like /projects/usep/test_landing_page so you and others can see the development.

@emylonas -- this is easy to do -- and I can use the same base-template as the rest of the site. The question, though -- what should the landing page have on it? If you get me a napkin sketch I can add the page with a url like /projects/usep/test_landing_page so you and others can see the development.

This is marked "future" because there has been no discussion yet about what
would be on the landing page!
On Fri, Jan 29, 2021, 08:36 Birkin James Diana<EMAIL_ADDRESS>wrote:

@emylonas https://github.com/emylonas -- this is easy to do -- and I
can use the same base-template as the rest of the site. The question,
though -- what should the landing page have on it? If you get me a napkin
sketch I can add the page with a url like /projects/usep/test_landing_page
so you and others can see the development.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Brown-University-Library/usepweb_project/issues/66#issuecomment-769808743,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA7ZPO6CM2NF6PH53PZ7LS4K2UVANCNFSM4WX6BBEA
.

This is marked "future" because there has been no discussion yet about what
would be on the landing page!
On Fri, Jan 29, 2021, 08:36 Birkin James Diana<EMAIL_ADDRESS>wrote:

@emylonas https://github.com/emylonas -- this is easy to do -- and I
can use the same base-template as the rest of the site. The question,
though -- what should the landing page have on it? If you get me a napkin
sketch I can add the page with a url like /projects/usep/test_landing_page
so you and others can see the development.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Brown-University-Library/usepweb_project/issues/66#issuecomment-769808743,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOA7ZPO6CM2NF6PH53PZ7LS4K2UVANCNFSM4WX6BBEA
.


Update dependencies and use latest archives

Updates the dependencies of the latest versions, fixes some bzlmod warnings introduced by rules_apple 3 PR
WARNING: For repository 'build_bazel_apple_support', the root module requires module version<EMAIL_ADDRESS>but got<EMAIL_ADDRESS>in the resolved dependency graph.
WARNING: For repository 'build_bazel_rules_swift', the root module requires module version<EMAIL_ADDRESS>but got<EMAIL_ADDRESS>in the resolved dependency graph.

Additionally, moves the latest versions in repositories.bzl back to using the release archive instead of a git clone. Not sure why those were changed

A new rules_apple & rules_swift version will be tagged soon that include some stardoc fixes (which is why they're failing here) ill update this pr when theyre done.
We essentially need: https://github.com/bazelbuild/rules_apple/pull/2292

Ok thanks - I've filed an issue for the problems we ran into after the [stardoc update](https://github.com/bazel-ios/rules_ios/pull/776 here:
https://github.com/bazel-ios/rules_ios/issues/783

Updated the PR to include rules_apple 3.1.0 and rules_swift 1.13.0 which fixes the issues we were seeing with stardoc and bzlmod. CI is now back to using bzlmod for the stardoc tests

Updated again to rules_apple 3.1.1 which brings one final fix for non bzlmod users. This should be ready now, @jszumski @thiagohmcruz when ya'll have a minute


feature: prevent macOS Spotlight from scanning Asahi created partitions and volumes

feature: prevent macOS Spotlight from scanning Asahi created partitions and volumes
noted -- Spotlight scanned the ESP drive and created its own hidden folders.
The installer can drop .metadata_never_index in the root of each volume it creates to prevent Spotlight from scanning.
Likewise for Time Machine ... .com.apple.timemachine.donotbackup

PR forthcoming

This is the one issue you've opened that is actually useful. Please actually send a PR for this and stop spamming with everything else.


Chef 2549

Adding start handlers to Chef (for notifications at the start of a chef run), along with unit tests for report handlers and start handlers.

This was merged. In the future please add links to any pull requests in the associated tickets so they get closed when the branch is merged. Thanks!


Reflection Error on older versions of Android

Hello, I tried your plugin on the latests versions of Android and it works great, but I tried it on Genymotion with both 2.3.7 and 4.1.1 targets and got this reflection error on super.onCreate(savedInstanceState);:
https://ghostbin.com/paste/9w9he
I tried again with 4.2 and 4.4.2 and it worked as it should, even on an Android L Preview device.
I don't know if there are some limitations that I didn't read or if you were aware of this bug before.

Hello!
2 Years have passed and I get the exact same error when building for android:
warning: Ignoring InnerClasses attribute for an anonymous inner class
(groovyjarjarantlr.TokenStreamRewriteEngine$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(groovyjarjarantlr.build.ANTLR$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(groovyjarjarantlr.debug.misc.ASTFrame$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
Does anyone have a fix for this please?

groovyjarjarantlr.debug.misc.ASTFrame$1 is not a class produced by groovy. It comes from antlr and jarjar has been used to change the package for a bigjar version, which includes antlr already. There should be no reflective operations on that class. So this should be no problem normally. That´s why they are warnings, not errors. How does this prevent you from working with the plugin?


QA: Fix all the tests

VERY QUALITY
Core tests:

transactiontests, txvalidationcachetests and wallettests were spending dust

changed test amounts

dogecoin-tx tests were failing due to a difference in tx version with upstream caused by 140cc1d

made versions explicit

dogecoin-tx tests had some statements that were referring to the bitcoin-tx executable

changed to dogecoin-tx

QT tests:

rpcnestedtests was testing for a bitcoin block hash

changed to the dogecoin block hash

paymentservertests was testing to spend the maximum amount of bitcoin, which works differently on DOGE.

commented the test out

RPC test framework:

Core test framework was calling python3.6 hardcoded, which doesn't work on trusty (and thus our travis setup)

hardcoded to python3 like everything else

Pull tester dependencies were using wget, where everything else uses curl

changed to use curl

Auxpow framework libraries were using litecoin_scrypt but deps were installing ltc_scrypt

reverted libraries to use ltc_scrypt

Auxpow framework libraries were calling _target attribute which was supposed to be just target

changed to use target

Auxpow framework libraries were using python 3.5+ binary.hex() calls which don't work on trusty

changed to use binascii calls consistently for binary.hex() and binary.fromhex()

RPC tests

importprunedfunds, fundrawtransaction and listtransaction were spending dust

changed test amounts

importprunedfunds was re-spending target outputs used in later tests

changed tx creation order to ascending value

multi_rpc was writing credentials to bitcoin.conf

fixed that to write to dogecoin.conf

Travis:

remove sudo flag because its depreciated - removes warning
rename env/matrix to env/jobs - removes warning
RUN_TESTS directive requires python3-dev for compiling ltc_scrypt

Much appreciation. many commit. such pullrequest. wow. nice


⚠ Bofrost.at has degraded performance

In ef1ef7e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2136 ms

Resolved: Bofrost.at performance has improved in 65e20d6.


Can't use npm package ajv and perhaps many others

In an attempt to do input validation for our smart contract, as an experiment, I attempted to use the popular ajv package.
As a result of building with TSC with CLI arguments the tsconfig.json in a typical location adjacent to project.json is ignored. This is surprising behavior to many and still not well documented by microsoft but unfortunately its true.
Not having known this fact I added the allowSyntheticDefaultImports flag to my tsconfig.json but i didn't help! That is when I decided to look at how near-sdk-js actually works and discovered this quirk. I was able to reproduce the error in my console and using npm link ../near-sdk-js was able to patch it and move forward.
This lead me to another discovery. commonjs is commented out however I did need that to allow rollup to build my file.
One third thing that was required by ajv and rollup interacting was some rollup-json plugin.

This is all a very long winded way of perhaps pointing out a deeper issue. near-sdk-js is perhaps doing too much OR it may need more flags OR it may need to become smarter.
I think at minimum commonjs support should be added to rollup not sure why that got removed.
I think, probably, if there is a tsconfig.json file present tsc should run without arguments. OR there should be a flag to the CLI to avoid compiling typescript (type checking) with tsc entirely since rollup is doing the transpiling anyway. Those tsc checks can be done externally by someone that knows what they're doing.

Regarding input validation, since package import is not really working, I went ahead and rolled my own. I am actually very happy with how it came out, extremely lightweight and probably better suited to smart contract programming anyway. But most importantly it worked with the existing build system.
It is also worth mentioning that this was on 0.5.0-1 and I know there has been a release since then and that line i ponted out has been modified with some sort of "don't check libs" flag but I don't think that fixes the issue raised here.

now that the build process is broken up this is resolved


SSH from docker container to other VMs

Hello,
I have a airflow check that performs BashOperator with below command.
ssh root@xxxxx python2.7 xxx.py
Task failed so I went in to the worker container and checked that ssh is missing in container.
I can't find online how to install ssh on docker container. If there is anything you can help, very much appreciated.

Hi @sj860908 ,
i have tried to install openssh-client by doing this in the docker file && pip install openssh-client and the logs on the console showed that it has been installed successfully. But when i got into the Airflow worker cli with docker exec i didn't find it.
So as a workaround i did this:
sudo docker exec -u root -it container_num /bin/bash
apt-get update
apt-get install openssh-client

Hi,
You've to rebuild the docker image with openssh. You've to add remote host to known_hosts too (ie https://github.com/puckel/docker-airflow/issues/38#issuecomment-273355115)


chore: reset package version

@anbraten have you "dry-run" it? Will the first version be then 0.0.1? Is that okay since we already published 0.1.0?

@anbraten have you "dry-run" it? Will the first version be then 0.0.1? Is that okay since we already published 0.1.0?

@raphaelschwinger Just tested it. semantic-releases uses some different way of gathering the current version. It wont ever change the version inside the package.json in our repo anyways. It only sets the correct version before releasing to npm.

@anbraten Whats the version number in npm  then?

@anbraten Yes, but will this PR affect this ?

@raphaelschwinger It wont change anything. I just did it for documentation purpose as I saw other repositories setting the version to that. As this does not change the source-code it wont increase the version.


drivers: led: LP5562: Add DTS property for default LED current

The LP5562 driver did not have a way to specify the LED current. This adds a DTS property which will apply the specified current per channel when the driver initializes or the default value of 17.5mA if no property is provided.

Some early feedback. At this point my main ask would be that you keep the formatting changes (assuming that they are truly necessary) in a separate commit, as this makes it difficult to identify actual changes otherwise. Thanks!

Sorry about that. I ran clang-format to ensure my changes were formatted correctly, but didn't check to see if it had made changes to the original file contents.
Should try and revert the formatting changes and update this PR, or proceed with it as is and just make sure to be aware of this in the future?

Should try and revert the formatting changes and update this PR, or proceed with it as is and just make sure to be aware of this in the future?

Hi @Jamal-Ra-Davis. Thanks for this patch. And yes you need to fix it. Please limit the changes to the purpose described in the commit message. Don't mix it with formatting changes.

Updated to revert formatting changes

@Jamal-Ra-Davis ping

Apologies for the long delay. I've move the default value to the DT binding and updated the DT_INST_PROP calls accordingly.

Hi @Jamal-Ra-Davis,
Sorry for the delay too. I'll at it this week !

Hi @Jamal-Ra-Davis,
I forgot you and I apologize deeply.
Are you still active on this PR ? A new PR arrived to add the same feature (https://github.com/zephyrproject-rtos/zephyr/pull/70204). Please let me know if you want to continue or if you are OK for the other PR to take over.

Hi @Jamal-Ra-Davis,
I forgot you and I apologize deeply.
Are you still active on this PR ? A new PR arrived to add the same feature (#70204). Please let me know if you want to continue or if you are OK for the other PR to take over.

Hi @simonguinot, I'm still active on this, but I'm open to whichever is easier or more straightforward. If you have a preference for how to proceed, let me know.

Hi @Jamal-Ra-Davis,
I forgot you and I apologize deeply.
Are you still active on this PR ? A new PR arrived to add the same feature (#70204). Please let me know if you want to continue or if you are OK for the other PR to take over.

Hi @simonguinot, I'm still active on this, but I'm open to whichever is easier or more straightforward. If you have a preference for how to proceed, let me know.

Thanks @Jamal-Ra-Davis. Now the easier is to go with https://github.com/zephyrproject-rtos/zephyr/pull/70204. I thinks it is ready to be merged. Please can you review and test it ? Thanks in advance.

Hi @Jamal-Ra-Davis,
I forgot you and I apologize deeply.
Are you still active on this PR ? A new PR arrived to add the same feature (#70204). Please let me know if you want to continue or if you are OK for the other PR to take over.

Hi @simonguinot, I'm still active on this, but I'm open to whichever is easier or more straightforward. If you have a preference for how to proceed, let me know.

Thanks @Jamal-Ra-Davis. Now the easier is to go with #70204. I thinks it is ready to be merged. Please can you review and test it ? Thanks in advance.

Other PR looks good to me. I'll go ahead and close mine out.

@Jamal-Ra-Davis really sorry about the hiccups -- hopefully you'll find other opportunities to contribute in the future :)

@Jamal-Ra-Davis really sorry about the hiccups -- hopefully you'll find other opportunities to contribute in the future :)

No worries, it happens. Glad to see this feature making it in :)

@Jamal-Ra-Davis really sorry about the hiccups -- hopefully you'll find other opportunities to contribute in the future :)

No worries, it happens. Glad to see this feature making it in :)

Sorry again @Jamal-Ra-Davis. I'll be more careful next time.


pagination problem: url always is module's path for :index

Hi
Thank you for the great module.
I face a problem. The url of the pagination always return about the module's path.
Can it return the current url?
for example:
MyApp.Router.Helpers.url(conn) <> conn.request_path which would return a result like "http://localhost:4000/categories/4/products".
When I do category that will be very helpful. This url will get the products that belong to the category. The view shares with the product view. Thus, the template will render the products.
https://github.com/vinsol/nectarcommerce/blob/master/apps/nectar/web/templates/category/products.html.eex
I try to change the linker in paginate_view.ex as following.
   querystr= Plug.Conn.Query.encode(%{rummage: Map.put(rummage, "paginate", %{"per_page"=> per_page, "page"=> x})})
    raw_link(x, conn.request_path <> "?" <> querystr )

That's a great catch, @toreal! I think we can make the index_path default to struct_path, but also let people pass in a parameter to the pagination_link function.
Thanks for pointing this out!

@aditya7iyengar do you have an example somewhere on how to pass it as a param? I cannot figure it out :) it is still using the :index path.


fix(client): check for modifier in replace shortcut

Closes #3390

Thanks! Great we have this fixed.


Preview of Data Set tables can include HTML paragraph tags

Overview
Preview (and possibly DITA generation) of data set table headers will output raw HTML tags such as
 when it should not.
Steps to replicate

On the Test system, view in the Mauro the branch "Test branch" under "Data Dictionary > Active Branches > Angie"
View "Data Sets > Clinical Data Sets > National Eye Colour Data Set > REFERRALS"
Notice the description is standard HTML
Preview this data set in the Orchestrator
The output looks like this:

Expected behaviour
The table description should render HTML content correctly.
Related

NHSDigital/DataDictionaryPublication#505

The problem
Reviewing some of the behaviour I found the following:

The
 tags can be seen if the Markdown tab is selected
If the
 tags are removed and the text written as two lines with a blank line between them then the preview in the editor renders correctly but in the orchestrator the paragraphs are joined
When two lines are added in the HTML tab they are written to the backend as:
line1

line2

 which is a wrong interpretation and then that text is show literally in the orchestration UI so I suspect the orchestration UI element is treating all content as plain text with no rendering soe either it should be updated or it should strip all tags.
When re-editing the text and selecting Markdown the tags can be seen but I would expect the HTML tags to have been converted to markdown.
Removing the HTML tags in the Markdown view and selecting Preview shows the expected layout and when saved the lines are separated by newlines so there's an inconsistency between the Markdown and HTML editors.  In addition the description shown in the MDM UI after editing as Markdown no longer shows two lines explaining the problem seen in ii. above.
The link to the markdown guide in the editor navigates to the markdown guide for GitHub which is clearly not what is happening here
When switching between Markdown and HTML tabs the text gets further messed-up; if markdown is entered as:

    # Heading

    para1

    para2

Switching to HTML shows:
    # A heading para1 para2

Switching back to Markdown:

# Heading

     para1

     para2

Which is just a mess.
Clearly it works in some situations but not all.  I think the bottom line is that the editor is broken and the storage of the text needs some thinking about—it at least needs to be consistent—either markdown or html.

In the first instance, the markdown tab needs could be disabled to avoid mixing markdown & html an only allow the front-end to submit html for storage.  Then, any UI components which do not process the response as html, should use code that will extract plain text html before displaying it.


mouth movement unclear

First of all, Kudos to your amazing work.
For some of the anime character, there is hardly any lip movement when in webcam I am moving my lips. Specially if the character is male. I have generated some character myself. Attaching two examples of avatar image.I have maintained all the criteria you mentioned.  Any suggestions would be very helpful.

This version of the software cannot open closed mouth, so you will not be able to see any mouth movement from the first image.
To get some mouth movement from the second image, paint the mouth red or pink.


Handle (non-)nullability

At some point we'll need to support defining whether a field or argument is nullable or non-nullable. As for now, a decent starting point will just be forcing the nullability to match the CLR type's nullability. So nullable for classes, non-nullable for structs except Nullable<T>.
This isn't a long-term solution, since multiple ORMs support non-nullable relationships (e.g. Entity Framework with int SomethingId foreign keys). Also it would be nice to allow non-nullable arguments that map to a CLR class type.

Support for changing nullability of a field will depend on #17.

Per discussion with @rspeele:
Optionality of argument fields will be handled with an Optional<T> wrapper class (similar to Nullable<T> but allowing classes). This will indicate to the parser that a specified argument is not required. Arguments that are not wrapped with Optional are assumed to be required.
In the case of the initial query (see AddField in #17), if all required arguments are not supplied then validation fails. In the case of extra arguments (see WithArguments in #17), each successive filter will only be applied if all of the required arguments are present.


React 0.14.0 compat

Fixed #43

removed react/lib/emptyFunction dependency (seems to be deprecated in 0.14.0-beta3)
added react-dom for findDOMNode
bumped peer-dependency versions

:+1:

So we have been using our fork with the same changes as this PR, and are noticing that when typing in the middle of the textarea the cursor will suddenly jump to end of the textarea after the first key stroke. Needless to say its not a helpful behavior. Still trying to track down what the cause is, since it doesn't occur in react 0.13

Mm... also you may want to add "files": ["src/"] to package.json

@koistya why? src is explicitly in .npmignore and there's lib instead with compiled es5 code.

This way it could be possible to install this library from github (e.g. in case you need to fork it, make some changes and install from GitHub instead of NPM)

@koistya probably we should add some hooks for npm to compile dep after install.

Ref c72b0b77229aae775de11c91257ca8ffb3558aa5


Pixel art

Cleaned up a little bit of (individual) character page and added some simple images :)
I promise they look better when they are smaller!  Not that I'm an artist or anything.

I'll demo this sometime before merging it in :)


Upgrade nanopb to latest release.

Fixes security vulnerability reported in #37011
PiperOrigin-RevId: 297248686
Change-Id: Ib24b109c8a36b8673842b2f2ebb771406e5fa022

@mihaimaruseac -
grpc used in TF doesn't work with nanopb 0.4.1. I also tried updating grpc to 1.27.0 but it fails at bazel fetch step.
I'd tried updating nanopb to <IP_ADDRESS> tag which also has the security fix and also works with TF 2.1 and TF 1.15.2.

@npanpaliya is this for master, for 2.1 branch or in general?

Guess I'll have to actually build and test each of the versions. Do you have a test case?

No, I don't know any tests yet. I'm trying to find out.
BTW, if we update grpc in TF to 1.24 or above, we don't even need to update nanopb as nanopb has been removed from 1.24 version of grpc. https://github.com/grpc/grpc/commit/7ec6e8a4de6eba4eb3a8298ceb5aa82c0209b3a1.
If there is no specific reason for using grpc 1.19.x in TF and we can safely update that to higher version, the issue itself gets resolved.

@npanpaliya is this for master, for 2.1 branch or in general?

I checked 1.15.2 and 2.1. Both fails with nanopb 0.4.1.

Thank you for the updates. I'll hold off on merging these for now. Is master ok? I haven't seen an issue there (where nanopb update was merged)

TF's master branch is working fine because it has grpc updated too. grpc used in master branch is 1.27.0-pre1 which doesn't use nanopb at all.
In TF, is there any other external package other than grpc which uses nanopb? If not, then I think we can remove nanopb from workspace.bzl file. And that means the security issue reported originally gets invalidated.

Thanks. I'll take a look on nanopb usages and update accordingly.

@mihaimaruseac - Did you get a chance to look at this?

This is not on master and won't be merged except when we need to do a patch release for 2.1
As such, looking at thisis down-prioritized to up until we need to release the patch. We won't merge this until then

It fails to build, indeed. I will try removing it from master too.


Integrate Prettier and add a configuration file with instructions for safe usage.

Integrate Prettier and add a configuration file with instructions for safe usage. Anything else ;-)

Please use Markdown for guides : something like that :
PRETTIER GUIDE
Hi,
To use Prettier correctly (if you don't know what Prettier is, it's a module that formats your code correctly,
like this, so everyone has the same formatting style as you), you need to follow these steps:

Install the Prettier module (on VSCODE, you need to press "CTRL"/"CMD" + "SHIFT" + "X" and search for "Prettier - Code formatter")

Install the ESLint module (on VSCODE, you need to press "CTRL"/"CMD" + "SHIFT" + "X" and search for "ESLint")

Configure Prettier. To do this, press "CTRL"/"CMD" + "SHIFT" + "P" and type "Open User Settings JSON". Be careful, choose JSON!

After that, paste these commands into the JSON file:
{
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "prettier.requireConfig": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": "always",
        "source.organizeImports": "always"
    }
}

D'ailleurs, je pense que dans ton json tu devrais mettre :
    "prettier.requireConfig": True,

à la place de
    "prettier.requireConfig": true,

If you want 😁

Mais pourquoi une majuscule alors que le reste de la config (perso) est en minuscule ?

Good job! But indeed as @xav35000 said the guide should be revised

Mais pourquoi une majuscule alors que le reste de la config (perso) est en minuscule ?

Thats my bad i was confused with the json syntax for a bit. Sorry !

I will change the extension and after it's done 👍

Done !

Done !

Nice job! We will wait until the ongoing refactoring is complete to merge this PR and format all files, to avoid creating conflicts. Thanks


SSL Module Design Document outline draft

Signed-off-by: Himanshu Setia<EMAIL_ADDRESS>Description
This document talks about the SSL module to provide encryption support at REST and transport layers in OpenSearch ensuring all communication is encrypted.
PS: this document is still work in progress and does not represent the final design yet.
Issues Resolved
#1418
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@setiah What shall we do with this?

@setiah : Are you still working on this ?

Joining the folks poking @setiah :)   Poke Poke Poke!

Looks like this draft has stalled for about 4 months. @setiah are you still working on this or should we close this?


VS 2019 - "Connect" to project

When using the "Connect" feature for projects in VS 2019 (So that you can do Pull Requests, etc.) is it possible to have it use SSH by default? Or is there a way to change the Origin while still in Visual Studio to the SSH version?

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

ID: 64e85ff9-9add-d15c-e92f-02d7dd05e0f2
Version Independent ID: 0cbd7427-6acd-3cfc-1a3b-8bf5ca60f3bd
Content: Connect to your Git repos with SSH - Azure Repos
Content Source: docs/repos/git/use-ssh-keys-to-authenticate.md
Product: devops
Technology: devops-code-git
GitHub Login: @apawast
Microsoft Alias: sdanie

@colinbashbash -- Colin, thank you for your questions.  You may find answers here:

Azure DevOps Support Bot
Azure DevOps on Stack Overflow

@apawast -- Apeksha, please look into this issue.


Find way to make obvious what all extension methods exist in the docs

Right now you have to hunt through all of the traits and it makes it hard to see the big picture.

https://github.com/assert-rs/assert_cmd/issues/53 is a really good log of an experience in trying to adopt assert_cmd./

Normally our examples are very focused on a single feature.  We should provide examples that show all the features
We should have a section that highlights Command / Output and then highlight additional functionality with links to the relevant extension traits
We should identify the different errors and try to consolidate them.  I never noticed because they have only been in my test functions where I only unwrap them
Is there a way we can make the transition between different states clearer (command, stdin, assertion, etc)?  We ran into a similar problem with assert_cli, see https://github.com/assert-rs/assert_cli/issues/70.

@azriel91 any other thoughts or feedback on the above?

Yeap, it'll be useful to have bigger examples that cover all of the common cases  (for some definition of common)
If necessary, there could be one mega example at the end for a corner case.

Yeap, I think a comment annotated example will help, something like:
use std::path::MAIN_SEPARATOR;

#[test]
fn integration_test() {
    Command::main_binary()
        .unwrap()

        // --- environment, args, working dir --- //
        // See <https://doc.rust-lang.org/std/process/struct.Command.html>
        .env("APP_VAR", "value")
        .args(&["--timeout", "2000"])
        .current_dir(
            format!(
                "{base_dir}{sep}tests",
                base_dir = env!("CARGO_MANIFEST_DIR"),
                sep = MAIN_SEPARATOR
            )
        )

        // --- stdin --- //
        .with_stdin()     // Returns `StdinCommandBuilder`
        .buffer("exit\n") // Returns `StdinCommand`
                          // Note: `.path("..")` returns `io::Result<StdinCommand>`
        .output()         // Returns `io::Result<std::process::Output>`
        .unwrap()

        // --- assertion --- //
        .assert()                // Returns an `Assert`
        .code(predicate::eq(42)) // Assert a specific exit code
        .output(predicate::str::starts_with("Hello")); // These can be chained!
}

That StdinCommandBuilder -> StdinBuilder is a gotcha. Also, I guess the extension traits being the first method call is something we should explain up front.

This one might be a preference thing, so probably comes down to some communal survey. I like to avoid unwrap()s because it saves a little bit of noise when reading the test.

Perhaps the pre-knowledge of the assert_cli model was a handicap, but knowing the "sections" now helps my understanding of assert_cmd.
I know the StdinCommandBuilder -> StdinCommand confused me because normally Builders have a build method or similar, which makes it obvious when you switch to the built object, whereas both buffer and path are build methods for StdinCommandBuilder (and to add to the confusion they return different built objects), so it's a gotcha.
Perhaps taking the Assert part out of the chain in examples would make it clearer. That is, it's still chainable, but breaking the chain could make it explicit like so:
    let output = Command::main_binary()
        .unwrap()
        .with_stdin()     // Returns `StdinCommandBuilder`
        .buffer("exit\n") // Returns `StdinCommand`
                          // Note: `.path("..")` returns `io::Result<StdinCommand>`
        .output()         // Returns `io::Result<std::process::Output>`
        .unwrap();

    output.assert()              // Returns an `Assert`
        .code(predicate::eq(42)) // Assert a specific exit code
        .output(predicate::str::starts_with("Hello")); // These can be chained!

One other thing, the ability to do this felt weird:
let output = Command::main_binary()
    .unwrap() // `Command`
    .output() // `io::Result<std::process::Output>`
    .unwrap() // `Output`
    .ok();    // `OutputResult` aka `Result<Output, OutputError>`

That is, not sure if it's detectable that you could instead do this:
let output = Command::main_binary()
    .unwrap() // `Command`
    .ok();    // `OutputResult` aka `Result<Output, OutputError>`

woosh, that's an essay

Also from  https://github.com/assert-rs/assert_cmd/issues/32

find ways to make the role of predicates clearer
try to find some way to make relevant predicates more visible.

So I've made some documentation tweaks.  The linking could be improved; I was feeling lazy.
https://docs.rs/assert_cmd/0.10.1/assert_cmd/

btw I didn't merge the errors.

In some respects, this is like 3 crates in one
The different types of errors all serve very different roles.  At least for OutputError that has an intentional structure for people to access the data.

I like to avoid unwrap()s because it saves some noise when reading the test.

The one thing I realized about this approach is it loses call stack information unless the underlying errors capture a backtrace which nothing in assert_cmd does atm.

The one thing I realized about this approach is it loses call stack information unless the underlying errors capture a backtrace which nothing in assert_cmd does atm.

that's okay, I've been keeping an eye on failure's progress, and the std::error::Error trait is slowly moving (https://github.com/rust-lang/rust/issues/53487).
Progress 😄!

I feel like the new docs resolve this.


Add Docker environment & web demo

Hey @JingyunLiang ! 👋
Thank you for merging the PR from HCFlow yesterday! We found this model of yours very cool as well so we made a demo too.
This pull request makes it possible to run your model inside a Docker environment, which makes it easier for other people to run it.  We're using an open source tool called Cog to make this process easier.
This also means we can make a web page where other people can try out your model! View it here: https://replicate.ai/jingyunliang/swinir
Claim your page here so you can edit it, and we'll feature it on our website and tweet about it too. It would give you the ownership of the page and we recommend you doing so :)
In case you're wondering who I am, I'm from Replicate, where we're trying to make machine learning reproducible. We got frustrated that we couldn't run all the really interesting ML work being done. So, we're going round implementing models we like. 😊

@CJWBW I suggest that you can design something like   .  A distinguished icon is more eye-catching and gives people better impression.

@CJWBW I suggest that you can design something like   . A distinguished icon is more eye-catching and gives people better impression.

Thank you very much, that is a great suggestion! We are working on it :)

Wow this model is pretty impressive. Just like in the movies when they say "enhance!" but it actually works!
@JingyunLiang have you had a chance to check out the demo page @CJWBW created for you? You can claim your page here so you can edit it, and we'll feature it on our website and tweet about it too.


[release-1.21] autoregistration: fix xdsNode locality bug

This is an automated cherry-pick of #51816

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio_release-1.21
607ad09418b577a4d5b77c75a195675e707403b3
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

/retest


Fail if the target document will be changed

For the purpose of continuous integration (CI), I'd like a script that will fail (as in exit non-zero) when someone adds a new ADR record but forgets to update the table of contents.
It could look something like:
adr-log -d ./docs/adrs/ -i --disallow-changes

If that command would otherwise require updating / creating a file, it would fail. Such a failure probably indicates that the commit author forgot to re-generate the table of contents.
The current work around is something like this in a CI script:
adr-log -d ./docs/adrs/ -i
# Check to see if any files were modified and exit non-zero:
git status ...

The workaround is not too bad but it requires relying on something like git within CI and some bash magic.
As a point of reference prettier --check exists for a similar use case.

Pull request welcome! #hacktoberfest


[Benchmarking] [Java] new java.lang.OutOfMemoryError in Java benchmarks after local build cache change

Describe the bug, including details regarding any error messages, version, and platform.
As part of the Arrow benchmarking suite, we have been running the Java microbenchmarks with Archery on every Arrow commit. They are run on a bare-metal machine with the characteristics listed in the "hardware" section of this Conbench page.
Note that the benchmarks run this Arrow CI script to build Java Arrow, with the environment variables in this file used for building and running benchmarks.
Starting with this PR's commit:

https://github.com/apache/arrow/pull/39708

the Java benchmarks have started to time out after the default timeout of 6 hours. They used to take less than an hour. Before timing out, the following traceback is printed:
Exception in thread "CommonsExecStreamPumper-pool-9-thread-2" java.lang.OutOfMemoryError: Java heap space
	at java.lang.StringCoding.decode(StringCoding.java:215)
	at java.lang.String.<init>(String.java:463)
	at java.lang.String.<init>(String.java:515)
	at com.gradle.d.a.a.a(SourceFile:83)
	at com.gradle.d.a.a.flush(SourceFile:78)
	at com.gradle.d.a.a.write(SourceFile:72)
	at java.io.PrintStream.write(PrintStream.java:480)
	at com.gradle.d.a.b.write(SourceFile:203)
	at org.apache.commons.exec.StreamPumper.run(StreamPumper.java:112)
	at java.lang.Thread.run(Thread.java:750)

I assume that the Java memory configs need to be changed, but I don't have any experience with Java. This could be an easy fix by changing the environment variable file linked above, and using @ursabot please benchmark lang=Java to see if the change fixed anything.
Note that the microbenchmark results will not be tracked until this is fixed.
Component(s)
Benchmarking, Java

Note: I consider it a (different) bug that the bot posted this success message on the PR in question: https://github.com/apache/arrow/pull/39708#issuecomment-2015693416
Since no Java benchmark results were ever posted to Conbench, the bot saw that all posted results were successful, and did not comment on the lack of Java results.

I am hitting OOM running locally. 100s of GB of this message are being printed:
https://github.com/apache/arrow/blob/515c61dd617e65c01a6e40e570487ad4ae9f151c/java/vector/src/main/java/org/apache/arrow/vector/ipc/WriteChannel.java#L109

I think some of the performance benchmarks might be configured incorrectly. A few Java benchmarks use Level.Invocation when setting up and tearing down, including WriteChannelBenchmark:
https://github.com/apache/arrow/blob/2146ab10e653f927a6e92d29ee0910f30f4cb996/java/performance/src/test/java/org/apache/arrow/vector/ipc/WriteChannelBenchmark.java#L58-L69
According to the javadocs, Level.Invocation has dragons:
https://javadoc.io/static/org.openjdk.jmh/jmh-core/1.1.1/org/openjdk/jmh/annotations/Level.html#Invocation
Level.Invocation is only for benchmarks that take >=1ms. Our benchmark is zeroing out an unaligned 8 byte buffer.. Running the benchmark shows billions of these buffer alignment operations in the benchmark, which makes me think there is some race condition happening on setup/teardown causing a near infinite loop.

Nvm, I think this is okay. It's configured to run for 5 iterations 10 seconds each. We are just printing out billions of debug lines so just need to disable DEBUG logging.

Issue resolved by pull request 40786
https://github.com/apache/arrow/pull/40786