Implement version command

Hello!

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details
Currently, when running schema-tools version, the tool just outputs "TODO". It would be ideal if the tool could output its version at the time of invocation.
Affected area/feature

Hi @kpitzen , I am interested to work on this issue. Would you mind to assign this to me?
My proposed solution:

Update cmd to print the Version stored in version package (see version.go#L4).

// schema-tools/cmd/version.go

Run: func(command *cobra.Command, args []string) {
    fmt.Println(version.Version)
},

Update deployment related files to adjust the value of version.Version on build/deployment

Wdyt? Thanks.

@rafiramadhana Sure. That plan sounds good.

Update deployment related files to adjust the value of version.Version

We don't generally adjust the value in version.go. We override the version by passing a linker flag: -X github.com/pulumi/schema-tools/version.Version={{.Tag}}. That may have been what you meant, but I'm not sure.

@iwahbe Yes. That's what I meant.

Closed by https://github.com/pulumi/schema-tools/pull/37.


Define =~ method on Timezone identifier

It's useful to match agains a timezones identifier using regex.
e.g. this rails issue: https://github.com/rails/rails/issues/35973 this
commit overrides the =~ operator to the Timezone class so that clients
can match against its identifier.

🤔 I can't get a lot of insight out of the build failure, it seems like it's struggling to resolve the concurrent-ruby version, this seems pretty unrelated to the changes here.

Thank you for submitting this pull request. I've merged the change.
The build failure was unrelated. It was caused by an error verifying the rubygems.org TLS certificate. I've committed 719204b75e9d0a2c605ae099f737ef571c7458ec as a fix.


Fixed VERSION as 0.10

It seems missing changed.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4868

Relevant Lines:
5862

💛  - Coveralls

IMO, I recommend use https://getcomposer.org/doc/07-runtime.md#installed-versions or https://github.com/composer/package-versions-deprecated

Thanks!
And also thanks to the recommendation! I'll try it.


Install failed  while creating the image file

i tried mutiple time with axiom build after few installation gets failed to create image

@Jaikumar3
Seems like go is not being installed. Can you show me the provisioner you are using? I’m guessing it’s custom?

@0xtavian Hi i used default provisioner only and i try large size too like 50 gb and 70gb .. still getting same error

@Jaikumar3 looking at the screenshot above, it seems like its trying to also install aws cli which is not in any Provisioner.
try deleting ~/.axiom and starting over.

i used default provisioner..  try ~/.axiom folder too .. i tried more dan 10-times same error

@Jaikumar3
can you show me the rest of the axiom build terminal output? feel free to discuss in DM. join our discord https://discord.com/invite/c6BHVfn

@0xtavian i attach the file full installtion of ax
message.txt

@Jaikumar3 Thanks, i'm able to confirm there is some issue with Linode whne using the default provisioner. I believe Linode changed something recently.
However, even though I get the 002 context deadline exceeded error, the image still builds successfully.
A few minutes after you receive the error, can you run ax images ls to see if the image is in fact created?
You might need to select the image (ax images select axiom-default-$timestamp) since Packer reports the image creation failed, Ax wont automatically select it.
Thanks for reporting. Looking into it.


Fix the parent artifactId used in Swagger Code Customizations

Description
The wrong parent artifactId was being used for code customization POMs.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


F this error

g++ -LC:\Users\Kosmolet\vcpkg\installed\x64-windows-static\debug\lib -lsioclient -shared -o shared_lib.dll shared_lib.o -Wl,--out-implib,libshared_lib.a
shared_lib.o:shared_lib.cpp:(.text+0x31): undefined reference to sio::client::~client()' shared_lib.o:shared_lib.cpp:(.text+0x68): undefined reference to sio::client::client()'
collect2.exe: error: ld returned 1 exit status

Hi, it seems that the socket io shared DLL is not being found by the compiler

Have you tried following the instructions to compile without CMake?

Adding this to my CMakeLists.txt solved it for me;
find_library(SIOCLIENT_LIBRARY sioclient)
target_include_directories(foo PRIVATE ${sioclient})
target_link_libraries(foo PRIVATE ${SIOCLIENT_LIBRARY})
``` [(from here)](https://vcpkg.io/en/docs/examples/installing-and-using-packages.html#handling-libraries-without-native-cmake-support)


Retreive depth from depthframe

I'm using the following code to retrieve the depth point from the colour image pixel point (X,Y). I used this as a reference https://github.com/IntelRealSense/librealsense/issues/7754
public static Vector3 Map2DTo3D(this Intrinsics intrinsics, Vector2 pixel, float depth)
  {
     Vector3 point = new Vector3();
      float x = (pixel.x - intrinsics.ppx) / intrinsics.fx;
      float y = (pixel.y - intrinsics.ppy) / intrinsics.fy;
      if (intrinsics.model == Distortion.InverseBrownConrady)
      {
          float r2 = x * x + y * y;
          float f = 1 + intrinsics.coeffs[0] * r2 + intrinsics.coeffs[1] * r2 * r2 + intrinsics.coeffs[4] * r2 * r2 * r2;
          float ux = x * f + 2 * intrinsics.coeffs[2] * x * y + intrinsics.coeffs[3] * (r2 + 2 * x * x);
          float uy = y * f + 2 * intrinsics.coeffs[3] * x * y + intrinsics.coeffs[2] * (r2 + 2 * y * y);
          x = ux;
          y = uy;
      }
      point.x = depth * x;
      point.y = depth * y;
      point.z = depth;
      return point;
  }

I managed to retrieve the color intrinsic as follows,
      colorCamIntrinsic = ActiveProfile.GetStream(Stream.Color).As<VideoStreamProfile>().GetIntrinsics();
Now what should be the depth value that needs to be passed to Map2DTo3D

Hi @Zumbalamambo   In the issue that you linked to, one of the commenters at https://github.com/IntelRealSense/librealsense/issues/7754#issuecomment-1170684537 used the following definition for depth:
using (var depth = obj.Streams.FirstOrDefault(s => s.Stream == Stream.Depth && s.Format == Format.Z16).As<VideoStreamProfile>())

ResetMesh(depth.Width, depth.Height);

@MartyG-RealSense May I know what is obj.Streams?

@MartyG-RealSense i used the following code to retrieve the depth.
VideoStreamProfile depthVp = profile.Streams.FirstOrDefault(s => s.Stream == Stream.Depth && s.Format == Format.Z16) ``        ?.As<VideoStreamProfile>()
But it is a VideoStreamProfile and not a float point value (depth). It's something else.
How do I retrieve the depth?

It looks as though you are using a script from the Mapping 2D to 3D section of a C# / Unity guide at the link below.
https://lightbuzz.com/intel-realsense-coordinate-mapping/
In the paragraph of that guide just before the script, they state that "the depth of the desired point can be found by calling the GetDistance() method of the DepthFrame class".
float depth = depthFrame.GetDistance(x, y);

@MartyG-RealSense the retrieved XYZ data is totally wrong. Is there any example of click and know depth using Unity Realsense?

Also, how do I flip the frame horizontally or vertically?

Unity RealSense example scenes render depth visually but do not have accompanying numeric depth values as an overlay.  This is because the Unity wrapper converts the camera data into a Unity material so that it can be viewed on-screen as a graphical representation of the data.
Non-RealSense pointcloud generation tools in the Unity Asset Store are also typically visual-only with no display of the numeric values.  For example:
https://assetstore.unity.com/packages/tools/utilities/point-cloud-viewer-and-tools-16019
The link below is a project that gives greater control over generating a pointcloud with RealSense data by using a Unity Visual Effect Graph, but again it does not return real-time numeric depth values.
https://github.com/keijiro/Rsvfx

In regard to flipping the orientation of the Unity RealSense material, I am not aware of a way to do so unfortunately.  It is possible to perform a vertical flip of the orientation of the main camera image though by simply changing the Z rotation value of the main camera object from '0' to '180'.

Feature Request:
An example to select a point in the Image and get the XYZ position via Unity.

I have forwarded your Unity example feature request to my Intel RealSense colleagues to seek their feedback.  Thanks!

Hi @Zumbalamambo  After discussion with my RealSense colleagues, an official feature request has been created for a Unity example program that performs the function of providing a depth value when the image is clicked on.
This case should be kept open whilst the feature request is active, but you do not need to take any further action.  Thanks very much for the request!

The feature request for the creation of a Unity example has been closed because the RealSense team are no longer updating the RealSense Unity wrapper due to an increase in Unity licence fees.


jdk8 sanity.external s390x_linux_openliberty-mp-tck and x86-64_linux_tomee taking a considerable amout of time

Describe the bug
jdk8 sanity.external testsuites s390x_linux_openliberty-mp-tck and x86-64_linux_tomee are taking a considerable amount of time to run. This greatly impacts zLinux especially due to limited machine resource.
https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.external_s390x_linux_openliberty-mp-tck/
https://ci.adoptopenjdk.net/view/Test_external/job/Test_openjdk8_hs_sanity.external_x86-64_linux_tomee
s390x_linux_openliberty-mp-tck : avg = 5hrs
x86-64_linux_tomee : avg = 9hrs38mins (typically Aborts)

on xLinux:
16:32:12  Preparing all bnd projects in the workspace (this can take a while)
16:33:50  All bnd projects in the workspace have been prepared

on zLinux:
05:51:19  Preparing all bnd projects in the workspace (this can take a while)
06:23:00  All bnd projects in the workspace have been prepared

So on xLinux this step takes 1min38sec, on zLinux it takes 31min41sec, so roughly 20x slower, why?

OpenLiberty package build time:
zLinux 5+hours (gets aborted before completion)
xLinux 1.5 hours

Comparing jdk11 zLinux build time for a given openliberty module:
jdk11 : 2 mins
jdk8: nearly 2hours!

This is probably it! "Zero VM"
07:39:18  =JAVA VERSION OUTPUT BEGIN=
07:39:18  Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
07:39:18  openjdk version "1.8.0_272"
07:39:18  OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_272-202010051720-b09)
07:39:18  OpenJDK 64-Bit Zero VM (AdoptOpenJDK)(build 25.272-b09, interpreted mode)
07:39:18  =JAVA VERSION OUTPUT END=

https://github.com/AdoptOpenJDK/openjdk-build/issues/2038 might be related.

Updated issue to address just the zLinux problem.
Raised separate issue for tomee on xLinux problem: https://github.com/AdoptOpenJDK/openjdk-tests/issues/1997

Close in favour of epic #2057


[Implementation Guide] I'm looking for a freelancer to implement this for my company's chatbot

I am in way over my head with this project. I would love to hire someone, as a freelancer, to implement this solution for a chatbot that my company has deployed through Power Virtual Agent/Copilot Studio Chat (classic). The analytics that we get through PVA are not sufficient for our operations, so we would like to see the data through Power BI.

Hi @nicolelynn4182,
We can't recommend freelancers or partners on this GitHub repository. The feedback we gather here is more about the samples themselves or about the implementation guide content.
Have you considered posting on the https://aka.ms/CopilotStudioCommunity forum? There may be Copilot Studio subject matter experts and freelancers willing to help you.
Henry


[Bug] [Master] repeated submit task

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened

What you expected to happen
every task submit once.
How to reproduce

Anything else
No response
Version
dev
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

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

Hi, @caishunfeng , I read the code you modified, I think you solved the problem of concurrent execution of TaskEvent, but not solved the problem of repeated submit task, it will still repeat generate and submit, is my understanding correct?

I think the source of the problem is repeat generate task, What do you think?

I think the source of the problem is repeat generate task, What do you think?

It's seems that repeat generate task, but the main reason is that the upstream task event execute twice.

I think the source of the problem is repeat generate task, What do you think?

It's seems that repeat generate task, but the main reason is that the upstream task event execute twice.

Taking the figure as an example, do you mean that task_child_one and task_child_two are executed once each?

Taking the figure as an example, do you mean that task_child_one and task_child_two are executed once each?

Yes

Ok, @caishunfeng, thank you for your answer, Can two upstream task only generate one task instance of task_union. I think it is reasonable to generate once.^_^


Allow passing empty strings to short options + Check 'default' values

Tests are missing but I'm not sure which test file would be the best place to test each bug fix.
I would very much like some hints on that matter.

Thanks, could you give a description and example of what are the bugs you are fixing.
Looking at the changeset I have no idea what you are trying to do.
Each module has its respective unit-test module.


Form pjax does not work

Form Button Save does not work.
in bootcards-demo-app.js, line 128:
$(document)
.pjax('a[data-pjax]')
.on('submit', 'form[data-pjax]', function(event) {
//use pjax to submit forms
$.pjax.submit(event);
})
When click in Save button, he acts like Cancel button.
None submit event is fired to server, why?
Thanks.

See the README file. The save function isn't meant to be working. The demo app was created to show how to apply the classes for the UI components, not as a demo on how to write an application.

I've used the code described here https://github.com/defunkt/jquery-pjax but for some reason it doesn't work anymore. Had a look but couldn't figure out why.
BTW: if I would now have to write a similar app, I would use some JavaScript framework like Angular, Vue, or other. Makes it a lot easier and maintainable.


Conditional sources?

When developing a set of components, (e.g.. Vagabond --> MBrace.Core --> MBrace.Azure -> ...), each with their own package, it would be very convenient to be able refer to a "ephemeral" package feed such as an AppVeyor feed in order to access alpha versions of the packages without publishing them to nuget.org
Of course I can add
source https://ci.appveyor.com/nuget/vagabond-6odcsr0usg1g

but the problem is that I would only want this to be active on my own local machine, or on the appveyor build, but never when building "final" non-alpha versions of packages that get pushed to nuget.
Basically I'm wondering if it could be plausible to have a feature where source declarations are conditional in some way.  It's not entirely obvious to me whet they would be conditional on - perhaps in this case I would just want a "not golden" or "devmode" flag or something.  And it's no clear how it would be applied, since all the paket.lock etc. is dependenct on this feed, so you have to re-run paket.exe
This is really just thinking out loud but it seems a common situation, and I'm wondering if people have hit this before?  I really fear pushing broken sets of packages to nuget.org that accidentally depend on alpha versions of other packages that aren't available on nuget.org
thanks
don

Do you know about https://fsprojects.github.io/Paket/local-file.html ?
Am 08.06.2017 19:55 schrieb "Don Syme"<EMAIL_ADDRESS>
When developing a set of components, (e.g.. Vagabond --> MBrace.Core -->
MBrace.Azure -> ...), each with their own package, it would be very
convenient to be able refer to a "ephemeral" package feed such as an
AppVeyor feed in order to access alpha versions of the packages without
publishing them to nuget.org
Of course I can add
source https://ci.appveyor.com/nuget/vagabond-6odcsr0usg1g
but the problem is that I would only want this to be active on my own
local machine, or on the appveyor build, but never when building "final"
non-alpha versions of packages that get pushed to nuget.
Basically I'm wondering if it could be plausible to have a feature where
source declarations are conditional in some way. It's not entirely
obvious to me whet they would be conditional on - perhaps in this case I
would just want a "not golden" or "devmode" flag or something. And it's no
clear how it would be applied, since all the paket.lock etc. is dependenct
on this feed, so you have to re-run paket.exe
This is really just thinking out loud but it seems a common situation, and
I'm wondering if people have hit this before? I really fear pushing broken
sets of packages to nuget.org that accidentally depend on alpha versions
of other packages that aren't available on nuget.org
thanks
don
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/2401, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNNLZhgYFNgVRP_ecjejw7Mql5WeKks5sCDWcgaJpZM4N0alP
.

No I didn't that will do the trick well enough, thanks!

A couple of questions

Can you use a nuget feed in the paket.local ?
nuget Vagabond -> https://ci.appveyor.com/nuget/vagabond-6odcsr0usg1g

Can you have a paket.local up a few further directories, governing a collection of projects (e.g. in my c:\github\dsyme directory rather than one in each of c:\github\dsyme\Vagabond , c:\github\dsyme\MBrace.Core  etc)

Is the spec of the feed in the paket.local additive to other feeds for the package (selected based on version) or does it completely override them?

(reopen since there are active questions)

/cc @theimowski

Can you use a nuget feed in the paket.local ?

Haven't tested this scenario. If it doesn't work at the moment, should not be a big deal to add

Can you have a paket.local up a few further directories, governing a collection of projects (e.g. in my c:\github\dsyme directory rather than one in each of c:\github\dsyme\Vagabond , c:\github\dsyme\MBrace.Core etc)

Nope, that's not implemented, but should be fairly easy

Is the spec of the feed in the paket.local additive to other feeds for the package (selected based on version) or does it completely override them?

It completely overrides them - the should always be a warning issued when an override is detected.
Also, there can be just a single override for a given nuget

@theimowski What happens if the same repo and build command produces multiple NuGet packages? e.g. see below
nuget MBrace.Core -> git https://github.com/mbraceproject/MBrace.Core.git master build: "build.cmd NuGet", Packages: /bin/, OS: windows
nuget MBrace.Flow -> git https://github.com/mbraceproject/MBrace.Core.git master build: "build.cmd NuGet", Packages: /bin/, OS: windows

Hmmm struggling to get paket.local to work at all...    My paket is up-to-date (not pre-release)
C:\GitHub\dsyme\MBrace.StarterKit>.\.paket\paket.bootstrapper.exe
Checking Paket version (downloading latest stable)...
Paket.exe 4.8.7 is up to date.

I tried Paket 5.0.0-rc003/ too

@theimowski Any idea what I'm doing wrong? Thanks

@theimowski @forki Ah, I see, paket.local is used when you run paket restore but not paket update.  That's not what I had expected - I thought the package versions/resolutions would be influenced by the packages available from the local sources.

Nope, the override thing happens only when running paket restore - overrides do not mess with paket.lock.
After fixing formatting to following:
nuget Vagabond -> git file:///c:\github\dsyme\Vagabond master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Core -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Flow -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Thespian -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Runtime -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.CSharp -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Azure -> git file:///c:\github\dsyme\MBrace.Azure master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Azure.Management -> git file:///c:\github\dsyme\MBrace.Azure master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.AWS -> git file:///c:\github\dsyme\MBrace.AWS master build:"build.cmd NuGet", Packages: /bin/

And then running paket.exe restore, I get:
C:\github\dsyme\MBrace.StarterKit (master)
λ .paket\paket.exe restore
Paket version 4.8.7
paket.local override: nuget Vagabond group Main -> file:///c:\github\dsyme\Vagabond master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Core group Main -> file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Flow group Main -> file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Thespian group Main -> file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Runtime group Main -> file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.CSharp group Main -> file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Azure group Main -> file:///c:\github\dsyme\MBrace.Azure master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.Azure.Management group Main -> file:///c:\github\dsyme\MBrace.Azure master build:"build.cmd NuGet", Packages: /bin/
paket.local override: nuget MBrace.AWS group Main -> file:///c:\github\dsyme\MBrace.AWS master build:"build.cmd NuGet", Packages: /bin/
Cloning file:///c:\github\dsyme\MBrace.Core to C:\Users\BRE44821\.paket\git\db\MBrace.Core
Cloning file:///c:\github\dsyme\MBrace.Core to C:\Users\BRE44821\.paket\git\db\MBrace.Core
Cloning file:///c:\github\dsyme\MBrace.AWS to C:\Users\BRE44821\.paket\git\db\MBrace.AWS
Cloning file:///c:\github\dsyme\MBrace.Core to C:\Users\BRE44821\.paket\git\db\MBrace.Core
Cloning file:///c:\github\dsyme\MBrace.Core to C:\Users\BRE44821\.paket\git\db\MBrace.Core
Cloning file:///c:\github\dsyme\MBrace.Azure to C:\Users\BRE44821\.paket\git\db\MBrace.Azure
Cloning file:///c:\github\dsyme\MBrace.Core to C:\Users\BRE44821\.paket\git\db\MBrace.Core
Cloning file:///c:\github\dsyme\MBrace.Azure to C:\Users\BRE44821\.paket\git\db\MBrace.Azure
Cloning file:///c:\github\dsyme\Vagabond to C:\Users\BRE44821\.paket\git\db\Vagabond
Checking for uncommitted changes in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.AWS
Checking for commits made in detached HEAD state in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.AWS
Setting C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.AWS to c0ce3f70505810d7e96ccf245b9f03e550215d47
Checking for uncommitted changes in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Core
Checking for uncommitted changes in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Azure
Checking for commits made in detached HEAD state in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Core
Checking for commits made in detached HEAD state in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Azure
Setting C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Core to 581ea64e3b17276ad0f969430b618dc5f6fa56bf
Setting C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Azure to d0f2c0d264e9cc90925ab07c0bb913cb4e390f12
Checking for uncommitted changes in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\Vagabond
Checking for commits made in detached HEAD state in C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\Vagabond
Setting C:\github\dsyme\MBrace.StarterKit\paket-files\localfilesystem\Vagabond to 9b5fcfada60e6330123b37f2765ffc5f34a91ad3
Paket failed with:
        Fetching the git cache at C:\Users\BRE44821\.paket\git\db\MBrace.Core failed.
Message: Could not run "git clone --mirror "file:///c:\github\dsyme\MBrace.Core" "C:\Users\BRE44821\.paket\git\db\MBrace.Core"".
Error:
fatal: destination path 'C:\Users\BRE44821\.paket\git\db\MBrace.Core' already exists and is not an empty directory.

So it seems that currently there's a limitation in how paket.local works in that there can be a single git override from a given directory.
A workaround can be specifying the git override just once for a single path, and then using source override, like below:
nuget Vagabond -> git file:///c:\github\dsyme\Vagabond master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Core -> git file:///c:\github\dsyme\MBrace.Core master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Flow -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Thespian -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Runtime -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.CSharp -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Azure -> git file:///c:\github\dsyme\MBrace.Azure master build:"build.cmd NuGet", Packages: /bin/
nuget MBrace.Azure.Management -> source c:\github\dsyme\MBrace.Azure\bin
nuget MBrace.AWS -> git file:///c:\github\dsyme\MBrace.AWS master build:"build.cmd NuGet", Packages: /bin/

Please try this one and let me know if it works for you.

@theimowski @forki An alternative would be this in paket.dependencies:
git file:///c:\github\dsyme\Vagabond master build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.Core master build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.Azure master build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.AWS master build: "build.cmd NuGet", Packages: /bin/

However this does clones and does the build in paket-files\localfilesystem e.g.
Running "C:\GitHub\dsyme\MBrace.StarterKit\paket-files\localfilesystem\Vagabond\build.cmd NuGet"
Running "C:\GitHub\dsyme\MBrace.StarterKit\paket-files\localfilesystem\MBrace.Core\build.cmd NuGet"

This loses sharing between different projects in the DAG.  It feels like we want a git source option in paket.dependencies to build shared components (e.g. Vagabind and MBrace.Core in this example) in-place and to ensure commit-ID consistency for all instances of that component  (effectively the commit ID becomes the version ID for that component)

That's right - I forgot about the fact paket does clone the repo to paket-files, my example from previous comment will thus not work.
How about using the source override for all components, i.e.
nuget Vagabond -> source c:\github\dsyme\Vagabond\bin
nuget MBrace.Core -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Flow -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Thespian -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Runtime -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.CSharp -> source c:\github\dsyme\MBrace.Core\bin
nuget MBrace.Azure -> source c:\github\dsyme\MBrace.Azure\bin
nuget MBrace.Azure.Management -> source c:\github\dsyme\MBrace.Azure\bin
nuget MBrace.AWS -> source c:\github\dsyme\MBrace.AWS\bin

and before running paket restore in StarterKit, you'd have to build locally all the subcomponents?

and before running paket restore in StarterKit, you'd have to build locally all the subcomponents?

@theimowski I'll try that to see if it works.   It feels wrong though -  the "update" has been run with respect to very different packages and dependency chains. These new sources could have totally different dependencies.  Also testing a one line fix in Vagabond would take quite a lot of fiddling around with paket update, doing builds, check to see if the new packages have been picked up and are consistent etc.,
It feels like to achieve one good (reliable builds) we sacrifice another (rapid iterative development for a graph of components).

... paket does clone the repo to paket-files

@theimowski @forki was wondering if there is a  feature lurking where replacing the branch ID master with . indicates that the packages should be built in place
git file:///c:\github\dsyme\Vagabond . build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.Core . build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.Azure . build: "build.cmd NuGet", Packages: /bin/
git file:///c:\github\dsyme\MBrace.AWS . build: "build.cmd NuGet", Packages: /bin/

though it's quite hard to think through how this would actually work in practice

@dsyme paket.local was designed for local fast development when you know what you are doing. It shouldn't have an impact on paket update to not "accidentally" commit some intermediate dev packages which might not be available for others. Build Servers will than check if everything is still sane.
To be honest it's still unclear to me what you actually want.

but the problem is that I would only want this to be active on my own local machine, or on the appveyor build

local machine is definitely paket.local but appveyor is kind of more tricky I guess.

Basically I'm wondering if it could be plausible to have a feature where source declarations are conditional in some way.

There is a feature to make a complete paket group conditional, it's not that well documented though (and is not working jet for new SDK):
group g1
condition: COND1

group g2
condition: COND2

You can then use one set or the other depending on which msbuild variable you set to "true".

it's still unclear to me what you actually want.

The broad scenario is more or less clear to me, though the mechanisms to support it aren't.

Assume a component D made from 5 components in a DAG - call these A, B1, B2, C, D - with D --> C --> (B1,B2) --> A dependencies.  These come from separate github projects and each projet builds one or more packages

Assume we have a local clone of each these projects. If you like we can assume the clones of A, B1, B2 and C are in D/paket-files/github.com/A/... (like existing github sources).  However these clones should not be nested (no D/paket-files/github.com/C/paket-files/github.com/B1/paket-files/github.com/A/...) and there should only be one clone of each repo.  Each clone should be on a branch (not in detached-head state) to allow work on that.

I want to develop, build and update across this graph so that the freshly built packages and any extra implied dependencies are correctly built, picked up and consistent across the components.

When I do a "Update and Build" across the whole DAG I would expect

build A
paket update on B1
build B1
paket update on B2
build B2
paket update on C
build C
paket update on D
build D

When in development mode, each operation happens "in place" using the HEAD commit (or even better using uncommitted changes). Each paket update should use the previous build(s) as sources

Once the changes are confirmed, you commit, publish, tag and everything is re-checked on CI

This feels like some kind of fantasy, but the alternative is to collapse everything into one github repo and one solution - an Everything.sln in Visual Studio.  That's very appealing of course!

This kind of "cascade" behavior IMO would make things very complicated, and that's what we tried to avoid when introducing paket.local
I think there's one important detail that might not seem obvious at first:
Even if you have this kind of dependency chain, you can still test locally changes made in A component from D component without rebuilding components between.
In practice this means:

apply change in A
manually trigger the build of A
make sure there's an override for A in D
restore packages (with override) and build D
run D with the changes applied in A

And it seems this workflow could be easy enough given one is using floating version dependencies with default Paket resolution strategy, which is take the highest version matching.

I'll close this.  I think the problem is very real and fundamental in the long run - in the long run we have to have mechanisms/practices in place where we can push a change to a base package through a whole graph of other packages relatively easily, all on a local machine, with no expansion of the DAG and with full paket dependency management and consistency checking.
But I don't have any specific mechanism to propose just yet - I'll keep thinking it over.


🐛 [flutterfire configure] Missing xcodeproj dependency

Bug report
Describe the bug
When running flutterfire configure on a fresh installation, it terminates with the exception cannot load such file -- xcodeproj (LoadError). Since sudo gem install xcodeproj solved the issue for me, it looks like an unmet dependency, which is missing in your cli bundle.
Steps to reproduce
Steps to reproduce the behavior:

Install flutterfire CLI using dart pub global activate flutterfire_cli
(Add $PATH if prompted by previous command)
Run flutterfire configure in an existing Firebase+Flutter project (not yet using Flutterfire CLI)

Expected behavior
All dependencies to be bundled into the Flutterfire CLI.
Sample project
-- n/a --

Additional context
OS: macOS 13.1
Full Stacktrace
Unhandled exception:
Exception: /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- xcodeproj (LoadError)
        from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        from -e:1:in `<main>'

#0      ConfigCommand.run (package:flutterfire_cli/src/commands/config.dart:540:11)
<asynchronous suspension>
#1      CommandRunner.runCommand (package:args/command_runner.dart:209:13)
<asynchronous suspension>
#2      main (file:///Users/my-user/.pub-cache/hosted/pub.dartlang.org/flutterfire_cli-0.2.7/bin/flutterfire.dart:57:5)
<asynchronous suspension>

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
❯ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.3.10, on macOS 13.1 22C65 darwin-arm, locale en-DE)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] VS Code (version 1.74.2)
[✓] Connected device (4 available)
[✓] HTTP Host Availability

