Disable-WindowsOptionalFeature has no counterpart to Enable-WindowsOptionalFeature

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Installed version is PowerShell-7.3.0-rc.1-win-x64.msi.
Enable the feature using PowerShell 7. You will notice it works:
PS C:\Windows> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Do you want to restart the computer to complete this operation now?
[Y] Yes  [N] No  [?] Help (default is "Y"):

Now try to disable it from same PowerShell, you will notice it does not work with either option:
PS C:\Windows> Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Disable-WindowsOptionalFeature: A parameter cannot be found that matches parameter name 'All'.
PS C:\Windows> Disable-WindowsOptionalFeature -Offline -FeatureName Microsoft-Hyper-V -All
Disable-WindowsOptionalFeature: A parameter cannot be found that matches parameter name 'Offline'.

Expected behavior
`Disable-WindowsOptionalFeature` should undo all the changes made by `Enable-WindowsOptionalFeature` or at least the `Offline` feature should instead.

Actual behavior
The Microsoft official website does not explain or link on how to undo the change, apparently it's only one-way:
[url=https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/]Hyper-V on Windows 10[/url]

Error details
No response
Environment data
$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.7
PSEdition                      Core
GitCommitId                    7.2.7
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Visuals
No response

This cmdlet is not part of PowerShell 7.  Per their docs the switches you are trying to use don't exist: https://learn.microsoft.com/en-us/powershell/module/dism/disable-windowsoptionalfeature?view=windowsserver2022-ps

That's the problem, that doesn't exist.

That's the problem, that doesn't exist.

@superbonaci  - the module which contains these commands is owned by Windows, not by the PowerShell 7 language.
I can't test on the machine I'm posting from,  but my memory ( from doing this a lot, but  quite some time ago) is that removing the parent feature removed all the children so there is no need for -all . If I'm mis-remembering and the child features do need their own calls to disable-  then the inconsistency should be fixed, but it can't be fixed here

whatever


flutter run crashes with INSTALL_FAILED_UPDATE_INCOMPATIBLE

On Linux, using Android emulator.
git clone git@github.com:flutter/flutter.git
cd flutter
bin/flutter
cd examples/hello_world
../../bin/flutter packages get
../../bin/flutter run lib/main.dart

Launching lib/main.dart on Android SDK built for x86 64 in debug mode...
Running 'gradle assembleDebug'...                    20.6s
Built build/app/outputs/apk/app-debug.apk (21.5MB).
Installing build/app/outputs/apk/app.apk...
Failed to install build/app/outputs/apk/app.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package io.flutter.examples.HelloWorld signatures do not match the previously installed version; ignoring!]

Oops; flutter has exited unexpectedly: "Exit code 1 from: /usr/local/google/home/skybrian/software/android/platform-tools/adb -s emulator-5554 install -r build/app/outputs/apk/app.apk".
Sending crash report to Google.
Crash report sent (report ID: f2598419e0000000)
Crash report written to /usr/local/google/home/skybrian/tmp/flutter/examples/hello_world/flutter_01.log;
please let us know at https://github.com/flutter/flutter/issues.

I tried another emulated device I had hanging around (nexus 4) and got the same result. A brand new emulated device does work, though.

When it does launch, it seems to be taking longer, too.

Can you add the output of flutter doctor?  I'm surprised it's saying Android SDK built for x86 64 but maybe that's expected?  I would have expected to see it say ARM in there, but maybe it's talking about the SDK binaries not the target type.
FYI @jason-simmons

$ bin/flutter doctor
[✓] Flutter (on Linux, channel master)
    • Flutter at [redacted]/tmp/flutter
    • Framework revision 18d69b1b3e (3 hours ago), 2017-04-05 16:25:20 -0700
    • Engine revision 5d9a642257
    • Tools Dart version 1.23.0-dev.11.5

[✓] Host Executable Compatibility
    • Downloaded executables execute on host

[✓] Android toolchain - develop for Android devices (Android SDK 25.0.2)
    • Android SDK at [redacted]/software/android
    • Platform android-25, build-tools 25.0.2
    • ANDROID_HOME =[redacted]/software/android
    • Java binary at: /opt/android-studio-with-blaze-2.2/jre/bin/java
    • Java version: OpenJDK Runtime Environment (build 1.8.0_76-release-b03)

[✓] Android Studio (version 2.2)
    • Android Studio at /opt/android-studio-with-blaze-2.2
    • Gradle version 2.14.1
    • Java version: OpenJDK Runtime Environment (build 1.8.0_76-release-b03)

[-] IntelliJ IDEA Community Edition (version 2016.3)
    • Dart plugin not installed; this adds Dart specific functionality.
    • Flutter plugin not installed; this adds Flutter specific functionality.
    • For information about managing plugins, see
      https://www.jetbrains.com/help/idea/managing-plugins.html

[✓] IntelliJ IDEA Community Edition (version 2017.1)
    • Dart plugin version 171.4006
    • Flutter plugin version 12.1

[-] WebStorm (version 10)
    • Flutter plugin not installed; this adds Flutter specific functionality.
    • For information about managing plugins, see
      https://www.jetbrains.com/help/idea/managing-plugins.html

[✓] IntelliJ IDEA Ultimate Edition (version 2016.3)
    • Dart plugin version 163.13137
    • Flutter plugin version 12.0

[✓] Connected devices
    • Android SDK built for x86 64 • emulator-5554 • android-x64 • Android 7.0 (API 24) (emulator)

Thanks.  https://github.com/flutter/flutter/issues/2898 suggests that we currently do built for x86-64 emulators, but that knowledge may also be old. :/

When was the previous version of your app built and installed on the emulated device?  Does it predate Flutter's use of Gradle to build APKs?
If the app is sufficiently old, you may need to uninstall it manually before installing a new build.

I don't know the exact timing, but that seems quite likely. If it's a just a one-time thing, I can recreate the emulated devices and move on.

