Unable to set Pixel without iterating over [Pixel]

Perhaps I'm misunderstanding how some of these functions work, but it's hard to tell. Every example uses Frame::per_pixel().
None of these approaches work to set a single Pixel, and I'm not sure why.
fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    let pixels = frame.raw_mut();
    pixels[12] = Pixel::WHITE;
}

fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    frame.set(UVec2::new(3, 2), Pixel::WHITE)
        .expect("Error!");
}

fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    let pixels = frame.raw_mut();
    let pixel = &mut pixels[13];
    *pixel = Pixel::WHITE;
}

The only possible way I can find to set pixels without using Frame::per_pixel() is like this
fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    let pixels = frame.raw_mut();
    for pixel in pixels {
        // we can also do pixels.iter().enumerate() and make sure enumeration is some number
        *pixel = Pixel::WHITE;
    }
}

I include this, because it is very similar to my third code block above. In both of those, we are dereferencing a &mut Pixel, yet only the case inside of the loop works.
Testing on EndeavourOS, updated Rust version with
bevy = "0.12.0"
bevy_pixel_buffer = "0.6.0"

Hi! I'm on windows, bevy 0.12.1, and all your update functions work for me.
I've added a new single_pixel example, but it's just the second snippet you posted. Test if the new example works on your system before further investigation. Do it in a clean project or clone the repo and run cargo run --example single_pixel.

Thanks for the speedy reply!
The example actually works great. After running that and debugging my code, it would seem the error is actually coming from how I'm importing DefaultPlugins.
const WIDTH:  f32 = 128.0;
const HEIGHT: f32 = 128.0;

fn main() {
    let default_plugins = DefaultPlugins.set(
        WindowPlugin {
            primary_window: Some(Window {
                resolution: WindowResolution::new(WIDTH, HEIGHT),
                ..default()
            }),
            ..default()
        }
    );

    let size = PixelBufferSize {
        size: UVec2::new(WIDTH as u32, HEIGHT as u32),
        pixel_size: UVec2::new(1, 1),
    };

    App::new()
        .add_plugins(DefaultPlugins.set(
            WindowPlugin {
                primary_window: Some(Window {
                    resolution: WindowResolution::new(WIDTH, HEIGHT),
                    ..default()
                }),
                ..default()
            }
        ))
        .add_plugins(PixelBufferPlugin)
        .add_systems(Startup, pixel_buffer_setup(size))
        .add_systems(Update, update)
        .run();
}

fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    let mut rng = rand::thread_rng();
    let pos = (
        rng.gen_range(0..frame.size().x),
        rng.gen_range(0..frame.size().y),
    );
    frame.set(pos, Pixel::random()).expect("out of bounds");
}

I'm not getting any errors, but only a few pixels are being changed in frame, and it takes a while.
Changing pos to (5, 5) for instance shows that, even though it SHOULD be in range, it isn't visible.
Is there perhaps a better way to be setting my window resolution that works with this crate?
ie.
fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    frame.set((5, 5), Pixel::random()).expect("out of bounds");
}

Doesn't set any visible pixel to Pixel::random().

Oh, I think I have found the issue!
I think it was an issue of misunderstanding on my hard. I had assumed that no matter what PixelBufferSize.pixel_size was, the first visible pixel would be at (0, 0), however, this isn't the case!
In the code I posted in Comment 3 (just above), the center of the screen is pixel (256, 256) [which is coming from the 512, 512 size].
The area is then 32x32 pixels wide, so the first visible pixel is (256 - 16, 256 - 16) = (240, 240).
My code to change the FIRST pixel is as follows
fn main() {
    let size = PixelBufferSize {
        size: UVec2::new(WIDTH as u32, HEIGHT as u32),
        pixel_size: UVec2::new(16, 16),
    };

    App::new()
        .add_plugins(DefaultPlugins.set(
            WindowPlugin {
                primary_window: Some(Window {
                    resolution: WindowResolution::new(WIDTH, HEIGHT),
                    ..default()
                }),
                ..default()
            }
        ))
        .add_plugins(PixelBufferPlugin)
        .add_systems(Startup, pixel_buffer_setup(size))
        .add_systems(Update, update)
        .run();
}

fn update(mut pb: QueryPixelBuffer) {
    let mut frame = pb.frame();
    frame.set((240, 240), Pixel::random()).expect("No worky!");
}

Simpler thing to do is to read the docs I guess lol
Just needed to not have PixelBufferSize be equal to my screen resolution...
    let size = PixelBufferSize {
        size: UVec2::new(WIDTH as u32 / 4, HEIGHT as u32 / 4),
        pixel_size: UVec2::new(4, 4),
    };

Fixes all problems!

Ok, so you were drawing outside of the window. Naming things is hard, but yes, size is not actual screen size, but the size of the buffer, and if the pixels are bigger, they won't fit.
I'm glad you found the solution, good luck with your project 😄


generator: support proto2

Proto2 support, it passes conformance tests and on the first glance doesn't miss any functionality.
Fixes #11.

Unfortunately I had to also implement group support, didn't find a reasonable way to avoid it while preserving passing conformance tests.

@vmg Can you have a look, please?

This looks very good to me. There are no changes on the generate proto3 code, which I think was the critical goal for this PR, and the generated proto2 code looks reasonable to me (at the very least it passes the conformance suite). I'm gonna merge this, although potential users beware that I won't be testing the proto2 codegen in Vitess because we don't have any proto2 in Vitess!

Thanks for the contribution!


add git permissions error faq