• No issues found!

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
-- Shouldn't be relevant --

@j-mastr
flutterfire configure related issues need to be filed in dedicated repo: https://github.com/invertase/flutterfire_cli/issues
Closing from here.


Update losses.py

Copy of issue #10
Hello,
in the tv_loss function, kornia.losses.total_variation(x) returns a tensor of shape [Batch x Channels] instead of [Batch]. I think this behaviour is in line with the documentation of kornia, but conflicts with the purpose and docstring of the tv_loss function.
This unexpected behaviour prevents benchmark training for batch sizes > 1.
Taking a mean over the channels of each image should be an appropriate fix, right?

Thanks a lot @simon-donike .
@ivanorsolic Give a shout if you see any worries there :)


Add CLI for Microsoft 365 to Get SharePoint Site Recycle Bin Items And Export It To CSV

🎯 PR aim
Add CLI for Microsoft 365 equivalent 👨💻 -
https://pnp.github.io/script-samples/spo-recyclebin-items-to-csv/README.html?tabs=pnpps
✔ What was done

[X] updated readme with script
[X] updated sample.json

🔗 Related
#119
📸 Result
result of the script

one thing that's worth mentioning is that the m365 spo site recyclebinitem list command which is used in the CLI version of this script is in the latest CLI for Microsoft 365 release which is still considered as beta