@skybrian (and others that may hit this), the quicker fix is simply to uninstall the app from the emulator (either by longpressing on it's shortcut, or via settings > apps).
That being said, I'm puzzled you hit this; supposedly we fixed this in https://github.com/flutter/flutter/issues/8172.

Good to know. I haven't seen it since then, so I'll close this.

I am getting the same problem though I am running it on the real device, I created a fresh project and run the command "flutter run" from the terminal.


#1639333451 Separate test dummy data

What does this PR do?

Separates office and party test data into separate modules
Description of Task to be completed?

[x] Move office test data into separate files
[x] Move party test data into separate files

How should this be manually tested?
After cloning the repository to your local machine - check README.md for instructions. Move to the repository directory and check out  ch-separate-dummy-data-1639333451. The test folder will have the test data dummy in separate modules.
Any background context you want to provide?
Makes the code more readable.
What are the relevant pivotal tracker stories?
#1639333451

Coverage remained the same at 100.0% when pulling e93e2c2fe27cb1590949a9f21651112faefd63e6 on ch-separate-dummy-data-1639333451 into 69c57849a2be1d0facb3586f4074d16d13cc40ac on develop.

Nice work.
Instead of having mock data being in the same folder as test. Create a folder called mock_data and place those mock data inside so that it can easily be identified.

Nice work.
Instead of having mock data being in the same folder as test. Create a folder called mock_data and place those mock data inside so that it can easily be identified.

Moved the test data to test_diretory


Footer

when creating or editing contest, the footer still block the content.
the footer appears when user is at the bottom of the page, but this will block the content.
Maybe at bottom, the footer should disappear, and at other place, the footer is shown.
The solution two I can think of, is that we can fix the footer right beneath the content.
So that it won't block in any situation. But this conficts with current design.

Well, I want to know that this issue occurs in which branch.
I will test and figure out this problem later.

in bruce/dev

Your idea is good.
I rewrite the css to fix footer beneath the content.
Please test my latest commit, and give me a feedback whatever it is subject to revision or not.

Thanks hydai, it won't block anything now. thanks!


Subscriptions are not terminated on the client when the maxInterval expires

Problem
This got broken by #20080.
In RefreshLivenessCheckTimer we used to do:
System::Clock::Timeout timeout = System::Clock::Seconds16(mMaxInterval) + mExchange->GetSessionHandle()->GetAckTimeout();

but this got changed to:
        VerifyOrReturnError(mReadPrepareParams.mSessionHolder, CHIP_ERROR_INCORRECT_STATE);
        timeout = System::Clock::Seconds16(mMaxInterval) + mReadPrepareParams.mSessionHolder->GetAckTimeout();

When not doing resubscription, mReadPrepareParams doesn't contain anything, so that VerifyOrReturnError always fails.  But nothing ever checks the return value of RefreshLivenessCheckTimer, so we proceed with things.  The timer is not scheduled, and if we never hear back from the other side we don't treat that as a subscription failure.
Proposed Solution

Add tests that would have caught this problem.  It's fairly surprising that we don't have any.
Figure out whether callers should be checking the return value of RefreshLivenessCheckTimer.  If not, it should return void.
Decide whether lack of a session here should lead to an immediate Close call, just like failure to schedule a timer does.
Figure out where the session should be coming from here:

Possibly we should go back to using the exchange (since all the non-test calls to this function do in fact have an exchange), and if we need OverrideLivenessTimeout to work we can fall back to the read prepare params if there is no exchange.
As above, but change OverrideLivenessTimeout to just take a session as argument.
Another option would be to always store the session in mReadPrepareParams, even when we're not doing auto-resubscription.  But then we'd also want to update it any time we get a message, because the incoming message may not be on the session we sent the original subscribe on.  In fact, that session could be long-gone even as we're getting messages from the server on a different session, so getting a session from mReadPrepareParams is just not at all reliable.

@mrjerryjohns @yunhanw-google

Add tests that would have caught this problem. It's fairly surprising that we don't have any.

I'm surprised too. Will add.

Figure out whether callers should be checking the return value of RefreshLivenessCheckTimer. If not, it should return void.

There's clearly precedence for calling Close() to handle errors in there, so we should be using that and switching this to void.

Possibly we should go back to using the exchange (since all the non-test calls to this function do in fact have an exchange), and if we need OverrideLivenessTimeout to work we can fall back to the read prepare params if there is no exchange.

That would make OverrideLivenessTimeout not usable in a capacity where re-subs are disabled.

As above, but change OverrideLivenessTimeout to just take a session as argument.

This seems onerous, especially when the session info could already be made available in private state.

Another option would be to always store the session in mReadPrepareParams, even when we're not doing auto-resubscription. But then we'd also want to update it any time we get a message, because the incoming message may not be on the session we sent the original subscribe on. In fact, that session could be long-gone even as we're getting messages from the server on a different session, so getting a session from mReadPrepareParams is just not at all reliable.

Yes, this is what I'm leaning to.

There's clearly precedence for calling Close() to handle errors in there, so we should be using that and switching this to void.

I take that back - it should return an error, since it's being called during various inbound message processing flows where the final closure of the client object is handled somewhere else. The logic to call Close() within that method should be removed, and moved up to OverrideLiveness...


[Spring-Cloud] Update API version to 2022-01-01-preview

Description
This PR upgrades the commands who use "preview" API version to switch to the latest preview API version. Because the 2022-01-01-preview is the only API version to support the Enterprise sku. As 2022-01-01-preview API version introduces some breaking changes since last preview API version. This PR also address these breaking changes in API level, and keep consistency on command/arguments/response
This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

Spring-Cloud

@yuwzho, please summarize what you changed in description.

#4294


Chapter 10 fitting neural model - pandas has no attribute 'Series' error

In chapter 10 at the training and evaluating model, i run the code in my jupyter ('copy and paste'):
history = model.fit(X_train, y_train, epochs=30,
validation_data=(X_valid, y_valid))
It gives me - "AttributeError: module 'pandas' has no attribute 'Series'"
I cant understand why is this so, I've imported pandas and all, is there a package i need to install to solve this problem?
thanks,
tony

Solved: i updated anaconda all and it somehow removed Pandas from its env, had to reinstall pandas in anaconda env.


Cannot package any win32 apps on Mac OSX, fails with ENOENT no such file error

electron-packager version 5.1.0  is installed globally, and although it can create Darwin builds successfully, any win32 builds fail in the same way:
$ electron-packager ./ myapp --platform=win32 --arch=x64 --version=0.32.1
Downloading electron-v0.32.1-win32-x64.zip
[============================================>] 100.0% of 48.76 MB (851.72 kB/s)
Packaging app for platform win32 x64 using electron v0.32.1
[ { [Error: ENOENT: no such file or directory, mkdir '/var/folders/cv/fm6v8wqs5nv_nj03hhjm__vdldthvd/T/electron-packager/win32-x64/myapp-win32-x64/resources/app']
    errno: -2,
    code: 'ENOENT',
    syscall: 'mkdir',
    path: '/var/folders/cv/fm6v8wqs5nv_nj03hhjm__vdldthvd/T/electron-packager/win32-x64/myapp-win32-x64/resources/app' } ] undefined

This is the same issue as #133

Closing, since this is a duplicate.


fix(map): improve hasId check to not use any

Close #7653. There might be other problems in the module if objects without id fields are coming out of useQuery, but this will fix the immediate error that occurs within hasId.

Closing in favor of https://github.com/dxos/dxos/pull/7658


Migrate to 1.21 version of the docker remote API

As I have the intention to use docker and this gem heavily, I would like to use the latest version of the docker api.
Is someone already migrating this gem to be compatible with the latest docker API version ? If not, I volunteer to do it. I read your TESTING.md but of course, any other guidelines on a good way to do it are welcome.
Thanks a lot,
Albin.

@AlbinOS is there something missing that you need? The docker API is incredibly loose, so it should just work.  I've considered just removing that from the URL since docker doesn't seem to care about it.

@tlunter, I would not say that I really miss something, it's more to be certain to be up to date with the docker API. Especially as I'm starting a new project right now, I would like to be as up to date as possible.
What I understood is that using 1.16 instead of 1.21 when calling the API may change the behavior. For example, when I read on the 1.21 docker remote api changelog page :

GET /info now lists engine version information

If we use /1.16/info instead of /1.21/info or /info (as it points to the latest version of the api to my understanding), we would receive different information right ?
For the moment, as you said, I have changed the version to 1.21 in my local gem and everything is working so far. I didn't run the test but I will do it to see if something breaks.

Usually, no, you wouldn't receive anything different.  Very rarely do they actually disable something if you're accessing with an old version which is why we haven't changed it since 1.16.

So, If I understand correctly, accessing 1.16 is the same as accessing 1.21 only with the guarantee that the changes made since 1.16 will not break anything ?
Let's assume that they change something on /info so much that any call made before would brake, they will then remove it from the /1.16/ route instead of leaving the older version accessible there ?
Sorry for the trivial question but I'm new with api design, thanks for you time.

@AlbinOS it's better to think that there is only 1 API, and that the version is just another signal should they want to special case something.  More often than not, anything they add will ignore the version number, so it shouldn't be an issue.  There hasn't been that much changing in the API since the beginning, you'll note that docker v1.3 clients actually work fine with docker v1.9.  In the event that they do make a change like that we'll want to bump the version, but using remote API v1.16 is good for now!

@tlunter, thanks for the explanation, I'll be more confident using the gem and the api now.


Add a graphical progress bar to the web ui

In the case of an unlimited duration run, the progress bar resets and continues until the run is cancelled.

I signed it!


Error instead of Panic

Currently go-ext4 panics on most of the errors paths. Think it would be worth returning an error (which the current code supports with return statements) so that client code can deal with the error as they like. Currently all errors returned from most functions are always nil.
This will allow flexibility in use. Client code can panic if they like or continue gracefully.

What is "errors paths"?
I'm not sure what you're referring to. The project is very strict in general and should only return a nil if no errors were encountered.

Please don't open issues unless you're able to cite specific examples.

What I meant by error path is the code paths it takes when errors occur.
For instance, the usage of
log.PanicIf(err)

whenever an error is encountered. It would panic the app.

Currently a function would either:

return with no error
or panic

I am suggesting it should

return with nil err when no error (like it does now)
return a non-nil err when error occurs. the error can document the cause of the error. Then the user has the flexibility to do what they want about it.

The top of each function also has defer-recover handling.
Read more about the "Defer-Recover-Panic" pattern in Go:
https://blog.golang.org/defer-panic-and-recover

It panics there too (after recovering). It uses log.Panic(err)

It would greatly simplify logic and work flow if we drop the panic recover model and simply return the errors.

The problem is that defer-recover-panic is good for also catching the errors that Go or unhandled errors that external libraries originate.. The errors that are caused due to failures that are outside of your control. It's simple enough if you know how it works. It makes sure that all panics are funneled down to a return value so that the caller can always check it. Things are simpler without it only until what you're doing gets more complicated, and then it becomes an indispensable safety net.
In additional, I have some error management that always makes sure that all non-primitive errors (e.g. io.EOF) always have a stacktrace attached to them. Even though Go-originated errors won't show a specific line-number where the error originated, we can guarantee that you'll at least be able to identify the function.
I've fixed the recover() blocks. That was a bug.

Heya,
Just wondering if you would consider a PR to re-write the error handling logic as:
if err := ...; err != nil {
  return fmt.Errorf("...context...: %v", err)
}

as opposed to panicking?
I get the desire to have a stack trace for each error, but it goes against Effective Go patterns + the overhead of defer is non-neglible for cpu-bound programs. That said, this is your project, so style conventions are your call.

I don't know if that's a reasonable argument. Please share a link supporting your claims.
The pattern is recommended in Effective Go right below where you shared and nowhere is there a footnote assigning a cost to defers. Ostensibly it can't be much more expensive than any other function call. That being the case, the current state of development encourages readability or reusability at the expense of a couple of extra cycles. The age when terse or indipherable programming ruled the land in the name of ultra-optimization to win every cycle we could was a long time ago. All systems are fast and cycles are abounding nowadays. No one is gonna argue for saving a couple of cycles (if what you say is true) by shaving a few defers.
The truth is that the panic-defer-recover pattern is there for a reason. It allows us to have a higher degree of control during both general operation and testing and a commensurate increase of quality as a result, which I happily embrace.

My point about performance is minor; I'm mostly a fan of error types for handling errors for their readability and convention properties. I agree that readability > performance in most cases.

Ostensibly it can't be much more expensive than any other function call.

Nack, defers are tracked in their own structure in each frame, so they can be unwound when the function returns or panics. For the same reason, defers can't be inlined. (I deleted the rest of the stuff I wrote here once I looked at the code, as its changed a lot recently).

Please share a link supporting your claims.

The relevant code is here and below (see newdefer). This is actually been optimized a lot since I last looked at it.
Previously, every defer issued a write barrier, and needed to check+grow the stack in a lot of cases due to the defer frames. This overhead had quite a performance hit on hot paths, and a quick Google shows theres a few blog posts also observing their performance hit.
Now, it looks like most simple defers (like yours, with no arguments) can be allocated on the nosplit stack, and write barriers are eliminated, so the performance should be a lot better (just the overhead of handling the defer structure and running it). A quick look suggests goreview/29656 & goreview/171758 are to thank. That said, this will still be wicked slow in really hot code paths due to the lack of inlining.

It allows us to have a higher degree of control during both general operation and testing

How?
In any case, how is
defer func(){
  if e := recover(); ... {
    ...
  }
}

if <errorcheck> {
  panic(thing)
}

meaningfully different from
if <errorcheck> {
   return nil, fmt.Errorf("context: %v", err)
}

The only upside I can see with the panic is the stack frame.


[Feature][core] Support spark/flink engine internally

Search before asking

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

Description
When deploying seatunnel job, we need install spark/flink environment first. I think we need new mechanism to let spark/flink build in.
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

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

Welcome @yx91490 ~

I have some discussions about the desgin:

suppose that most enterprise users have alread deployed their spark or flink, therefor we should integrate spark/flink optionally.
if we choose integrate spark/flink, the artifact package will be bigger,  maybe twice than ever, is this acceptable？
If we download spark/flink, I don't known is it allowed by asf?


fix config  /scan

fixes config for blockchain monitor / explorer
fixes scan's POST request.

Coverage increased (+0.01%) to 94.28% when pulling 89e39eed1630cddcc397a64beb5e6c98671e3d6d on matiu:bug/config into 611075f856a752ef5a35678f62e1c713d39f732e on bitpay:master.


Use Remote State to generate traces for Debug API

Closes: https://github.com/onflow/flow-evm-gateway/issues/530 https://github.com/onflow/flow-evm-gateway/issues/583
Description

For contributor use:

[x] Targeted PR against master branch
[x] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[x] Code follows the standards mentioned here.
[x] Updated relevant documentation
[x] Re-reviewed Files changed in the Github PR explorer
[x] Added appropriate labels

Closing in favor of: https://github.com/onflow/flow-evm-gateway/pull/635


Using socket programing to make bulk whois

This version let you get whois info of lots of ip address as soon as possible :)

