Append working directory to swift compiler args when presented in build settings

Currently there's no explicit api for sourcekit to recognize swift's working-directory other than through compiler args
When build server contains such setting, inject the correct args in place.

Currently this is only applied to the BuildServerBuildSystem, but it probably also should be done in at least the CompilationDatabaseBuildSystem as well.  Maybe we should handle this in the SwiftLanguageServer code so that it applies to all sources of compiler arguments?  @akyrtzi any concerns about that approach?

I agree, the changes should be done in SwiftLanguageServer. I think longer term it would be ideal to remove the buildSystem.settings() function entirely, something like the approach in #183.

Maybe we should handle this in the SwiftLanguageServer code so that it applies to all sources of compiler arguments? @akyrtzi any concerns about that approach?

Seems like the right approach.

@benlangmuir Thanks for the suggestion, now mutating args in SwiftLanguageServer itself
as @rmaz point out, this is more like a short term patch, would love to get this sorted out with https://github.com/apple/sourcekit-lsp/pull/183

Ah I missed that comment - what particularly would #183 help with here?  It would mean we only need one place to accept arguments from the build system (the delegate method), but we'd still need to modify them to add the working directory, no?

@benlangmuir ping for review, changed logic to the file setting model now

@swift-ci test

@swift-ci please test

@swift-ci please test

@swift-ci please test Linux

BuildServerBuildSystemTests.swift:44: error: -[SKCoreTests.BuildServerBuildSystemTests testSettings] : XCTAssertEqual failed: ("Optional(["-a", "-b", "-working-directory", "/path/to/some"])") is not equal to ("Optional(["-a", "-b"])")

@swift-ci test

@swift-ci please test

@swift-ci please test

CompilationDatabaseTests.swift:203: error: -[SKCoreTests.CompilationDatabaseTests testCompilationDatabaseBuildSystem] : XCTAssertEqual failed: ("Optional(["-swift-version", "4", "/a/a.swift", "-working-directory", "/a"])") is not equal to ("Optional(["-swift-version", "4", "/a/a.swift"])")

@swift-ci please test

@benlangmuir Safe to merge?


duplicate extract for aquatone and gowitnesss not added to binaries folder

https://github.com/osmedeus/osmedeus-base/blob/68b442aa6578cc071b0f3115791ac45e3a71c7e4/data/install-external-binaries.sh#L59

Thank you for reporting, I just push a quick fix for it


slot does not seem to work with svg

<template>     <require from="./selection-highlight.css"></require>     <svg class="highlight-item" ref="highlightElement"><slot></slot></svg> </template>
when using
        <selection-highlight selected-item.two-way="selectedTab">             <rect class="highlight-rect" />         </selection-highlight>
it does appear in the render tree in chrome dev tools but it does not draw.
if I edit the html in chrome and delete the slot comment element it renders fine.
is this a aurelia issue or something else?

I don't believe the spec is designed to enable slot inside an svg. It's part of the HTML spec.


Mirror Maker 2: offset-syncs variable

Introduce offset-syncs.topic.override to MirrorConnectorConfig for overriding the default topic mm2-offset-syncs.ALIAS.internal. This can help with shared kafka clusters that require every topic to have a prefix, such as some of heroku's.
Committer Checklist (excluded from commit message)

[ ] Propose a KIP (or ask an apache member)
[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Hi @ryannedolan, wondering if you could spare a little guidance.
I created offset-syncs.topic.override variable with a default of null. What I would have loved to do is to create something like offset-syncs.topic with a default value of mm2-offsets-sync.<ALIAS>.internal, but was unable to due to the alias in the string, and think it would require a much larger change to do so. Thoughts?
I also emailed<EMAIL_ADDRESS>to get access to create a KIP, but that seems to be a dead end. If I get together the content for a KIP, would you be willing to submit it?
Thanks!

@cgetzen the larger change would be worth it IMO. I think a KIP is the right way forward. Happy to help, but you should be able to get permission to create a KIP yourself. Might just take a few tries, unfortunately. Maybe check who has been responding to such requests lately and reach out to them directly.
Are there other properties that we could make more customizable in this way too? Might be a good time to address them all together.

Much appreciated. Another property is the heartbeats topic.
I will create the KIP as soon as I get my head around all the different types of configs and how they work together. Thanks!

I believe this has been addressed by KIP-690, so closing this PR.


[cinder-csi-plugin] Remove redundant imagePullPolicy

What this PR does / why we need it:
Which issue this PR fixes(if applicable):
fixes https://github.com/kubernetes/cloud-provider-openstack/issues/1598
...as done for cinder-csi-plugin chart version 1.4.x in: https://github.com/kubernetes/cloud-provider-openstack/pull/1602
...but now for cinder-csi-plugin chart version 1.3.x.
...to ensure a smooth upgrade for anyone else passing Kubernetes v1.21 before v1.22.
Special notes for reviewers:
Superseeds https://github.com/kubernetes/cloud-provider-openstack/pull/1781 (which was accidentally closed).
Release note:

NONE

@jichenjc Could you take a look?
Needs ok-to-test.
This is a new attempt at https://github.com/kubernetes/cloud-provider-openstack/pull/1781 (with gofmt fix applied).

/ok-to-test

/test pull-cloud-provider-openstack-check

/retest

/retest

/test pull-cloud-provider-openstack-check

@jichenjc Any ideas? Seems this fails in other PRs too, for example as seen in https://github.com/kubernetes/cloud-provider-openstack/pull/1775#issuecomment-1027647543

/retest

@MPV The above jobs are not required for this PR, will override them.

/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.19
/override openlab/cloud-provider-openstack-acceptance-test-e2e-conformance-stable-branch-v1.20
/override openlab/cloud-provider-openstack-multinode-csi-migration-test
/override openlab/cloud-provider-openstack-sanity-test-csi-cinder

/override openlab/cloud-provider-openstack-test-occm

/lgtm

/lgtm
/approve


TSLint LS changes the original diagnostics array

Hi. There is a problem with the code:
https://github.com/angelozerr/tslint-language-service/blob/master/src/index.ts#L304
It uses the original diagnostics object from the parent LS (doesn't copy it).
The parent LS caches the object so every time when I call getSemanticDiagnostics (and the file wasn't changed so the parent LS can use the cache) it adds more and more tslint errors.
There is no way to reproduce the error in VSCode because it doesn't call getSemanticDiagnosticsSync.
we can fix the problem by adding this code:
if (prior === undefined) {
   prior = [];
} else {
   prior = prior.slice();
}

I guess you can also use a cache as the parent LS does it.

Thanks @anstarovoyt for your suggestion, is there any change to have a PR?


Scoped global refresh for BDPs

When a BDP does a root refresh, don't refresh the entire tree.
Instead, this refreshes any item which has a child that is provided by said BDP.

This change is causing bugs with creating/deleting resources. We should revert it until we have a better solution.
The issue is since BDPs were able to signal a root refresh which resulted in refetching the list of resources, BDPs used it to signal resources had been created/deleted. With this change, the list is never updated and Azure resources thinks the deleted resource should still exist even if it doesn't, which results in errors.
However, I don't think it was ever intended for BDPs to be able to do this. It should be the responsibility of the resource provider to signal that the list of resources needs updating. The issue with that is the default Azure resource provider is built-in, and clients have no way of signaling that the list needs to be refetched.
We could make it so that when the list is refetched, only parts of the tree with new or removed nodes are refreshed. Or we could keep it simple and revert to always refetching the list, and refreshing the entire tree again.


Issue with reading data from newly created topic

I have run consumer with auto creating topic true for test-topic-2 then after some time tried pushing data in to that topic however it is never reading data (test-topic is properly read without any issues).
TOPIC            PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                  HOST            CLIENT-ID
test-topic       8          70477           71801           1324            ABCDE                                        /HOST            kafkajs
test-topic       4          84243           85566           1323            ABCDE                                        /HOST            kafkajs
test-topic       5          70483           71807           1324            ABCDE                                        /HOST            kafkajs
test-topic-2     10         -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     8          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     3          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       2          70480           71804           1324            ABCDE                                        /HOST            kafkajs
test-topic-2     6          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       6          84057           85475           1418            ABCDE                                        /HOST            kafkajs
test-topic-2     2          -               1               -               ABCDE                                        /HOST            kafkajs
test-topic-2     7          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       3          84149           85472           1323            ABCDE                                        /HOST            kafkajs
test-topic-2     0          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       10         84236           85559           1323            ABCDE                                        /HOST            kafkajs
test-topic       1          84291           85568           1277            ABCDE                                        /HOST            kafkajs
test-topic-2     9          -               1               -               ABCDE                                        /HOST            kafkajs
test-topic       11         70388           71806           1418            ABCDE                                        /HOST            kafkajs
test-topic-2     5          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     11         -               1               -               ABCDE                                        /HOST            kafkajs
test-topic       7          84283           85606           1323            ABCDE                                        /HOST            kafkajs
test-topic       9          84251           85481           1230            ABCDE                                        /HOST            kafkajs
test-topic       0          84244           85473           1229            ABCDE                                        /HOST            kafkajs
test-topic-2     1          -               1               -               ABCDE                                        /HOST            kafkajs
test-topic-2     4          -               1               -               ABCDE                                        /HOST            kafkajs

After trying to run code with fromBeginning flag i am able to recover some partitions which had data but partitions which never had any data still stay stale and when data produced to that stale partition it is never read. (only enabling fromBeginning flag allows to to recover that partition and start reading properly from there)
TOPIC            PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                  HOST            CLIENT-ID
test-topic       8          71801           71801           0               ABCDE                                        /HOST            kafkajs
test-topic       4          85566           85566           0               ABCDE                                        /HOST            kafkajs
test-topic       5          71807           71807           0               ABCDE                                        /HOST            kafkajs
test-topic-2     10         -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     8          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     3          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       2          71804           71804           0               ABCDE                                        /HOST            kafkajs
test-topic-2     6          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       6          85475           85475           0               ABCDE                                        /HOST            kafkajs
test-topic-2     2          1               1               0               ABCDE                                        /HOST            kafkajs
test-topic-2     7          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       3          85472           85472           0               ABCDE                                        /HOST            kafkajs
test-topic-2     0          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic       10         85559           85559           0               ABCDE                                        /HOST            kafkajs
test-topic       1          85568           85568           0               ABCDE                                        /HOST            kafkajs
test-topic-2     9          1               1               0               ABCDE                                        /HOST            kafkajs
test-topic       11         71806           71806           0               ABCDE                                        /HOST            kafkajs
test-topic-2     5          -               0               -               ABCDE                                        /HOST            kafkajs
test-topic-2     11         1               1               0               ABCDE                                        /HOST            kafkajs
test-topic       7          85606           85606           0               ABCDE                                        /HOST            kafkajs
test-topic       9          85481           85481           0               ABCDE                                        /HOST            kafkajs
test-topic       0          85473           85473           0               ABCDE                                        /HOST            kafkajs
test-topic-2     1          1               1               0               ABCDE                                        /HOST            kafkajs
test-topic-2     4          1               1               0               ABCDE                                        /HOST            kafkajs

Would you be able to reproduce this issue as a standalone script? It would be helpful to understand the exact sequence of events, and to be able to dig into which member is assigned to which partitions, and so on.

@Nevon looks like this issue is intermittent, have not yet found exact cause, i will do more tests with that tomorrow and let you know if there will be any progress

@goriunov what is the state of the consumers? are they always running? Have you published data after booting the consumers? Setting fromBeginning after the partition has been initialized has no effect.

@tulios consumer was always running and consuming from one topic, then i just pushed some messages to second topic (java client kafka-console-producer.sh --broker-list ...) which never had any messages before and was able to see that messages get in to LOG-END-OFFSET but never read from there. After that i have restarted consumer and that did not help. Then i added fromBeginning and it correctly pulled messages from the partitions which had LOG-END-OFFSET but were not read before. Then removed fromBeginning and restarted client and everything just works.
I was not able to replicated this issue constantly yet, but it happens quite often, will do more test later.

@tulios @Nevon after a bit more testing i am not able to reproduce the issue above


Overworked header handling.

Fixed double handling of X-Forwarded-For header.
Added X-Real-Ip and X-Forwarded-Proto header.
Changed configuration documentation to match the header behaviour.

BTW, you can just force push commits into your own branch and github will update the PR automatically. Found that out on a different project :)

Thx


fix(buffer): Buffer was missing from dev builds

High Level Overview of Change
Only when running npm run start was Buffer missing.
Type of Change

[x] Bug fix (non-breaking change which fixes an issue)

This error has disappeared.


Should scikit-build pick the right compiler on Windows automatically?

We've recently ported a pretty complex project with C, C++ and Cython used as Python extensions to sikit-build-core.
We got it all working on Mac an Linux, but on Windows, we're having some issues.
(Using Powershell: it seems to be required by our CI)
Our first attempt resulted in it building for x86 instead of x64 -- it turns out that we had (carelessly ) used a Powershell configured for x86. And we're making progress with a generic powershell and activating the x64 compiler with: vcvars64.bat.
However -- shouldn't scikit-build (or cmake) figure that out for us, and call the right compiler, based on the Python that's doing the build? I'm a bit concerned that setting it up by hand ahead of time is a bit fragile for less experienced uses and CI systems, etc.
Or is that just that way it is?
Note: this could be related to #590 -- though that made me think that it should "just work"
-CHB

Do you use a GHAction like ilammy/msvc-dev-cmd@v1? What issues do you see, is it in the compiler chosen or in the build artifacts produced?

we're building locally at the moment, and will be using our in-house gitLab CI (and ultimately conda-forge, but baby steps...)
It's the compiler (or how it's set up) -- it seems to simply use the default set up in the shell -- so it was trying to build 32 bit extensions agains 64 bit libraries.
Never got as far as build artifacts :-)