Hey @Adam-it , nice sample and cli enhancement too, thank you 👏 for your contribution - it is highly appreciated. This should be live shortly 😊


Dummy non-master branch PR for testing new semver release command

Test promote command [semver:minor]


Add ControlCard

Related issues
This PR closes https://github.com/mapbox/mr-ui/issues/51 as it adds ControlCard.
Description of changes
👋 Open to discussion/feedback!
ControlCard

New component, examples, and tests that uses Heading and Icon. Allows opinionated variation in the following:

buttonType ('close', 'collapse')
onButtonClick
title
titleSize ('primary', 'secondary', 'tertiary', 'minor')

Traditionally, this kind of card has only been used in the Account Dashboard and Atlas's Account Dashboard.
Testing

Created/updated documentation examples for each component. See the documentation Batfish site with npm run start-docs.
Created/updated Jest test cases and snapshots for each component. See npm test and the test cases app with npm start.

@kepta assigning this one to you for review.


Feature/natural headers

Added Natural headers to test resources. Changed some tests to take headers into account.

still a few tests (6, I think) are not succeeding. I need you to look into these, please. They all seems related.

The log here is a compile error.
I think this test slipped in from the other branch?


APR missing unicode functions

Is there a reason why the header "apr_arch_utf8.h" is not copied into the installed folder? It resides in VCPGK\buildtrees\apr\src\apr-1.6.3\misc\win32