Added file switch to define the ip list file
Became faster because of bulk mode and socket programing
less request = cleaner ip

Thanks Alins 👍


 This means the assembly gets built BEFORE these extra samples/utils - so they are not included ON THE FIRST RUN. On subsequent runs - ie in the developer's environment, they will be picked up on asecond run - albeit an old version ....
Of course the official build is clean every run, so the extra will always be missing
The fix should be to add the correct dependencies.

This brings up an interesting issue -- how exactly to express the right dependencies to ensure everything needed is built ready for assembly, and that other modules are then built using this assembly.
Most of our code is in open-metadata-implementation. However we also have some components under open-metadata resources, such open-metadata-archives (utilities for CIM information model etc), lab notebooks in open-metadata-labs & a series of samples in open-metadata-samples including for example the coco pharma security provider.
With the main assembly built, our docker image inserts this into the image.
The docker image themselves are then used by our helm charts and docker-compose
.. yet these modules themselves are under open-metadata-resources/open-metadata-deployment
Currently the assembly is not really dependent on anything, but happens to work. Simple adding dependencies on the obvious 'parent' pom is actually not sufficient - for example see https://stackoverflow.com/questions/11131575/build-order-of-maven-multimodule-project. The files were include are referenced by relative path to the assemblies directory (defeating the dependency mechanism)
One approach is to ensure that WHENEVER we include a file into the assembly, we must include the exact artifact that originates in -- not a parent , but the actual artifact as a dependency. It appears though the assembly descriptor already effectively supports this - see https://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html - we should be replacing file paths with module dependencies.
A slightly cleaner way may be to assume most things we build could contribute, and restructure so that a parent project does the assembly (and makes use of useAllReactorProjects as per https://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html), with all our implementation (+samples etc etc) as submodules. Docker images/charts would be out of that tree, but this is a significant rejigging of the directory structure. Even this has some challenges as per https://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries
I will look at refactoring the assembly to

detect errors if possible
define moduleSets per contributing dependency

I hope this will be the 'correct' way to let maven properly resolve dependencies and include just what is needed (without getting into circles unnecessarily). Unfortunately our structure is now complex enough that the initial incorrect useage is now breaking

Note - have split out corrections/improvements to the assembly we use for jupyter (notebooks) and the node based ui/presentation server to seperate issues as there are other factors to look at.
The changes for this issue will focus on the core egeria distribution.

On investigation it appears we are getting every dependency pulled in regardless of what modules are put in any directory of the distribution. Following up with maven team -> https://lists.apache.org/thread.html/r131e0699cb3d60763d0904425491924097168bb2de68da24bb5ddcb5%40<users.maven.apache.org>

Opened up another issue with maven: https://issues.apache.org/jira/browse/MASSEMBLY-940 - the dependencies being loaded are wrong. They should be base off a moduleSet (as best I can determine) NOT project.
Looking for alternatives.

I've looked again at how we might improve the maven based assembly particularly to any shorter term solutions
Without getting deep into maven and fixing/forking the assembly plugin or building a custom plugin, the assembly build is limited.
We can only pull in all assemblies from the POM level (of the assembly) or none. We cannot do moduleset specific including (ie dependencies of connectors in once place, clients in another, utilities in a third etc)
The maven download, dependency, build-helper plugins have some overlapping capabilities, but only work on a single module that is being built, there's no real way of doing aggregate changes/merges across a set of modules.
The 'provided' scope can help when building a single module as we can say 'that's ok - it's already in the platform', but since our modules can get used in different ways  and pulled in transitively it can be tricky to specify this correctly which is particularly tricky without extensive testing/validation of different components at least in terms of assembly structure & dependencies.
Ideally for example under server/lib we might want

to add our connectors
to include their dependencies
but skip any already built into the server chassis (since this is where they run)

Clients on the other hand need to be standalone  to we probably want

all clients
with all dependencies

We might conceive of other structures or common dirs, & building aggregate jars, but this flexibility doesn't seem possible.
There seem to be few options that can be done simply as a near term measure
a) Always create & use 'uber jars' for anything pluggable such as connectors, being used in an unknown way (clients), standalone (utilities etc). This probably has the least impact. We already build these jars, we just need to include them in artifacts, and then the assembly. Very little work and reliable at the expense of size/time
b) Have a general 'lib' directory into which we add ALL dependencies  - but this will be > 400 including duplication of server components. Again only minor change to the build/server to ensuring the correct LOADER_PATH is specified, but it would mean client/utility uses specifying classpath correctly or still using some uber jars. Overall not as simple. There is also a noteable additional impact on build time (5-10 minutes) in evaluating all the dependencies together due to their complexity
I plan to close this out persuing option a) if no comments follow so we can fix the initial issue
A possible medium term measure is to revisit packaging & dependency management across the product so that we focus more on standard 'packages' (we have some already, but don't use them, and they may be incomplete), and have a very clear perspective on which modules make up different 'platforms'. We then shift our dependencies away from fine-grained to this coarser grained level. We can then more easily make use of 'provided' scope for either common bundles or the server platform, and reduce the list of extra dependencies or increasing in size of uber jars. We might wish to do this alongside reviewing our overall build/packaging approach as it's likely to need more investment in experimentation and flexibility in our build. (see also #3371). (Note also that any changes here currently do quite increase build time.)
Or we may break the direct 1:1 mapping between the jars we build and our maven artifacts outside maven itself so that the 320+ do not get published - we won't have them. Instead we keep the 320+ source jars and assemble them on-demand as part of a build process into the more select 'package' type bundles that make sense. This also could address other process challenges but would depend on a radical change like #3371
So really More medium term more review of this area is needed & elaboration of the use caseswith a broader look across all artifacts (ie including docs) ie

Java developer building extensions to egeria or including in their tech - mostly maven driven
Someone deploying egeria - focussed on server/connectors & how to add additional ones
etc etc

I think that is best served by a fresh issue & analysis & being less concerned on any current technical constraints of the build process & more concerned on the end users. We can fix the near term issue here.

As per #3458 we will

drop clients
place all dependent jars into a common lib directory
include samples/utilities as uber jars

This has now been implemented. closing


dts: bindings: misc: nrf: Support disabling lfosc

The BICR LFOSC.LFXOCONFIG.MODE field supports disabling the usage of an external crystal oscillator to disable LFXO as LF clock source. This adds the enum to the binding, the rest of the codebase already supports the feature.
This is already supported in nrf-regtool here https://github.com/nrfconnect/nrf-regtool/commit/b23cdefbd0166b064fa946102b61bc6e097fd749

Please add:
nrf-squash! [nrf noup] dts: nordic: Add support for BICR generation
as the first line of the commit message body.

@anangl fixed, could you please check again? Corresponding sdk-nrf build is also green https://github.com/nrfconnect/sdk-nrf/pull/17098


Cross-compilation CI job

A CI job that cross-compiles wheels from the host and tests them on the target platform by exchanging wheel artifacts

macOS arm64 to amd64 (Xcode)

macOS amd64, arm64 to arm64, amd64 and vice versa (Zig) (doesn't currently work, related issue: https://github.com/ziglang/zig/issues/20689, regression in 0.13.0?)

macOS amd64, arm64 to Windows amd64, arm64, i686

macOS arm64 to Linux amd64, aarch64, ppc64le, s390x (amd64 excluded because arm64 runners are faster)

Windows amd64 to arm64, i686

Windows amd64 to macOS amd64, arm64

Windows amd64 to Linux amd64, aarch64 (ppc64le and s390x excluded since Docker containers needed to test)

Linux amd64 to arm64

Linux amd64 to macOS amd64, arm64

Linux amd64 to Windows amd64, arm64, i686

and so on (to be decided)

linux-s390x combo does not work (have to stick with native compilation for now)
# runtime/cgo
error: unknown target CPU 'generic'
note: valid target CPU values are: arch8, z10, arch9, z196, arch10, zEC12, arch11, z13, arch12, z14, arch13, z15, arch14, z16

while ppc64le, amd64, aarch64 are working as usual.

With #163 merged, this is now easier to configure (still no MUSL support at this time, however).


Can't extract in directory with brackets in directory name

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Execute :
Expand-Archive -Path "$ZIP_DIRECTORY$ZIP_NAME" -DestinationPath "C:$UNZIP_DIRECTORY[TEST]"
No problem with :
Expand-Archive -Path "$ZIP_DIRECTORY$ZIP_NAME" -DestinationPath "C:$UNZIP_DIRECTORY\TEST"
Expected behavior
Unzip in directory [TEST]

Actual behavior
New-Item: An item with the specified name C:\$UNZIP_DIRECTORY\[TEST] already exists.

Error details
New-Item: An item with the specified name C:\$UNZIP_DIRECTORY\[TEST] already exists.

Environment data
Win10 + Powershell 7.2

Visuals
No response

Related #12168 ##6232

Expand-Archive may need to have path parameters like LiteralPath to support what's asked in the issue.
@SteveL-MSFT can you please move the issue to the Archive repo?

@SteveL-MSFT looks like this issue can be moved to the Archive repo


Refactor

This PR

removes LatentGPs which has been moved to AbstractGPs.
Renames the package to NonConjugateGPs as suggested in #5
Fixes tests to be compatible with the new design of LatentGPs in AbstractGPs
Removes dependencies which are not necessary anymore

If the name "NonConjugateGPs" is not an issue for anyone, I will change the repository name too.
@devmotion @willtebbutt @theogf @yebai

What functionality are we actually planning to provide in this package? Just the likelihoods? Or approximate inference as well?
I'm also somewhat dubious about calling this "NonConjugateGPs" because I don't know what that means. i.e. what is a non-conjugate Gaussian process?

Fair enough I am so usee to the term that I forgot it is a very big shortcut. A non-conjugate GP is for me a Gaussian Process on which you do not apply a Gaussian likelihood.

If I understand correctly, all we need for non-Gaussian GPs is the likelihoods defined in this package along with the GP and LatentGPs given by AbstractGPs.
Am I right in saying LatentGP could be a non-Gaussian GP? Or is there some other component I am missing?
If this is true, the likelihoods defined in this package are quite generic and are not tied GPs in the way they are defined. LikelihoodFunctions.jl is probably an fair name to have.
However, our tests are from the context of GPs. Should we change this to be more generic? If we do, I am not sure what would be the right place add such GP related tests.

Maybe call this “GPML2” since it is a user-facing libraries? The digit in the name is to satisfy Julia package conventions.

I am also open to recycling the name “GPMLJ”, which is a good name, I think.

I quite dislike GPML(2/J) because it is very uninformative and anyway packages guidelines recommend to avoid acronyms.
If I understood correctly, we only want to have the likelihoods implemented in here but not the inference for it. IMHO the name LikelihoodFunctions is just super generic and maybe too much for our aim. How about simply GPLikelihoods.jl?

If I understood correctly, we only want to have the likelihoods implemented in here but not the inference for it. IMHO the name LikelihoodFunctions is just super generic and maybe too much for our aim. How about simply GPLikelihoods.jl?

GPLikelihoods.jl is something that I could get on board with -- it's clear that we're talking about likelihoods for GPs.

My feeling is that these likelihood functions will be highly intertwined with inference methods. So it might be hard to have something as clean as KernelFunctions.  If that’s the case, then a slightly more generic name that includes approximate inference might make sense.
I don't see why acronyms are bad, for example Stats, MCMC, GP are used ubiquitously.

I don't see why acronyms are bad, for example Stats, MCMC, GP are used ubiquitously.

They're not inherently bad -- to my mind descriptive names are just preferable because they're descriptive. You have to explain acronyms to people, and they can be easy to forget if they're not obvious.
For example, I could probably get on board with calling something GPML2 if it's doing something similar to GPML.
I could not get on board with calling something GPMLJ.jl, because the J is repeating information already present in the .jl. The fact that MLJ.jl does it does not mean that we should do it. Their naming decision was bad.

@willtebbutt Given what @yebai is saying it is not clear to me what is the aim for this package:
I understand that we want to provide functions to provide likelihoods compatible with the AbstractGPs framework and more generally with the Turing framework.
What I don't understand is: do we also want to provide inference for it? In my opinion opening Pandora's box as there are sooooo many ways to do inference for GPs...
I would then rather see an additional package namely "NonConjugateGPs" providing special inference methods as well as notebook examples on how to do this more "classically", i.e. use a Turing model and sample from it, or use AdvancedVI.jl etc...

Yeah. I was under the impression that this was going to be a place where we specify a bunch of likelihoods that are to be used with LatentGPs in AbstractGPs. The reason for keeping them separate being a concern about the dependencies that this package is likely to introduce.
I was under the impression that a separate "GPML"-like package was going to be the thing that ties this together for users.

Ok so let's make this democratic :)

:+1: NonConjugateGPs
:heart: GPLikelihoods
:laughing: LikelihoodFunctions
:tada: GPML2
:rocket: GPMLJ

I am happy with the GPLikelihoods name.
Still, I think it's prudent to develop the likelihood interface for a couple of weeks before embarking registration. See the reasoning below.

The reason for keeping them separate being a concern about the dependencies that this package is likely to introduce.

My feeling is that the need for a dedicated likelihood package is not big since a lot of the functionality exist in Distributions. The extra bits needed for GP are likely some user-friendly interfaces.  Therefore, the need for a separate package might fade if the likelihood types and methods can be sufficiently abstract. In that case, we can consider making an effort to avoid explicit dependence on heavy packages like Distributions. Then we can keep the generic likelihood types and methods inside the AbstractGPs package.
This is potentially better in the long run because it allows GP inference developers to extend this likelihood interface by importing the AbstractGPs package. For example, each inference method can be in its own package, providing inference specific extensions of likelihood functions. On top of that, we can have a user-facing library (similar to the GPML Matlab library, or GPFlow) that depends on AbstractGPs, KernelFunctions and various inference packages.


Wack a mole still points to youtube video

Repro steps:

Go to hour-of-code 2022 skillmap https://arcade.makecode.com/--skillmap#mole
Start the first tutorial
See YouTube video

YouTube is blocked in many schools, and this is not compliant. This needs to be point to the self-hosted azure media service videos.
Same in Bursting balloons skillmap.

I have it open right now, it's not YouTube, it's Azure.  You can tell because it has the "Pop out video" button.
Can you try again in a private browser?

This is the code that's checked in:

Oh caching. Tried in-private and it doesn't repro. Thanks for checking. Not an issue customer will face. Closing as no repro


gildas: add alternative url for the source code

Motivation for this change
For each new release, the upstream developers of Gildas move the source code of the previous release to a different directory. Add this directory to the list of url to avoid build failure at each new
release.
Please cherry-pick to 18.09 when merging.
/cc #45960
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build gildas

Success on x86_64-darwin (full log)
Attempted: gildas
Partial log (click to expand)
copying path '/nix/store/j81z6kp9b5q85v5xirv786q5lnzcv14g-libXcomposite-0.4.4' from 'https://cache.nixos.org'...
copying path '/nix/store/n8iam5q5wrsxvg8bfj9d9xg4pz5bg4db-gdk-pixbuf-2.36.12' from 'https://cache.nixos.org'...
copying path '/nix/store/a40rnybsv5lzvffsik7gzi9fcd8jywf5-libXcursor-1.1.15' from 'https://cache.nixos.org'...
copying path '/nix/store/sz4wl7sxw1q118hr5dkmvgrgi8wh3931-libXdamage-1.1.4' from 'https://cache.nixos.org'...
copying path '/nix/store/9gqbl1w4grib1llhy6zxax75zg499g2w-libXi-1.7.9' from 'https://cache.nixos.org'...
copying path '/nix/store/c1m7khqfg6ywk45lyc1frx0m9q02b0in-libXrandr-1.5.1' from 'https://cache.nixos.org'...
copying path '/nix/store/dban8pbd5zbzc3nqjkkky7lz3qm8v6n5-python-2.7.15-env' from 'https://cache.nixos.org'...
copying path '/nix/store/ak332hpkmnrbfsvr4702vk9n8xlgz5kj-gtk+-2.24.32' from 'https://cache.nixos.org'...
copying path '/nix/store/8ls62k9lm45ysy4yry5csy0czadm3nh8-gildas-20180801_a' from 'https://cache.nixos.org'...
/nix/store/8ls62k9lm45ysy4yry5csy0czadm3nh8-gildas-20180801_a

Success on x86_64-linux (full log)
Attempted: gildas
Partial log (click to expand)
copying path '/nix/store/wqaz7as6ka8az0af0ln6526mh5j3zpny-harfbuzz-1.8.8' from 'https://cache.nixos.org'...
copying path '/nix/store/lqvm9v7f5ah5wxhpwcx59h6hh1f3vigz-libusb-1.0.22' from 'https://cache.nixos.org'...
copying path '/nix/store/bphci20w7xm0h1mjghfg2r6m69q3zm39-python-2.7.15-env' from 'https://cache.nixos.org'...
copying path '/nix/store/c4gfdlr7lyn9nzqygaa8f6fkkaw565kd-avahi-0.7' from 'https://cache.nixos.org'...
copying path '/nix/store/2rafsmql17xfvd871zawrh3jsb4fgr4y-pango-1.42.1' from 'https://cache.nixos.org'...
copying path '/nix/store/gwk2iwphfpclvk44naqxbmwv1y91fp3w-cups-2.2.6-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/dxbr1z2syvfl23x5vgnwhfjpcbij6lig-cups-2.2.6' from 'https://cache.nixos.org'...
copying path '/nix/store/06d5gpdx7ix1i6lp8sj9i2i4s3vd6qd6-gtk+-2.24.32' from 'https://cache.nixos.org'...
copying path '/nix/store/mbpxj7kpl52k3syg2xcc1j6bh1fjsa7l-gildas-20180801_a' from 'https://cache.nixos.org'...
/nix/store/mbpxj7kpl52k3syg2xcc1j6bh1fjsa7l-gildas-20180801_a

Success on aarch64-linux (full log)
Attempted: gildas
Partial log (click to expand)
these paths will be fetched (15.11 MiB download, 206.70 MiB unpacked):
  /nix/store/1a4qy9vygrh7c08a2xh9arw3lpivyi3d-python-2.7.15-env
  /nix/store/49bcdnkv34fsm7kriyns3lmr6ga98raz-gildas-20180801_a
  /nix/store/vh6lk0v5n0sw9aql2zlws9xsp259c16s-cfitsio-3.430
copying path '/nix/store/vh6lk0v5n0sw9aql2zlws9xsp259c16s-cfitsio-3.430' from 'https://cache.nixos.org'...
copying path '/nix/store/1a4qy9vygrh7c08a2xh9arw3lpivyi3d-python-2.7.15-env' from 'https://cache.nixos.org'...
copying path '/nix/store/49bcdnkv34fsm7kriyns3lmr6ga98raz-gildas-20180801_a' from 'https://cache.nixos.org'...
/nix/store/49bcdnkv34fsm7kriyns3lmr6ga98raz-gildas-20180801_a

[detached HEAD 0ba0f158efc] gildas: add alternative url for the source code (#46145)
Author: Sebastien Maret<EMAIL_ADDRESS>Date: Thu Sep 6 16:10:21 2018 +0200
1 file changed, 4 insertions(+), 1 deletion(-)

Thanks @Mic92


numerous warnings in the output of the evaluation mode

2024-01-30 10:57:02,582 [WARNING]
WARNING: Image format corrupt. Number of images in meta_df: 1. Exiting.
2024-01-30 10:57:02,582 [WARNING]
WARNING: Image format corrupt. Number of images in meta_df: 1. Exiting.
2024-01-30 10:57:02,582 [WARNING]

I dont see this warning anymore. Closing for now.


Recently used emojis change places every time you click in this group

Describe the bug
Hi! I noticed a bug when, when clicking on recently used emojis, they begin to change among themselves, although they should remain in their places, this creates inconvenience for users
To Reproduce
Steps to reproduce the behavior:

Go to Live Preview of the vue3-emoji-picker
Click on App.vue file
The third line of the code has prop :display-recent which means, that we would display recently used emojis in emoji-picker.
Now when we clicked on emoji in recently used group you'll see, that emojis start insert at the beginning.

Expected behavior
Recently used group should have static emoji positions when we click by the emoji.
Screenshots

Codesandbox
Link to codesandbox
Necessary information (please complete the following information):

Vue version: ^3.4.21
Vite/Vue-CLI version:
Node version: v21.7.3
EmojiPicker version: ^1.1.8

The emoji you're currently clicking on is the most recent, so it comes first.
it's always sort one by one , not recently "group"


Release notes for beta-20161201

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/b957147628536cd4aa8b876fa86bae8fc6708bd4/


Code block does not show the language

Unlike the default theme, code blocks do not show the language of the code in the upper left corner of the code block

hey @nashv! so recently the styling for code blocks was simplified to be more like the default obsidian styling, so the code language now appears on the top right. here's a small example.

can you ensure you're on the latest version of the theme and test? if the issue is resolved, pls close this ticket. thanks!

hey, after updated to 2.1.19, the code block badges disappeared in reading mode.
edit mode

reading mode

If I hover the mouse over it, copy appears.
obsidian version: 1.4.16


[NSE-122][DNM] add prefix support in columnar sort

What changes were proposed in this pull request?
This pr tries to compare prefixes before sorting real data.
fixes https://github.com/oap-project/native-sql-engine/issues/122.
How was this patch tested?
locally tested

close this pr due to performance regression https://github.com/oap-project/native-sql-engine/pull/123


Added the possibility of 'protected' env parameters. (+test).

We didn't talk about this, but I think this feature is a natural addition.
Basic env parameters - especially ones that could be mentioned in the docs - should be protected from future changes, since many 3rd party and custom tasks can rely on these values.
Consider the env parameters set by the Builder (#272).
If a 3rd party task later desides to set the "server" env var, there's nothing to stop him in doing so.
Now if a developer just include that task in his deployment process without digging in the code and checking every detail, it can cause side-effects, since after that task runs, any following task that relies on the "server" env var will fail in some way.
At this point, the developer can easily misjudge the situation and believe that the depoyer code itself is buggy, while in reality the 3rd party task is the one causing unwanted side-effects.
If this pull request gets accepted, I'll create another one, which sets the aforementioned "server" env parameter as protected.

Were you think this case ?
$env = new Environment();
$env->set('protected', ['a' => 1, 'b' => 2], true);
$env->set('protected.a', 'some-other-value');

Good point, I didn't think of the dot notation.
I'll refactor the logic so it would handle such a situation.

Good addition. Must have feature. I suggest туче syntax:
$env->setProtected('key', ...);

But it has to be accessible by dot notation:
$env->setProtected(''server', [
            'name' => $config->getName(),
            'host' => $config->getHost(),
            'port' => $config->getPort(),
        ]);

$env->set('server', ...); // Thrown an exception.

$env->set('server.name', ...); // Thrown an exception.

I like this, one thing though: setProtected should be setAsProtected.
What are your thoughts on that?

I think setProtected($key, $value) better. But setAsProtected is like set as protected this key setAsProtected($key).

Well if you really want, I can implement it as setProtected it just sounds a bit off to me.
Anyway, here's a longer explanation why I think "setProtected" would be slightly off.
setProtected(...) in a proper sentence would be: "Set this key protected." (or even better: "Set this key to be protected.")
This implies that there's an already existing key, which I now want to set to be protected.
What the method really should mean, is that I want to set a new key as a protected key.
So the setAsProtected(...) would then mean: "Set this key as protected." which properly implies, what I really meant.
Here's some example which further illustrates what I think the difference is between the two names:
/**
 * This function sets an existing key to be protected.
 * @param string $key The key which needs to be protected
 */
function setProtected($key)
{
    // ...
}

/**
 * Sets a new environment parameter as protected.
 * @param string $key The parameter's key
 * @param string|bool|int|array $value The key's value
 */
function setAsProtected($key, $value)
{
    // ...
}

Originally when you proposed the setProtected method, and I still didn't read the code examples, I thought you meant this:
$env->set('server', [
    'name' => $config->getName(),
    // ...
]);

$env->setProtected('server');

Then again: I can roll with setProtected if you really want. :+1:

Well, you convinceв me. setAsProtect is better.

Thanks! ^^
I'll get to it as soon as I have some free time then. :)

I added the modifications and tests.
One thing though:
the logic of the new tests is to set something as protected with the setAsProtected method, then check if the set method would work after that.
Now this of course doesn't test what happens, if I set new parameters with the setAsProtected method, and then try to use it again instead of set.
Of course since internally the setAsProtected method calls the set method, it shouldn't be a problem, but I thought it worth mentioning anyway.

Note: if this gets accepted, I'll write the documentation for this and #272 the next week.

Awesome! Nice work! Merged! :beer:  :beers:

Will wait for docs...

@ZeeCoder , @elfet
Did you test with case:
    public function testContainingProtectedParam()
    {
        $env = new Environment();
        $env->set('not_protected', []);
        $env->setAsProtected('not_protected.protected', 'value');

        // throw exception => ok
        $env->setAsProtected('not_protected', 'value');

        // throw exception => error ???
        $env->setAsProtected('not_protect', 'value');
    }

Cause is https://github.com/deployphp/deployer/blob/master/src/Server/Environment.php#L87
Please fix this problem !!!!

hmm, I can't fix it until monday, I only have my mobile on the weekend. :/

@ZeeCoder ,
I fixed in PR #288

Thanks!

I have a new idea. That is all env vars "private" by default. And if you want you can override it with $env->override(key, value)?
@ZeeCoder @oanhnn @gordalina what do you think?

@elfet Are all variables can be override ? What was so different set function?

I thought about that too, because it's just so easy to implement it.
But I think protected env vars are protected for a reason.
Implementing an override method would let the users break things, exactly what we want tot avoid.
I think everything can be solved easily without overriding protected env vars.
Also: I think this discussion can be closed, the only thing needs to be done is adding this to the documentation. (Which I will do.)


[ci][windows] Remove 32bit python CI on AppVeyor

We only ship the windows agent with 64bit python nowadays (starting from the upcoming 5.12.0 actually), so it's not worth it to test python 32bit on appveyor.
Also, upgrades python to 2.7.13 on AppVeyor.

:+1:


ObjectVar getitem typing issues

@adhami3310 do you have any idea on how to fix the typing test?
reflex/tests/units/vars/test_object.py:112:5 - error: "__getitem__" method not defined on type "ObjectItemOperation" (reportGeneralTypeIssues)

ObjectItemOperation is essentially just a Var with no typing. You can generally call .to(< the type it should be> on it.

I think in the example above it could lose the typing ? I can take a look into that.

I think in the example above it could lose the typing ? I can take a look into that.

Reflex always supported accessing vars in that way, so I think the general goal should be to add full typing support for this.
However, we could lose the typing as a mitigation. But I would not put too much effort into that, we can use # pyright ignore annotations until reflex supports it.

by lose typing i meant runtime typing, reflex should maintain runtime typing as long as possible to limit the need for .to, but static typing is a different question, and generally difficult to get right with object vars

i believe before, all vars supported [], but right now we're moving away from that, the issue in this case is that static typing doesn't pick up on that field is an object var, as far as i know, it seems impossible to provide static typing that would not lose the context here without returning Any

Sounds like you are hitting some of python's typing limits? :/
I have just added another test (https://github.com/reflex-dev/reflex/pull/4380/commits/13845143f8d5d571700cb6125e78adf2b8b10193) which is quite interesting. dict[str, str] works but dict[str, bool] does not. This sounds like it should be fixable.

@adhami3310 any news regarding the objectvar dict[str, bool] thing? Shall I open an issue for this?


add

Important: Please read all instructions carefully.
Select the appropriate category for what this PR is about
This PR is:

[X] Adding a new domain
[ ] Updating existing domain size
[ ] Changing domain name
[ ] Removing existing domain from list
[ ] Website code changes (512kb.club site)
[ ] Other not listed

Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

[x] I used the uncompressed size of the site
[x] I have included a link to the GTMetrix report
[x] The domain is in the correct alphabetical order
[x] This site is not a ultra lightweight site
[x] The following information is filled identical to the data file

- domain:
  url:
  size:
  last_checked:

GTMetrix Report:

Need the GT Metrix report.

sorry. link was in comit
https://gtmetrix.com/reports/control.org/XrcNRZS7/


Fix auto verification of contracts

Problem solved
Short description of the bug fixed or feature added

PR-Codex overview
This PR introduces the export of the verifyContract function from ContractSourcesPage.tsx and integrates it into the CustomContractForm component to send a verification request after deploying a contract.
Detailed summary

Changed verifyContract from a local function to an exported function in ContractSourcesPage.tsx.
Imported verifyContract into custom-contract.tsx.
Added a call to verifyContract in the CustomContractForm after contract deployment.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

Merge activity

Oct 21, 5:08 PM EDT: The merge label 'merge-queue' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.


Ref iterators for Query

Would be neat to have one more alternative to the existing query APIs. A iterator directly received from the query, replacing world.Query(in, (...) => {});
Like this :
var query = world.Query(in desc);
foreach(var refs in query.GetIterator<Position, Velocity,...>()){
   refs.t0.x += refs.t1.x;
   refs.t0.y += refs.t1.y;
}

foreach(var refs in query.GetEntityIterator<Position, Velocity,...>()){
   Console.WriteLine(refs.entity);
   refs.t0.x += refs.t1.x;
   refs.t0.y += refs.t1.y;
}

Those could probably even replace world.Query(in, (...) => {}) calls completly, since they offer more advantages. They will not closure copy, offer greater controll over the iteration flow and are probably easier to maintain.
@andreakarasho Probably already had a first draft of this according to #35 ( if i understood that correctly ) ^^

Not really, I had a moc using the Entities array into Chunk struct, so not the real target

Update
The first variants already work on my local branch... i think it would make sense to actually add deconstructors to reference types... this way it could even be optimized like this :
foreach(var (pos, velocity) in query.GetEntityIterator<Position, Velocity,...>()){  <-- Deconstruction happening here, makes it more readable.
   Console.WriteLine(refs.entity);
   pos.t0.x += velocity.t1.x;
   pos.t0.y += velocity.t1.y;
}

Update
I did some benchmarking and profiling. Its slower than the current delegate, inline, manual approach.
This is actually a terrible way of performing queries.
Each enumerator movenext a new struct is being created and returned, pollutes the stack. Furthermore enumerators do not inline well, even when being forced.
An better alternative is probably :
foreach(var (positions, velocities) in world.Query().GetChunkArrayIterator()){}

Probably the existing solution could also be optimized with storing a ref struct and reusing it ?


[FEAT-REQ] Adding a callback to only receive the checked node

Hello!
As stated in the other issue (https://github.com/JairajJangle/react-native-tree-multi-select/issues/81), I think it would be cool to have a way to receive only the selected node, if we want to handle things differently or to use the tree in another context than like options.
Currently, I'm using something like that:
function checkBox(current){
  let removed = save.filter((o) => current.indexOf(o) === -1);
  let added = current.filter((o) => save.indexOf(o) === -1);

  console.log(added);

  save = current;
}

which isn't too bad, but it's not very practical either. So I think it could be nice to get the checked/unchecked node directly in some way.
And maybe a way to get the full object (or a partial one) and not only the id, or a way to pass down more informations? Well, I feel like I will have to do another issue xD

Hey there! 👋 Thanks for your patience and for sharing this!
I believe the functionality you're suggesting might introduce additional overhead on each checkbox state change, which I'd prefer to avoid in the core library for now.
I checked this again, and as of now, there isn’t a simpler or more direct way to achieve this other than comparing the last state with the current state – which is exactly how you're already handling it.
That said, I think your current method is on the right track! If you're open to it, using Lodash to calculate the difference might make things a bit cleaner. Here's an example of how you could implement it:
import _ from 'lodash';

function checkBox(current) {
  const added = _.difference(current, save);
  const removed = _.difference(save, current);

  console.log(added);
  save = current;
}

This should make the comparison more concise while achieving the same result.
Since this can be implemented externally without too much hassle, I’ll go ahead and close this issue. If you feel there's anything else you'd like to explore, feel free to open another issue – I’m always happy to discuss! 😄
Thanks again for your input and for contributing to making the library better. 🙏


Xlm transfer

Transferred xlm from ledger to coin base and was never received!!!

Same here, I’m trying to figure it out as well, let me know if you find anything.

Same here, I’m trying to figure it out as well, let me know if you find anything.


Play video with light on IPhone/IPad

I use the following method attached to
onClick:
  handlePlayPause = () => {

        if (!this.state.isStarted && this.props.hasLight) {

            this.setState({
                isLoadingVideo: true,
                playing: true
            }, () => this.player.handleClickPreview());

        } else {

            this.setState(prevState => ({playing: !prevState.playing}));

        }

 };

onReady:
  handleReady = () => this.setState({isLoadingVideo: false});

onStart:
  handleStart = () => this.setState({isStarted: true});

What I'm trying to do is to remove thumbnail(light) and play the video when user clicks the thumbnail. Everything works well on Mac or android, but not same on IPhone/IPad. When I click the thumbnail, it disappears, but video doesn't start. What is more, when I click on play, video doesn't start again. Video starts after second click on play button.
Expected Behavior
Play video after click on thumbnail.

Running into into the same problem too, with using Light.
Can try it with the official demo actually:  https://cookpete.com/react-player/

load it on your phone
Pick Vimeo/Youtube
Pick Light mode
See player demo update with cover image, then tap image
Player loads, but pauses on 1st frame

I suspect that the light mode tries to embed in our videos with autoplay. And that just doesn't play. Unless it's muted. Which is weird, since I thought the preview was a way to trick the player to play unmuted due to user interaction.
There could also be some complex user-behaviour tracking on the phone (IOS). Like what was the user last setting on a video. Muted? Was playing? /shrug
I tried this with Youtube and Vimeo

I thought the preview was a way to trick the player to play unmuted due to user interaction.

Light mode is just a way to defer loading the full player API until the user wants to watch the video. It actually causes more problems on mobile than it solves. See https://github.com/cookpete/react-player/issues/1034 for more.


WIP: Add failing test to kernel demonstrating possible memory management error

Check out this branch locally, then
cd kernel
./test.sh

to run the test.
The test will fail, indicating an issue I encountered.

Thank you so much for this great reproduction, I really appreciate it!
I think I have a fix here: https://github.com/extism/extism/pull/new/fix-kernel_memory_bug
The issue was when the re-use offsets were being calculated we weren't accounting for the size of the MemoryBlock structure so MemoryBlock::status was being overwritten for second half of the split memory.

I just verified my change works against CI - I am going to push my commit to this branch and merge it shortly.
Thanks again for your report!

Hm, that seems like a weird CI failure,  I'm going to open a separate PR to test against.

@Marton6 let me know if you continue to run into any issues when using the latest main branch - if everything is working we can make a new bugfix release


RFC: limit simutanous publish requests

Following on from this question: https://stackoverflow.com/questions/63286981/gcp-pubsub-why-does-publishing-200k-messages-rapidly-result-in-2-5-million-mess
If I've understood the issue correctly, basically when we throw lots of messages at the client/sdk rapidly it correctly splits them into batches but does not limit the number of simultaneous gRPC publish requests that are made.
These requests are (as far as I can tell) going over a single http2 connection, which in nodejs by default is limited to 100 concurrent streams

peerMaxConcurrentStreams  Sets the maximum number of concurrent streams for the remote peer as if a SETTINGS frame had been received. Will be overridden if the remote peer sets its own value for maxConcurrentStreams. Default: 100.
ref: https://nodejs.org/api/http2.html

As far as I can tell in the instance of pubsub we are either:

Taking this default of 100
Reducing the value to 1/2 (based on rg -uu max_concurrent_streams)
Or accepting a value set by the server side unknown to me

I believe that by issuing so many simultaneous requests that they get gummed up, exceed the deadline (or some other condition) and are automatically retried as per the retry behaviour specified here: https://github.com/googleapis/nodejs-pubsub/blob/master/src/v1/publisher_client_config.json#L13-L21
I'm not very familiar with the code base, especially the google-gax / grpc-js parts so I'm hoping someone with deeper knowledge can confirm this theory.
I think the problem can be solved by doing something along the lines of this:
https://github.com/googleapis/nodejs-pubsub/compare/master...mnahkies:mn/limit-num-of-inflight-publish-requests?expand=1
I haven't yet tested that solution, but plan to test this and if it fits in with the project direction can refine it and write unit tests etc

@mnahkies Thanks for the report! I don't know as much about the grpc side of things, so maybe I can beg some help from @murgatroid99 ? :)

Hi @feywind / @murgatroid99 just wondered if you'd had a chance to look at this?

@mnahkies I think this is going to end up being handled by publisher-side flow control, which isn't implemented in Node yet. That is in the queue, though.


Change Alicloud EIP type PayByTraffic

What this PR does / why we need it:
Change Alicloud EIP type PayByTraffic. It will save a lot of money. Origin setup was charged more than 1/2 of VM instances!!!

Thanks Jerry, however, not needed - we will create a new release 0.22.0 from master branch later today (including this fix).
Closing this PR, then.


Workflow executions: Cleanup job + service code flow

What does this PR do and why?
Describe in detail what your merge request does and why.
This PR modifies the code flow of jobs and services to have a final step where a "Cleanup" step is performed after a Workflow Execution has reached one of it's 3 end states of completed, canceled, or error.
This PR does not contain the changes that do the cleanup. That will be handled in a separate PR.
In this PR, the cleanup job is queued, and when run, runs the service which simply marks cleaned as true. This is so we can test all cases that pertain to the job/service code flow.
Main change that is visible to UI is that workflow executions are not deletable until after the cleanup service has run. So there is a 30 second job queue delay between a run being completed/canceled/error and being deletable.
Fixes #521
Dependant on #605
This service will clean up files generated though a Workflow Executions life that are no longer needed.
The job handles scheduling the cleanup service.
The simple explanation of the code flow is
The existing code flow for Workflow Executions is:
initial >> [ submitted, running, etc] >> One of end state [completed, canceled, error] >> WE is deletable
New code flow is:
initial >> [ submitted, running, etc] >> One of end state [completed, canceled, error] >> Cleanup job >> .cleaned? >> WE is deletable
The full code flow diagram is
This diagram is also included on a new docs page.

How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Run a workflow execution and verify that after completion/cancelation/error state, the run is not immediately deletable.
Then after the cleanup job/service has run, it is deletable.
PR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

[x] I have evaluated the PR acceptance checklist for this PR.

ENHC0010012


Docs don't show which properties each object has

The docs should show which properties each object has.
For example, each finding has a retestInquiries prop that is a FindingFindingRetestInquiryManager but that is nowhere to be seen in the documentation.

The casing for the probs is also inconsistent. Some are camelCase and some snake_case in https://github.com/dongit-org/python-reporter/blob/main/reporter/object_children.py


When upgrading from 0.17.3 to 0.18.1, the values generated are different, deterministic but different from before

This looks like a breaking change in the deterministic behavior, in comparison to previous versions.
See https://github.com/prisma/prisma/pull/21718
Example test failing
https://github.com/prisma/prisma/actions/runs/6726544886/job/18283002179?pr=21718#step:8:2012
FAIL 0-legacy-ports/aggregate-raw/tests.ts
  ● 0-legacy-ports.aggregate-raw (provider=mongodb) › match

    expect(received).toMatchInlineSnapshot(snapshot)

    Snapshot name: `0-legacy-ports.aggregate-raw (provider=mongodb) match 1`

    - Snapshot  - 2
    + Received  + 2

      [
        {
    -     email<EMAIL_ADDRESS>    +     email<EMAIL_ADDRESS>        },
        {
    -     email<EMAIL_ADDRESS>    +     email<EMAIL_ADDRESS>        },
      ]

      70 |       })
      71 |
    > 72 |       expect(users).toMatchInlineSnapshot(`
         |                     ^
      73 |         [
      74 |           {
      75 |             email<EMAIL_ADDRESS>
      at Object.<anonymous> (0-legacy-ports/aggregate-raw/tests.ts:72:21)

How can I ensure that this never happens again? Could I use a seed for example?
Is it possible to somehow get back the old deterministic behavior?

Hey @Jolg42
Yep, this was indeed a breaking change. And I'm sorry, we did not communicate this well (to your points in #47 and #48).

How can I ensure that this never happens again? Could I use a seed for example?

It's a tricky one - the reason for the breaking change was because of improvements made. Some improvements we make can be done in a way that does not change the current output for a given input, but some changes are unfortunately not this way. I know how annoying this is, considering the whole point of copycat is that the outputs do not change if the inputs do not.
I think the best we can do is this:

Actually have a changelog
Use major version bumps rather than minor for breaking changes like this

Is it possible to somehow get back the old deterministic behavior?

Copycat should still be deterministic, in that a given input will map to a given output. If this is no longer the case, that is a bug we should investigate. After upgrading copycat, the same input will now map to a different output (because of the breaking change), but it'll always map to this new output (e.g. when called with the same input multiple times).
That said, I think you're referring more to the fact that the output is now different, and you want it to be the old output, right?  In that case, if you need to get back to the old output, you can downgrade to 0.18.0-rc.6 or earlier. That would be a temporary fix until you are ready to upgrade though. If you need it to say the same output but still get the improvements that 0.18.1 adds, I'm afraid that isn't possible because of the nature of the improvements.
Does that make sense?

Thanks, @justinvdm 🙌🏼. Peter mentioned to me last night that there was maybe another option, but he was not sure about that, so I thought it was better to ask!
For now, we'll keep the old version until we have capacity to upgrade, it's not a priority compared to other things at the moment. We'll get to it one day 👍🏼

@Jolg42 release notes for 0.18.1, as promised :) https://github.com/snaplet/copycat/releases/tag/v0.18.1
We'll continue to do this for new releases.

Very nice release notes & performance improvement 🙌🏼 Well done!


Create a plan for November pressure jump experiment

based on the confluence docs  page.
We need to create sub-issues for this epic. We need to:

[ ] make a list of devices needed
[ ] make an example plan that fits the basic scientific use case
[ ] try out at p38
[ ] create pressure cell ophyd device https://github.com/DiamondLightSource/dodal/issues/658

tagging @barnettwilliam for reference

@stan-dot I can't modify the list to add this:
create pressure cell ophyd device https://github.com/DiamondLightSource/dodal/issues/658

added

initial draft of devices needed

valve
pressure controller
detector

plan parameters

initial pressure
final pressure
number of captures before the jump
number of captures after the jump
???

base rate - some detectors going at different frequencies
haven't considered how to make a generic plan doing that.
one of the deliverables is to replace tfg, so will need a generic scan plan.
tfg atm does not do multiples of the base rate (???) but no gui for this
camera is the slowest (up to 20Hz), pilatuses (up to 250Hz), and tetramm (20kHz) have the same frame time

what parameters?
nominal exposure times (per detector (?))
OAV only ever an ancillary measurement, but unfortunately it is the slowest
Pilatus exposure time should be the main reference point
Tetramm is set to match Pilatus
Can we run an optical camera at some divisor of the Pilatus rate, so we choose an integer close to 20Hz??
but the image could be ruined, intensity must be sensible so that it's not over- or under- saturated

we can do a small test plan in order to make the pressure cell work

meeting notes
pressure - just 1 jump
very the initial pressure 150-250
linspace
1500-3000 with 2000 the main vlaue
10s, jump, (5s, more captures high resolution), 10s after
both tetramms (i0, it) and waxs and saxs
vaery from 5 seconds to 10 minutes
shouldn't be outside those bounds


[Bug] [Module Name] Can not print Job Statistic Information when Using Spark Engine

Search before asking

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

What happened
Can not print Job Statistic Information when Using Spark Engine
SeaTunnel Version
2.3.4
SeaTunnel Config
env {
  execution.parallelism = 1
  job.mode = "BATCH"
}

source {
  jdbc {
    url = ""
    driver = "com.mysql.cj.jdbc.Driver"
    connection_check_timeout_sec = 100
    user = ""
    password = ""
    query = "select * from t_table"
  }
}

transform {

}

sink {

  CosFile {
    path="/tmp/hive"
    bucket = "cosn://****"
    secret_id = ""
    secret_key = ""
    region = "ap-beijing"
    file_format_type = "parquet"
  }

}

Running Command
./bin/start-seatunnel-spark-3-connector-v2.sh --master local --deploy-mode client --config ./config/mysql_cos.conf

Error Exception
seatunnel job success done,but there no Job Statistic Information  in logs

Zeta or Flink or Spark Version
No response
Java or Scala Version
No response
Screenshots
No response
Are you willing to submit PR?

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

Code of Conduct

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

Job metrics information only supported when use seatunnel zeta engine.


Suggestion

Hi
If it is possible to add a feature to save the images in zip format that would be a great option or show how to do it via filename pattern
thank you 😊

Duplicate of #69.


Node Extra info

An extra structure used by the node to store some more information about the node object.

Looks good but please add:

#197
#182


Update camundala-helper to 1.30.25

About this PR
📦 Updates io.github.pme123:camundala-helper from 1.30.23 to 1.30.25
📜 GitHub Release Notes - Changelog - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (1.30.23).
You might want to review and update them manually.
CHANGELOG.md

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.github.pme123", artifactId = "camundala-helper" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.github.pme123", artifactId = "camundala-helper" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, version-scheme:early-semver, old-version-remains, commit-count:1

Superseded by #120.


Emit an event when database has finished syncing with connected peers

https://github.com/orbitdb/orbit-db/issues/474 describes a situation in which this event would be useful. Existing events do not communicate this information.
The load event is emitted simply once a database has finished loading from memory. This event may be emitted before the database has synced with connected peers.
The replicated event is in fact emitted after a database has synced; however, it does not always fire (and there is no straightforward way to determine whether it will fire). For example, if a connected peer does not have the database open, or it does not have any heads for the database, then no replication will occur and the replicated event will not fire. Thus, it's uncertain whether the replicated event will ever fire, so one cannot reliably wait for this event to fire in order to know that a database has finished syncing with peers.
I have implemented a solution for this problem; however, this solution is not sufficient in its current form. I'm linking to it here as an example of what a solution might look like. The solution spans 2 repos:
orbit-db changes
orbit-db-store changes
Further, here is an example of code that uses this new synced event to know when a database has finished syncing (usage is still a bit complex, as the event fires only once per peer/database combination, and requires additional pubsub message sending to request that a connected peer open a specific databse): https://github.com/projectaspen/aspen/blob/master/packages/orbit-connect-client/src/orbit-connect-client.js#L104

@tyleryasaka we discussed this yesterday in the community call. See the notes here (under "semantics of synced"). The notes should capture the (design/ux) challenge here, but if they don't, let us know and we can continue the discussion here.

I've created a PR that implements the solution I am referring to. It makes minimal code changes, and does not touch the enqueueing system (unlike my original solution). It requires an accompanying change to orbit-db-store.
https://github.com/orbitdb/orbit-db/pull/514
https://github.com/orbitdb/orbit-db-store/pull/38

Upon further investigation, I see that my initial approach was naive. The store sync method waits for heads to be replicated, but not necessarily the rest of the graph. I updated my PR to orbit-db-store to use the replicated.progress event to ensure that all of the nexts have been followed and the db has been fully replicated. This seems to solve the problem, though it's not a perfect solution.
The downside to this is that if other things are being added to the queue rapidly, then this may hang indefinitely. It waits for all queue items to complete, not just the ones derived from the heads in the current request. That said, currently as this is used in orbit-db, this would not block anything other than the new event I have proposed adding. So it should be acceptable, maybe?
Ideally, what should really happen is that we should have a way of knowing when the items derived from the given heads have been replicated.  The queue would likely need to be refactored for this approach.

@tyleryasaka reached out on Gitter to discuss this further. I like the general direction of the PRs, but we should think about covering all the different use cases and make sure we get the semantics right (ie. "what/when is ready?").
Thanks for pushing this! Fixing it would help many 👍

Something like this would be helpful to us too!
Specifically, we'd like to know when we've finished "syncing" with all peers after first connecting. I'm not completely clear on what the knowable things here are, but as was said above, it's fine that there's no finality, but "I know what the peers I'm connected to know as of, say, 30 seconds ago" is very valuable, e.g. for users who have been offline and are coming back online, or for users who might suspect they have some issue with their internet connection.

Due to the archiving of many of the legacy modules and with the release of version 1, the attached PR will, unfortunately, be stale.
I'm going to close this issue as part of housekeeping but feel free to move the discussion to a new issue including solutions in the context of v1.


feat: allow adjustable height of copyable text

This change adds a height attribute to ui.copyable text so that copyable textbox height can stay consistent with textbox height, as specified in issue #1302.
See example use case:

text box of certain height
user enters text and hits Submit
if the query was successfully, user gets back a "copyable text box" of same height (i.e. ui.copyable_text() of same height)

Also includes updated docs and example.

Thanks for the PR @cvanvoorhis!

See example use case

Can you please update the PR description with a video/screenshots that verify your changes work?

These changes alone crash the program, so I made the changes to ui.py and types.py that allows height to be an attribute of CopyableText. However, the height of the textbox does not actually change in the display, as you can see in the attached screenshots.

Despite setting the height to 1000px and then 500px, the height of each textbox is the same, and they display a scrollbar. I believe this because of the TextField.styles.js in the @fluentui module, which has the relevant lines in an attached screenshot. If multiline is true, the height of the textbox is set to auto.

So my question is, do we want to change this implementation? My changes won't show up visually because of this implementation, but changing it would change all TextFields in the wave app I believe, and we do not want to do that.
What are your thoughts?

Thanks @cvanvoorhis!

These changes alone crash the program, so I made the changes to ui.py and types.py that allows height to be an attribute of CopyableText.

When adding a new attribute to a widget, you need to call make generate to generate the type definitions automatically after editing Typescript definitions. See contributing guidelines.

I believe this because of the TextField.styles.js in the @FluentUI module

That's possible. In that case, you shall overwrite the default Fluent styles if your new attribute (height) is set. If it's not set, the component should render as before to prevent breaking changes for existing apps. Here is a small example of how something similar is done for our textbox component.

Apologies for the lack of communication lately.
Thank you for the help! When I run make generate the page now updates, however the height is not showing up as intended. It displays as spacing in between the textboxes themselves, as shown below.

When I changed copyable_text.tsx to have field: { height: height}, fieldGroup: { minHeight: height } like the textbox.tsx example, the textboxes display the same as the images before.
Personally I think the expandable textboxes of copyable text already allow for adjustable height, what do you all think about changing this feature to be called spacing instead of height?

however the height is not showing up as intended

Yes, you need to make the styling right :) You need to first identify the HTML node that needs the height to be set (I assume it's going to be some textarea) and then find out how to style it in the FluentUI way.

Personally I think the expandable textboxes of copyable text already allow for adjustable height, what do you all think about changing this feature to be called spacing instead of height?

Spacing would be of no use. The goal of this issue is to provide a way to render bigger area of copyabletext in case there is simply too text for copying and you would like to avoid scrollbars.
As noted previously, you should focus more on the correct CSS styling.

Just pushed commits that implement this change. The height is still adjustable after the textbox is made. You can see the height is set in the images below:

Let me know if I should add more documentation and/or make the example better somehow?

Thank you for your suggestions! I made those changes as well as kept the styling of expanding the textbox that was available before in the most recent commit.
Here is a vid showing that off:
https://user-images.githubusercontent.com/113397293/206731912-ddbb61f3-3dfe-4470-b3a4-d24d140a5f00.mp4


useLocation search value is empty

Version
5.1xx
Steps to reproduce
 <Link to={`/app/instances/draft/${row.ID}?clone=true`}>

When I use link tag like above and on the target page, if I use useLocation() Hook it gives following

if I use  link tag like below
 const temp = `/app/instances/draft/${row.ID}?clone=true`;
 <Link to={temp}>

it gives this output

the 'search' value in the location object is empty

I can't reproduce this. If you can provide a Codesandbox that reproduces this, we can look into it. But this points to being something else outside of React Router.


Support .d2.svg and .d2.png like .drawio.svg / .drawio.png in VS Code extension

D2 is a fantastic project, especially the VS Code extension which makes it easier to edit files. I'd like to suggest that the VS Code extension team add the type of slick SVG and PNG integration offered by hediet.vscode-drawio extension.
As stated in the hediet.vscode-drawio documentation:

.drawio.svg are valid .svg files that can be embedded in Github readme files! No export needed.
.drawio.png are valid .png files! No export needed.

It would be cool to have the same functionality for D2 diagrams:

.d2.svg would be valid .svg files that can embed their D2 into the SVG and then the SVG can be easily used directly in Markdown and other files
same with .d2.png

Once D2 code can be embedded into an .d2.svg or .d2.png file, the visual and code can be managed in the same file and be easily editable by VS Code at the same time.
Thanks!

It took me a minute to wrap my head around this, but it's pretty simple in concept.  I'll assume that it's implemented with metadata in the svg and png files.  So an SVG or PNG file has D2 file contents stored as metadata.  If the extension opens one of these SVG/PNG files, it extracts the metadata as editable text, then when it renders (using D2 on the command line), it puts the text into the SVG/PNG file, which if opened by a image viewer, shows as a fully formed SVG/PNG image.
This solves one BIG problem, it allows you to have a single file for markdown embedding.  So when you embed 'foo.d2.svg', it just works for markdown (e.g. github).  No editing your source file, then forgetting to run the conversion to another file that is actually embedded into your markdown.
Not my decision to make, and would require some work on D2 cli, as well as the extension. I rate it as 'highly interesting'

Thanks for the quick look @BarryNolte -- glad to see you find it interesting.
In my opinion, this "D2 as meta data" embedded in SVG or PNG files could be strictly a feature of the VS Code extension (like hediet.vscode-drawio) and should not require any changes to the D2 CLI.
That's because an .d2.svg or .d2.png file would be only "editable" by those who understand the metadata. A regular .d2 file (processed by the CLI) would remain unchanged.

we don't want editor lock-in, where your teammate uses vscode and you use vim and you can't decode unless you download vscode. i think this is a good feature to do, but we'd have it in the CLI to do the embedding, so that VSCode users can call the command automatically, and others can do it manually. we also want to make sure the encoding/decoding is the exact same code for all editors, so it needs to be centralized in the main program.
shouldn't be hard to do and I think a good idea. i'm wondering if we should include the D2 script in the encoded form to save space (like a playground link https://play.d2lang.com/?script=qlDQtVOo5AIEAAD__w%3D%3D&), or include the raw script for preservation and readability without an outside tool. leaning towards the former, but let me know if you have any thoughts.
thanks @shah !

After walking the dog and thinking about this, I agree that as much functionality should be pushed to the CLI.  Then everyone can benefit, not just vscode users. On encoding the data, I would suggest against, having it as clear text is easier to code, easier to test, easier to debug and given the average size of a D2 file, no major space saving and disk space is cheap.

the concern with space pertains more to serving images over the web.
i'm not sure what the exact flow for easier to test/debug is, can you elaborate on a use case?

Still probably doesn't make a difference.  I have a 6.3Kb test file that's pretty average++, but it creates a 1.6Mb svg and 1.8Mb png file.  So, even with 100% compression, it's a 0.4% savings.
I'm just thinking of myself, but if I'm inserting stuff into a file, I want to be able to see it as plainly as possible.  The D2 file doesn't hold any secret that isn't present in the svg or png file, so it's not a security problem. It's just an extra step that doesn't really provide a benefit.


Tracking job progress with conditions

recheck

recheck

/test openstack-ansibleee-operator-build-deploy

@raukadah could you please help me to understand why the zuul job is failing?

https://review.rdoproject.org/zuul/build/72cab743059140ea8cf6716ec8afe888/log/job-output.txt#1297
the compute node failed to deploy.
you can see the job logs here https://review.rdoproject.org/zuul/build/72cab743059140ea8cf6716ec8afe888/logs
specifically the
"Get deploy-external-dataplane-compute pod name"
task failed

I couldn't find why Get deploy-external-dataplane-compute pod name failed, the AEE pod seems ok

recheck

/test openstack-ansibleee-operator-build-deploy

The failure seems to be unrelated to this PR
TASK [edpm_container_manage : Update container configs with new config hashes] ***
1201 | fatal: [<IP_ADDRESS>]: FAILED! => {"msg": "Failed to set execute bit on remote files (rc: 1, err: Couldn't open /dev/null: Operation not permitted\n)"}
1202

https://review.rdoproject.org/zuul/build/243ce2777e3645548e1b289b45821911/log/logs/controller/pod/deploy-external-dataplane-compute-fnm2l-logs.txt
https://github.com/openstack-k8s-operators/edpm-ansible/blob/main/edpm_ansible/roles/edpm_container_manage/tasks/main.yml#L64

recheck

the CI error is
2023-03-02 19:46:21.923642 | TASK [Wait for deploy-external-dataplane-compute to finish]
2023-03-02 19:46:22.575444 | controller | error: condition not met for pods/deploy-external-dataplane-compute-w75m5

I have to think that might be related. We need to look at how that TASK is defined.

TASK [Wait for deploy-external-dataplane-compute to finish]

runs edpm_play from install_yamls:
https://github.com/rdo-infra/rdo-jobs/blob/3c5990dd77fc3e009b2fbce8f06a6dc2c19ffbb0/playbooks/edpm/deploy_podified_control_plane.yaml#L84-L102
If we check the deploy-external-dataplane-compute logs, we can see the real failure:
https://review.rdoproject.org/zuul/build/90d1f2838fe44bb59f060d493db00d1d/log/logs/controller/pod/deploy-external-dataplane-compute-w75m5-logs.txt
which is:
TASK [edpm_nova_libvirt : Run nova_libvirt_config container] *******************
--
950 | fatal: [<IP_ADDRESS>]: FAILED! => {"changed": true, "cmd": "podman run --detach --name nova_libvirt_config quay.io/tripleomastercentos9/openstack-nova-libvirt:current-tripleo sleep infinity", "delta": "0:00:06.968038", "end": "2023-03-02 19:54:34.772814", "msg": "non-zero return code", "rc": 125, "start": "2023-03-02 19:54:27.804776", "stderr": "Trying to pull quay.io/tripleomastercentos9/openstack-nova-libvirt:current-tripleo...\nGetting image source signatures\nCopying blob sha256:adb76314d13d1b8548638e6886cc66d9404cbc03942cffde8e07601d6df67bf6\nCopying blob sha256:1d5eadfc16157a6fe1c21b525fd2b7ab40e4f15e2ee26fe0e9f709462eef0991\nCopying blob sha256:48f4134a0ede9722eac053b4bccc9e84667d55192999a94b58414ed1715209c6\nCopying blob sha256:73e8511d8a1257f6f7de96785bedb71537ad3279e7ee9671db9c5866f8e86869\nCopying blob sha256:3178b58951ceec753153282930db35032e9091ba3ccadbd202f4e95c97910a22\nError: writing blob: storing blob to file \"/var/tmp/storage1996167166/2\": happened during read: unexpected EOF", "stderr_lines": ["Trying to pull quay.io/tripleomastercentos9/openstack-nova-libvirt:current-tripleo...", "Getting image source signatures", "Copying blob sha256:adb76314d13d1b8548638e6886cc66d9404cbc03942cffde8e07601d6df67bf6", "Copying blob sha256:1d5eadfc16157a6fe1c21b525fd2b7ab40e4f15e2ee26fe0e9f709462eef0991", "Copying blob sha256:48f4134a0ede9722eac053b4bccc9e84667d55192999a94b58414ed1715209c6", "Copying blob sha256:73e8511d8a1257f6f7de96785bedb71537ad3279e7ee9671db9c5866f8e86869", "Copying blob sha256:3178b58951ceec753153282930db35032e9091ba3ccadbd202f4e95c97910a22", "Error: writing blob: storing blob to file \"/var/tmp/storage1996167166/2\": happened during read: unexpected EOF"], "stdout": "", "stdout_lines": []}
951 |

Ok, yea, then it reran it was successful:
https://logserver.rdoproject.org/97/97/b9db1b8791d97c8f22d3740e267e76552928c719/github-check/openstack-ansibleee-operator-github-rdo-integration-centos-8-crc-singlenode-centos-9-external-compute/90d1f28/logs/controller/pod/deploy-external-dataplane-compute-xhxqr-logs.txt


Add ActiveGameRuleComponent, generic TryRoundStartAttempt and minPlayers

from the xeno antag pr btw
About the PR
ActivatedAt should be moved to ActiveGameRuleComponent at some point but that requires touching nukie code pre-refactor and I don't want the servers to break again.
Technical details
ActiveGameRuleComponent replaces the Active field on GameRuleComponent and EndedGameRuleComponent replaces the Ended field.
It simplifies the logic for querying game rules and is also faster, both at the moment and once Arch is implemented.
MinPlayers is also now in the GameRuleComponent, and is used when TryRoundStartAttempt is called on the base GameRuleSystem method.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes
The Active and Ended fields have been removed from GameRuleComponent. HasComp<ActiveGameRuleComponent> and HasComp<EndedGameRuleComponent> should be used to check if a game rule is active instead.
The ActivatedAt field has been moved from GameRuleComponent to ActiveGameRuleComponent.

ActivatedAt should be moved to ActiveGameRuleComponent at some point

The ActivatedAt field has been moved from GameRuleComponent to ActiveGameRuleComponent.

sus

sus (breaking changes is wrong)
copy paste blunder from the xeno antag pr btw


@mzikherman: Change /press redirect

We have to do this to work around not being able to create shortcuts for certain pages. I wonder if we should drop this blacklist in Gravity and replace these hard-coded redirects with shortcuts 🤔

Yea these definitely seem like they could be shortcuts in Gravity/the database.
In terms of routes like /artists though, what would be the shortcut for that? Or would we rely on the proper stacking of Force middleware to handle those before they hit the shortcut part?