There are various factors that influence the compiler detection, but generally it's environment variable CC and what resolves cc in PATH (similar for CXX). For window it should resolve to cl.exe. But about the 32 vs 64 bit issue on Windows, I am not familiar enough to debug that. From what I've read on ilammy/msvc-dev-cmd@v1 it basically calls vcvars64.bat so that cl.exe to the appropriate value. It did specify this nuance iirc, but I couldn't follow it. Maybe you can decipher it better.
As for conda-forge, it works automagically, on this issue.

it basically calls vcvars64.bat so that cl.exe to the appropriate value.

Ahh -- that's what I thought, but it didn't seem to be happening in our case.

From what I've read on ilammy/msvc-dev-cmd@v1

What's that? where in code would that be?
-Thanks

https://github.com/ilammy/msvc-dev-cmd

This is purely anecdotal, but I am currently going through a conversion of a 32-bit project to 64-bit, on Windows, and I was very pleased to find that scikit-build-core did "just work" for me. I use tox and have two environments set up (py39-32 and py312-64) that use different base_python values for 32 and 64-bit respectively (the same is true for their packaging environments as well). Each one correctly identifies the right toolchain to compile the extensions to the right bit-ness, without any further input from me. That is running on a standard powershell without pre-setting up any compilers or anything - is it possible that when you activate vcvars in advance you prevent scikit-build-core from doing its own activation?

Afaik, there is no secret sauce for detecting compilers within scikit-build-core, and everything is based on how CMake detects it. There is a bit of manipulation for the -G generator, but other than that, it should be as close to vanilla CMake as possible, with only additional SKBUILD cache variables. Hopefully I got this right @henryiii.
So, if you are able to get your CI working for plain CMake, adding scikit-build-core should be straightforward. Although, I personally always add the CMAKE_C_COMPILER option explicitly in the CI.

We do want to get the same compiler setuptools would get if things is specified. If you set up your shell with x86 (by clicking on the "x86 command line" shortcut or running vcvars.bat) but use a 64-bit Python, that's asking for trouble. But if you don't activate anything, it should ask CMake to find MSVC with the correct bittiness. You shouldn't need to manually run vcvars (such as through ilammy/msvc-dev-cmd) for most cases. We try to match Python's bittiness unless it's specified (VSCMD_ARG_TGT_ARCH) here: https://github.com/scikit-build/scikit-build-core/blob/3594f33a852ec2ee4deb3ad65613782ee644d7b5/src/scikit_build_core/builder/sysconfig.py#L102-L134

@henryiii: Thanks! That was what I thought should happen, apparently we were trying to be too clever.
I'll report back if/when we get it working, and we can then close this.

Ok, I might have been premature when I said that this was working for me - I have now found a really confusing situation. To test it, I have created a dummy project which contains only an empty CMakeLists.txt and the following pyproject.toml:
[project]
name = "test"
version = "0.0.1"

[build-system]
requires = ["scikit-build-core[pyproject]>=0.8.2"]
build-backend = "scikit_build_core.build"

[tool.tox]
legacy_tox_ini = """
[tox]
envlist = py312-64

[testenv]
base_python = python312-64
package = wheel
"""

I currently have a 32-bit Python 3.9 and a 64-bit Python 3.12 installed on my system (and VS2019). I have created new venvs from both 3.9-32 and 3.12-64 and run only pip install tox on each of them, then run tox from each environment on the test project. The 3.9-32 environment succeeds in building the wheel correctly (using a 3.12 virtualenv) while the 3.12-64 environment fails with output of
-- Building for: Visual Studio 16 2019
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.22631.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

If I manually run cmake.exe from the 3.12-64 tox's packaging virtualenv then it correctly finds the compiler without issue, and if I run either python -m pip wheel . or python -m build from either env then I get the wheel I want. So I cannot figure out what could be going on within tox that could be causing this issue. @henryiii, I will raise this issue with tox as well, but do you have any insights into what could be going wrong that might be causing this issue?

Tox isolates you from the surrounding environment variables by default. Nox does not, by the way. You can set a tox config to pass through environment variables. That’s my first suspicion for what might be surprising.

@JamesMakela-NOAA: I think you solved this -- if so, maybe post what worked for you, and then we can close, if no one else has ongoing questions.


Cannot use the PowerShell scripts that this page guides to.

https://github.com/OfficeDev/O365-InvestigationTooling/blob/master/Get-AllTenantRulesAndForms.ps1
The PowerShell Script that can download from this link is archved.
This script connects to Exchange Online using Basic Authentication and is not currently available.
Therefore, the "Steps to confirm the Rules and Forms attack using PowerShell" procedure is invalid.
I have created this issue because I think you need to edit this page.

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

ID: 82d82939-8b5a-2d4c-6cc9-5a3443ee5b99
Version Independent ID: 8d4fd954-0a92-67e8-f2fd-ca5ffaaacac2
Content: Detect and remediate the Outlook rules and custom forms injections attacks. - Office 365
Content Source: microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack.md
Service: microsoft-365-security
Sub-service: mdo
GitHub Login: @MSFTTracyP
Microsoft Alias: tracyp

@zumapool Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Revert Pydantic to a non-optional dependency

Pydantic has been made an optional dependency in #1431, but Litestar still depends on Pydantic in various places (some datastructures and as a default signature modelling backend). This PR reverts Pydantic to a non-optional dependency.
Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

By submitting this issue, you agree to:

follow Litestar's Code of Conduct
follow Litestar's Contribution Guidelines

Description
Close Issue(s)

Is it planned to make Pydantic optional at some point? I couldn't find a related open issue.