When I copy the header manually, it gives me access to "apr_conv_utf8_to_ucs2(...)" and "apr_conv_ucs2_to_utf8(...)". That means that "apr-1.6.3\misc\win32\utf8.c" is compiled.

Hi @chhenning , thanks for reporting this issue!
This issue has been fixed. Plz update vcpkg and rebuild apr.
Thanks.


Combine name with id if both present

Issue: https://github.com/styled-components/babel-plugin-styled-components/issues/44
This will allow users to use the babel plugin with ssr (which sets the componentId at compile time) and displayName by combining them at runtime if both are present.

I'll see later what these kinds of ids look like :)

Awesome, thanks @griffinmichl, this is a lot better 👌


[typescript-resolvers] Extract union types to ResolversUnionTypes

Description
As discussed in a proof of concept, we thought that by creating a ResolversUnionTypes type and use reference unions in ResolversTypes and ResolversParentTypes give us a bit more control in the future.
As the result, the union types are no longer inlined in ResolversTypes and ResolversParentTypes
Example use case (future)
In the future, we could make union members' __typename non-nullable whilst leaving the counterparts in ResolversTypes and ResolversParentTypes as optional:
// typescript plugin types
export type BookResult = {
  __typename?: "BookResult";
  result?: Maybe<Book>;
};

export type StandardError = {
  __typename?: "StandardError";
  error: string;
};

// typescript-resolvers types
export type ResolversUnionTypes = {
  BookPayload: (BookResult & { __typename: "BookResult" }) | (StandardError & { __typename: "StandardError" }); // Non-nullable typename are not implemented. This is here as proof of concept
};

export type ResolversTypes = {
  // ...
  BookPayload: ResolverTypeWrapper<ResolversUnionTypes["BookPayload"]>; // This forces `BookPayload` require __typename from its union members `BookResult` and `StandardError`
  BookResult: ResolverTypeWrapper<BookResult>; // __typename of BookResult is still optional
  StandardError: ResolverTypeWrapper<StandardError>;
  // ...
};

export type ResolversParentTypes = {
  // ...
  BookPayload: ResolversUnionTypes["BookPayload"]; // This means BookPayload.__resolveType has access to non-nullable __typename from its union members.
  BookResult: BookResult;
  StandardError: StandardError;
  // ...
};

Type of change
Please delete options that are not relevant.

[x] Refactor: change how union types are referenced

How Has This Been Tested?

[x] Unit tests

Test Environment:

OS: MacOS
@graphql-codegen/typescript-resolvers:
NodeJS: 16.15.0

Checklist:

[x] I have followed the CONTRIBUTING doc and the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

This caused an issue in my project due to the fact that now the first argument for __resolveType resolver function definition is wrapped in ResolverTypeWrapper where before it wasn't, which makes it possibly a promise.

type ResolverTypeWithoutPromise = Exclude<ResolverTypeWrapper, Promise<unknown>> should do what you want.

you can also extract all the sub-types as well.
import type { ResolversTypes } from "./path/to/generated/graphql"

type ShallowTypes = {
  [Key in keyof ResolversTypes]: Exclude<ResolversTypes[Key], Promise<unknown>>
}

@ryanrhee thanks for your answer. The issue is with the parent argument (first argument) of the resolver for __resolveType field.
export type ResolversParentTypes = ResolversObject<{
  ...
  MyType: ResolversUnionTypes['MyType'];
  AnotherType: ResolverTypeWrapper<Mapper>
  ...
}>;

export type ResolversUnionTypes = ResolversObject<{
  MyType: { contract: ResolversTypes['AnotherType'] }; // This now uses ResolversTypes which uses ResolverTypeWrapper
}>;

I guess the only way to fix it is to add this type to the mappers as well?

You could add it to the mappers as well.
Does __resolveType() allow async functions? If so, you could check if the first argument is a promise and then resolve it so that you are always operating on the underlying type.
{
  __resolveType: async (objOrPromise, ...) => {
    // obj is `Promise<T> | T`
    const obj = Promise.resolve(objOrPromise)
    // your code here; obj is now of type `T`
  }
}

Thanks @ryanrhee. I needed to add await, but it worked:
{
  __resolveType: async (objOrPromise, ...) => {
    // objOrPromise is `Promise<T> | T`
    const obj = await Promise.resolve(objOrPromise)
    // your code here; obj is now of type `T`
  }
}

However, it is a bit concerning that this happened in a patch update from @graphql-codegen/typescript-resolvers 3.1.0 to 3.1.1.

Hi @hector-del-rio ,
Do you mind creating a small repo or sandbox with a small schema and minimal codegen config? This will help me understand the problem better 🙂
For context, this went in as a patch because we only move type references around. Maybe I missed a use case. Sorry!

Hi @hector-del-rio,
This should be fixed in https://github.com/dotansimha/graphql-code-generator/pull/9206 🙂
It'll go out in the next version. Thanks for reporting the issue 🙌

Thank you @eddeee888 🙏


Better Junimos/Forrestry not working

As the title suggests, Better Junimos doesn't work. Error log says there are files in the mod folder, but no .json. . .
What can I do?
thanks you lovely Farmers

As the title suggests, Better Junimos doesn't work. Error log says there are files in the mod folder, but no .json. . . What can I do?
thanks you lovely Farmers

This is not the place to get mod support
You didn't even read the instructions before asking for support.


Windows: add SwiftSyntaxCDataTypes.h to the toolchain

This repairs the toolchain manifest after apple/swift#39441 which split
the header into two files.  This ensures that both halves are packaged.

CC: @ahoppen

Sounds reasonable to me.


:diamond_shape_with_a_dot_inside:

Adds support for multiple aliases.
Fixes #34.

👍 I wish I could do this with my kids, so they would respond to any of their names or pet names.


LinearViewer Improvements

This issue will track the improvements that need to be made to the LinearViewer component.

Mismatches
the way mismatches are rendered.

{mismatches.map((base) => {
        const xPerc = (base.index / maxEnd) * 100;
        const width = Math.max((1 / sequence.length) * 100, 0.25);

        return (
          <g
            className={classNames(mismatchClassName?.(base) || "bg-red-400")}
            key={`sequence-${sequenceIdx}-mismatch-${base.index}`}
          >
            <line
              x1={`${xPerc - width / 2}%`}
              y1={`${sequenceIdx * 10 + 10}`}
              x2={`${xPerc + width / 2}%`}
              y2={`${sequenceIdx * 10 + 10}`}
              strokeWidth={5}
            />
          </g>
        );
      })}

Right now we render an element for every mismatch between the first sequence, and all other sequences. This is predictably inefficient and slow on any sequences of non trivial length.
We should first have a prop hideMismatches?: boolean that opts out of rendering mismatches.
Secondly, we should render mismatches more efficiently. Some ideas I've had, but open to others:

collapse adjacent mismatches into a mismatch range, and render that instead
Use an element with a linear gradient based on where mismatches are

[ ] The first thing we should do to tackle this is create a storybook story that repros this performance issue.

Deliverable: story per perf fix

Annotation layout bug
Annotations are currently slotted into different "tracks" by the type field. We should instead lay them out in an efficient way that avoids overlaps.

Consider ranaming sequence to "baseSequence" and otherSequences to "alignedSequences"


[SPARK-42373][SQL] Remove unused blank line removal from CSVExprUtils

What changes were proposed in this pull request?

Remove blank line removal from CSVExprUtils. This is currently unused as the parser used to generate inputs for this code-path removes blank and whitespace lines.
Why are the changes needed?

Closes SPARK-42373. The current state is misleading, indicating that the function is responsible for functionality that it is not. The multiline codepath does not contain any methods claiming to remove blank lines, leading to a confusing disparity between the two. If in the future blank lines need to be removed from an Iterator[String], this behavior should be added back explicitly.
Does this PR introduce any user-facing change?

No
How was this patch tested?

See CSVSuite tests that read "cars..." files which contain blank lines on the multiline and non-multiline code-path.

Doesn't look the refactoring makes it particularly easier to read to me.

Doesn't look the refactoring makes it particularly easier to read to me.

@HyukjinKwon I was doing some work towards another issue here that I think demonstrates the problem. The code reads:
val skippedLines = iter.drop(options.skipLines)
filterCommentAndEmpty(skippedLines, options)

It looks like:

options.skipLines lines are dropped
comments and blanks are removed

What actually happens:

blank lines are removed
options.skipLines lines are dropped
comments and blanks are removed