this pr adds a github permissions error faq and solution as support have received tickets regarding this issue.
[internal slack thread[(https://dbt-labs.slack.com/archives/C02NCQ9483C/p1718256493389559)

thanks to your flags @matthewshaver ! oneteam!


Example dialog

Sorry for my bad English.
I'm trying to put a dialog with the button and open it but does not work me the example of the official website.
I copied the HTML code of this page: http://ui.lumapps.com/directives/dialogs
And under the code I put the script:
<*script>
$ scope.opendDialog = function (DialogID)
{
     LxDialogService.open (DialogID);
};
$ scope.closingDialog = function ()
{
     LxNotificationService.info ('Dialog closed!');
};
</* script>
I want to know how to do it
Thank you very much to all :)

In angular controller you should add LxDialogService and LxNotificationService in function
example angular.module('').controller(function ($scope, LxDialogService, LxNotificationService) {})

Thank you very much for the help but I am a novice in LumX. Where do I put this code?
Thanks again


Display chip for cancelled messages

Displaying a chip when a message is cancelled, from this discussion: https://dust4ai.slack.com/archives/C050A0S2Z7F/p1696924941531459

argh! he got me

I meant "Clash with @philipperolet's PR" :)

:fearful: incentive to increase velocity :laughing:

I actually clashed with myself 😅


Sync with main branch, misc fixes and cleanup

Removed the inline assembly and sync the esp-hal-common/src/interrupt/riscv.rs file

This was missing some changes from main

sha and usb_serial_jtag examples are working as expected
Miscellaneous cleanup/improvements

Got the ADC driver building and added the adc example as well.

The mcpwm example is now working correctly, too.


Change self signed certificates to not include extended key usage

The current code specifies server auth: https://github.com/kubernetes/client-go/blob/82aa063804cf055e16e8911250f888bc216e8b61/util/cert/cert.go#L155
The problem is the current self generated certificates do not work with curl (on Fedora):
curl --cacert apiserver.crt https://localhost:32786 -v
* Rebuilt URL to: https://localhost:32786/
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 32786 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: apiserver.crt
  CApath: none
* Server certificate:
* 	subject: CN=<nil>@1507833167
* 	start date: Oct 12 18:32:47 2017 GMT
* 	expire date: Oct 12 18:32:47 2018 GMT
* 	common name: <nil>@1507833167
* 	issuer: CN=<IP_ADDRESS>@1507833167
* NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)
* Certificate type not approved for application.
* stopped the pause stream!
* Closing connection 0
curl: (60) Certificate type not approved for application.
More details here: https://curl.haxx.se/docs/sslcerts.html

Removing the extended key usage allows everything to work as expected. Since these are for self signed certificates, I am hoping that the removal isn't a security issue. Some potentially relevant links:
https://tools.ietf.org/html/rfc5280#section-<IP_ADDRESS>
https://bugzilla.mozilla.org/show_bug.cgi?id=1049176
https://github.com/google/stenographer/issues/124
(?) https://github.com/golang/go/issues/11087

the goal was to prevent that cert from being used as a client certificate

@liggitt is this then an invalid way to use the certificates or can the key usage for the CA be changed? https://github.com/kubernetes-incubator/service-catalog/blob/5f4ca01ed86bd5e11a64390bcd3031767477ca63/contrib/hack/start-server.sh#L55

I didn't realize that Fedora 27 was switching crypto libraries for curl to OpenSSL. Given that curl with NSS was the only problematic scenario, I'm closing this.
https://fedoraproject.org/wiki/Changes/libcurlBackToOpenSSL

@liggitt may I ask why autogenerated /var/lib/kubelet/pki/kubelet.crt includes the CA:TRUE if the certificate cannot be used as a CA as per https://bugzilla.mozilla.org/show_bug.cgi?id=1049176?
        X509v3 Basic Constraints: critical
            CA:TRUE

If it doesn't, go will not allow specifying the cert as a trust root

@liggitt please correct if I misunderstand.
As in Switch to wget for integration apiserver checks (#1384), the certificate includes the certificate extensions below.
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment, Certificate Sign
        X509v3 Extended Key Usage:
            TLS Web Server Authentication
        X509v3 Basic Constraints: critical
            CA:TRUE

Based on RFC 3280, as Extended Key Usage extension is there, the certificate can be only used for a server certificate but cannot be used for CA certificate?

RFC 3280  <IP_ADDRESS>  Extended Key Usage
If the extension is present, then the certificate MUST only be used
for one of the purposes indicated.  If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present.  Certificate using
applications MAY require that a particular purpose be indicated in
order for the certificate to be acceptable to that application.
If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special keyPurposeID anyExtendedKeyUsage.  If the
anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
be critical.

I think the point in SEC_ERROR_INADEQUATE_CERT_TYPE when root CA cert has extendedKeyUsage set which was originally cited by @jpeeler stating "it can't be used to issue certificates." indicates it cannot be used as a CA certificate.

From rfc 5280, section <IP_ADDRESS>: (Extended Key Usage)
If the extension is present, then the certificate MUST only be used
for one of the purposes indicated.
If the only purpose indicated in the certificate with the extension is OCSPSigning, then it can't be used for anything other than signing OCSP responses. In particular, it can't be used to issue certificates.

Therefore, it looks to me, having CA:TRUE will not have any effect. So I wonder why it is there.
        X509v3 Basic Constraints: critical
            CA:TRUE

If the intention is to use the certificate both for CA and also TLS server certificate, then perhaps ** anyExtendedKeyUsage** could be required which may allow applications (curl in the original problem statement) to accept the cert as CA?
I suppose the wget behaviour of accepting the certificate as CA cert could be incorrect and the curl behaviour rejecting would be correct.
If above makes sense, could you reconsider the original request of "not include extended key usage"? For myself, /var/lib/kubelet/pki/kubelet.crt has the same and I cannot use it as CA cert to talk to kubelet.


Support read_mtx and read_csv

Codecov Report
Base: 81.97% // Head: 80.76% // Decreases project coverage by -1.20% :warning:

Coverage data is based on head (ad4ee9f) compared to base (b569565).
Patch coverage: 66.66% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #7      +/-   ##
==========================================
- Coverage   81.97%   80.76%   -1.21%
==========================================
  Files           3        4       +1
  Lines         294      312      +18
==========================================
+ Hits          241      252      +11
- Misses         53       60       +7

Impacted Files
Coverage Δ

src/io.jl
66.66% <66.66%> (ø)

src/mtx.jl
68.53% <0.00%> (-0.70%)
:arrow_down:

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

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


improve usability of contract functions

When passing around contract functions throughout an app, I have ended up in situations where near-api-js ends up throwing an error:
TypeError: Cannot read property 'account' of undefined

Using arrow functions ensures correct binding of these functions, so that this refers to what we expect.
Also, when passing functions throughout an app, it can be convenient to have passedFunction.name behave correctly. The second commit adds behavior for this.

@willemneal @vgrichina it looks like we do not currently have any tests for Contract. Should I add one and test this new behavior?

@willemneal @vgrichina it looks like we do not currently have any tests for Contract. Should I add one and test this new behavior?

This code is exercised indirectly in account.test.js (and probably other places). Feel free to add more specific tests!
Note that this change seems to be breaking some of existing tests.

@vgrichina I added my own test file and I think it's working. The tests pass locally and in the "Pull Request" build. However, the "Branch" build fails consistently for the ci-betanet environment – I think this might be a configuration issue, but haven't yet tracked it down. Are these failures expected right now?


create PBF to GeoJSON translator lamda

@migurski Just wanted to flag that the global z12 PBF tile set is up on CloudFront:
http://tiles.sharedstreets.io/12-{x}-{y}.{reference|intersection|geometry|metadata}.pbf
I'd love to work with you all to put a PBF -> GeoJSON lambda in front of these tiles using your GeoJSON spec. I'm curious if that's something you all would be willing to take on writing and we could host as part of the core SharedStreets API?

This is great, Kevin! We’re currently running our experimental live service using Overpass API + OSMnx. It works well but relies on the kindness of a very-dynamic backing service.

I’m new to PBF, so I have some beginner questions about reading data based on a few minutes of tinkering.
I’ve found this .proto definition for SharedStreets, and compiled it to a Python file using protoc. This is the resulting Python file.
Here’s how I’m attempting to read PBF data, and the error I see:
>>> import sharedstreets_pb2 as ss
>>> data = open('12-656-1582.pbf', 'rb').read()
>>> ss.SharedStreetsReference().ParseFromString(data)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/message.py", line 185, in ParseFromString
    self.MergeFromString(serialized)
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/python_message.py", line 1083, in MergeFromString
    if self._InternalParse(serialized, 0, length) != length:
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/python_message.py", line 1109, in InternalParse
    new_pos = local_SkipField(buffer, new_pos, end, tag_bytes)
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/decoder.py", line 850, in SkipField
    return WIRETYPE_TO_SKIPPER[wire_type](buffer, pos, end)
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/decoder.py", line 799, in _SkipGroup
    new_pos = SkipField(buffer, pos, end, tag_bytes)
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/decoder.py", line 850, in SkipField
    return WIRETYPE_TO_SKIPPER[wire_type](buffer, pos, end)
  File "/Users/migurski/Documents/SharedStreets/.venv-mvt/lib/python3.6/site-packages/google/protobuf/internal/decoder.py", line 820, in _RaiseInvalidWireType
    raise _DecodeError('Tag had invalid wire type.')
google.protobuf.message.DecodeError: Tag had invalid wire type.

Ah! So the SharedStreets tiles use length delimited encoding (the technique $GOOG recommends for files over ~1mb to allow stream processing of data). Turns out the Python Protobuf library doesn't have helper functions to parse these messages, but I found this example on how do to it:
https://www.datadoghq.com/blog/engineering/protobuf-parsing-in-python/
Just posted a quick example here using your compiled version of the .proto file:
https://github.com/sharedstreets/sharedstreets-python/blob/master/test.py

Oh, also, just made https://github.com/sharedstreets/sharedstreets-python/ public. @migurski  I'll add you to the repo now and let's move the Python specific stuff over there.

Thank you, Kevin—pip install sharedstreets is a much better experience!

Still a WIP, but check out the test.py file in the repo as an example on how to open the PBF files.

But lots of interest in Python interfaces so let's build this out to support common needs with tile data!

I have had a chance to get into this, see https://github.com/sharedstreets/sharedstreets-python/pull/3.
For our use, OSM street names are helpful. Would it be possible to get those into the OSM metadata? It’s not otherwise super useful since we're never tying things back to OSM by node or way ID, but it is very helpful to be able to show meaningful street and intersection names.
I’ve also noticed that the sample data is very detailed, with lots of service alleys and driveways included. We’ve been targeting slightly larger streets for our use, and I wonder if it would make sense to provide several different cuts of the data with varying road class cutoffs? This might also be helpful for future applications like hierarchical tile-based routing where you might want big, coarse freeway networks at lower zoom levels.


Support -ftuning_list in kernel tuning pass

-ftuning_list can indicate which op to tune in kernel tuning pass.

The pipeline logs show it could successfully run all ROCm tests but report errors in the end of the test report:
ROCM	naive_cases #1	correctness	Succeed!
ROCM	naive_cases #2	correctness	Succeed!
ROCM	naive_cases #3	correctness	Succeed!
ROCM	naive_cases #4	correctness	Succeed!
ROCM	naive_cases #5	correctness	Succeed!
ROCM	blockfusion_cases #1	correctness	Succeed!
Test execution failed.
##[error]Bash exited with code '1'.


index 0 is out of bounds for axis 0 with size 0

I am new to python and github.This is the first time i am using it.
I am getting an error when I run coding.py
Someone help me fix this error
line 118, in
image = cv2.imread(data[0])
IndexError: index 0 is out of bounds for axis 0 with size 0
coding.txt

This is because load_utiris() from datasets.py returns an empty list. First, you need to download the dataset from https://utiris.wordpress.com/ and put it into "UTIRIS V.1" directory. Alternatively, you can create your own loader that loads your data.

Thank you..


Fix Drawer

Description

In English mode, the content should be in English
In English mode, the drawer should open from left to right
In my opinion, the width is too large
The Language switcher is missing

Screenshots

Additional information
No response

looks like some Json work is needed on locales.
do you want to be assigned @noams24 ?

@Darkmift sure,
what about the rest of the issues I described?

Iirc the design has no specifics for that.
Maybe Max-content with some.padX will suffice.
As for dir....there's a hook for that to apply.

closing #239
@noams24 please add the language toggler in there as well


Add secrets patch to podman

Adds support for mounting secrets especially on RHEL where the container
can use the host subsription to run yum
Signed-off-by: umohnani8<EMAIL_ADDRESS>

@rhatdan @mheon @baude PTAL

Addresses issue https://github.com/projectatomic/libpod/issues/539

@umohnani8 Can you rebase on latest master? That should fix the test failures

rebased

"Podman run with --sig-proxy" test keeps failing. I have rebased with upstream master and don't believe I changed anything to affect this test.

@umohnani8 Can you rebase again? Upstream tests should be green

Looks good.
@rh-atomic-bot r+


address issue where when all 256 symbols are used then num_active mus…

…t be special cases to 256 instead of zero, fix int representation so that negative index value is generated when more than 127 symbols are used

Here is a script that generates a file that contains all 256 symbols, this can be used to test the patch.

cat write_bytes.tcl
set outfd [open "all_bytes.bin" "w"]
fconfigure $outfd -encoding binary -translation binary

for {set i 0} {$i < 256} {incr i} {
set c [binary format c $i]
puts -nonewline $outfd $c
puts "wrote byte value $i"
}
puts "wrote all bytes"


SIGINT not processed correctly with --dryrun option

With --dryrun the signal is not handled until execution crosses a directory boundary.
Note this example below is  sending the SIGINT from the keyboard but I first found the issue when trying to abort test run from Listener python code due to fatal error from failed api call to external software tool; in this case TestRail.
On a run without the --dryrun option sending one Ctrl-C does this:
==============================================================================
Smoke
==============================================================================
Smoke.System Test
==============================================================================
Smoke.System Test.Smoke Api Conf Verify :: Full test of GeistAPIVariables.py
==============================================================================
Test API Valid Single Value                                           | PASS |
------------------------------------------------------------------------------
Test Variable Number Of Args By Primary Name                          Second signal will force exit.
| FAIL |
Execution terminated by signal
------------------------------------------------------------------------------
Test Variable Number Of Args By Secondary Name                        | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test With Expected Value                                              | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Add Supported Camera Host Only                             | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Set URL On Supported Camera                                | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Set Username On Supported Camera                           | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Add Second Camera                                          | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Delete Of Camera                                                 | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Add Email Target                                           | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Set Email Target After Add                                 | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Delete Email Target                                        | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Add Two Email Targets                                      | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Test Valid Set Email Target After Two Added                           | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
... (rest of tests)

But with the --dryrun option sending one Ctrl-C does this:
==============================================================================
Smoke
==============================================================================
Smoke.System Test
==============================================================================
Smoke.System Test.Smoke Api Conf Verify :: Full test of GeistAPIVariables.py
==============================================================================
Test API Valid Single Value                                           | PASS |
------------------------------------------------------------------------------
Test Variable Number Of Args By Primary Name                          | PASS |
------------------------------------------------------------------------------
Test Variable Number Of Args By Secondary Name                        | PASS |
------------------------------------------------------------------------------
Test With Expected Value                                              | PASS |
------------------------------------------------------------------------------
Test Valid Add Supported Camera Host Only                             | PASS |
------------------------------------------------------------------------------
Test Valid Set URL On Supported Camera                                | PASS |
------------------------------------------------------------------------------
Test Valid Set Host On Supported Camera                               | PASS |
------------------------------------------------------------------------------
Test Valid Set Username On Supported Camera                           | PASS |
------------------------------------------------------------------------------
Test Valid Add Second Camera                                          | PASS |
------------------------------------------------------------------------------
Test Delete Of Camera                                                 Second signal will force exit.
| PASS |
------------------------------------------------------------------------------
Test Valid Add Email Target                                           | PASS |
------------------------------------------------------------------------------
Test Valid Set Email Target After Add                                 | PASS |
------------------------------------------------------------------------------
Test Valid Delete Email Target                                        | PASS |
------------------------------------------------------------------------------
Test Valid Add Two Email Targets                                      | PASS |
------------------------------------------------------------------------------
Test Valid Set Email Target After Two Added                           | PASS |
------------------------------------------------------------------------------
... (rest of tests)

With --dryrun  it  appears the signal is eventually handled.  In this run above once execution comes back up from a lower suite I start to see abort of test cases:
... (further along in run after SIGINT sent)
==============================================================================
Smoke.System Test.smoke Utility lib
==============================================================================
Test Del Test Users                                                   | PASS |
------------------------------------------------------------------------------
Test Get IPv4 GW                                                      | PASS |
------------------------------------------------------------------------------
Test API Failure Stats Error 1                                        | PASS |
------------------------------------------------------------------------------
Test API Failure Stats Error 2                                        | PASS |
------------------------------------------------------------------------------
Test App Restart Stats Error 1                                        | PASS |
------------------------------------------------------------------------------
Test App Restart Stats Error 2                                        | PASS |
------------------------------------------------------------------------------
Smoke.System Test.smoke Utility lib                                   | PASS |
6 critical tests, 6 passed, 0 failed
6 tests total, 6 passed, 0 failed
==============================================================================
Smoke.System Test                                                     | FAIL |
135 critical tests, 134 passed, 1 failed
135 tests total, 134 passed, 1 failed
==============================================================================
Smoke.Testrigs
==============================================================================
Smoke.Testrigs.smoke SensorDatabase
==============================================================================
DB Init                                                               | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------
Add                                                                   | FAIL |
Test execution stopped due to a fatal error.
------------------------------------------------------------------------------

I did not see this when first posting as that run was not crossing directory boundaries so it appeared signal was never handled.  Here is a snippet of the dir tree layout to give idea of when signal is finally handled.
smoke
├── system_test
│   ├── __init__.robot
│   ├── smoke_api_conf_verify.robot
│   ├── smoke_api_set_data.robot
│   ├── smoke_test_system_suite_setup.robot
│   └── smoke_Utility_lib.robot
├── testrigs
│   ├── __init__.robot
│   ├── smoke_SensorDatabase.robot
│   ├── smoke_SensorSwitch_port_ctrl.robot
│   ├── smoke_SensorSwitch.robot
│   └── smoke_TestRig.robot
└── toucan_gui

My guess is that nobody has ever though that someone would like to stop dry-run execution because it typically runs so fast. This is nevertheless a bug, but I don't consider it too high priority.

Yea, it is an edge case.  Maybe there is another way to accomplish what I am doing.
I have two Listeners.
The one running with dryrun is making api calls into TestRail to create the Cases (in TestRail parlance.)  This is why I run it dryrun; I do not want to execute the test, just parse thru an RF suite to ID what tests it will run  (BTW, dryrun is not very fast when each test is making an API call to TestRail. ;-) )
The other Listener runs during actual run and makes API calls to TestRail to add the result to TestRail.
I agree it is trivial.  Would not be surprised it is resolved as 'Wont Fix'.  Since RF users are Test Engineers it is ingrained to bug everything for CYA. ;-)


Updated name of login config file

Updated the name of the login configuration file in cleanup script

Good catch. Thanks.


How data is sampled?

I want to train a model for one pass (1 epoch) on fineweb_edu_10bt_shuffled. Should I pass nSteps in the config which is:
nSteps = nExamples // (batch_size * nDevice * nAccumulation) if not how else I can ensure my model is trained on all of fineweb_edu_10bt_shuffled for at least 1 epoch (exactly).

Thanks @mathuvu  for your comment.
I have a follow-up.
So if I have nDevices << nchunks then the seen nchunks (number .jsonl files) would be just nDevices and training will loop over on portion of these chunks (== nDevices) defined in config until it completes nSteps?
data:
  root_dir: data/
  sources:
    fineweb_edu_10bt_shuffled: 1.0

If so - the best way to ensure that model is seeing all of fineweb_edu_10bt  data (or any other data) is to process it first into nChunks same as nDevices? Can you please confirm? Thanks in advance.

So if I have nDevices << nchunks then the seen nchunks (number .jsonl files) would be just nDevices and training will loop over on portion of these chunks (== nDevices) defined in config until it completes nSteps?

Yes, it will loop on a subset of the data

If so - the best way to ensure that model is seeing all of fineweb_edu_10bt data (or any other data) is to process it first into nChunks same as nDevices?

You can put nchunks to 1 if you want to make things easier or nchunks == nDevices.

A paragraph has been added in readme. Thank you for your feedback!


illegal hardware instruction on text input

OS: Linux x86_64
Looks like it's caused by termbox::tb_poll_event() call in RustBox::poll_event() method (crate rustbox), but I have no idea why.

Can you give a little more info on how to reproduce this? I'm able to insert text in Linux without issue. Also what version of rustc?

rustc 1.0.0-dev (b6d91a2bd 2015-02-15 07:53:07 +0000)

Can you give a little more info on how to reproduce this?

Run iota
Press any key

Appears on a release version, a debug one works fine.

@suhr, ok, I'm seeing the problem now with the release version. Will look into it!

So this was caused from an update to termbox which added two extra fields to its event struct. rustbox uses a wrapper around the termbox API called termbox-sys which has a struct called RawEvent which is a mapping to the termbox event struct. RawEvent was missing the two new fields which were added to termbox, and it seems like adding them has fixed this.
Not sure why this was only showing in release builds, though.
Let me know if this has resolved it for you!

Yes, this have fixed an issue.


Deterministic fake embedding model

Feature request
An implementation of a FakeEmbeddingModel that generates identical vectors given identical input texts.
Motivation
Currently langchain has a FakeEmbedding model that generates a vector of random numbers, that is irrelevant to the content that needs to be embedded.
This model is pretty useful in e.g., unit tests, because it doesn't need to load any actual models, or connect to the internet.
However, there is one realistic feature it misses, which makes it "fake" compared to a realistic embedding model -- given input texts are the same, the generated embedding vectors should be the same as well.
This will make unit tests that involve using a FakeEmbeddingModel more realistic. .E.g., ou can test if the similarity search makes sense -- searching by the exact identical text from your vector store should give me an exact match, because the embeddings are identical, which gives a distance of 0.
Your contribution
I can submit a PR for it.
We can use the hash of the text as a seed when generating random numbers.
In this case, if input texts are identical, we should get exactly the same embedding vectors.

Closed by #8706


Evaluate CDash as a replacement for Autobuild

Our home-grown autobuild systems has a few disadvantages compared to other periodic

Based on inflexible shell scripts
All-or-nothing approach to testing (can only test all platforms at once, can't easily re-check a single failing build)
Output formatting issues (ie, checking quickly whether tests pass or fail, how many failed, etc.)

See also issue #33.
CDash (same authors as CMake) is a possible replacement for Autobuild widely used in the community. We could evaluate CDash through their hosted service: https://my.cdash.org
Some helpful links:

https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Using-CTEST-and-CDASH-without-CMAKE

I have a proof of concept implementation of cdash in #2587. Output is shown in https://my.cdash.org/index.php?project=Charm%2B%2B.
To test this out, you can run the following script:
#!/bin/bash

set -o errexit -o nounset

rm -rf charm
git clone --branch cdash https://github.com/UIUC-PPL/charm
cd charm
echo "set(CTEST_SOURCE_DIRECTORY \"$(pwd)\")" >> cdash/CTestCustom.cmake
echo "set(CTEST_BINARY_DIRECTORY \"$(pwd)\")" >> cdash/CTestCustom.cmake
ctest -VV -S cdash/Stages.cmake -DSTAGES="Start;Update;Build;Test"

This is currently Darwin-only but is easy to modify.


Factorial panics if floating point value is given

second PR for develop branch

Great, merging. Thanks again!

Thanks a lot. :-)


frostwire-bin: 6.9.7 -> 6.9.8

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/frostwire/versions.
meta.description for frostwire-bin is: "BitTorrent Client and Cloud File Downloader"
meta.homepage for frostwire-bin is: "https://www.frostwire.com/"
meta.changelog for frostwire-bin is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.9.8 with grep in /nix/store/m3908p1wrmrf11m311lgm80cb9ry64l5-frostwire-6.9.8
found 6.9.8 in filename of file in /nix/store/m3908p1wrmrf11m311lgm80cb9ry64l5-frostwire-6.9.8

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
frostwire-bin

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/m3908p1wrmrf11m311lgm80cb9ry64l5-frostwire-6.9.8 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A frostwire-bin https://github.com/r-ryantm/nixpkgs/archive/c41b541b22fb02bfae325446f58da81b76be148d.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/m3908p1wrmrf11m311lgm80cb9ry64l5-frostwire-6.9.8
ls -la /nix/store/m3908p1wrmrf11m311lgm80cb9ry64l5-frostwire-6.9.8/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

frostwire-bin

Maintainer pings
cc @gavinrogers for testing.

Launches.
https://blog.frostwire.com/2022/04/27/new-frostwire-6-9-8-for-windows-mac-x86-and-arm-and-linux-with-new-jlibtorrent-1-2-16-0-and-new-java-runtime-environment-18-0-1/


Register WebP in the UTI exporter

I didn't add a WebP UTI because I was sure OS X had one declared, but I'm unable to find it... Thanks!


Monkeypatch enphse env

Pull Request
Description
Add monkeypatch for environment variables to:

test_getenphse_authorization_url
test_getenphse_token_and_system

partly Fixes #152
How Has This Been Tested?
Checklist:

[x] My code follows OCF's coding style guidelines
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have checked my code and corrected any misspellings

Thanks @BraunRudolf


when path contain '[' and ']'  character, tf.data.experimental.load return an empty dataset

Click to expand!
Issue Type
Bug
Source
binary
Tensorflow Version
tf 2.8
Custom Code
Yes
OS Platform and Distribution
Linux Ubuntu 20.04
Mobile device
No response
Python version
3.9
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
11.6
GPU model and memory
No response
Current Behaviour?
when I load a dataset use tf.data.experimental.load , I get an empty dataset, but the dataset actually is not empty, the dataset was saved by tf.data.experimental.save correctly .The save path contains '[' and ']' character. If I remove '[' and ']' character , tf.data.experimental.load works fine.

Standalone code to reproduce the issue
import tensorflow as tf

tf.data.experimental.load('datasets/build/train[m]_data')

Relevant log output
No response

@xianzhuo-sky
In order to expedite the trouble-shooting process, please provide a code snippet to reproduce the issue reported here. Thanks!

@sushreebarsa I change to the latest nightly build version 'tf-nightly-2.10.0.dev20220427', and can't use  tf.data.Dataset.load .
AttributeError: type object 'DatasetV2' has no attribute 'load'

@xianzhuo-sky
In order to expedite the trouble-shooting process, please provide a code snippet to reproduce the issue reported here. Thanks!

@sushreebarsa https://colab.research.google.com/drive/18hZU3XTB4mRu783IyO6X2l8IjjP709Cp?usp=sharing

@gadagashwini I was able to replicate the issue on colab ,please find the gist here for reference .Thank you!

tf.data.Dataset has no attribute load.
tf.data.experimental.save and tf.data.experimental.load are in experimental stage.
I could able to reproduce the issue
Case1: Path with character ['']
import tempfile
import os
path = os.path.join(tempfile.gettempdir(), "/test[a]")
# Save a dataset
dataset = tf.data.Dataset.range(2)
tf.data.experimental.save(dataset, path)
new_dataset = tf.data.experimental.load(path)
for elem in new_dataset:
  print(elem)

Output
Empty
Case2: Path without character ['']
import tempfile
import os
path = os.path.join(tempfile.gettempdir(), "/test")
# Save a dataset
dataset = tf.data.Dataset.range(2)
tf.data.experimental.save(dataset, path)
new_dataset = tf.data.experimental.load(path)
for elem in new_dataset:
  print(elem)

Output
tf.Tensor(0, shape=(), dtype=int64)
tf.Tensor(1, shape=(), dtype=int64)

Uses tf.data.Dataset.save() and tf.data.Dataset.load() as tf.data.experimental.save() and tf.data.experimental.load() is getting depricated in future tensorflow versions and faced the same issue. Please find the gist here. Thanks!


Theme Manager wont work with 2 Main windows on different (STA) Threads

I have a Prism Application with a Bootstrapper and App.MainWindow (MetroWindow) running on MainThread and a seperate Login Window (also MetroWindow) running on sperate STA Thread to keep the UI responsive while Bootstrapper is running.
When switching the Theme in any situation the Application throws an exception: "The calling thread cannot access this object because a different thread owns it."

My assumption is that static Implementation and Event subscription from MetroWindow causes the Metro Window to crash when it does not belong to the Mainthread.
Thanks in advance,
Johannes

@johanneswanzek Please create and publish a sample app with your implementation of this situation. Thx!

Hello @punker76 Thanks for the fast response! :)
Please find my little Demo attached. I tried to keep it as simple as possible.
MahAppsSTAThreadApp.zip

@johanneswanzek Thank you for the sample! This helped me to find the problem. 👍


Remove JsonIgnore Annotation from getPolicyId()

Policy Id shouldn't be ignored because it is better not to add serialization capabilities in frontend apps (better performance)

Thanks @edridudi


CIV-TASK Fail script when uploads fail

JIRA link (if applicable)
N/A
Change description
Fails the script when an upload fails, to prevent the build from running only to fail at a latter stage like functional tests and so on.
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Once this is merged, go back to the following and mark the appropriate conversations as resolved, leaving a comment as well:
https://github.com/hmcts/civil-ccd-definition/pull/2250/files


Vapo followup

Description
Adding links table to the VAPO notebook.

Can you fix the merge issues with this branch? Maybe do a rebase from main and re-add the new changes.

Not sure if the commit history was done correctly. It might make sense to just create a new branch from main and add your changes to that instead.

Can you fix the merge issues with this branch? Maybe do a rebase from main and re-add the new changes.

Thanks created another PR from scratch. I will close this.


Theming reloaded

The current theming approach is quite painful and confusing. It was presented a couple of years ago in this RFC and—while at the time it was a clear improvement to the box-all-the-styles approach we had—it introduced a whole new set of moving parts. Way too many moving parts.
A simple use case
Let's say we are a new user and we want to change the style of a button. Quite a simple use case, certainly. We search for "button style" in the API reference (yes, the API is actually somewhat documented!) and we find the Button::style method. Great! But wait, what is... this?!
pub fn style(
    self,
    style: impl Into<<Theme as StyleSheet>::Style>
) -> Button<'a, Message, Theme, Renderer>

How do we even use this? What is style supposed to be exactly? We have a generic Theme which implements a StyleSheet trait which has an associated Style type. Three moving parts! So we need to figure out first the specific Theme type we are dealing with, find its StyleSheet implementation, look at the Style associated type and then learn how to use that. But... I just want to change the color of a button! How hard can that be?!
The current system is terribly complicated; and I have wanted to revisit and redesign it for a while. It seems that time has finally come.
Functions all the way down
What would the ideal style method look like? It should let the user easily customize the appearance of a widget based on its current status without much friction.
The only reason to have StyleSheet traits is to allow users to define different appearances for each particular widget status (like active, hovered, disabled, etc.). However, if we encode the widget status as data we can then leverage a single entrypoint for the whole appearance of a widget! A simple function!
pub fn style(
    self,
    style: fn(&Theme, Status) -> Appearance,
) -> Button<'a, Message, Theme, Renderer>

Thus, widget style is defined using a function pointer that takes the current Theme and some widget Status (if the widget is stateful) and produces the final Appearance of the widget.
There is only one moving part here: the generic Theme type. However, if you are not using a custom theme, this will always be the built-in Theme. And if you are using a custom theme, then you are probably already familiar with the Theme generic type.
We can easily change our button color now:
button("I am red!")
    .style(|_theme, _status| button::Appearance::default().with_background(color!(0xff0000)))

We can even make a style helper for our red buttons:
fn red_button(_theme: &Theme, _status: &button::Status) -> button::Appearance {
    button::Appearance::default().with_background(color!(0xff0000))
}

And using it is straightforward:
button("I am red!").style(red_button)

Each widget module exposes some built-in style helpers that are readily available. For instance, button exposes primary, secondary, success, danger, and text. Using them is analogous to the previous example:
button("I am the danger!").style(button::danger)

Since styles are just functions, this means you can easily compose and extend existing styles:
fn rounded_primary(theme: &Theme, status: Status) -> button::Appearance {
    button::Appearance {
        border: Border::with_radius(10),
        ..button::primary(theme, status)
    }
}

I think this design is glaringly simple; and it was the obvious approach all along. I guess it's not so easy to escape my past trauma as a web developer...
Capturing state
But wait! If styles are just function pointers and not closures... Does that mean that we cannot style widgets based on application state? Let's say we have a Color in our state. Can we use it to style a widget? Yes, thanks to the new themer widget!
The themer widget introduced in #2209 can be used to change the Theme type for a subtree of the widget tree. This means we can set our Color as the Theme generic type and use that in our style function. For instance:
themer(
    color,
    button("I am dynamic!").style(|color, _status| button::Appearance::default().with_background(color)),
)

In fact, since Color can be directly used as the default style of a button, we can just write:
themer(color, button("I am dynamic!"))

By making this kind of dynamism opt-in, we avoid either boxing closures or introducing yet another generic type to all the widgets.
Custom themes
Finally, custom themes do not need to worry about a myriad of StyleSheet traits and Style enums anymore. Instead, they only need to implement the DefaultStyle trait of each widget. For instance, let's say we have a custom theme named MyCustomTheme and we want all of its buttons to be red by default (oh god, why):
impl button::DefaultStyle for MyCustomTheme {
    fn default_style() -> fn(&Self, button::Status) -> button::Appearance {
        red_button
    }
}

And that's all! I think this considerably simplifies the most painful part of iced :partying_face:

This entire PR is looking great to me! I've already tried to upgrade some of my apps using this and it feels really good.
I also really like the DefaultStyle implementation which should simplify custom themes quite a lot. And I also like the way you made it work with the Themer widget like this:
themer(
    color,
    button("I am dynamic!").style(|color, _status| button::Appearance::default().with_background(color)),
)

There is only one problem I can see with it right now. This works because you've implemented the button's DefaultStyle trait to Color. You've also done so for the container, as did you for the gradient, so that you can you this on the gradient example:
let gradient_box = themer(
    gradient,
    container(horizontal_space())
        .width(Length::Fill)
        .height(Length::Fill),
);

The problem is that the themer propagates the NewTheme to all its contents, so if we've tried to add some other content to that container like this:
        let gradient_content = column![
            text("Input:"),
            text_input(
                "placeholder",
                if self.transparent { "transparent" } else { "not transparent" }
            ),
            horizontal_space(),
        ];

        let gradient_box = themer(
            gradient,
            container(gradient_content)
                .width(Length::Fill)
                .height(Length::Fill),
        );

It would fail because TextInput doesn't implement it's DefaultStyle for Gradient or Gradient::Linear. And the user can't implement it either because of the orphan rule. This means that every implementation done like this for the container would have to be done on every widget that has an Appearance.
It also means that if the user wants to change something else besides the ones you've implemented in a dynamic way, it is not possible. For example, let's say I an application where I want the border width of some container to change according to some value on my App, how would I do that? We can't do this:
container(gradient_content)
.style(|t, s| {
    let width = if self.transparent {
        2.0
    } else {
        1.0
    };
    container::Appearance {
        border: iced::Border {
            color: Color::BLACK,
            width,
            radius: 0.0.into(),
        },
        ..container::bordered_box(t, s)
    }
});

Because of [E0308] closures can only be coerced to fn types if they do not capture any variables. So the Themer would be the obvious choice, but since you haven't implemented container::DefaultStyle to Border I can't do this:
let border = iced::Border {
    color: Color::BLACK,
    width: if self.transparent { 2.0 } else { 1.0 },
    radius: 0.0.into(),
};
let c = themer(
    border,
    container(gradient_content)
);

I'm not sure what the solution should be other than implementing every widget's DefaultStyle for every Appearance property that they can have like Border, Background, Color, Shadow, Scrollbar... And implement all of the properties for all the container like widgets that can have content and an appearance like Container, Button, Menu, PickList, ComboBox...

The problem is that the themer propagates the NewTheme to all its contents, so if we've tried to add some other content to that container like this:

You can nest themers.

It also means that if the user wants to change something else besides the ones you've implemented in a dynamic way, it is not possible.

You can use anything as the new theme:
themer((theme, self.transparent), ...)

We just need to add a with_style constructor for most widgets that skips the DefaultStyle bound. Some of them already have this, like Menu and Scrollable.

Until then, Themer::new accepts a closure that allows derivation from the current theme:
Themer::new(
    move |theme| {
        let width = if self.transparent {
            2.0
        } else {
            1.0
        };
        container::Appearance {
            border: Border {
                color: Color::BLACK,
                width,
                radius: 0.0.into(),
            },
            ..container::bordered_box(t, s)
        }
    },
    my_container,
)

You can use anything as the new theme:
themer((theme, self.transparent), ...)

This doesn't work with the error that the container doesn't implement DefaultStyle for (_, _).
So I've tried using the nested Themer to have the inner content use the app's theme again but the compiler still complains and I can't seem to figure out why. Here is what I'm doing:

The full code:
use iced::application;
use iced::widget::{
    checkbox, column, container, horizontal_space, row, slider, text, text_input, themer, Themer
};
use iced::{gradient, window};
use iced::{
    Alignment, Color, Element, Length, Radians, Sandbox, Settings, Theme,
};

pub fn main() -> iced::Result {
    tracing_subscriber::fmt::init();

    Gradient::run(Settings {
        window: window::Settings {
            transparent: true,
            ..Default::default()
        },
        ..Default::default()
    })
}

#[derive(Debug, Clone, Copy)]
struct Gradient {
    start: Color,
    end: Color,
    angle: Radians,
    transparent: bool,
}

#[derive(Debug, Clone, Copy)]
enum Message {
    StartChanged(Color),
    EndChanged(Color),
    AngleChanged(Radians),
    TransparentToggled(bool),
}

impl Sandbox for Gradient {
    type Message = Message;

    fn new() -> Self {
        Self {
            start: Color::WHITE,
            end: Color::new(0.0, 0.0, 1.0, 1.0),
            angle: Radians(0.0),
            transparent: false,
        }
    }

    fn title(&self) -> String {
        String::from("Gradient")
    }

    fn update(&mut self, message: Message) {
        match message {
            Message::StartChanged(color) => self.start = color,
            Message::EndChanged(color) => self.end = color,
            Message::AngleChanged(angle) => self.angle = angle,
            Message::TransparentToggled(transparent) => {
                self.transparent = transparent;
            }
        }
    }

    fn view(&self) -> Element<Message> {
        let Self {
            start,
            end,
            angle,
            transparent,
        } = *self;

        let gradient = gradient::Linear::new(angle)
            .add_stop(0.0, start)
            .add_stop(1.0, end);

        let inner_content = themer(
            iced::Sandbox::theme(self),
            column![
                text("Input:"),
                text_input(
                    "placeholder",
                    if self.transparent { "transparent" } else { "not transparent" }
                ),
                horizontal_space(),
            ]
        );

        let content_themer = Themer::new(
            move |theme| {
                let width = if self.transparent {
                    2.0
                } else {
                    1.0
                };
                container::Appearance {
                    border: iced::Border {
                        color: Color::BLACK,
                        width,
                        radius: 0.0.into(),
                    },
                    ..container::bordered_box(theme, container::Status::Idle)
                }
            },
            container(inner_content)
            .width(500)
            .height(200)
        );

        let gradient_box = themer(
            gradient,
            // HERE IS WHERE IT COMPLAINS:
            // Diagnostics:
            // 1. the trait bound `iced::advanced::iced_graphics::iced_core::Element<'_, _, iced::gradient::Linear, _>: std::convert::From<iced::widget::Container<'_, Message>>` is not satisfied
            //    the following other types implement trait `std::convert::From<T>`:
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Column<'a, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::MouseArea<'a, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Row<'a, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Themer<'a, Message, Theme, NewTheme, F, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Button<'a, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Checkbox<'a, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::ComboBox<'a, T, Message, Theme, Renderer>>>
            //      <iced::advanced::iced_graphics::iced_core::Element<'a, Message, Theme, Renderer> as std::convert::From<iced::widget::Container<'a, Message, Theme, Renderer>>>
            //    and 25 others
            //    required for `iced::widget::Container<'_, Message>` to implement `std::convert::Into<iced::advanced::iced_graphics::iced_core::Element<'_, _, iced::gradient::Linear, _>>` [E0277]
            container(content_themer)
                .width(Length::Fill)
                .height(Length::Fill),
        );

        let angle_picker = row![
            text("Angle").width(64),
            slider(Radians::RANGE, self.angle, Message::AngleChanged)
                .step(0.01)
        ]
        .spacing(8)
        .padding(8)
        .align_items(Alignment::Center);

        let transparency_toggle = iced::widget::Container::new(
            checkbox("Transparent window", transparent)
                .on_toggle(Message::TransparentToggled),
        )
        .padding(8);

        column![
            color_picker("Start", self.start).map(Message::StartChanged),
            color_picker("End", self.end).map(Message::EndChanged),
            angle_picker,
            transparency_toggle,
            gradient_box,
        ]
        .into()
    }

    fn style(&self, theme: &Theme) -> application::Appearance {
        if self.transparent {
            application::Appearance {
                background_color: Color::TRANSPARENT,
                text_color: theme.palette().text,
            }
        } else {
            application::default(theme)
        }
    }
}

fn color_picker(label: &str, color: Color) -> Element<'_, Color> {
    row![
        text(label).width(64),
        slider(0.0..=1.0, color.r, move |r| { Color { r, ..color } })
            .step(0.01),
        slider(0.0..=1.0, color.g, move |g| { Color { g, ..color } })
            .step(0.01),
        slider(0.0..=1.0, color.b, move |b| { Color { b, ..color } })
            .step(0.01),
        slider(0.0..=1.0, color.a, move |a| { Color { a, ..color } })
            .step(0.01),
    ]
    .spacing(8)
    .padding(8)
    .align_items(Alignment::Center)
    .into()
}

I'm probably doing something wrong. But still haven't find out what...
From what I understand there is no problem if the content of the container to which we are giving the gradient with themer has no content that requires an appearance, like Text, Space... But if the content needs to have an appearance from a Theme it complains, because we will have elements of type Element<'a, Message, Theme, Renderer> along with elements of type Element<'a, Message, gradient::Linear, Renderer> which doesn't work.
How would you approach something like this?

Oh I see it now. The problem is here:
        let content_themer = Themer::new(
            move |theme| {
                let width = if self.transparent {
                    2.0
                } else {
                    1.0
                };
                container::Appearance {
                    border: iced::Border {
                        color: Color::BLACK,
                        width,
                        radius: 0.0.into(),
                    },
                    ..container::bordered_box(theme, container::Status::Idle)
                }
            },
            container(inner_content)
            .width(500)
            .height(200)
        );

When using the above it is expecting the incoming theme (OldTheme) to be an iced::Theme but is isn't it is a gradient so we need to change it here already not only on the inner_content like I was doing. The inner_content still needs it because here we are changing the NewTheme to a container::Appearance. Like this:
        let inner_content = themer(
            iced::Sandbox::theme(self),
            column![
                text("Input:"),
                text_input(
                    "placeholder",
                    if self.transparent { "transparent" } else { "not transparent" }
                ),
                horizontal_space(),
            ]
        );

        let content_themer = Themer::new(
            move |_theme| {
                let width = if self.transparent {
                    2.0
                } else {
                    1.0
                };
                container::Appearance {
                    border: iced::Border {
                        color: Color::BLACK,
                        width,
                        radius: 0.0.into(),
                    },
                    ..container::bordered_box(&iced::Sandbox::theme(self), container::Status::Idle)
                }
            },
            container(inner_content)
            .width(500)
            .height(200)
        );

This way it works! Thank you for the explication!

@alex-ds13 If it's just a simple toggle, why not something like this?
container(column![...])
    .style(if self.transparent { thin_bordered_box } else { container::bordered_box })

This was just an experiment to see if I could still change some appearance aspects according to the App's state. But yes that would make sense for this case.
Even the case I'm using right now could be done like that. I'm using a modal to show the errors of the app and I want that modal to always have the same theme and look, regardless of the app's theme. I'm using a Themer for that. The errors inside it then have different appearances according to their severity. So I need the content inside the themer to be able to change their style according to the app's state. Which can be done like that by matching on the error's severity and have a different style function for each one.

@alex-ds13 Remember that you can always implement your own sub-theme for just the modal and implement DefaultStyle for any of the widgets it uses.
// modal.rs
pub enum Theme {
    Information,
    Warning,
    Error(error::Severity),
    // ...
}

impl container::DefaultStyle for Theme {
    // ...
}

impl text_input::DefaultStyle for Theme {
    // ...
}

Then:
themer(modal::Theme::Error(self.error.severity()), modal::view())

@alex-ds13 #2326 should let you use closures now!


docs: Proto field comment updates, edit general gRPC API warning

fix: Clear storage_grpc_service_config.json to avoid nested retry strategies

(This is the only result of regenerating all APIs. I suspect Storage.v2 was lost in some of the more unusual PRs last week.)


New snippet format

New snippet format in .snippet files
Should work everywhere and not just specific editors
Existing snippet implementation that was disabled by default has been removed as discussed
For now only supports insertion snippets and insertion snippets with a phrase. Supporting wrapper snippets requires Cursorless and so far we don't have mechanism for adding Cursorless specific stuff in community.

Discussion points

This pr contains all of my own snippet definitions. Do we want this or do we want community to start with more of a blank slate?

Fixes #848

@pokey @josharian Please give this a try :)

I vote to keep all your snippets.

@pokey raised the issue that my list names are not that easy to understand. I view the word snippets as in namespace. Nice when you look in the debug window that they are sorted next to each other. To people have any suggestions
current: snippet_insert, snippet_insert_with_phrase, snippet_wrap
snippet_insertion?
snippet_insertable?

@pokey raised the issue that my list names are not that easy to understand. I view the word snippets as in namespace. Nice when you look in the debug window that they are sorted next to each other. To people have any suggestions
current: snippet_insert, snippet_insert_with_phrase, snippet_wrap
snippet_insertion?
snippet_insertable?

I thought they were fine, but if pressed I'd be inclined to ditch insert. Aren't all snippets insertable after all? 😃
snippet
snippet_with_phase
snippet_wrapper

@pokey raised the issue that my list names are not that easy to understand. I view the word snippets as in namespace. Nice when you look in the debug window that they are sorted next to each other. To people have any suggestions
current: snippet_insert, snippet_insert_with_phrase, snippet_wrap
snippet_insertion?
snippet_insertable?

I thought they were fine, but if pressed I'd be inclined to ditch insert. Aren't all snippets insertable after all? 😃
snippet snippet_with_phase snippet_wrapper

True.

Ok I did some local testing; works great! The only thing I noticed is that the phrases are always unanchored. For almost all of the snippets, this feels like the right thing, but it definitely bit me for "snip comment", where anchoring would prob be better as that is more of a prose formatter thing. But that feels out of scope for this PR; happy to have that be follow-up work


Building is broken from "scripts"

If I run
./node_modules/@danielx/civet/dist/civet test.civet
everything is fine.
But if I add a script in package.json:
"scripts": {
     "test": "civet < ./test.civet > ./test.ts"
}

and try to run it with
npm run test
I get:
/dev/fd/test.civet failed to load:
[Error: ENOENT: no such file or directory, open '/dev/fd/test.civet'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/dev/fd/test.civet'
}

The above worked 0.4.38, I just updated to 0.5.36 and it doesn't work anymore.

What operating system are you using?
Does ./node_modules/@danielx/civet/dist/civet < test.civet > test.ts work on the command line?
Does civet test.ts -o test.civet work as a script?

It's working for me on WSL with Civet v0.5.37 and v0.5.28 just for an added data point.

@edemaine

What operating system are you using?

I'm on an apple silicon mac.
Running uname -mprs produces
Darwin 21.6.0 arm64 arm in Terminal and
Darwin 21.6.0 x86_64 i386in VSC, I guess that's under Rosetta.
Regarding the results for each command there's no difference whether I run them in the native Terminal or VSC's terminal.

Does ./node_modules/@danielx/civet/dist/civet < test.civet > test.ts work on the command line?

Nope, it doesn't, in either terminal.

Does civet test.ts -o test.civet work as a script?

Do you mean civet test.civet -o test.ts?
Yes! That works as a script in both native and rosetta terminal.

Yes! That works as a script in both native and rosetta terminal.

A simple civet test.civet also works as a script.
"scripts": {
        "civet2": "civet test.civet"
 }

Sorry, I meant civet -c test.civet -o test.ts as an alternative way to transpile.
I'll try testing on a Mac myself.

Sorry, I meant civet -c test.civet -o test.ts as an alternative way to transpile.

Oh, gotcha, yes, that also works as a script.

Ok, so it's just the pipe form that's broken, so you should be set for a workaround. But we appreciate the report and will investigate!

Yepp, sure am! Thanks for your help!

I confirmed the buggy behavior on a Mac (probably any Unix actually). Should be all fixed on the latest version of Civet!


Some ideas

Hi,
I would like to make some suggestions to improve your plugin for fast typing :

Allow word prioritization in the list according to the frequency of the words used in the hole vault => More frequent words show at the top of the list .
Or/and according to the frequency of the words in the
Allow creating shortcut for inserting word. First choice => insertion key (enter or tab). Second, third and fourth choice => personal shortcuts or/and personal shortcuts for up/down (as it is not optimal to use arrows while typing)
Allow to ban words and also to add list of blacklisted words. In my case, I've a mix of english and french in my vault due to the fact I'm writing in french, but a lot of readings are in english and I copy paste somme parts. Here it would be great to have the possibility to ban all english words (using a list provided here https://github.com/kpym/FrequencyDictionaries)

Many thanks for your work !
Enjoy your day,
Michaël

Hey, thanks for the feedback!

Word prioritization based on frequency is definitely planned
The reason I've opted to use a simple dropdown with two keys is because Obisdians keybind system is integrated with the command system, I didn't really want to add to commands for these simple actions. I'll look into it again though.
Good idea. I guess this should be case-insensitive, right?

Great ! Thanks for your work !

Hi! About word prioritization , are you planning to add it also for LaTex commands?

Hi! About word prioritization , are you planning to add it also for LaTex commands?

Yes. I think that would make sense

@Oskiator Basic blacklist feature is now avaiable!

@Oskiator Basic blacklist feature is now available! Let me know if it fits your needs

Hi, I'm sorry, for now, I'm unable to test it "deelpy". Got a tendinitis on both wrist, so I stopped using obsidian, waiting for full recovery. But I thank you for that great option.
I just checked the options of the plugin. I wasn't able to find it, Has it been implemented in the last update ?
All the best !

No problem. There's no specific setting for it. You can check the README to see how it works.


New package: Aserto.Topaz version 0.30.10

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

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

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree [company="Aserto"]

@microsoft-github-policy-service agree company="Aserto"


Avoid continuous destroy and create of azapi_resource diag_settings

Overview/Summary
Fixed the destroy and create of azapi_resource diag_settings. This PR is linked with the issue #939 .
This PR fixes/adds/changes/removes

Adds The Variable diag_settings_location
Enables Users to override the value location in azapi, to avoid continuous destroy and create of azapi_resource diag_settings
Solves the Issue #939

As part of this Pull Request I have

[x] Checked for duplicate Pull Requests
[x] Associated it with relevant issues, for tracking and closure.
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[ ] Performed testing and provided evidence.
[ ] Updated relevant and associated documentation.

@microsoft-github-policy-service agree

@Keetika-Yogendra please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”), and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your contributions to Microsoft open source projects. This Agreement is effective as of the latest signature date below.

Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to Microsoft under this Agreement.
“Project” means any of the projects owned or managed by Microsoft and offered under a license
approved by the Open Source Initiative (www.opensource.org).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
Originality of Work. You represent that each of Your Submissions is entirely Your original work.
Should You wish to Submit materials that are not Your original work, You may Submit them separately
to the Project if You (a) retain all copyright and license information that was in the materials as You
received them, (b) in the description accompanying Your Submission, include the phrase “Submission
containing materials of a third party:” followed by the names of the third party and any licenses or other
restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
guidelines concerning Submissions.
Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
Licenses.

Copyright License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
parties.
Patent License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.

Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
You later become aware that would make Your representations in this Agreement inaccurate in any
respect.
Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
defenses of lack of personal jurisdiction and forum non-conveniens.
Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.

@microsoft-github-policy-service agree

Hi!
Do you think we should use the default location that is supplied as an input already? is there a case for them being different?

Thank you for your PR! A few comments on the implementation but really appreciate the effort

closed in favour of #968 thank you for your PR, I have taken the fix and ported it across


Allow batchSize to be any numeric type

FerretDB version
commit.txt: 43a40249aef7a8abef0eb956a6263111051ac5c9
package.txt: docker-local
branch.txt: main
version.txt: v1.2.0-13-g43a40249-dirty
Backend
PostgreSQL
Environment

OS: Ubuntu 22.10 x86_64
Deployment: v1.2.0-13-g43a40249-dirty
Deployment details: Deployment details: 23.0.3

What did you do?
Some options are loosely typed in the mongo shell but are then parsed according to type constraints in MongoDB. All numeric types are stored as doubles, and because of this I suspect they will silently fail a lot of cursor related jstests. We should probably handle this.
mongo --quiet --eval 'db.foo.find({}).batchSize(1);'

What did you expect to see?
That the batchSize was parsed to an int32.
What did you see instead?
Error: error: {
	"ok" : 0,
	"errmsg" : "BSON field 'batchSize' is the wrong type 'double', expected type 'int'",
	"code" : 14,
	"codeName" : "TypeMismatch"
}

See also:
// response from MongoDB in legacy shell
---
> db.foo.find({}).batchSize("a")
Error: error: {
	"ok" : 0,
	"errmsg" : "BSON field 'FindCommandRequest.batchSize' is the wrong type 'string', expected types '[long, int, decimal, double']",
	"code" : 14,
	"codeName" : "TypeMismatch"
}

Duplicate of #2005


feat: PLNSRVCE-1087 Test Tekton Result stored in the persistent storage

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Issue ticket number and link
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:

[x ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/jira refresh

/hold

https://github.com/tektoncd/results/blob/main/pkg/apis/v1alpha2/types.go?

@flacatus This is to match Kubernetes object types, which will match with the data field in the response only. Not the whole response itself. For this test, it just verify if the record item >= 1.

/hold

/unhold


Add support for GCS

Add support for Google Cloud Storage.

Hi @alunarbeach This is in our roadmap and will be worked on soon. Meanwhile, its not hard to get it working. You will need these steps. Try it out if you need to hack something quickly (will be great if you can contribute too)

Add GCS Maven dependencies
Google has their own FileSystem impl for GCS. Look at https://cloud.google.com/hadoop/google-cloud-storage-connector
You need to change hdfs-site.xml to include GCS specific properties and authentication details.

With the above steps, you must be able to get streamx to write to GCS.

@alunarbeach I have added GCS support, tested and pushed the changes.  Please try it out and let us know if you see any issues.
Provide GS destination in "s3.url" config itself. Will refactor StreamX later. (You will have to use S3SinkConnector as if you are using S3 itself and just provide GS location in s3.url)
Thanks

Thanks @PraveenSeluka. will try this out soon.


SSL_ERROR_BAD_CERT_DOMAIN with https://rusty-rain.xyz/ web site.

Just to let you know that the website has a cert error.

Interesting!   Thank you!

this has been fix


Prl 4363 4697 combined

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)
[ ] the enable_keep_helm label has been added, if the helm release should be persisted after a successful build

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/PRL-4363
https://tools.hmcts.net/jira/browse/PRL-4697
Change description
Removing other option and hint text changes
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

No longer needed as covered in https://github.com/hmcts/prl-ccd-definitions/pull/1709


Cleaned up indentation

There was a mixture of tabs and space used for indentation. I converted everything to tabs.

Pulled in master from fork queue.


extend: add os_specifiable (for on_macos/on_linux)

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew tests with your changes locally?
[ ] Have you successfully run brew man locally and committed any changes?

This PR adds a module named OSSpecifiable (I'm open to other names) that can be included in a class to define the methods on_macos and on_linux
This reduces code duplication and should allow #9421 and #9438 to each be simplified to a single include statement

Review period will end on 2020-12-08 at 03:01:45 UTC.

Review period ended.


⚠ Bofrost.be has degraded performance

In 7396b5d, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1896 ms

Resolved: Bofrost.be performance has improved in 1fffad3.


ReferenceError: window is not defined break SSR

Please follow the issue template below. Failure to do so will result in a delay in answering your question.

Library

[ ]<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[x]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>
Important: Please fill in your exact version number above, e.g<EMAIL_ADDRESS>Framework
n/a
Description
When trying to SSR the code, window not being defined causes the SSR to fail
Error Message
ReferenceError: window is not defined
    at Function.BrowserUtils.getBrowserNetworkClient (PATH_TO_PROJECT/node_modules/@azure/msal-browser/src/utils/BrowserUtils.ts:67:9)

Security

[ ] Is this issue security related?

Regression

[x] Did this behavior work before?
Version:
1.3

MSAL Configuration
n/a
Reproduction steps
import MSAL and try SSR'ing
Expected behavior
the code should be more sensitive to window not being defined
Browsers/Environment
node. Yes, I know this a browser-based package, trying to SSR for the browser! Perhaps delaying the call that checks for window (or probably fetch) until runtime would help.
Thanks!

@mbrevda This is a known issue that we intend to fix. We will follow up when we have done so.

I hate to ask, but can you give a unit of measure for an ETA (days/weeks/months)?

@mbrevda Unfortunately, we are not able to give a more specific timeline yet, but we would like to have this fixed soon.

@mbrevda There is now a PR open to fix this scenario, and will be included in an upcoming release of MSAL.js v2. This issue will be updated when that PR has been accepted and merged.

I saw, thanks for pointing it out! Looking forward to the release


Failed to start container - "unauthorized" in a public repo

I'm trying to start an instance running prometheus like this
gcloud beta compute instances create-with-container prometheus \
 --container-image quay.io/prometheus/prometheus:v2.1.0

but I keep getting this error:
data:  "2018/02/05 14:55:36 Error: Failed to start container: Error response from daemon: {"message":"Get https://quay.io/v2/prometheus/prometheus/manifests/v2.1.0: unauthorized: Invalid Username or Password"}"
Is downloading public docker images supported? What am I doing wrong?

Hi,
This is not intended. It looks like we've been passing the GCE-specific Oauth2 token everywhere, and this undestandably fails for a repository that does not recognize it.
I will publish a fix today, however it might take a moment to release it.

Has this been fixed/released?
I'm also seeing this just now for the Elasticsearch registry:
docker.elastic.co/elasticsearch/elasticsearch:5.6.8

Hi,
The fix has been merged, but it is not yet released. With the current version domains other than gcr.io (for public/private containers) and docker.io (public only) may not work.

Thanks @pderkowski  - for now I've mirrored the image I need to GCR.

This has been fixed some time ago. Closing.


used compatible version for optional chaining

partial fox for issue (https://github.com/Chia-Network/chia-blockchain/issues/1384) with starting electron app on Ubuntu

Ubuntu has preinstalled the old version of Node which has no support for JavaScript optional chaining. We are transpiling the application. But the main starting script for the Electron application is not using it. I will change it in the next refactoring cycle.
You can find more information about this issue here https://github.com/Chia-Network/chia-blockchain/issues/1384#issuecomment-805916769.


Request: Example using OAuth1.0 with Yahoo

First off, just wanted to say thanks for all the great work you've done with Satellizer. Its awesome!
I'm currently working on a MEAN app to utilize the Yahoo Fantasy Sports api (which is still on Oauth1.0) and I can't figure out how to request a token, use this token to request auth, and then receive and access token to hit the Fantasy Sports api. I've tried to follow your steps in the README, but without any luck.
Would you, or someone, be able to post an example of how to do this? Thanks so much!

@lsbyerley You should ask this question on Stack Overflow or Gitter chat room. Otherwise it becomes really hard to keep track of actual issues with the library.
Personally, I have never dealt with Yahoo's OAuth 1.0 flow, hence the example is using OAuth 2.0 authorization protocol.
You have all the tools you need: ability to create custom OAuth 1.0 and OAuth 2.0 providers with Satellizer, straightforward server-side examples without any library magic demonstrating both OAuth 1.0 and OAuth 2.0 flow. So all you really need to is to research how other people deal with Yahoo Fantasy Sports API. That, however, is outside the scope of this project.


Customization via custom components

I think that it's a common requirement to heavily customize the appearance of documentation.
Now I should create a local copy of nextra-theme-docs and customize the style with all the @apply Tailwind directives.
In this way I loose the ability to keep my project updated with nextra-theme-docs new features and the style can become quite messy.
Wouldn't it be better to have nextra-theme-docs more "headless", just creating the structure and accepting as config components for H1, H2, SidebarLink etc?
Since I already have Tailwind in my project, I could create these components already styled and dark-mode ready and pass them to the headless nextra-theme-docs.
What do you think about it?

I think the theme can provide some component extensibility, like accepting H1~H2 in the theme config. But for styles, ultimately you will have to write your own CSS to fully customize it.
So I feel the best way is to import your own CSS inside _app.js, instead of "nextra-theme-docs/style.css" (or you can import and override some styles).

Thank you, Shu.


Adapt replication batch size dynamically

Currently the number of events that are replicated through a single akka-message is fix (eventuate.log.write-batch-size) (if enough events wait for replication). If the binary representation of the resulting message exceeds the akka-remote frame size (akka.remote.netty.tcp.maximum-frame-size) the message is dropped at the source and the replication essentially stops as each retry results in the same error. A problem like this can only be fixed by re-configuring ether eventuate.log.write-batch-size or akka.remote.netty.tcp.maximum-frame-size and restarting the application (or at least the actor-system).
To avoid a restart in these situations eventuate could either adapt the replication batch size dynamically (for example if n (n>=1) replication requests did not receive a response, the batch size is reduced incrementally by factor f1 (f < 1) until a replication response is received. After that the batch-size can be increased again either incrementally (by factor f2) or at once to its original size.
Alternatively the batch-size is no longer measured in number of events but rather in number of bytes.

Some thoughts: an implementation that can determine the total number of bytes on sender-side would probably result in the most efficient replication algorithm (without changing too much).
The receiver would then probably have to request either

"at-most-n" events (allowing the receiver to apply some primitive form of back-pressure), or
"as many as fit in the batch" events (to achieve a large throughput)

The feasibility of 2. probably depends on:

if it is possible to determine an upper bound for the protocol overhead in which the actual batch is embedded
if we can determine the serialized size of the events batch. AFAICR ad hoc the serialization is done by Akka so it is not clear to me if this is possible.

I'd be happy to help in both discussion and implementation ;-)