Is it planned to make Pydantic optional at some point? I couldn't find a related open issue.

It is, perhaps. We aren't clear yet - we will need at least one Backend Setup by the user, so not for V2.


Allow Gatsby Source Kontent Plugin to filter by collection

Motivation
We use one Kontent project with multiple collections for mutiple sites. We have a separate build process for each site. This means that each site pulls all the data down for all the sites even though it is not needed. We can filter by language but all our sites use the en-gb language as well as their own native language so all en-gb content is pulled even if it is not in a relevant collection
Proposed solution
Enable filtering on collection as well as language

Curious if adding support for query params would be a good way to approach this. On our sites we would benefit from filtering content items by workflow steps (such as archive — https://preview-deliver.kontent.ai/{{KENTICO_PROJECT_ID}}/items?system.workflow_step=archived) to limit the content sourced for builds. Collections can also be filtered this way according to the API. A more flexible solution that relies on the API's robust filtering method could enable a variety of capabilities.
One wrinkle to this approach is that it appears filtering by language is handled with a query param, so perhaps it would need to be documented as an optional additionalFilterParams or similar to avoid complicating the implementation.

Hello @anthonyshughes and @bwlng,
thank you for reaching out!
I was thinking about the robustness of the solution. And @bwlng's idea about extending the configuration is pretty easy to implement but the robustness would not be really great - I will try to come up with something more complex, like a hook, but we can fall back to the easy string-based configuration for the queries. - Can you think of any other filter you might want to use? IMO it makes sense for filtering based on system properties, right?
But in general, I have identified some possible problematic areas I would like to discuss prior to the implementation.
Cross collection Links

How about linking an item from a different collection - Collection1 -> Collection2 using linked items element or rich text element. This item would not be in the model is that OK?

Cross Links that aims to filtered-out item

How about linking an item from another workflow (any s property) using linked items element or rich text element. This item that does not fit the filter would not be in the model is that OK?

Webhook handling

Currently there is no way of configuring webhooks to be fired only for specific collection items - are you OK that the processing would just skip these (maybe with some info log fr verbose output)?

I also have one more general question. I am testing gatsby v4 compatibility (#192), which is currently in alpha. What do you think about upgrading to the gatsby v4 with your project - my preliminary testing looks like there might not be any breaking changes from the kontent gatsby source plugin point of view.

@Simply007, @bwlng,
Yes I agree that it would make sense to create a more generic solution to allow filtering on all the system properties rather than just collection.
Cross collection Links
From our point of view, we accept that linking to a collection that is filtered would cause an issue with links. Most of our editors only have access to the collections that are relevant to their site so this shouldn't be a problem for us. We would make it part of the editor training that they can't link to items from other collections for the couple of editors that do have access to multiple sites. I can see it could cause confusion for other customers if they are not aware of this restriction.
Webhook handling
Filtering webhooks by collection is a feature that I would like to see implemented within Kontent. We currently use an AWS Lambda function to receive the webhooks from Kontent and then redistribute them to our Gatsby Cloud sites depending on the collection the webhooks are for. This stops us building sites that do not have any changes. So not a problem for us specifically but again could be an issue for other customers.
I think that the potential issues that could be caused by implementing this feature could also be a problem for anyone using the Delivery Rest API. If these points are documented via the API filtering section then it shouldn't cause too many problems.
Gatsby V4
We will try upgrading and see what happens.

@bwlng @anthonyshughes
Alright,
how about trying the lean approach.
I will implement the feature, release the feature in alpha as experimental, you will test it out and if everything is OK, I can include it as an experimental feature in the standard release (and add tests for it). After some adoption/testing time, we can continue to push it as standard configuration property in one of the upcoming major/minor releases.

@bwlng @anthonyshughes
Alright,
how about trying the lean approach?
I will implement the feature, release the feature in alpha as experimental, you will test it out and if everything is OK, I can include it as an experimental feature in the standard release (and add tests for it). After some adoption/testing time, we can continue to push it as standard configuration property in one of the upcoming major/minor releases.
What do you think?

We are happy to go with this approach and test it out.

@Simply007,
We have upgraded to V4 (4.0.0-alpha-9689ff.5) and it hasn't caused any noticable issues. Seems to have sped up page queries which is nice.

@Simply007,
We have upgraded to V4 (4.0.0-alpha-9689ff.5) and it hasn't caused any noticable issues. Seems to have sped up page queries which is nice.

Great to hear! I still need to release the kontent gatsby source plugin to ensure that the source plugin is correctly using Gatsby v4.
Out of interest: Could you share the numbers for the time boost?

@bwlng @anthonyshughes
Alright,
how about trying the lean approach?
I will implement the feature, release the feature in alpha as experimental, you will test it out and if everything is OK, I can include it as an experimental feature in the standard release (and add tests for it). After some adoption/testing time, we can continue to push it as standard configuration property in one of the upcoming major/minor releases.
What do you think?

We are happy to go with this approach and test it out.

I have released version 7.3.0-alpha.0 - could you test it out?
I have described options in the Available options section - so for you, the value could be system.collection=<COLLECTION_CODENAME>.

Out of interest: Could you share the numbers for the time boost?

This is only from a local single clean (no cache) build for each version so not exactly scientific but a definite improvement.
V3
success run page queries - 1470.570s - 11685/11685 7.95/s
V4
success run queries in workers - 908.137s - 11685/11685 12.87/s

I have released version 7.3.0-alpha.0 - could you test it out?
I have described options in the Available options section - so for you, the value could be system.collection=<COLLECTION_CODENAME>.

We have tested this using a single collection as the filter and also mutliple (system.collection[in]=austria,default) and it works perfectly. Not only has it reduced the time to source and transform nodes but it has also reduced the time to run the page queries. I assume because the page queries now has less nodes to sort through.

Perfect @anthonyshughes!
I will keep this version out like that for a while so that you can send your feedback if you have some.
Then I will probably release a new version of the source plugin targeting gatsby v4 (#192) once it is out and stable.
Finally, I will include this feature as experimental in the release/or maybe include it as standard into the release if I have time to come up with a more robust solution.

@Simply007 I tested 7.3.0-alpha.0 by filtering our archived items
  ...
  experimental: {
    additionalItemFilterParams: `system.workflow_step[neq]=archived`,
  }
  ...

Works as expected, thanks so much! I can't think of any filters outside of the system properties we would need to filter.

Cross collection Links and Cross Links that aims to filtered-out item – if these are being filtered out to create individual sites, it makes sense to treat them as external links and train editors to handle them that way
Webhook handling – this won't impact our project, but agree it would be nice to have additional options within Kontent for filtering webhooks based on criteria. We currently filter webhooks in the app that receives them as well

Thank you both for the feedback @bwlng @anthonyshughes!
May I ask you for one more favor? Could you change the collection/workflow step to the one that is filtered in and vice versa?

@Simply007,
I have been using gatsby-source-kontent/v/8.0.0-beta.1 and gatsby-kontent-components/v/8.0.0-beta.1 for over a week now and all seems fine so far. No issues to report.

@Simply007 Thanks! I have been using the filtering option in v8 and have no issues to report with this feature. Works great 👍

Is there any plan to make gatsby-source-kontent compatible with Gatsby v4?


Dotfiles

yadm, git-crypt, etc.
Do I need this?

https://yadm.io/docs/faq#usage

Some way to enter repo initially, text entry with my GitHub repo as the default. That allows others to use this more easily and doesn’t hinder me that much at all. Could add a confirm step to hit enter.
The usage link below has hooks and a section on using https frost and then ssh after changing the url and decrypting the SSH keys

yadm clone -b main https://github.com/iancleary/dotfiles.
https://github.com/TheLocehiliosan/yadm/issues/232 leaves the branch on master, so I would need to checkout main, delete master, decrypt prompt,
yadm clone -b main https://github.com/iancleary/dotfiles
yadm checkout -b main
yadm branch -D master
yadm decrypt (enter password)
eval $(ssh-agent -s)
ssh-add ~/.ssh/github_id_rsa
ssh -T<EMAIL_ADDRESS>

Bootstrap script: https://github.com/iancleary/dotfiles/commit/5576ce40a09740443646723a5b1b0741eabfc9b2


Add DEFAULT_AUTO_FIELD in exmple setting

Add DEFAULT_AUTO_FIELD in the examples setting.
It shows a warning when running the example app.

I'd suggest https://github.com/jazzband/django-two-factor-auth/issues/436#issuecomment-1445363150 instead.

You may also include a note in the Changelog (in a new Unreleased section).

@claudep
Thanks for your review and suggestion


Missing .npy files

I'm trying to run main.py, but it's asking for '/Scene1/HeatCubes/S_EnvObj_L_0002.npy', the closest thing to this in the database provided is '/Scene1_Street/HeatCubes/L_0002_heatcube.mat'.
Is there a separate location I can find the .npy files? Or a function you used to convert between .mat and .npy?
Thanks!

Hello Srah,
Please check this answer:

Thank you.
I was able to run preprocess_data.py after doing the following:

Downloading HADAR database
Renaming Folders from Scene1_Road to Scene1
Changing lines 58 and 59 in preprocess_data.py from
`ids = [f"L_{i:04d}" for i in range(1, 5)]
ids += [f"R_{i:04d}" for i in range(1, 5)]

#to:
ids = [f"{i:04d}" for i in range(1, 5)]
ids += [f"{i:04d}" for i in range(1, 5)]
`


update payments contract to  track payment IDs

We need to create a few helper methods that make it easy to retrieve the latest payment ID for a user without having to listen to events such that we can easily update the database wth the payment ID based off the pending call data state.

see latest commit


Revive at least one new implementation Open Maintainers Call

The py-libp2p Open Maintainers Call happens this Thursday: https://lu.ma/2024-03-28-py-libp2p

The py-libp2p notes are taken here: https://docs.google.com/document/d/1UJhieRHgHLEfzqE06BNujwWf3Qwl5VIFKaFtA-6LgKo/edit?usp=sharing


Build breaks for branches with "/" in the name

Ref https://bccmedia.semaphoreci.com/jobs/5c339c46-90c4-4d69-9b1c-d9b6bd1ae2fa

Fixed as part of #1016


[Header] 'Magnifier' image has got incorrect size.

Environment: Firefox Version 78.0.2 (64-bit)/Windows 10 Home 1903
Reproducible: always
Build found: 4a2d9d1
Steps to reproduce

Go to GreenCity https://ita-social-projects.github.io/GreenCityClient/#/welcome

Actual result
'Magnifier' image has got 26px x 26px size

Expected result
'Magnifier' image has to 11px x 11px size

According to mockup search icon has 16px 16px  in header component

In search pop-up it has 24px 24px

The search pop-up has 16x16 size

according to mockup search icon in header shoul be 16px 16px
in the mockup

in the projects

https://www.figma.com/file/K5qc43VjSkWVz8mobuovxs/ITA-Greencity?node-id=2213%3A399
https://ita-social-projects.github.io/GreenCityClient/#/welcome

Thank you for your letter, sorry for mistake...
On Fri, Nov 13, 2020 at 5:01 PM Nataliia Skrebets<EMAIL_ADDRESS>wrote:

according to mockup search icon in header shoul be 16px 16px
in the mockup
[image: image]
https://user-images.githubusercontent.com/50843868/99085737-3dca6900-25d1-11eb-986f-0cd93f4f45f9.png
in the projects
[image: image]
https://user-images.githubusercontent.com/50843868/99086076-b29da300-25d1-11eb-8d61-ac782d412b77.png
https://www.figma.com/file/K5qc43VjSkWVz8mobuovxs/ITA-Greencity?node-id=2213%3A399
https://ita-social-projects.github.io/GreenCityClient/#/welcome
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ita-social-projects/GreenCity/issues/1192#issuecomment-726812545,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APQL2Z3XKL3CAY5XNFFESWTSPVC3BANCNFSM4QIDMJHA
.


Moving Optimism bin to Optimism Cli

Closes https://github.com/paradigmxyz/reth/issues/9408

how's it going with this? need some help? I have a PR that's a dependent on this @loocapro

how's it going with this? need some help? I have a PR that's a dependent on this @loocapro

Hi @emhane, since i removed some cfg flags, I am running in some workspace dependency issue here:
https://github.com/paradigmxyz/reth/actions/runs/9909282475/job/27376994891?pr=9439
Any advice?

how's it going @loocapro ?

only thing missing here is getting ahold of the feature snafu @joshieDo and I are getting this over the line

release builds work fine: https://github.com/paradigmxyz/reth/actions/runs/10144116336/job/28046941974?pr=9439

Thanks @joshieDo for taking this on!! Amazing work!!


Fix AlertmanagerConfigInconsistent alert

Previously the alert would fire when the number of Alertmanager pods
didn't match the number of replicas defined in the Alertmanager spec
even though all the running pods had the same configuration hash. This
type of issue is already covered by KubeStatefulSetUpdateNotRolledOut
(and possibly KubePodNotReady), having AlertmanagerConfigInconsistent
also active in this situation creates unnecessary noise.
With this change, the alert expression only returns when Alertmanager
pods have different configuration hash values irrespective of the number
of pod replicas. The message annotation has also been enhanced to report
the configuration hash for each pod.
xref: https://bugzilla.redhat.com/show_bug.cgi?id=1846397

Nice!

Is there an upstream alertmanager-mixin? If so we should probably port this over to there...

There's this long standing PR that I need to carry over: https://github.com/prometheus/alertmanager/pull/1629
It doesn't check for alertmanager_config_hash yet but it would be a good addition indeed.


Update EstimatorV2 result decoder

Summary
Update EstimatorV2 result decoder.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

3 of 6 (50.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 82.545%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_runtime/utils/estimator_result_decoder.py
2
5
40.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
5495

Relevant Lines:
6657

💛  - Coveralls


Lightmap baking sometimes freezes on "integrate indirect lighting".

Godot version
4.2.beta4
System information
Windows 11, Godot 4.2.beta4, Forward +, Integrated graphics
Issue description
Godot freezes when baking lightmap after changing lightmap size hint property or size of the meshinstance.
lightmap works normally and fast for small scene, but freezes when increasins those values.

I couldn't figure out if the issue is hardware related or a bug.
Steps to reproduce
Setting up simple scene(plane, cube, sphere) and unabling uv2 on them.
Adding lightmapGI
Changing lightmap size hint or scale of the primitive mesh.
Clicking on bake lightmaps.
Minimal reproduction project
4.2.beta4lightmap.zip

Thanks for the report! Consolidating in https://github.com/godotengine/godot/issues/54679.


FLEDGE - AddCustomAudienceOverrideRequest doesn't work with custom CustomAudience.owner value

Hi,
As I was testing out the seller/buyer js override functionality that has been recently introduced to the Fledge implementation, I noticed that the CustomAudience override requests don't have any effect if the owner property of the CustomAudience is not equal to the package name of the application. For example, in the FledgeJava sample application,
when I change the following code snippet from MainActivity class:
// Set up Custom Audience Wrapper(CAs)
String owner = context.getPackageName();
CustomAudienceWrapper caWrapper = new CustomAudienceWrapper(owner, BUYER, context, EXECUTOR);

to:
// Set up Custom Audience Wrapper(CAs)
CustomAudienceWrapper caWrapper = new CustomAudienceWrapper("test", BUYER, context, EXECUTOR);

The override just doesn't work and there is no bidding js to evaluate the ads. I'm not sure if this is a bug or some unmanifested requirement.  I had not noticed any negative impact of the custom owner property value on the application before the js override functionality was introduced.

Hey @flowenol, this is expected but not well documented in our JavaDoc.
We are allowing overrides only to entities that have been created by the same application trying to override their data.
The reason why there is no explicit failure is because we don't want this API to become a way for an app to explore CustomAudiences created by another one.
We are going to improve the documentation.
Thank you for your feedback!!

Thank you for the clarification.


Overhaul normalize processing

In this PR you can see a couple of conservative improvements I made to the "normalization":

Removing unnecessary parametrization.
Make tag injection idempotent (arguably fixing a latent bug).

followed by a more aggressive change, which is completely deleting the "liferay-theme-deps-normalize" plug-in and making it so that we don't mutate installed node_modules any more. From the commit message:
This commit deletes the liferay-theme-deps-normalize package from the repo and replaces the hack that it used to use (mutating the installed liferay-frontend-theme-unstyled packaged in node_modules) with a build transform that injects the tags as the files are written into the build directory.
Test plan:
Unfortunately, it's complicated:

yarn test
In packages/liferay-theme-tasks/package.json, remove dependency on liferay-theme-deps-7.2 because it is not yet published and will otherwise cause things to blow up.
Use the local copy of the generator to create a new theme called "test"; ie. yo ./packages/generator-liferay-theme
cd test-theme and change this line in gulpfile.js to make it use the local tasks package:

- var liferayThemeTasks = require('liferay-theme-tasks');
+ var liferayThemeTasks = require('../packages/liferay-theme-tasks');

Run the "build" task; ie. node_modules/.bin/gulp build
Inspect build/templates/portal_normal.ftl and see the tags have been    injected.

One disclaimer about the injectJS function: I wrote code to handle both the isStream() and isBuffer() case, but console.log shows that we only get buffers so one of the branches is effectively untested. If there is a bug in there and it blows up, we'll have to deal with that, but it's possible we'll never get a stream here. FWIW, I based what I wrote in that branch on these docs:

https://gulpjs.org/writing-a-plugin/
https://gulpjs.org/writing-a-plugin/dealing-with-streams.html
https://www.npmjs.com/package/through2
https://nodejs.org/api/stream.html#stream_transform_transform_chunk_encoding_callback
https://nodejs.org/api/stream.html#stream_transform_flush_callback

Was originally trying to extract this from #174 but ending up going a different route.

Going to merge this one in order to make #179 easier to review. I can follow-up on any feedback related to this one.


Apply for CII Best Practices Badge

As a FiWare GA, QL has to get a CII Badge---see Jason's email about it, subject: [Fiware-technical-committee] Applying for CII Best Practices Badge.
I tried creating an account three times, but I never got the confirmation email from CII with the activation link. @chicco785 if you could please try creating an account with
Account Name: Martel Innovate
Email: your work email
Pass: the one I shared in passbolt
Then I'll do the rest...

@c0c0n3 why not using the github account? https://bestpractices.coreinfrastructure.org/en/login

badge owner should be martel, not c0c0n3?

then also my email is not good, right?

yea, ideally we'd use an admin-like email, e.g<EMAIL_ADDRESS>if we do have one. i tried with<EMAIL_ADDRESS>i.e. a tried to create an account in martel's name but with my email address as contact. the problem i had is that the account got created (and i can log in!) but it still isn't active since i never got the activation email in my martel inbox, so i thought there might have been a problem w/ my email since i tried recreating the account and having them resend the activation email but still no luck.

no activation link arrived so far

arrived now

awesome, thanks alot. i'll take it from here. also i've found an email address we could use<EMAIL_ADDRESS>if any of us gets emails there i could replace your email with orchestra's...

filling out the form was a bit of a schlep but it's done and dusted now. bage linked to readme too, see 1b525f1.


fix(ios): keyboard auto dismisses

Summary
Fixes #566
Related:
https://github.com/callstack/react-native-pager-view/pull/462
https://github.com/satya164/react-native-tab-view/issues/1244
Test Plan
See repro in #566 and video there.
After this change:
https://user-images.githubusercontent.com/697707/169838926-ef0e0b74-de56-4ff7-a39a-53f295564978.mp4
What's required for testing (prerequisites)?
See repro in #566 and video there.
What are the steps to reproduce (after prerequisites)?
Compatibility

OS
Implemented

iOS
✅

Android
❌

Checklist

[x] I have tested this on a device and a simulator
[ ] I added the documentation in README.md
[ ] I updated the typed files (TS and Flow)

Thank you @andreialecu for the contribution  🎉

Hey @andreialecu thanks for your work on this.
Just wanted to share a quick personal experience that your initial fix (with animated:NO) worked for me for the view height.
With animated:YES the view height appears to intermittently come up too short again.
I've got a lot of moving parts in my app and haven't had a chance to isolate it yet but just wanted to drop a comment in case it's relevant!

Indeed I also intermittently noticed this just one time.
Seems to still occur but very rarely in my experience. Looks like more investigation is needed.


Reading Negra corpus files with a NegraCorpusReader

The NegraCorpusReader enables reading corpora files created by annotate, a tool for efficient semi-automatic annotation of corpus data. Available corpora in this format are the German NEGRA and German TIGER corpora. Further information on the corpora and where to obtain them can be found here:
http://www.coli.uni-saarland.de/projects/sfb378/negra-corpus/negra-corpus.html
http://www.ims.uni-stuttgart.de/projekte/TIGER/TIGERCorpus/
Information on the annotate tool can be found at
http://www.coli.uni-saarland.de/projects/sfb378/negra-corpus/annotate.html
A NEGRA corpus file consists out of annotated sentences separated by #BOS (beginning of sentence) and #EOS (end of sentence) markers on their own line. Each sentence consists of words and columns containing the lemma, tag, chunk and/or morphological tag. Each word and its tag information has its own line.
Here is an example of the Negra corpus and its format
#BOS 2 2 899973978 1
Sie			PPER	3.Pl..Nom	SB	504
gehen			VVFIN	3.Pl.Pres.Ind	HD	504
gewagte			ADJA	Pos..Akk.Pl.St	NK	500
Verbindungen		NN	Fem.Akk.Pl.*	NK	500
und			KON	--		CD	502
Risiken			NN	Neut.Akk.Pl.*	CJ	502
ein			PTKVZ	--		SVP	504
,			$,	--		--	0
versuchen		VVFIN	3.Pl.Pres.Ind	HD	505
ihre			PPOSAT	.Akk.Pl	NK	501
Möglichkeiten		NN	Fem.Akk.Pl.	NK	501
auszureizen		VVIZU	--		HD	503
.			$.	--		--	0
#500			NP	--		CJ	502
#501			NP	--		OA	503
#502			CNP	--		OA	504
#503			VP	--		OC	505
#504			S	--		CJ	506
#505			S	--		CJ	506
#506			CS	--		--	0
#EOS 2
(http://www.coli.uni-saarland.de/projects/sfb378/negra-corpus/corpus-sample.export)
Because of similar corpus structure, this reader is based on and very
similar to the ConllCorpusReader. Both corpora have their tokens structured
as grid. NEGRA corpus file provide more token information though.
The NegraCorpusReader can be found at
https://github.com/ptnplanet/NLTK-Contributions
It is licensed under the Apache 2.0 Licence to enable the use with and within the NLTK.Migrated from http://code.google.com/p/nltk/issues/detail?id=623earlier comments
<EMAIL_ADDRESS>said, at 2011-06-05T11:57:49.000Z:
I've also written a corpus reader for the Negra export format, with the important difference that mine also gives you the complete parse trees. Since these can contain crossing branches, the terminals are indicated by indices. The code is at:
https://github.com/andreasvc/disco-dop/blob/master/negra.py

+1


ensure non-scanned pseudo motor remain unchanged?

@klauer
Thanks first for sharing the pseudo axis code for theta-dependent lab x and lab z.
I noticed that when only the lab x is being scanned, the lab z position would slowly drift.
I suppose that this is because at each point it's doing a forward position calculation and a small calculation error can propagate? Or is this rather not expected?
Is there a more elegant/fundamental way to solve this issue besides using scan_nd to force labx and labz both reach the targeted positions (since lab_z is not being scanned, it would be the same position for the entire list).
I only noticed this once I started scanning 2D images. See below for two consecutive scans.
BlueSky [18]: hr2dxrf_scanplan = OuterProductAbsScanPlan(det, tomo_stage.finey_top, 0, 20, 5, tomo_lab.lab_x, 0, 80, 11, True)

BlueSky [19]: hr2dxrf_scanplan = bp.subs_wrapper(hr2dxrf_scanplan, livecallbacks)

BlueSky [20]: gs.RE(hr2dxrf_scanplan)
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|   seq_num |       time | tomo_stage_finey_top | tomo_stage_finey_top_user_setpoint |      lab_x |      lab_z | real_finex_top | real_finex_top_user_setpoint | real_finez_top | real_finez_top_user_setpoint | real_theta | real_theta_user_setpoint | current_preamp_ch0 | current_preamp_ch2 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|         1 | 20:37:09.5 |               -0.007 |                              0.000 |      0.003 |     79.817 |         79.817 |                       79.828 |          0.003 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000912 |       -0.000000024 |
|         2 | 20:37:11.0 |               -0.008 |                              0.000 |      8.005 |     79.804 |         79.804 |                       79.817 |          8.005 |                        8.000 |    89.9999 |                  89.9999 |        0.000000927 |       -0.000000024 |
|         3 | 20:37:12.4 |               -0.007 |                              0.000 |     16.004 |     79.792 |         79.792 |                       79.804 |         16.004 |                       16.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|         4 | 20:37:13.9 |               -0.006 |                              0.000 |     24.005 |     79.779 |         79.779 |                       79.792 |         24.005 |                       24.000 |    89.9999 |                  89.9999 |        0.000000921 |       -0.000000024 |
|         5 | 20:37:15.4 |               -0.006 |                              0.000 |     32.003 |     79.769 |         79.769 |                       79.779 |         32.003 |                       32.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|         6 | 20:37:16.9 |               -0.006 |                              0.000 |     40.000 |     79.758 |         79.758 |                       79.769 |         40.000 |                       40.000 |    89.9999 |                  89.9999 |        0.000000917 |       -0.000000024 |
|         7 | 20:37:18.3 |               -0.006 |                              0.000 |     48.000 |     79.746 |         79.746 |                       79.758 |         48.000 |                       48.000 |    89.9999 |                  89.9999 |        0.000000916 |       -0.000000024 |
|         8 | 20:37:19.9 |               -0.007 |                              0.000 |     55.999 |     79.735 |         79.735 |                       79.746 |         55.999 |                       56.000 |    89.9999 |                  89.9999 |        0.000000911 |       -0.000000024 |
|         9 | 20:37:21.4 |               -0.006 |                              0.000 |     63.998 |     79.723 |         79.723 |                       79.735 |         63.998 |                       64.000 |    89.9999 |                  89.9999 |        0.000000911 |       -0.000000024 |
|        10 | 20:37:22.8 |               -0.006 |                              0.000 |     72.000 |     79.712 |         79.712 |                       79.723 |         72.000 |                       72.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        11 | 20:37:24.3 |               -0.006 |                              0.000 |     80.003 |     79.701 |         79.701 |                       79.712 |         80.003 |                       80.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        12 | 20:37:25.7 |                4.994 |                              5.000 |     80.003 |     79.700 |         79.700 |                       79.712 |         80.003 |                       80.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        13 | 20:37:27.3 |                4.994 |                              5.000 |     71.999 |     79.689 |         79.689 |                       79.700 |         71.999 |                       72.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        14 | 20:37:28.9 |                4.994 |                              5.000 |     63.997 |     79.679 |         79.679 |                       79.689 |         63.997 |                       64.000 |    89.9999 |                  89.9999 |        0.000000915 |       -0.000000024 |
|        15 | 20:37:30.3 |                4.995 |                              5.000 |     55.998 |     79.667 |         79.667 |                       79.679 |         55.998 |                       56.000 |    89.9999 |                  89.9999 |        0.000000911 |       -0.000000024 |
|        16 | 20:37:31.8 |                4.995 |                              5.000 |     47.998 |     79.655 |         79.655 |                       79.667 |         47.999 |                       48.000 |    90.0004 |                  89.9999 |        0.000000907 |       -0.000000024 |
|        17 | 20:37:33.3 |                4.995 |                              5.000 |     40.001 |     79.644 |         79.644 |                       79.655 |         40.001 |                       40.001 |    89.9999 |                  90.0004 |        0.000000913 |       -0.000000024 |
|        18 | 20:37:34.9 |                4.994 |                              5.000 |     32.003 |     79.632 |         79.632 |                       79.644 |         32.003 |                       32.000 |    89.9999 |                  89.9999 |        0.000000913 |       -0.000000024 |
|        19 | 20:37:36.3 |                4.993 |                              5.000 |     24.004 |     79.621 |         79.621 |                       79.632 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        20 | 20:37:37.9 |                4.994 |                              5.000 |     16.003 |     79.610 |         79.610 |                       79.621 |         16.003 |                       16.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
|        21 | 20:37:39.4 |                4.994 |                              5.000 |      8.003 |     79.599 |         79.599 |                       79.610 |          8.004 |                        8.000 |    90.0004 |                  89.9999 |        0.000000922 |       -0.000000024 |
|        22 | 20:37:40.8 |                4.992 |                              5.000 |      0.004 |     79.587 |         79.587 |                       79.599 |          0.004 |                        0.001 |    89.9999 |                  90.0004 |        0.000000920 |       -0.000000024 |
|        23 | 20:37:42.2 |                9.993 |                             10.000 |      0.005 |     79.586 |         79.586 |                       79.599 |          0.005 |                        0.001 |    89.9999 |                  90.0004 |        0.000000921 |       -0.000000024 |
|        24 | 20:37:43.7 |                9.994 |                             10.000 |      8.005 |     79.572 |         79.572 |                       79.586 |          8.005 |                        8.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        25 | 20:37:45.1 |                9.993 |                             10.000 |     16.007 |     79.559 |         79.559 |                       79.572 |         16.007 |                       16.000 |    89.9999 |                  89.9999 |        0.000000924 |       -0.000000024 |
|        26 | 20:37:46.7 |                9.994 |                             10.000 |     24.003 |     79.547 |         79.547 |                       79.559 |         24.003 |                       24.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        27 | 20:37:48.1 |                9.995 |                             10.000 |     32.004 |     79.536 |         79.536 |                       79.547 |         32.004 |                       32.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        28 | 20:37:49.7 |                9.995 |                             10.000 |     40.001 |     79.525 |         79.525 |                       79.536 |         40.001 |                       40.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        29 | 20:37:51.3 |                9.995 |                             10.000 |     48.000 |     79.514 |         79.514 |                       79.525 |         48.000 |                       48.000 |    89.9999 |                  89.9999 |        0.000000917 |       -0.000000024 |
|        30 | 20:37:52.8 |                9.995 |                             10.000 |     55.999 |     79.502 |         79.502 |                       79.514 |         55.999 |                       56.000 |    89.9999 |                  89.9999 |        0.000000910 |       -0.000000024 |
|        31 | 20:37:54.3 |                9.996 |                             10.000 |     63.997 |     79.490 |         79.490 |                       79.502 |         63.999 |                       64.000 |    89.9999 |                  89.9999 |        0.000000916 |       -0.000000024 |
|        32 | 20:37:55.7 |                9.995 |                             10.000 |     71.998 |     79.481 |         79.481 |                       79.490 |         71.998 |                       72.000 |    89.9999 |                  89.9999 |        0.000000916 |       -0.000000024 |
|        33 | 20:37:57.4 |                9.996 |                             10.000 |     80.001 |     79.469 |         79.469 |                       79.481 |         80.001 |                       80.000 |    89.9999 |                  89.9999 |        0.000000921 |       -0.000000024 |
|        34 | 20:37:58.7 |               14.997 |                             15.000 |     80.001 |     79.469 |         79.469 |                       79.481 |         80.001 |                       80.000 |    89.9999 |                  89.9999 |        0.000000919 |       -0.000000024 |
|        35 | 20:38:00.3 |               14.997 |                             15.000 |     71.998 |     79.458 |         79.458 |                       79.469 |         71.998 |                       72.000 |    89.9999 |                  89.9999 |        0.000000919 |       -0.000000024 |
|        36 | 20:38:01.8 |               14.997 |                             15.000 |     63.997 |     79.447 |         79.447 |                       79.458 |         63.998 |                       64.000 |    90.0004 |                  89.9999 |        0.000000916 |       -0.000000024 |
|        37 | 20:38:03.4 |               14.996 |                             15.000 |     55.999 |     79.436 |         79.436 |                       79.447 |         55.999 |                       56.001 |    89.9999 |                  90.0004 |        0.000000916 |       -0.000000024 |
|        38 | 20:38:04.7 |               14.996 |                             15.000 |     47.998 |     79.424 |         79.424 |                       79.436 |         47.998 |                       48.000 |    89.9999 |                  89.9999 |        0.000000913 |       -0.000000024 |
|        39 | 20:38:06.2 |               14.994 |                             15.000 |     39.999 |     79.412 |         79.412 |                       79.424 |         39.999 |                       40.000 |    89.9999 |                  89.9999 |        0.000000916 |       -0.000000024 |
|        40 | 20:38:07.7 |               14.995 |                             15.000 |     32.002 |     79.400 |         79.400 |                       79.412 |         32.002 |                       32.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        41 | 20:38:09.1 |               14.995 |                             15.000 |     24.004 |     79.387 |         79.387 |                       79.400 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000924 |       -0.000000024 |
|        42 | 20:38:10.6 |               14.995 |                             15.000 |     16.004 |     79.374 |         79.374 |                       79.387 |         16.004 |                       16.000 |    89.9999 |                  89.9999 |        0.000000924 |       -0.000000024 |
|        43 | 20:38:12.3 |               14.996 |                             15.000 |      8.004 |     79.362 |         79.362 |                       79.374 |          8.004 |                        8.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        44 | 20:38:13.8 |               14.994 |                             15.000 |      0.001 |     79.351 |         79.351 |                       79.362 |          0.001 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        45 | 20:38:15.2 |               19.995 |                             20.000 |      0.003 |     79.350 |         79.350 |                       79.362 |          0.003 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000931 |       -0.000000024 |
|        46 | 20:38:16.7 |               19.994 |                             20.000 |      8.005 |     79.338 |         79.338 |                       79.350 |          8.005 |                        8.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        47 | 20:38:18.1 |               19.994 |                             20.000 |     16.005 |     79.325 |         79.325 |                       79.338 |         16.005 |                       16.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        48 | 20:38:19.7 |               19.995 |                             20.000 |     24.004 |     79.314 |         79.314 |                       79.325 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        49 | 20:38:21.3 |               19.995 |                             20.000 |     32.004 |     79.301 |         79.301 |                       79.314 |         32.004 |                       32.000 |    89.9999 |                  89.9999 |        0.000000928 |       -0.000000024 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|   seq_num |       time | tomo_stage_finey_top | tomo_stage_finey_top_user_setpoint |      lab_x |      lab_z | real_finex_top | real_finex_top_user_setpoint | real_finez_top | real_finez_top_user_setpoint | real_theta | real_theta_user_setpoint | current_preamp_ch0 | current_preamp_ch2 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|        50 | 20:38:22.8 |               19.994 |                             20.000 |     40.002 |     79.289 |         79.289 |                       79.301 |         40.002 |                       40.000 |    89.9999 |                  89.9999 |        0.000000924 |       -0.000000024 |
|        51 | 20:38:24.4 |               19.994 |                             20.000 |     47.999 |     79.277 |         79.277 |                       79.289 |         47.999 |                       48.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
|        52 | 20:38:25.8 |               19.996 |                             20.000 |     55.999 |     79.266 |         79.266 |                       79.277 |         55.999 |                       56.000 |    89.9999 |                  89.9999 |        0.000000918 |       -0.000000024 |
|        53 | 20:38:27.3 |               19.996 |                             20.000 |     63.998 |     79.255 |         79.255 |                       79.266 |         63.998 |                       64.000 |    89.9999 |                  89.9999 |        0.000000919 |       -0.000000024 |
|        54 | 20:38:28.7 |               19.996 |                             20.000 |     71.999 |     79.245 |         79.245 |                       79.255 |         71.999 |                       72.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        55 | 20:38:30.4 |               19.995 |                             20.000 |     80.001 |     79.234 |         79.234 |                       79.245 |         80.001 |                       80.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
generator outer_product_scan ['544a67'] (scan num: 135)
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... giving up.
Out[20]: ['544a6792-fafd-4031-b712-4fbd854d2932']

BlueSky [21]: hr2dxrf_scanplan = OuterProductAbsScanPlan(det, tomo_stage.finey_top, 0, 20, 5, tomo_lab.lab_x, 0, 80, 11, True)

BlueSky [22]: hr2dxrf_scanplan = bp.subs_wrapper(hr2dxrf_scanplan, livecallbacks)

BlueSky [23]: gs.RE(hr2dxrf_scanplan)
At least one suspender is tripped. Execution will begin when all suspenders are ready.
Suspending....To get prompt hit Ctrl-C twice to pause.
At least one suspender is tripped. Execution will begin when all suspenders are ready.
Suspending....To get prompt hit Ctrl-C twice to pause.
At least one suspender is tripped. Execution will begin when all suspenders are ready.
Suspending....To get prompt hit Ctrl-C twice to pause.
At least one suspender is tripped. Execution will begin when all suspenders are ready.
Suspending....To get prompt hit Ctrl-C twice to pause.
At least one suspender is tripped. Execution will begin when all suspenders are ready.
Suspending....To get prompt hit Ctrl-C twice to pause.
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|   seq_num |       time | tomo_stage_finey_top | tomo_stage_finey_top_user_setpoint |      lab_x |      lab_z | real_finex_top | real_finex_top_user_setpoint | real_finez_top | real_finez_top_user_setpoint | real_theta | real_theta_user_setpoint | current_preamp_ch0 | current_preamp_ch2 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|         1 | 20:39:11.2 |               -0.007 |                              0.000 |      0.002 |     79.222 |         79.222 |                       79.235 |          0.003 |                        0.001 |    90.0004 |                  90.0004 |        0.000000931 |       -0.000000024 |
|         2 | 20:39:12.7 |               -0.007 |                              0.000 |      8.005 |     79.211 |         79.211 |                       79.222 |          8.006 |                        8.001 |    90.0004 |                  90.0004 |        0.000000938 |       -0.000000024 |
|         3 | 20:39:14.1 |               -0.006 |                              0.000 |     16.008 |     79.199 |         79.199 |                       79.211 |         16.008 |                       16.001 |    89.9999 |                  90.0004 |        0.000000938 |       -0.000000024 |
|         4 | 20:39:15.7 |               -0.006 |                              0.000 |     24.002 |     79.187 |         79.187 |                       79.199 |         24.003 |                       24.000 |    90.0004 |                  89.9999 |        0.000000938 |       -0.000000024 |
|         5 | 20:39:17.3 |               -0.006 |                              0.000 |     32.005 |     79.173 |         79.173 |                       79.187 |         32.005 |                       32.001 |    89.9999 |                  90.0004 |        0.000000931 |       -0.000000024 |
|         6 | 20:39:18.9 |               -0.006 |                              0.000 |     40.001 |     79.160 |         79.160 |                       79.173 |         40.001 |                       40.000 |    89.9999 |                  89.9999 |        0.000000933 |       -0.000000024 |
|         7 | 20:39:20.4 |               -0.005 |                              0.000 |     47.999 |     79.148 |         79.148 |                       79.160 |         47.999 |                       48.000 |    89.9999 |                  89.9999 |        0.000000928 |       -0.000000024 |
|         8 | 20:39:21.8 |               -0.005 |                              0.000 |     55.999 |     79.138 |         79.138 |                       79.148 |         55.999 |                       56.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
|         9 | 20:39:23.3 |               -0.006 |                              0.000 |     63.997 |     79.126 |         79.126 |                       79.138 |         63.997 |                       64.000 |    89.9999 |                  89.9999 |        0.000000921 |       -0.000000024 |
|        10 | 20:39:24.7 |               -0.005 |                              0.000 |     72.000 |     79.114 |         79.114 |                       79.126 |         72.000 |                       72.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        11 | 20:39:26.4 |               -0.005 |                              0.000 |     80.002 |     79.103 |         79.103 |                       79.114 |         80.002 |                       80.000 |    89.9999 |                  89.9999 |        0.000000930 |       -0.000000024 |
|        12 | 20:39:27.7 |                4.996 |                              5.000 |     80.001 |     79.102 |         79.102 |                       79.114 |         80.001 |                       80.000 |    89.9999 |                  89.9999 |        0.000000928 |       -0.000000024 |
|        13 | 20:39:29.4 |                4.994 |                              5.000 |     71.998 |     79.090 |         79.090 |                       79.102 |         71.998 |                       72.000 |    89.9999 |                  89.9999 |        0.000000923 |       -0.000000024 |
|        14 | 20:39:30.9 |                4.995 |                              5.000 |     63.997 |     79.079 |         79.079 |                       79.090 |         63.997 |                       64.000 |    89.9999 |                  89.9999 |        0.000000931 |       -0.000000024 |
|        15 | 20:39:32.4 |                4.994 |                              5.000 |     55.998 |     79.067 |         79.067 |                       79.079 |         55.998 |                       56.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        16 | 20:39:33.8 |                4.994 |                              5.000 |     47.999 |     79.055 |         79.055 |                       79.067 |         47.999 |                       48.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        17 | 20:39:35.4 |                4.994 |                              5.000 |     40.000 |     79.043 |         79.043 |                       79.055 |         40.000 |                       40.000 |    89.9999 |                  89.9999 |        0.000000923 |       -0.000000024 |
|        18 | 20:39:36.9 |                4.994 |                              5.000 |     32.002 |     79.030 |         79.030 |                       79.043 |         32.002 |                       32.000 |    89.9999 |                  89.9999 |        0.000000928 |       -0.000000024 |
|        19 | 20:39:38.4 |                4.993 |                              5.000 |     24.004 |     79.017 |         79.017 |                       79.030 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000928 |       -0.000000024 |
|        20 | 20:39:39.9 |                4.994 |                              5.000 |     16.004 |     79.005 |         79.005 |                       79.017 |         16.004 |                       16.000 |    89.9999 |                  89.9999 |        0.000000931 |       -0.000000024 |
|        21 | 20:39:41.4 |                4.993 |                              5.000 |      8.003 |     78.994 |         78.994 |                       79.005 |          8.003 |                        8.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        22 | 20:39:42.8 |                4.993 |                              5.000 |      0.002 |     78.981 |         78.981 |                       78.994 |          0.002 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        23 | 20:39:44.0 |                9.994 |                             10.000 |      0.002 |     78.981 |         78.981 |                       78.994 |          0.002 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        24 | 20:39:45.6 |                9.994 |                             10.000 |      8.005 |     78.969 |         78.969 |                       78.981 |          8.005 |                        8.000 |    89.9999 |                  89.9999 |        0.000000934 |       -0.000000024 |
|        25 | 20:39:47.1 |                9.994 |                             10.000 |     16.004 |     78.959 |         78.959 |                       78.969 |         16.004 |                       16.000 |    89.9999 |                  89.9999 |        0.000000934 |       -0.000000024 |
|        26 | 20:39:48.6 |                9.995 |                             10.000 |     24.004 |     78.948 |         78.948 |                       78.959 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        27 | 20:39:50.0 |                9.995 |                             10.000 |     32.004 |     78.935 |         78.935 |                       78.948 |         32.004 |                       32.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        28 | 20:39:51.6 |                9.994 |                             10.000 |     40.000 |     78.923 |         78.923 |                       78.935 |         40.000 |                       40.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        29 | 20:39:53.2 |                9.995 |                             10.000 |     47.999 |     78.909 |         78.909 |                       78.923 |         47.999 |                       48.000 |    89.9999 |                  89.9999 |        0.000000915 |       -0.000000024 |
|        30 | 20:39:54.6 |                9.995 |                             10.000 |     55.999 |     78.896 |         78.896 |                       78.909 |         55.999 |                       56.000 |    89.9999 |                  89.9999 |        0.000000915 |       -0.000000024 |
|        31 | 20:39:56.1 |                9.995 |                             10.000 |     63.997 |     78.885 |         78.885 |                       78.896 |         63.997 |                       64.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        32 | 20:39:57.6 |                9.995 |                             10.000 |     71.999 |     78.873 |         78.873 |                       78.885 |         71.999 |                       72.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        33 | 20:39:59.1 |                9.995 |                             10.000 |     80.002 |     78.862 |         78.862 |                       78.873 |         80.002 |                       80.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        34 | 20:40:00.5 |               14.997 |                             15.000 |     80.002 |     78.862 |         78.862 |                       78.873 |         80.002 |                       80.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        35 | 20:40:02.0 |               14.996 |                             15.000 |     71.998 |     78.851 |         78.851 |                       78.862 |         71.998 |                       72.000 |    89.9999 |                  89.9999 |        0.000000923 |       -0.000000024 |
|        36 | 20:40:03.6 |               14.996 |                             15.000 |     63.996 |     78.840 |         78.840 |                       78.851 |         63.996 |                       64.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
|        37 | 20:40:05.3 |               14.996 |                             15.000 |     55.998 |     78.828 |         78.828 |                       78.840 |         55.998 |                       56.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
|        38 | 20:40:06.8 |               14.996 |                             15.000 |     47.998 |     78.816 |         78.816 |                       78.828 |         47.998 |                       48.000 |    89.9999 |                  89.9999 |        0.000000915 |       -0.000000024 |
|        39 | 20:40:08.2 |               14.996 |                             15.000 |     40.000 |     78.803 |         78.803 |                       78.816 |         40.000 |                       40.000 |    89.9999 |                  89.9999 |        0.000000915 |       -0.000000024 |
|        40 | 20:40:09.7 |               14.995 |                             15.000 |     32.002 |     78.790 |         78.790 |                       78.803 |         32.002 |                       32.000 |    89.9999 |                  89.9999 |        0.000000925 |       -0.000000024 |
|        41 | 20:40:11.1 |               14.995 |                             15.000 |     24.002 |     78.777 |         78.777 |                       78.790 |         24.002 |                       24.000 |    89.9999 |                  89.9999 |        0.000000923 |       -0.000000024 |
|        42 | 20:40:12.7 |               14.993 |                             15.000 |     16.004 |     78.765 |         78.765 |                       78.777 |         16.004 |                       16.000 |    89.9999 |                  89.9999 |        0.000000923 |       -0.000000024 |
|        43 | 20:40:14.3 |               14.994 |                             15.000 |      8.003 |     78.754 |         78.754 |                       78.765 |          8.003 |                        8.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        44 | 20:40:15.8 |               14.994 |                             15.000 |      0.002 |     78.742 |         78.742 |                       78.754 |          0.002 |                       -0.000 |    89.9999 |                  89.9999 |        0.000000929 |       -0.000000024 |
|        45 | 20:40:17.2 |               19.994 |                             20.000 |      0.001 |     78.742 |         78.742 |                       78.754 |          0.002 |                       -0.000 |    90.0004 |                  89.9999 |        0.000000931 |       -0.000000024 |
|        46 | 20:40:18.6 |               19.995 |                             20.000 |      8.006 |     78.731 |         78.731 |                       78.742 |          8.007 |                        8.001 |    90.0004 |                  90.0004 |        0.000000931 |       -0.000000024 |
|        47 | 20:40:20.1 |               19.995 |                             20.000 |     16.005 |     78.719 |         78.719 |                       78.731 |         16.005 |                       16.001 |    89.9999 |                  90.0004 |        0.000000928 |       -0.000000024 |
|        48 | 20:40:21.6 |               19.994 |                             20.000 |     24.004 |     78.707 |         78.707 |                       78.719 |         24.004 |                       24.000 |    89.9999 |                  89.9999 |        0.000000926 |       -0.000000024 |
|        49 | 20:40:23.0 |               19.997 |                             20.000 |     32.003 |     78.696 |         78.696 |                       78.707 |         32.003 |                       32.000 |    89.9999 |                  89.9999 |        0.000000920 |       -0.000000024 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|   seq_num |       time | tomo_stage_finey_top | tomo_stage_finey_top_user_setpoint |      lab_x |      lab_z | real_finex_top | real_finex_top_user_setpoint | real_finez_top | real_finez_top_user_setpoint | real_theta | real_theta_user_setpoint | current_preamp_ch0 | current_preamp_ch2 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
|        50 | 20:40:24.4 |               19.994 |                             20.000 |     39.999 |     78.684 |         78.684 |                       78.696 |         39.999 |                       40.000 |    89.9999 |                  89.9999 |        0.000000921 |       -0.000000024 |
|        51 | 20:40:26.0 |               19.996 |                             20.000 |     47.999 |     78.672 |         78.672 |                       78.684 |         47.999 |                       48.000 |    89.9999 |                  89.9999 |        0.000000912 |       -0.000000024 |
|        52 | 20:40:27.4 |               19.997 |                             20.000 |     56.000 |     78.660 |         78.660 |                       78.672 |         56.000 |                       56.000 |    89.9999 |                  89.9999 |        0.000000912 |       -0.000000024 |
|        53 | 20:40:28.9 |               19.996 |                             20.000 |     63.996 |     78.648 |         78.648 |                       78.660 |         63.996 |                       64.000 |    89.9999 |                  89.9999 |        0.000000916 |       -0.000000024 |
|        54 | 20:40:30.4 |               19.996 |                             20.000 |     71.999 |     78.637 |         78.637 |                       78.648 |         71.999 |                       72.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
|        55 | 20:40:31.9 |               19.996 |                             20.000 |     80.001 |     78.625 |         78.625 |                       78.637 |         80.001 |                       80.000 |    89.9999 |                  89.9999 |        0.000000922 |       -0.000000024 |
+-----------+------------+----------------------+------------------------------------+------------+------------+----------------+------------------------------+----------------+------------------------------+------------+--------------------------+--------------------+--------------------+
generator outer_product_scan ['08190c'] (scan num: 136)
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... giving up.
Out[23]: ['08190c53-ac31-44b8-b629-4a69a66caa49']

If you move the other positioner explicitly to a position prior to the scan, it should respect that. Otherwise, it has no idea where you want it to be and uses the calculated position.
See the target property of PseudoSingle:
https://github.com/NSLS-II/ophyd/blob/master/ophyd/pseudopos.py#L90
It gets set in move: https://github.com/NSLS-II/ophyd/blob/master/ophyd/pseudopos.py#L144
To change it back to following the calculated value, use pos.sync()

Thanks. @klauer , @tacaswell , @danielballan , what is your recommendation in moving a single axis as part of a master plan? This is for both setting the fine z plus rotating to a new theta as part of the tomography plan. It'll look something like:
def tomo_proj(xxx):
    #collecting one projection
    MOVE_FINE_Z_TO_INITIATE_ITS_POSITION
    hr2dxrf_scanplan = OuterProductAbsScanPlan(det, tomo_stage.finey_top, ystart, ystop, ynumstep+1, tomo_lab.lab_x, xstart, xstop, xnumstep+1, True, md=md)
    hr2dxrf_scanplan = bp.subs_wrapper(hr2dxrf_scanplan, livecallbacks)
    scaninfo = yield from hr2dxrf_scanplan
    return scaninfo

def tomo_xrf(xxx):
    for theta_setpt in theta_traj():
        MOVE_THETA
        tomo_proj

I can do one of the following:

mov(positioner)
yield from list_scan([], positioner, [setpt])

Or, is there an equivalent of 'mov' function in the existing plan?
I've already tried abs_set:
BlueSky [30]: tomo_move_plan= abs_set(tomo_stage.theta, -85, wait = True)
BlueSky [31]: gs.RE(tomo_move_plan)

But the positioner motion was stopped before it reached the target position.
The other two methods (mov, list_scan) would wait for the motion to complete before continuing.

Using abs_set with wait=True in your custom plan should be the right solution here. I'm not sure why you're seeing any different results from the other methods, as they all rely on the same movement mechanism.

Thanks a lot @klauer! I still cannot get abs_set to behave the same.
For now I'm using the list_scan and just give one single position in the list as a work around.
Perhaps we should look into this at a later time.

That's a clever use of list_scan. Can you show us the plan with abs_set  that isn't working?

Here is what I've tried

tomo_stage.theta:

BlueSky [30]: tomo_move_plan= abs_set(tomo_stage.theta, -85, wait = True)
BlueSky [31]: gs.RE(tomo_move_plan)

hf_stage.x

BlueSky [17]: hfx_move_plan= abs_set(hf_stage.x, 5, wait = True)
BlueSky [18]: gs.RE(hfx_move_plan)

In both cases, they behave the same:
The setpoint changed according to the value given int the plan,
motor moved for a (very) short time,
move stopped almost immediately before reaching the targetting position,
and then setpoint changed to the current position.
For comparison, I've tested positioner.move(xx) functions which work just as expected for both positioners listed above.
We have a work around using list_scan so it it not super urgent; but I suppose it's good to have it resolved/understood.

Thanks for this useful report. These motors seems to be returning status objects that report that they are done when they are not actually done.
mov works by polling ("Are you done yet? Are you done yet?") whereas abs_set waits for the device to notify the RunEngine that it is done. Normally these two mechanism should always agree. I suspect a problem with the class definition for these objects.

Are these the same motors that were not working earlier?

Closing since there has been no action for more than a year. Please re-open if this is actionable.


New sample script: SPO simple site setup script

Hi👋
Idea 💡
I was thinking of a sample script that creates a site with some generic list or/and document library, adding some columns, modifying some navigation etc. Usually for provisioning I suppose the best is always to go with PnP provisioning 😉 but sometimes, somewhere, someone is always looking for this small script to go step by step with creating a site with some asset for some requirements- like a setup script for some solution/project/requirement/other. I also use this kind of setup scripts in some small projects (usually I go with PnP PowerShell but this time I went with m365 cli to try it out) so I was thinking to do something like this as a sample, but just simpler and more step by step 🤔
Do you think it makes sense?

Docs

Author
Adam (me I guess/ if possible 🤔)

Original Post
no post.. just an idea 😉

Description
small setup script to create a site + with list/s  + with adding some column/s + modifying view/s + modifying navigation  + with adding SP group (not sure if this is possible 🤔.. didn't see the command like spo group add 😉)

Keywords
SharePoint Online

Great idea! Let's do it!

If you're missing a specific command, feel free to create an issue. We'll spec it out together and try to implement it asap to get you unblocked.

ok PR opened 👍 ... I hope it was/is what you expected 😉.
Anyway while creating it I had one problem and noticed some small mistakes/improvements which could be good for separate issues (I think I could even take them if possible 🤔)
🐞 problem I had
I ma having some strange issue when adding a site column to an existing content type 🤔. The error is
Error: ' ' is an unexpected token. The expected token is '>'. Line 1, position 255.

It seems I ma doing everything as specified 🤔.. but probably I am doing something wrong 😉. Any tip is more than welcome 👍
In order to reproduce the problem we may execute the fallowing
> $field = m365 spo field add --webUrl "https://tenanttocheck.sharepoint.com/sites/setupTestSite11" --xml "<Field ID='{DAA84CE2-85B2-43AD-A06F-C6311E7D5E6B}' Type='Text' Name='SampleTextColumn' DisplayName='Sample Text Column' Required='FALSE' SourceID='http://schemas.microsoft.com/sharepoint/v3' StaticName='SampleTextColumn' FromBaseType='TRUE' />" --output 'json'
> $contentType = m365 spo contenttype add --webUrl "https://tenanttocheck.sharepoint.com/sites/setupTestSite11" --name "test" --id  "0x01007926A45D687BA842B947286090B8F67D" --group "test" --output 'json'
> $contentType = m365 spo contenttype get --webUrl "https://tenanttocheck.sharepoint.com/sites/setupTestSite11" --id "0x01007926A45D687BA842B947286090B8F67D" --output 'json'
> $field = $field | ConvertFrom-Json
> $contentType = $contentType | ConvertFrom-Json
> $fieldId = $field.Id
> $contentTypeId = $contentType.StringId
> m365 spo contenttype field set --webUrl "https://tenanttocheck.sharepoint.com/sites/setupTestSite11" --contentTypeId $contentTypeId --fieldId $fieldId --required false

💡 Some things I noticed when creating the sample (possible good candidates for improvements)

in the spo list set spec (https://pnp.github.io/cli-microsoft365/cmd/spo/list/list-set/) I think there is a small issue where in the  example we have allowContentTypes setting but it is actually contentTypesEnabled setting
the m365 spo contenttype add does not seem to output the content type json object, like most other add commands do 🤔. Need to do get to get it
could be a good feature to get content type by name instead of id (but I guess nowadays ct are not used so much 😉)
the spo site add (https://pnp.github.io/cli-microsoft365/cmd/spo/site/site-add/) seems to have a description setting but the spo site set doesn't (https://pnp.github.io/cli-microsoft365/cmd/spo/site/site-set/)

Awesome! Like I mentioned in the PR, let's create separate issue for each finding. That would help us to process them and fix if need be. Thanks again!

ok all added as separate issues 👍. I hope I added them properly 🤔... sorry in advance if I didn't fallow some of the standards 😉 I will try to improve 😋.
I didn't want to be the person that just adds issues and waits 😋 so if there are no volunteers I could try to do them all (but please consider that I could be not the fastest person for the task 😉).
And what about the problem I had with adding the field to the content type 🤔. Should I add a separate issue for that as well? or this will be fallowed with my PR?

You've done a great job 👏 Let's create a separate issue for the problem with adding field to content type as we should definitely look at it and having it separate will help us ensure that we won't lose track of it. Appreciate your help! 👏

sure... will try to add this today in the afternoon 😉

added #2337

the related bug was resolved.. the related RP #2353 I think is ready to be merged 🤔