This refactoring would make it clearer and consistent with the multiline case. It would then look like:
val skippedLines = iter.drop(options.skipLines)
filterComment(skippedLines, options)

and behave as expected when reading the code.
Additionally, this refactoring removes the function introduced in SPARK-18362 that is supposed to be removed as per the doc:
// Note that this was separately made by SPARK-18362. Logically, this should be the same
// with the one below, `filterCommentAndEmpty` but execution path is different. One of them
// might have to be removed in the near future if possible.

For the main use-case for this, https://github.com/apache/spark/pull/39907, I have settled to define an ordering that doesn't become unclear with these method names.


[BottleneckSuggestionProvider] Add target for action, if available.

When using the flag --experimental_profile_include_target_label when a Bazel profile is generated, action processing events include which target the action is being processed for.
If present, add this information to the "Break down bottlenecks" suggestions. If not present, add a caveat that highlights the flag could be set to improve the bottleneck suggestions.
Fixes #92.

New formatting of suggestions (with target)

Caveat, if no targets are included


Increment version for eventgrid releases

Increment package version after release of Azure.Messaging.EventGrid

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Messaging.EventGrid


Which range is used for media bypass in a call through a PSTN gateway?

Hello,
Which range is used for media bypass in a call through a PSTN gateway? Thanks in advance.

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

ID: c5164207-7822-cf54-717e-6216e0627ebd
Version Independent ID: 786f5413-3660-06eb-484f-8d5758d3ec59
Content: Port and protocol requirements for servers
Content Source: Skype/SfbServer/plan-your-deployment/network-requirements/ports-and-protocols.md
Service: unspecified
Product: skype-for-business-itpro
GitHub Login: @jambirk
Microsoft Alias: jambirk

Media range for Gateway depends on the gateway and needs to be configured on the gateway.


Add 'kpod images' and 'kpod rmi' commands

'kpod images' lists all images on a system.  'kpod rmi' removes one or more images from a system.  The images will not be removed if they are associated with a running container, unless the -f option is used

Need some tests to prove that these work and make sure nothing breaks them.

@nalind PTAL

:+1:

@mrunalp @runcom PTAL.  Would like to get this in, so that atomic can start to use them.

Should merging this PR wait until I can add the fix for projectatomic/buildah#133?  It's almost finished

Is this ready now?

LGTM, I think this is ready to merge.

retest

@mrunalp is that a command for a bot or is there something I'm supposed to do?

retest

@nalind @mrunalp @runcom If there are no other issues, can this be merged or are you waiting until the rh-atomic-bot tests are working again?

Needs rebase.

@14rcole Need to rebase this pull request.

@mrunalp I think this is ready to merge as soon as tests pass.

retest

Needs rebase as I merged another PR.

@mrunalp done

retest

LGTM


[Feature] Text chat

I don't want to reveal my voice but want to communicate with players

duplicate, already suggested, #18


Always suffix bash function with executable name to avoid clashes

Resolves #310
Generates:
# register-python-argcomplete pipx

# Run something, muting output or redirecting it to the debug stream
# depending on the value of _ARC_DEBUG.
# If ARGCOMPLETE_USE_TEMPFILES is set, use tempfiles for IPC.
__python_argcomplete_run() {
    if [[ -z "${ARGCOMPLETE_USE_TEMPFILES-}" ]]; then
        __python_argcomplete_run_inner "$@"
        return
    fi
    local tmpfile="$(mktemp)"
    _ARGCOMPLETE_STDOUT_FILENAME="$tmpfile" __python_argcomplete_run_inner "$@"
    local code=$?
    cat "$tmpfile"
    rm "$tmpfile"
    return $code
}

__python_argcomplete_run_inner() {
    if [[ -z "${_ARC_DEBUG-}" ]]; then
        "$@" 8>&1 9>&2 1>/dev/null 2>&1
    else
        "$@" 8>&1 9>&2 1>&9 2>&1
    fi
}

_python_argcomplete_pipx() {
    local IFS=$'\013'
    local SUPPRESS_SPACE=0
    if compopt +o nospace 2> /dev/null; then
        SUPPRESS_SPACE=1
    fi
    COMPREPLY=( $(IFS="$IFS" \
                  COMP_LINE="$COMP_LINE" \
                  COMP_POINT="$COMP_POINT" \
                  COMP_TYPE="$COMP_TYPE" \
                  _ARGCOMPLETE_COMP_WORDBREAKS="$COMP_WORDBREAKS" \
                  _ARGCOMPLETE=1 \
                  _ARGCOMPLETE_SUPPRESS_SPACE=$SUPPRESS_SPACE \
                  __python_argcomplete_run "$1") )
    if [[ $? != 0 ]]; then
        unset COMPREPLY
    elif [[ $SUPPRESS_SPACE == 1 ]] && [[ "${COMPREPLY-}" =~ [=/:]$ ]]; then
        compopt -o nospace
    fi
}
complete -o nospace -o default -o bashdefault -F _python_argcomplete_pipx pipx

Broken Travis CI build seems unrelated:
==> Summary
🍺  /usr/local/Cellar/git/2.28.0: 1,482 files, 48.8MB
Removing: /usr/local/Cellar/git/2.24.1... (1,558 files, 45.5MB)
==> Checking for dependents of upgraded formulae...
Error: No such file or directory - /usr/local/Cellar/git/2.24.1
The command "if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then brew install fish; fi" failed and exited with 1 during .
Your build has been stopped.

Please see https://github.com/kislyuk/argcomplete/issues/310#issuecomment-699585170


docs: Expand Docker Config Secrets and private registry

Description

Expand Docker Config Secrets and private registry.

Test

Additional Information
Tradeoff

Potential improvement

Thanks @viccuad for your reactivity. You rock


Proposal on LISA improvements (was The Future of Lisa)

This is derived from a document I wrote, but since that wasn't accessible to all who may find it useful, I figured putting it here made more sense where it can be tracked and actioned.
TL;DR
Due to low code quality, failure to adhere to standards, and architectural issues, LISA requires a great deal of work to reach a minimum level of maintainability. Without this effort, LISA is prone to bugs, regressions, and escalating maintenance costs. Some effort had begun to improve the current version, but getting these changes integrated has been slow due to inadequate test coverage and fear of introducing change to a fragile codebase. At this point those efforts are largely stalled.
While stabilization improvements may be achievable with the current code base, it will be faster to start fresh, incorporating lessons learned from the previous iterations. It is also possible to significantly reduce the amount of code Microsoft maintains by leveraging other Open Source projects, such as Ansible. It is recommended to create a requirements document for LISA and evaluate Open Source options against these requirements before proceeding with a replacement.
Background
This document came about as a result of the author attempting to ramp up to and contribute to the LISA project. Finding limited documentation and low code quality, the author initially thought the issues could be resolved with minimal to medium effort by applying standard linting, code cleanup, best practices and improving documentation. However, early in this effort, it was clear this would be a much larger task due to a lack of test coverage, undocumented code, and design issues. Continuing down this path would take years due to the extremely high level of technical debt taken on by the project.
Business case for this document
A naive observer may look at the LISA project and assume because it is being used it is both functional and adequate. However, IT organizations are concerned about much more than if software is functional at a specific point in time. Two primary concerns for IT organizations are efficiency and responsiveness.
Efficiency not only accounts for the amount of compute resources needed to run software, but also includes the cost of developing the software, the cost of maintaining the software, the cost of learning to use the software, and the human cost of using the software. While the cost of learning to use and actually using LISA are much higher than necessary, we’re primarily focused on the cost of developing and maintaining the software, or CoC (Cost of Change).
Responsiveness is not only the responsiveness of the running software, but the responsiveness of the organization to change. Change may be required due to other technical changes or customer need. Poor design and high technical debt increase the CoC (Cost of Change). This, in turn, leads to diminishing responsiveness. This is illustrated in the sample chart below.

The graph shows CoC (Cost of Change) in a hockey stick pattern. This is because the accumulation of technical debt accelerates as maintenance becomes more expensive and gets deferred.  Extrapolating this you get to a state where code is not maintained at all for fear of introducing unexpected changes. This is sometimes referred to as a death spiral.
The LISA project may have already entered a death spiral. This is clear from the long lead time for basic maintenance and aging dependencies. There are a few examples later in this document such as Support for Python 3.11 which, despite requiring simple changes, took 9 months to implement and was exacerbated by multiple layers of technical debt. It’s also evident in this PR for updating a year-old CI dependency where, after being stalled for 3 months waiting for review, the primary maintainer of LISA stated “we don't have bandwidth to test regressions” and suggested adding additional technical debt rather addressing the issues.
Essentially, we have reached a point where the current iteration of LISA is not getting basic maintenance and requires a significant increase in resources or risks atrophying to a point where we will no longer be able to address customer needs.
The current state of LISA
An initial review of LISA found a number of issues which led to higher numbers of bugs, security vulnerabilities, reduced performance, a steeper learning curve, increased maintenance costs, and increased development costs.
These issues are outlined in the following sections:

Non-standard and incomplete packaging
Limited test coverage
Code quality
Limiting design
Open Source
User experience
Maintainability

Non-standard and incomplete packaging
Python packages are self-contained archives with metadata describing the software and dependencies. Lisa is partially packaged, but due to an atypical layout, two directories, examples” and “microsoft”, fall outside of a packageable area. The “microsoft” directory, in particular, contains runbooks and code critical for LISA’s operation. To work around this, LISA must run out of a cloned git repo. This requires additional steps of maintaining a git submodule, cloning the repo, checking out the desired branch, installing as an editable package, and using flags to enable deprecated install behavior to ensure the LISA source files are found in the Python path.
In order to resolve the layout issues, code needs to moved out of these extra directories and the runbook path behavior needs to be modified so the runbook files included in the extra directories can be accessible from standard install locations.
Once these change are made, LISA, can be published to PyPI and installation will be as simple as pip install lisa. This also unblocks proper packaging of the internal repo, which can be published to an internal ADO Python package index, reducing installation to adding the index URL and running  pip install .... Not only will this simplify the user experience, it will speed up installation, and prevent failures once the deprecated behavior being leveraged is removed from pip.
There were additional issues with packaging which have been largely addressed by lisa #2353 and a corresponding internal change. These included:

Removing non-standard metadata
Separating dependencies into optional dependency groups
Removing non-standard helper-scripts
Separating CI activities into discrete operations
Eliminating duplication of dependencies between the internal and public repositories

Limited test coverage
LISA has limited unit test coverage (26.64%) and fragile code. This requires changes to be manually tested for each PR. Manual testing is error prone, limited in scope, and slow. This not only increases costs, but also the time required to make changes and the likelihood of regressions. The current state reduces confidence in pushing changes, resulting in delays accepting changes. This further increases time and costs because code must be rebased multiple times.
Increasing test coverage is mainly a matter of putting resources to writing tests, but, since LISA was not written with testing in mind, testing some parts of the code may be more challenging than necessary. Writing code with testing in mind involves keeping components independent with well-defined interfaces and reasonable defaults to readily be able to use them with stubs. This is generally good software design independent of testing.
All these issues compound when implementing changes that touch multiple parts of the code. For example, a PR to resolve a security vulnerability has been sitting unmerged for a month for fear it will unexpectedly break something. With adequate test coverage, this would not be an issue.
Code quality
Standard linting was only added to LISA in November 2022 and the majority of the checks needed to be disabled because they were failing. While, in some languages, linting is purely stylistic, since Python is an interpreted language, linting is equivalent to compile-time checks for compiled languages. It is used to find bugs, security vulnerabilities, and programmatic errors. Many of the issues listed below were identified thought standard linting. Others were found through reviewing the code and documentation.
Minor to Medium effort to resolve
The items listed in this section can be resolved without invasive changes to the code.
Some issues listed have been resolved or have an open pull request. These came about as part of the review for this document and have been submitted by the author. They are included here for completeness. For these cases, the pull request is noted.
Use of deprecated modules (Fixed in 2538)
Some logic was imported from a standard library module slated for removal.
Redefinition of build-in objects (Fixed in 2507)
Built-in class and function names were used for generic variables. This can cause unexpected behavior when one attempts to use the built-in after it has been overwritten.
Use of an undefined or conditionally defined variable (Fixed in 2498)
There are cases where a variable is used before it is assigned or may not be assigned in all cases.
Security Vulnerability: Use of eval (Fixed in 2514, submitted Jan 9, merged Feb 28)
The eval() function in Python is used to interpret a string object containing Python code at runtime. Seven cases were identified where eval() was used on unsanitized user input. This allows a user to execute arbitrary Python code from within LISA, with access to any resources available to LISA.
Modification of a list while iterating over it (To be fixed in 2561, submitted Jan 10)
If a list is modified while it is being directly iterated over, unexpected values can be returned from the list
No timeout specified for HTTP requests (To be fixed in 2539, submitted Jan 19, merged Fed 22)
Without a timeout specified, unresponsive HTTP requests can hang until the process is killed externally
No support for Python 3.11 and higher (To be fixed in 2557, submitted Jan 25, merged Apr 4)
Python 3.11 went GA in October 2022 but has been available for testing since October 2021. There was an effort by Anthony Shaw (Python Software Foundation Fellow and Microsoft Python advocate) to add support to LISA in July 2022, but it fizzled out after hitting a non-obvious error. The PR was closed 4 days after 3.11 went GA without merging the required fixes that were already identified.
The non-obvious error was due to an improperly implemented enum which leveraged a glitch corrected in Python 3.11. Mypy would have caught the issue, but the issue was masked due to improper typing.
Python 3.11 is a particularly important release to the community and Microsoft. Microsoft hired the creator of Python, Guido van Rossum, in November 2020 to work on improving the performance of Python. Python 3.11 is the first release of this multi-release effort. Python 3.11 is 10 to 60% faster than 3.10 and has a smaller memory footprint. Real world examples have shown CPU utilization cut in half simply by moving to Python 3.11.
Unnecessary Dependencies
LISA has a large number of external dependencies. Eternal dependencies are unavoidable in this type of program, but there are cases where packages are included for functionality that can be implemented with very little code. Including external packages makes sense for code that is difficult to implement, but unnecessary imports increase maintenance, install time, load time. Some Examples are listed below.
The use of the randmac package to create a random MAC address can be implemented with the single line f"x2:{':'.join(format(random.randint(0, 255), '02x') for _ in range(5))}".
The use of the python-dateutil package for date parsing rather than using the included datetime.datetime.strptime()
The use of the retry package rather than a simple context manager.
Unmaintained Dependencies
Standard engineering principles hold that dependency pinning creates an implicit contract with downstream consumers that the dependencies are monitored and maintained. For this reason, dependency pinning should be pushed as far downstream as possible. However, for various reasons, LISA pins dependencies in the development branch. These dependencies have gone unmaintained with some dating back to November 2021. This prevents LISA from taking advantage of security fixes, bug fixes, and efficiencies added to these packages.
Some recent effort has been made by the author to improve this by adding automatic dependency checking and PR creation. While this has been partially deployed, full deployment has been held up waiting to PRs to be merged. This is mainly due to inadequate repo management and limited test coverage.
Invalid implementation of __hash__()
The __hash__ method in Python is used to indicate uniqueness and should return a unique integer no greater than the size of sys.hash_info.width, typically the machine’s word size. __hash__() implementations in LISA returns strings, that are not always unique between instances and, at times, too long to preserve any uniqueness after being truncated to sys.hash_info.width.
Redefinition of variables in an outer scope
There are at least 21 cases where a variable has been given the same name as a variable in an outer scope. This can lead to bugs because the outer scope variable may be accessed without error before the inner scope variable is defined. Once the inner scope variable is defined, it can unintentionally mask the outer scope variable.
No encoding specified when reading or writing files
There are 26 identified cases where an encoding is not specified when reading or writing files. This can introduce compatibility issues between platforms. For example, documentation building was broken on Windows for this exact reason.
Various syntax and logic improvements
There are 276 additional cases of syntax and logic improvements identified through standard linting. Many more have been identified through additional analytic tools, such as Sourcery, and manual review. Improvements like these simplify logic, reduce computation time, reduce memory, and/or improve readability.
Major effort to resolve or rewrite needed
The items listed in this section require invasive changes to the code, extensive analysis, and/or breaking changes.
Incomplete or invalid class abstractions
There are 212 identified cases where a method in a parent class was abstracted but the subclass did not define the method. This points to invalid interface definitions and can be a source of bugs. Due to the large number of cases, automatic detection becomes ineffective.
Catching broad exceptions
There are 74 cases where a broad exception is caught rather than a specific exception. This is a common source of bugs because errors that would normally have been raised are caught and discarded, often in unrelated code. The best time to determine what exceptions should be caught is when the code is written since the developer will have context. Resolving these at a later point requires a developer to do additional analysis and research.
Cyclical Imports
There are 68 cases where a cyclical import was identified, primarily in the tools and operating systems modules. These are cases where an import depends on another import that depends on a previous import. These types of imports are very fragile and can result in race conditions where an object has not been initialized before it is accessed.
Duplicate Code
There are 60 cases where duplicate code was identified. This indicates the code has not been optimized. There are additional cases where nearly duplicate logic appears in multiple locations, though this is harder to detect across files.
Various memory and CPU inefficiencies
There are various places where memory and CPU are used inefficiently. Many of these cases are from unnecessarily keeping objects in memory longer than necessary or iterating over objects all at once rather than as needed. More complicated cases relate to the program’s architecture and involve creating objects that are larger than necessary or unnecessary at all.
Use of global statements
LISA has 8 incidents where global statements are used. These are cases where a variable in the global namespace is modified from a local namespace. While there are legitimate uses for global statements, they are extremely rare and often indicate an underlying design issue. To have 8 cases in a single program is extremely unusual. For a program of this size and complexity, it’s likely 0 to 1 of the globals are necessary. Further investigation is needed to determine the full scope of the issue.
Mix use of data classes, validation models, and general purpose classes
Data classes were introduced in Python 3.7 as an improvement over named tuples. They are intended as containers for typed data and, generally, have no methods.
Validation models (also known as schemas or data validation classes), are used to validate data received from an untrusted source. The most popular data validation libraries, Pydantic and Marshmallow, implement models as classes. The syntax is pure Python, but the structure is library-specific.
LISA has 142 data classes defined. Many are also used as validation models and general purpose classes. While this is supported, it unnecessarily increases complexity, and the way they are implemented prevents full introspection by linting and typing tools.
Incomplete plugin validation
LISA employs three different mechanisms for extending code: subclassing, abstract base classes, and Pluggy hooks. Not only is the number of methods confusing to downstream developers, but none of these methods perform plugin validation, so implementation errors won’t be presented until they cause a failure.
Compromised type definitions
Python is a dynamically-typed language, but use of static type checkers has become popular as a way of catching and preventing bugs. This requires type annotations to be added to the code.
LISA uses Mypy for type checking. However, when type annotations were added, the emphasis was put on ensuring Mypy passes rather than on correctness. This resulted in errors being broadly suppressed and objects being incorrectly typed.
Implementation like this makes type checking less useful. As an example, an improperly-typed object masked a bug which prevented LISA from running with Python 3.11
Lack of code documentation
The standard for Python inline code documentation is every class, function, or method should have a docstring explaining what it does, any expectations for the arguments, any limitations, and any additional information about return values that might be useful. Additionally, comments should be added to clarify non-obvious code or to break down larger blocks of code for readability. This goes back to the reality that code is read much more often than it is written, so it should be written to be read.
In contrast, LISA has little inline documentation, with some very large files completely devoid of comments and docstrings. This increases the time it takes to make changes, increases maintenance costs, and makes it more difficult for those unfamiliar with the code to contribute.
Limiting design
LISA has multiple areas where an attempt was made to decouple elements of the program, but it ended up creating additional coupling. An example is the concept of tools in LISA.
Ostensibly, tools are intended to abstract dependencies and syntactic differences between different platforms. While this can be worthwhile for specific tools, for general operations it adds complexity. For example, the basic activity of listing files is a method of the Ls class rather than a primitive that abstracts the implementation details. Whether this action is done by root or the logged in user is an argument to the method requiring redundant logic in most tool methods. This could have been implemented as a context manager, greatly simplifying the code.
LISA has a lot of other categories of objects, both internal and external. The purposes for these aren’t always apparent, either because there is overlap, little documentation, or because they use non-standard names (example: combinator vs matrix). It creates a steep learning curve for users and contributors alike.
Platform-specific components are not separated. This can lead to unexpected interdependencies, slows down development, and complicates testing. For example, the code to support Azure, AWS, and Libvirt are included in the main code base. The Azure-specific code, itself, has a large number of dependencies that can be inadvertently included in the main code base. Code like this is often kept in a separate repository, but could also be kept in an independent package within the same repository.
Open Source
Open Source software has many benefits, both for users and contributors. Some of these benefits are intangible, but many lead to reduced costs.
When open sourcing software, companies gain additional resources at no cost. Community members test software, identify bugs, provide pull requests, provide additional documentation, and expand capabilities. But to take advantage of this, a project must build a community. Open source is merit-driven, so communities will naturally form around quality software that provides a new capability or solves an existing problem in a novel way.
The current and previous versions of LISA have been open sourced under an OSI-approved license. However, LISA has not realized the benefits of community involvement, with almost all contributions coming from within Microsoft. This is primarily due to two reasons. The first is LISA does not provide a new capability. The second is LISA has low quality code and documentation. Open Source community members can’t justify investing time in LISA unless they are required to. This results in a small, largely disinterested community and little, if any, external support.
The inverse of this is companies can leverage existing Open Source projects with established communities to reduce their own development costs. LISA has done this to some degree by using community-provided Python modules for some capabilities. However, a large part of the LISA codebase reimplements functionality available in other projects. Not only does this require writing and maintaining new code, It means LISA is not taking advantage of the lessons these other projects have learned or the community contributions that deal with changes, security, performance, and useability.
User experience
Rather than a single configuration file, LISA is configured through both Python files and YAML  files. Configuration should be in a single place. One problem preventing this in the current implementation is test suites combine configuration with additional logic. This additional logic could be in generic plugins, allowing all configuration data to be in a single place. The burden of two different types of files providing different parts of the configuration is confusing to users and increases the steepness of the learning curve.
Additionally, the documentation is incomplete, confusing, and has not been reviewed for grammatical inconsistencies. The names used are not standard and conflict with common terms. For example, what would normally be called a "matrix", a way of running tests against multiple input sets is called a "combinator" in LISA, a term usually associated with lambda expressions.
Maintainability
There are currently very few people, perhaps only @squirrelsc  and @LiliDeng , who fully understand LISA’s design and implementation. Because it was not written with maintenance in mind, it would be difficult for anyone to be able to take over this work. In the event these resources were not available, the code would likely stagnate or be replaced.
As discussed in the Code quality section, Lisa is largely devoid of code documentation. This problem is compounded by current maintenance practices in which the majority of pull requests do not have descriptions. This means the only context preserved for these changes is the short pull request names and commit comments. Developers looking for context on why something was done a certain way have little information available to them. Not only is this frustrating, but it increases the development effort and can lead to code regression.
Alternatives
At its basic level, LISA is an orchestration framework for Linux system validation which can operate across multiple platforms. What it does is not particularly different from other orchestration frameworks, Ansible being the most popular. Ansible already comes with numerous modules, supporting all popular Linux distribution, cloud providers, and even Windows. It is also supported by Microsoft for use with Azure and used by other teams at Microsoft.
While some may think Ansible is strictly for deployment, use for validation is also common. Since LISA requires both deployment and validation, it seems well-suited to fill that gap. This video (7:05 for a good example) and the associated runbooks show how this might work. Essentially, desired state can be validated primarily using the Ansible’s built-in assert module. A callback plugin can be utilized to format and store the results as needed depending on the use case. Ansible is written in Python, has extensive developer documentation, and broad community support, so it is relatively easy to add additional capabilities.
If Ansible, or a similar framework, is utilized, it would need to be determined if it was a complete replacement or if it would live behind a thin wrapping interface. From a maintainability standpoint, it would be better if it lived on its own, but that may not fit the requirements.
The future of LISA
It’s clear, in its current state, LISA needs a lot of work just to reach a reasonable level of maintainability. At a minimum, it requires the following:

Standard packaging
Code cleanup
Improved documentation
Reliable test coverage
Refactoring / rewriting of some major components

Some of this work has already begun, but is slowed by limited test coverage and fragile code. Changes are tested manually and review is limited to two people. Stabilizing the current code base would likely take years.
It’s unclear if LISA, as a framework, provides additional capabilities than those provided by other Open Source tools, such as Ansible. An investigation to see what gaps exist when using other tools should be carried out. Even if a wrapper is required, the reduced maintenance burden and extensive community make it worth exploring replacing the majority of LISA’s code with Open Source alternatives.
Ultimately, the changes needed to bring the current version of LISA into an expected level of maintainability and useability would likely require multiple breaking changes and take more effort than rewriting from scratch. Utilizing existing Open Source solutions, either as a complete replacement or for the majority of the custom code, will reduce development time substantially and reduce future maintenance costs.
In order to properly evaluate the available options, a requirements document should first be created to ensure all the required and desired capabilities are captured and agreed upon. This can largely be done internally, but it may also be worth engaging close partners to provide input.
Recommended course of action

Create RFC 2119-style requirements documents to define requirements for LISA or its replacement
Review Open Source options which could fully or partially replace LISA
Identify gaps between Open Source solutions and requirements
Depending on the results of the previous step
a. If an Open Source solution can fully replace LISA, begin work on implementation plan
b. If an Open Source solution cannot fully replace LISA, begin design work for LISA v4

This is personal opinions, not represent LISA maintainers, and future of LISA. Thanks for the feedback, we respect different opinions. We had a lot of internal discussions already, won't be repeated here.
Anyone is welcome to submit PR to fix issues, which are mentioned here, but not fixed. The PR owner is responsible for quality of the PR, including test coverage. The evidence here is not enough to motive us to consider replacements.

@avylove you might be interested in the other LISAv3 I wrote in https://github.com/microsoft/lisa/pull/1107, that was not accepted in favor of this version you're now having to deal with.


Pick free ports for the test suite randomly

I had some problems on my machine with port 9001 being blocked.
There's no reason in using fixed ports, let's better pick free ones that work!

The below solution should also work on Windows. See:

Oh I didn't know that. Nice!
(Btw the test suite of the bot doens't work on Windows anyways: https://github.com/dlang-bots/dlang-bot/pull/91 - it already fails at the git clone because Windows has more restrictive file names...)


Exercise: Another cell

Closed #333

I have fix code style bug and add static method TextCell.repeat


Somatic contamination downsampling

Our contamination downsampling code is somewhat intelligent.  AlleleBiasedDownsamplingUtils contains methods to downsample the most suspicious reads up to a given contamination fraction.  However, its criterion for suspicion is a non-diploid allele fraction.  AlleleBiasedDownsamplingUtils::scoreAlleleCounts uses the following metric of goodness, with smaller values being considered better:
Math.min(maxCount - nextBestCount + remainderCount, Math.abs(nextBestCount + remainderCount))
where maxCount, nextBestCount, and remainderCount are the number of reads supporting the most common allele, the next most common allele, and all other alleles.  This score basically says "if it's heterozygous, return the difference between ref and alt counts.  If it's homozygous, return the number of reads not supporting the unique true allele."  The problem for somatic calling is that any time there is a somatic variant with low allele fraction this criterion is optimized by assuming homozygosity and downsampling only the variant.
It could be that instead of implementing somatic downsampling we should give up on distinguishing contamination from somatic variation and simply filter out calls whose allele fraction is comparable to the contamination.  But perhaps there's something more clever we could do.  @takutosato @ldgauthier @LeeTL1220 do you have thoughts?

Based on Chip's screenshot that I think was included with the old issue, the M1 contamination handling seems to do something similar to that proposal and that was the version he was happier with.

Closing this, because Chip is right. M1 is right, and the correct approach is not to downsample.  We should just pass the contamination to the Mutect filtering engine and let it decide.  A reasonable place to start is to simply filter variants with allele fraction less than the contamination, but we can later take it a step further and account for the population allele frequency.  For example, if contamination is 0.01 and we have a exonic variant with allele fraction 0.01 (I'm thinking ahead to cfDNA here so assume the depth is really high) that's not is ExAC, we know that it's population allele frequency can't be much more than one in a million.  And the chances of it being homozygous alt in the contaminant are really tiny.  Therefore, we would not throw out this variant.


bootnodes for mainnet

Added bootnodes directly to the start command

Thank you, I didn't know the correct format, and I didn't want to bother you that late at night 💖


[BUG] Catching errors

Describe the bug
I am trying to catch the error or to reconnect if the camera is disconnected due to the cable or any other error. but this method is not returning the values. is there any other way to catch this errors? and also is there a Generic error handler? o where can see all the possible errors.
I am using thet c++ API (V2.24.0)
Additional context
The error handling documentation is not really clear, I would appreciate your help :3

Hi @gabrielmercado90
At the moment there is no way of getting the actual error that caused the crash/disconnect.
We plan to add it in on the next major release.

Ok, thank you @moratom !!


Increase the maximum page size to allow single-call fetches of all cards or printings

We can revisit this in 35 years when the card pool exceeds the new limit


belinda's-closet_4_72_refactored-archive-updated-unit-test

Resolves #72
This PR updates the unit test for the archive function in the product service, references #61.
There is a small refactor to the function, as it was first validating the id, which we need, but when it passed that check we were creating a new Id Object to be passed. This is unnecessary.
To test:

In your .env file make sure to set the following variables as detailed in the installation instructions for this repo.
You must have a valid MongoDB URI string for a database connection and set it as MONGODB_URI=<your database connection string> in your .env.
You must set JWT_SECRET=jwt in your.env.
You must set an expiry for your JWT Secret, I did JWT_EXPIRES = 90d in your .env.
Using the available API calls in the ProductController, use Postman to test.
Without an Authorization token in the header you should not be able to create(POST), update(PUT), or delete(DELETE) a product making calls to the ProductController.
Sign-up a new user or login an existing user with 'user' as their role and copy the JWT token.
Set this token as a Header for Authorization, as seen in the first picture below.
As a user you still should not be able to create(POST), update(PUT), or delete(DELETE) a product making calls to the ProductController.
Sign-up a new user or login an existing user with 'admin' as their role and copy the JWT token.
Set this token as a Header for Authorization, as seen in the first picture below.
As an admin you should be able to create(POST), update(PUT), or delete(DELETE) a product making calls to the ProductController.

'Archiving' a product with a valid id found in the database, success:

'Archiving' a product with a valid id not found in the database:

'Archiving' a product with an invalid id, bad request:

Tests:

It passed all the tests for me. I also ran the same calls from your screenshots in postman and received the same results.


Concerning the Reproducibility of Results on ScanObjectNN

Hi! Thanks for your great job.
I find that directly using you repo and your checkpoint of Point-GPT-S cannot reproduce the result in your paper.
Specifically,  I download the pretrained.pth of Point-GPT-S and I run your code on downstream benchmark objbg and objonly in ScanobjectNN with minor changes to your code which aim at resolving the environment error.
But I only get 87.95% and 88.12% which is significantly than the reported results 91.6% and 91.0% in the paper of PointGPT.
And I think the minor changes to the code will not affect the results. The changes of code include:
From
# tools/builer.py
elif sche_config.type == 'CosLR':
        scheduler = CosineLRScheduler(optimizer,
                                      t_initial=sche_config.kwargs.epochs,
                                      # t_mul=1,
                                      lr_min=1e-6,
                                      cycle_decay=0.1,  # decay_rate
                                      warmup_lr_init=1e-6,
                                      warmup_t=sche_config.kwargs.initial_epochs,
                                      cycle_limit=1,
                                      t_in_epochs=True)

change to

elif sche_config.type == 'CosLR':
        scheduler = CosineLRScheduler(optimizer,
                                      t_initial=sche_config.kwargs.epochs,
                                      # t_mul=1,
                                      lr_min=1e-6,
                                      # cycle_decay=0.1,  # decay_rate
                                      decay_rate=0.1       # NOTE change here
                                      warmup_lr_init=1e-6,
                                      warmup_t=sche_config.kwargs.initial_epochs,
                                      cycle_limit=1,
                                      t_in_epochs=True)

And from
# models/PointGPT.py
        dim_t = self.temperature ** (2 * torch.div(dim_t, 2, rounding_mode='trunc') / self.num_pos_feats)

change to
        dim_t = self.temperature ** (2 * (dim_t / 2).trunc() / self.num_pos_feats)

I have no idea about how to reproduce you result on ScanobjectNN using Point-GPT-S. Could you help me about this?
Thank you.

Upon further searching online, I found that the functions decay_rate and cycle_decay serve the same purpose and should not affect the results. Similarly, the second code change involving trunc might not be related. Can you help me understand why the results are so poor?
Thank you!

This issue may stem from the learning rate specified in the config file; immediate modifications will be made. Thank you.


low accuracy

I trained the mono branch and tested without dense alignment.The result is bad.
bbox AP:92.51, 82.42, 67.09
bev  AP:10.17, 6.37, 6.75
3d   AP:6.79, 4.92, 3.72
aos  AP:90.87, 80.31, 64.89
Is it a normal situation?
if not,can you give me some advice?

Yes, it's normal.
In the mono branch, if you don't use the dense alignment, the 3D box is inferred from pure 2d bounding box, which can not guarantee the 3d accuracy.

Did you only use one image for everything in the Mono branch?


Feature Request: update ALERTS section from JSON output to be as complete as the HTML output

Missing functionality
The ALERTS section from the to_json() output gives only the types of errors and the column name (e.g. HIGH_CORRELATION, or ZEROS), but for example for the HIGH_CORRELATION error doesn't tell with which columns it is highly correlated to (although for this one specific I can obtain it from a different section of the JSON output). For the ZEROS warning the json output says '[ZEROS] alert on column XLarge Bags', but doesnt supply the information that it has 704 zero's (while the HTML output does actually show this). See the two images below to display the output difference:

Proposed feature
A more extensive JSON output from the to_json() function. The ALERTS section should not only tell what alert/error was encountered, but also quantify the errors (e.g. not only display [ZEROS] alert in column X, but just as in the HTML output format: [ZEROS] there were 704 zero's encountered in column X.
Alternatives considered
in the rest of the JSON string output details about the correlations can be obtained, but for the missing values (ZEROS), this is not possible as the JSON output is a barchart written out in HTML info.
Additional context
shouldn't be too difficult to fix, as the information exists in the HTML report, but not in the to_json() JSON string

Hi @Robin66014,
thank you for the detailed request! Indeed this is something that can improve the experience with the to_json method.
I've added to YData Profiling Roadmap - https://github.com/orgs/ydataai/projects/16

Hi,
In alert which have multiple high levels of correlations, the json file simply says the total number of high levels of correlation. Whereas in the HTML, it is possible to see what these are by simply hovering over them. Is it possible to replicate this using json alone?


Simulate all worm controllers, only allow input on IsCurrentTurn, added hats.

Each players pawn now becomes Pawn.Player rather than a worm. That player then simulates all of it's associated worms and only allows input where the worms IsCurrentTurn bool is set to true.
Fixes #34
Implements #27 camera

Found an issue whereby local worms can still fire after their turns are ended. Will resubmit when fixed.


Add data to HA chef-backend

Add data to chef-backend cluster to test the migration from chef-backend to chef-automate HA

There was configuration issue so that is why chef-backend backup was not working and even chef-backend was going down. So after configuration change chef-backend cluster was up and then backup was successfull


Attention :module 'tensorflow.python.keras.api._v2.keras.layers' has no attribute 'Attention'

Please make sure that this is a bug. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:bug_template
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):Win10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
TensorFlow installed from (source or binary):source
TensorFlow version (use command below):2.0.0a0
Python version:3.6
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:

You can collect some of this information using our environment capture
script
You can also obtain the TensorFlow version with: 1. TF 1.0: python -c "import tensorflow as tf; print(tf.GIT_VERSION, tf.VERSION)" 2. TF 2.0: python -c "import tensorflow as tf; print(tf.version.GIT_VERSION, tf.version.VERSION)"
model = keras.Sequential()
model.add(tf.keras.layers.Embedding(max_words, embed_size))
model.add(tf.keras.layers.Bidirectional(tf.keras.layers.LSTM(128, return_sequences=True)))
model.add(tf.keras.layers.Attention())
Describe the current behavior
AttributeError: module 'tensorflow.python.keras.api._v2.keras.layers' has no attribute 'Attention'
Describe the expected behavior
Code to reproduce the issue
Provide a reproducible test case that is the bare minimum necessary to generate the problem.
Other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

@ares5221 Could you try with 2.0.0rc1 or 2.0.0rc2 instead of 2.0.0a0? There it's all good for me.

2.0.0a0 is extremely old, please switch to 2.0.0rc2

@ares5221 Please find the github gist here. Attention layer does exist in tensorflow 2.0.0-rc2.

@ares5221 As mentioned by others, attention layer exists in recent versions of tensorflow (TF2.0.0 and others). Please check the more details and code examples of attention layer here.
I am closing this issue as this was resolved. Please feel free to open the issue if the issue persists in TF2.0. Thanks!

@ares5221 Could you try with 2.0.0rc1 or 2.0.0rc2 instead of 2.0.0a0? There tf.keras.layers.Attention does exist.

i try in win10，2.0.0rc2 it works, and ubuntu18.04 only support 2.0.0b1,and it works too
thanks very much

2.0.0 should be supported by every OS. Please make sure you have the latest pip though.

2.0.0 should be supported by every OS. Please make sure you have the latest pip though.

yes，thks


WIP: add support for checking nginx configuration files

Fixes #100

@onlineque Sorry for the long timeline but we're ready to start taking a look at this. Can you resolve the conflicts before we start our review? Thanks!

No issue, man :-)  Please, take a look, but first let me know if this way of handling the file masks for the nginx config files is feasible, as mentioned in the issue #100 itself. Thanks !


chore: database documentation

Requires https://github.com/block/ftl/pull/3857 to be merged first to make the migration section accurate.


Schematic doesn't get updated

Hey,
again the plugin is great. But its not working properly at my side. I'm working on Mac.
While the graphical issues have been solved which is great, I now have the problem, that the plugin does not update the schematic.
Here is what I do:
I open up the board (schematic is closed). I open up the plugin. I select a part and toggle BOM. If I open the part inside the board, I can now see that the BOM has been toggled. So far so good.
Now I do "Export to schematic" to write the new settings to the schematic.
If I now open the schematic, the new settings have not been overtaken and if I update now the board from the schematic, the new setting gets overwritten by the schematic.
Same is valid for other things like LSCS part number... I guess this is valid for all settings.
Is my workflow wrong?
Thanks,
Chris

Hi,
the export to schematic function s kind of hacky. KiCAD does not provide a proper API to write to the schematic.
They intended to come up with such an API for V7 but postponed it for V8.
But I doubt that it will make it in V8 as I've not seen even a early alpha of said API.
I cannot inverst time in a feature that is about to be changed anyway soon.
My workflow is to add LCSC numbers manually to the schematic. I totally see that this makes a large part of the plugin kind of useless, but my spare time is so limitid that we will have to live with that until the API lands.
Sorry that I cannot provide a more satisfying solution ...

Thanks for sharing details about the situation here; it makes perfect sense.  Looking at the code, it seems like there are three property names (LCSC, LCSC_PN, JLC_PN?) that are supported, though only LCSC is added if they don't exist.
Is the correct workaround here to manually add an LCSC property to schematic entities with the LCSC part number? That's almost too easy...


[BACKLOG-7462] New thin repository UI

@mdamour1976 And the big one.

Base build failed with return code 1

Base build failed with return code 1