Zorag Stubbornly Neutral (?Spoiler)

It's been a while but I'm having another play with Eamon:  I've just played through The Treachery of Zorag.  It's terrific but my overall impression is that it can be a bit finicky.  I note that in issue 77 you had a similar problem with Boris to the one I'm describing here.
I've managed to find my way through all the various plot points up until nearly the very end:  I've freed Zorag and am willing to have him join my party and see what happens, but he remains neutral and planted in his room.  I've offered him gold, a weapon, said yes and join us and okay and let's go and a whole lot of other words but Zorag just shrugs.
Am I missing something vital or just not using the right form of words?

Figured it out.  I wasn't using the correct form of words.
I won't post a spoiler here unless someone else has the same problem I did.

(I did have to dig into the code to figure it out)


Popover, getting _oControl for "addEventDelegate" but not for "removeEventDelegate"

When calling addEventDelegate, it attaches event on _oControl, but when calling removeEventDelegate it tries to remove events directly from Popup object.
I am not sure but it looks like "removeEventDelegate" should also be added to the array of forwarded functions on Line:764: https://github.com/SAP/openui5/blob/15d16f5322fcca1342e4b09776dd81162bf5e30a/src/sap.m/src/sap/m/ResponsivePopover.js#L764

Hello @derxe,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Niya


Dask Array's constant pad coerces array to NumPy ndarray

Currently Dask Array's pad (when using the constant mode) may end up coercing array data of a different array type to a NumPy ndarray. For example, the following code will result in a NumPy ndarray.
a_gpu_pad = da.pad(a_gpu, 1, "constant")
a_gpu_pad.compute()

This still happens if we try to set the constant_values differently. If we provide a 0-D array, we run into issue ( https://github.com/dask/dask/issues/4841 ).

@pentschev, do you have any thoughts on how best to handle this or issue ( https://github.com/dask/dask/issues/4841 )?

Seems like they should be treated as part of #4543, I'll check this and #4841 next.

Thanks Peter!

Is this resolved by the _meta PR?

No, unfortunately da.pad relies on da.asarray, which in turn relies on np.asarray. We've started a discussion on how to deal with those cases in #4883.
If this particular case (constant padding) is needed immediately, I think we could use *_like functions instead, but to solve pad more generally we will require to deal with the cases I mentioned above.

The one downside of using _like is it creates a dependency on the data in the array. That said, if this is as close as we can get to the right behavior here, this seems like the best way to resolve this issue.

@mrocklin @jakirkham just wanted to ping this issue to get help promote.  Any tips on solving the coercion issue for cupy arrays in the cupy_backed_array.map_overlap(..., boundary=0.) case?

@mrocklin @jakirkham just wanted to ping this issue to get help promote it.
Any tips on solving the coercion issue for cupy arrays in the cupy_backed_array.map_overlap(..., boundary=0.) case?

The original issue here with da.pad is going to be resolved by https://github.com/dask/dask/pull/6738. However, your issue with map_overlap (that internally relies on map_blocks) is probably solved by passing meta=, please see https://github.com/dask/dask/blob/8d622ad81162245d5e7663522b9721df5b23e9f4/dask/array/core.py#L486-L495


Create a podspec

Native apps that use components build with RN need to link with 3rd party RN libraries that contain native code. This is usually done using Cocoapods and most libraries will include a podspec to support this.
I have created a podspec with a few sensible settings. Ideally we should add a tag for the source property.
You don't have to publish the podspec on the public Cocoapods repo. Since react-native-mail-compose is already installed via npm the podspec can be referred to locally.

@MihaiDamian Thanks for PR. I have never created a podspec before, so I want you to be sure that this will work for others before I can merge this PR.
Could you confirm?

I'm using the fork containing the podspec in my app. I can confirm it works and the usage setup is the same as for other apps.

@MihaiDamian thanks! merged.


[Impeller] Poor performance with large nonzero fill paths.

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
I am using syncfusion_flutter_charts with  ColorFiltered. The performance is so slow.
App example

Run app by default using impeller
then disable the impeller

Expected results
Good or excellent performance.
Actual results
Performance is poor.
Code sample
Code sample
ColorFiltered(
          colorFilter: AppThemeProvider.currentTheme.name == AppThemesMode.dark.name
              ? const ColorFilter.mode(Colors.white, BlendMode.color)
              : const ColorFilter.mode(Colors.transparent, BlendMode.color),
          child: SfSignaturePad(
            key: _signatureGlobalKey,
            backgroundColor: Colors.transparent,
            strokeColor: Colors.black,
            minimumStrokeWidth: 3.0,
            maximumStrokeWidth: 4.0,
            onDraw: (offset, time) {
              setState(() => currentOffset = offset);
            },
          ),
        ),

Screenshots or Video

Screenshots / Video demonstration
https://github.com/flutter/flutter/assets/50643541/573efb92-e7b2-4131-a124-0af548bf3ee3
https://github.com/flutter/flutter/assets/50643541/0b16e806-c9c2-4bad-bde6-568f27d272a4

Logs
Logs
[Failed to change device orientation: Error Domain=UIScene ErrorDomain Code=101 "None of the requested orientations are supported by the view controller. Requested: landscapeRight; Supported: portrait" UserInfo={NSLocalizedDescription=None of the requested orientations are supported by the view controller. Requested: landscapeRight; Supported: portrait}](https://www.google.com/search?sca_esv=568251480&q=Failed+to+change+device+orientation:+Error+Domain%3DUIScene+ErrorDomain+Code%3D101+%22None+of+the+requested+orientations+are+supported+by+the+view+controller.+Requested:+landscapeRight;+Supported:+portrait%22+UserInfo%3D%7BNSLocalizedDescription%3DNone+of+the+requested+orientations+are+supported+by+the+view+controller.+Requested:+landscapeRight;+Supported:+portrait%7D&spell=1&sa=X&ved=2ahUKEwikr-7jvMaBAxUOrJUCHUTVCx8QBSgAegQIChAB)

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.13.0, on macOS 13.0 22A380 darwin-arm64, locale pt-BR)
    • Flutter version 3.13.0 on channel stable at /Users/mairramersilva/fvm/versions/3.13.0
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision efbf63d9c6 (6 weeks ago), 2023-08-15 21:05:06 -0500
    • Engine revision 1ac611c64e
    • Dart version 3.1.0
    • DevTools version 2.25.0

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /Users/mairramersilva/Library/Android/sdk
    • Platform android-33, build-tools 33.0.0
    • ANDROID_HOME = /Users/mairramersilva/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/mairramersilva/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14B47b
    • CocoaPods version 1.12.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] IntelliJ IDEA Community Edition (version 2022.1.3)
    • IntelliJ at /Applications/IntelliJ IDEA CE.app
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart

[✓] VS Code (version 1.82.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.72.0

[✓] Connected device (3 available)
    • sdk gphone arm64 (mobile) • emulator-5554 • android-arm64  • Android 11 (API 30) (emulator)
    • macOS (desktop)           • macos         • darwin-arm64   • macOS 13.0 22A380 darwin-arm64
    • Chrome (web)              • chrome        • web-javascript • Google Chrome 116.0.5845.187

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Happy to take a look at the performance but you need to include a reproducible example, not just a video recording.

Happy to take a look at the performance but you need to include a reproducible example, not just a video recording.

@jonahwilliamsI added an example for testing.

This overhead is all tessellation:

I'm going to merge this into https://github.com/flutter/flutter/issues/134432 because its the same underlying issue

Just as a tip here:
Looking at the videos, the application is very clearly "just" drawing strokes, but the profile that @jonahwilliams shared indicates that they're getting drawn with PaintingStyle.fill (otherwise they wouldn't hit that tessellatio ncode).
Tessellating these strokes as fills is very expensive in Impeller, and it would be far better to tessellate them as strokes.

Reopening because this is a bit different: we can actually fix this case by being smarter about large non-zero fill contours.

I have a pending fix in https://github.com/flutter/engine/pull/46282 that makes the performance comparable to Skia.

This change will be reverted so I'm re-opening the issue.

We think this is fixed now (from the linked issue #143077


Display the actual group name instead of the GUID for Azure AD groups

Internal Reference: SURE-4887
For Azure AD, Rancher shows the group GUID rather than the group name.

@nwmac I was trying to reproduce this issue, but I'm not sure if this is already fixed or not. Here's a screenshot in 2.9-head:

Fixed in 2.8.0


Adjust svgToTinyDataUri return type

What this does
This PR changes the return type of the main function from string to data:image/svg+xml,${string}.
The main function always adds data:image/svg+xml, at the beginning of the returned string and therefore this type changes definitely improves the type accuracy.
Motivation
I'm using this package to generate placeholder images for my Next.js page.
The Next.js image component expects the placeholder string to start with data:image/ and therefore throws an error when I pass a regular string to it. This could very well be useful when using other frameworks as well though.

@fjc0k


Alternative serialization implementation that compactly stores bytes

This solves #1298. Below I explain some changes that require attention.
FdWriter:

I have to change the way FdWriter works because it does not offer a similar interface that allows me to "modify" the last written word. Therefore, it is added with a single-word buffer that would only be used during the u8 serialization. This buffer will be flushed when full words are written, or when FdWriter is dropped (in Rust the variable currently drops when it is no longer in the scope, such as the end of the main() function, this should work as JOURNAL processing is after it).
This change is clearly not ideal as it introduces new behaviors. Now, the file descriptor works like regular file descriptors in Rust, in that they don't need to be closed or flushed manually, but Rust would flush and close them when dropping them.

Byte Handler:

The implementation has been further simplified compared with https://www.github.com/l2iterative/alternative-serde0. It no longer uses Rc and RefCell. It is much less hacky.

Location of handler reset:

Note that the handler is reset when the byte sequence ends. According to the analysis in #1298, there are only the following basic types that RISC Zero handles (and serializes):

bool
i8, i16, i32, i64, i128
u8, u16, u32, u64, u128
f32, f64
char
string
byte array

bool, u8 -> u8
i8, i16, i32, i64, u16, u32, u64, f32, f64, char -> u32
string, byte array, i128, u128 writes bytes directly (i128 calls u128 in serializer, but is separate in deserializer)
so, we just need to make sure that for string, byte array, i128, u128. u32, we reset the handler.
string and byte array starts their serialization by calling u32, so the handler would be reset before any byte is written, we don't need to add additional reset there.
as a result

we inject a reset in u128, u32 for serialization
we inject a reset in u128, u32, and i128 for serialization because i128 did not call u128 here.

Added a third test that checks edge cases. Some edge cases are as follows.
(Vec, u32) with 0, 1, 2, 3, 4, 5 bytes
(u32, Vec) with 0, 1, 2, 3, 4, 5 bytes

Let me take a look at the failed tests and think about how to fix it

@flaub ready for review again.
My local test has a failed test that does not seem to be due to this PR.
test tests::manager::integration_test_completed_proof_manager ... FAILED

failures:

---- tests::manager::integration_test_completed_proof_manager stdout ----
thread 'tests::manager::integration_test_completed_proof_manager' panicked at bonsai/ethereum-relay/src/tests/manager.rs:112:10:
deployment should succeed: MiddlewareError { e: MiddlewareError(JsonRpcClientError(JsonError(Error("missing field `baseFeePerGas`", line: 1, column: 39)))) }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@flaub ready for CI again.
My local test has a failed test that does not seem to be due to this PR.
test tests::manager::integration_test_completed_proof_manager ... FAILED

failures:

---- tests::manager::integration_test_completed_proof_manager stdout ----
thread 'tests::manager::integration_test_completed_proof_manager' panicked at bonsai/ethereum-relay/src/tests/manager.rs:112:10:
deployment should succeed: MiddlewareError { e: MiddlewareError(JsonRpcClientError(JsonError(Error("missing field `baseFeePerGas`", line: 1, column: 39)))) }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

that's just an issue with ethers-rs. The CI uses an old version of foundry because there was a breaking change (and not a released version of ethers that works) can ignore that.

To summarize, Austin pointed out that this would have an issue if the user is using multiple FdWriter for the same resource. For example, the user can obtain a writer to JOURNAL by just calling env::journal(), and there is no design to prevent that. If multiple journals are used, when they are being dropped (when the variable goes out of scope), the order of the dropping can also be "undefined behavior".
This issue is real because each FdWriter may just have "leftover" that has not yet written to the buffer.
A solution is to have something similar to this in the guest:
#[derive(Clone)]
pub struct PosixIo<'a> {
    pub(crate) read_fds: BTreeMap<u32, Rc<RefCell<dyn BufRead + 'a>>>,
    pub(crate) write_fds: BTreeMap<u32, Rc<RefCell<dyn Write + 'a>>>,
}

So that each time a user requests a FdReader or FdWriter, it is actually getting a reference to an Rc<RefCell<>> one. Ideally there should be another layer of abstraction, so that regular users do not have to operate on Rc<RefCell<>> which would require borrow or borrow_mut.

Let me experiment with that idea a bit. In general, we do not want to patch here and patch there, but want to resolve this systematically.
Adding a new syscall is also not reasonable.

@austinabell Circulate it to you for a third version.
This version no longer modifies how FdWrite works, it also reverts all the changes to WordWrite. All the changes are now implemented in and only in Serializer.
We want to restrict ourselves to serialization. The problem that we are encountering is that there are "buffered" bytes that have not been written to the stream.
First of all, we can split all types in Rust into three groups.

primitive types:

bool, u8, u16, u32, u64, u128, i8, i16, i32, i64, i128, f32, f64, char, str,
()
unit struct aka "struct Nothing"
unit enum aka "enum{ A, B, C }" with no underlying variables

"newtype", a virtually pseudo type defined over another type, which is specifically defined for efficiency

Option
newtype struct, aka struct(T)
newtype variant, aka `enum { struct1(T1), struct2(T2), ... }

wrapper:

seq, including vec![], long slice
tuple aka (T1, T2)
tuple struct aka struct(T1, T2)
tuple variant aka enum { struct1(T1, T2), struct2(T3, T4, T5) }
map
struct aka struct { a: A, b: B}
struct variant aka enum { struct1 {a: T1, b:T2}, struct2{a: T3, b: T4, c: T5) }

Note that if the buffered bytes have not been fully written to the stream, it means that the last primitive type being written has to be either bool or u8 (we will just treat bool as u8 in the following). There are no primitive types after it.
So, there are only two possibilities of this u8.

the variable to be serialized is immediately or not immediately inside some sort of a wrapper. By "not immediately", it means that struct { Option<struct(Option<u8>)> } will also be considered as "inside a wrapper".
the variable to be serialized is not inside any wrapper. It could be u8 or Option<struct<(Option<u8>)>>.

We handle both separately.
For the first case, we introduce a notion of "depth". When serializer enters a wrapper, the depth is increased by one, when it leaves the wrapper, the depth is decreased by one. When the depth is zero, it means that it must have left the last layer of meaningful wrapper, and there are no new bytes possible after it. It needs to be immediately written to the stream when the depth hits zero. The implementation looks like this:
    #[inline]
    fn decrease_depth<W: WordWrite>(&mut self, stream: &mut W) -> Result<()> {
        self.depth -= 1;
        if self.depth == 0 && self.status != 0 {
            stream.write_words(&[self.byte_holder])?;
            self.status = 0;
        }
        Ok(())
    }

For the second case, we notice that the last u8 is in depth 0, and therefore, this u8 is put into the buffer and immediately being written down into the stream, i.e., treating u8 as u32.
     fn handle<W: WordWrite>(&mut self, stream: &mut W, v: u8) -> Result<()> {
        if self.depth == 0 {
            stream.write_words(&[v as u32])?;
        } else {
            ......
        }
        Ok(())
    }

Let me know what you think. In addition, @austinabell can you approve the GitHub actions? So I may get CI to help finding bugs. I am fighting against the error "incompatible client version: 0.21.0-alpha.1" locally now.

I'll need to review before we run on CI, thanks.

If you want to test locally, you'll need to install the server from local source. You can do that with:
cargo install --path risc0/cargo-risczero

Just finished a local testing. The local test passes.

@austinabell Circulate it to you for a third version.

So for context, I'm not a stakeholder for these changes, I was just reviewing to help improve the proposal since I had thought through similar patterns and personally couldn't rationalize proposing to change the default. Haven't checked the semantics in depth, and seems like it's a reasonable implementation, but I'm still unsure about these two mainly:

Implementing specific semantics into serialization would be footguns and breaking changes for existing uses

Also don't have high confidence this would pass if (de)serialization for all types was fuzzed, previous bugs were not caught by these types of unit tests
(There still is a minor race condition if you are calling internal functions of the deserialize with multiple readers/writers it seems, I haven't dug too much into this though)

Unclear the cycle overhead for this logic

Yes, it's very minimal, but it's changing the default for users to optimize bad patterns, not correct ones

The first point from Austin related to breaking of existing implementations. There are two thoughts here.

since the library still has not had a stable release, it is still okay to change the serialization

but we then need to be very careful because if a bug is discovered in the stable release and we need to revert this algorithm, it would be troublesome

the problem that we encounter is for a host to work with an old ELF. This is important because we can already see that this change affects the ELF. If the ELF is hardcoded in  a larger system, then the programmer might have no way to update the guest ELF to the latest API

ideally, there would be, in the future, and maybe after the first stable release, a way for the executor or the prover to know what version the guest ELF is compiled on and approach that guest differently. This is reasonable since the guest itself already needs to contain some zkvm sdk glue code and it has to do with versions. This can enable the Bonsai cloud prover to know the version of the guest and support an older version of the VM if Bonsai finds that minimal adapter is needed

Regarding cycle count, I have a separate question. At this moment, every time a call to read or write is made, a syscall to sys_read or sys_write would happen. This is where I am more concerned on the cycle count.
Would it be more performant if a user tries to wrap it with, for example, BufReader and BufWriter? I just feel that the current implementation does make syscalls very frequently.

Reading through this, it seems the implementation is reasonable, and I can follow what the resulting codec looks like (bytes get packed, with padding whenever we transition form bytes to non-bytes). As a result, we should expect a 75% reduction in the number of calls to read a word from the host.
I went ahead and ran this on a couple of our examples to get samples. With the sha example with 50kB of data, I saw no change to performance as it is written, passing a String to the guest. This is not unexpected. I changed the example to pass in &[u8] and deserialize as Vec<u8>. This PR resulted in a 54% improvement, essentially all of which is accounted for by a reduction in the number of calls to FdReader::read_words.
I also went ahead and compared this to an implementation using end::stdin().read_to_end(&mut data). That implementation achieved a 90% reduction in cycles over the baseline of main. Although it is a significanty different method, avoiding serde all together.
Overall, I'm a bit reluctant to merge this approach. It feels a bit "stapled-on" to core the (de)serializer implementations and optimizes the single case of serializing u8, without e.g. addressing strings. This is clearly valuable for byte buffers, which are of key importance, but there exist other methods of serializing byte-buffers that are more efficient. What does seem to have over e.g. std::fs::Read is that it will work on any byte buffers that are arbitrarily nested in stucts without special logic.
All together, it feels like there is still significant work to be done, so the concern is that we will latter need to come back to this and rebuild the serializer a second time. Both of these transitions introduce some pain for developers, so ideally we'd do it once. On the other hand, we are pre-1.0.
One direction we still need to explore is using alternative, off-the-shelf, codecs. We need to explore e.g. changing out our codec for bincode or another serde codec. Going beyond that, something like rkyv is very interesting to completely avoid direct deserialization costs (especially in terms of copying memory) but would probably not be a good default due to impact on devex. Some context on the codec as it exists today, is that it was created for a world where reading data into the zkVM was zero-cost, since initial reads to a special non-deterministic region of memory were unconstrained, so the host would simply write data to that location without consuming any cycles.
@flaub do you have any opinions or intuitions on this given this information?
Profiles for this branch (e8d40279faf2928a6b29d37671e3a48c2f98336b), main (8650ac903bf10143e26fb11751555269e221abb3) and a version of the example using std::io::Read::read_to_end are provided in the tarball below.
sha_profiles.tar.gz

Here is a question: is the 90% reduction on the number of calls to "read" related to the ability to read many words at the same time because it can forecast how many needs to be read?
If so, this calls for the following thing to be implemented in the guest
"BufReader"
So if there are available words in the file descriptor, let it read more.
But a sequential question is: how big is the overhead of read_words? Is the serde cycle mostly due to the inherent machinery of serde? Note that serde cycle may, for a lot of applications, not the bottleneck, but it helps with users writing so.
One solution to help with stability is to allow customized serializer and deserializer. Or implement this as a third-party dependency that wraps the existing implementation. This could be implemented in a way that is transparent and does not require modifications to RISC Zero itself, basically an env2::

Related to the stable release, it is about whether we want to move forward with this new spec of the input where continuous bytes are packed.
Improving the performance could be sequential non-breaking changes

In the meantime, I uploaded a crate that converts a data struct to and back from u32 slices. (This would avoid the compatibility issue).
l2r0-small-serde

@weikengchen I'm wondering how well the l2r0-small-serde crate has been working for you? I think having an external crate is a good way to allow users to try it out. We could try adding a feature flag to this repository that enables this serialization format with the default being the same as is today.

There really has not been much usage to the small-serde from other users, so I think it remains largely unclear. It would be left to RISC Zero's decision what to do with this alternative format. Nevertheless, I think it is clear that the current format is suboptimal when it comes to Vec.
Having two serialization systems in the codebase that are enabled or disabled by a feature flag can bring complexity when one is compiling multiple repositories together (when a feature flag is turned on by one of the dependencies, other dependencies may involuntarily also get this feature flag enabled). I would advise against this approach.
It is time to pick one format and continue with it.

Given the results of #2182 I think we can safely close this and recommend that other codecs are used. I think our own serde format will be deprecated and we'll go with postcard as the default.


Synchronize CNI secure bridge documentation

with production use.

Nice, thanks! Shall we just add suitable routes for IPv6 too (i.e., running the script only with the static exclusions, not the Ansible hosts)?


Where is change log for release?

I searched and couldn't find any change log. I want to see what is new/changed in each release. Where can I find release notes?

service update release notes are in the commit message. Updates to hand written code are as well.


Issue when errors encounted

Hi,
We had a big struggle to debug a problem with a shipment.
Using the GetShipments.
The value of shipping_method was null, but the error was triggered on the json parsing with a invalid value on int32 (but not which).
I downloaded the code, and found out by setting the shipping_method to int? it would not fail here, and by adding the errors properties these errors can actually be read.
This would be much more useful to show the user also. And another benefit would be that a shipment can actually be validated in the GetShipments with a list of validation errors.
I only made a change in the Shipment.cs
Should I upload it to here, or send it to you?
We would really like to use the "official" package, rather than fixing this locally ourselves.

Hi,
You can upload it to here or send it to me.

Hi Rob,
Just sent you an email.

Make ShippingMethodId nullable and Added Errors property to Shipment.cs


[main] Update actions

Cron -knative-prow-robot
/cc knative-sandbox/ux-writers
/assign knative-sandbox/ux-writers
Produced by: knative-sandbox/knobots/actions/update-actions
Details:

/lgtm
/approve


Use MathBinary and MathUnary from python?

Is it possible to use org.apache.spark.ml.mleap.feature.{MathBinary, MathUnary} in a model built in pyspark?  If not, would you consider adding support for them to the mleap python module?

@aufrank Thanks for brining this up! Would you like to add support for them? You can use our OneHotEncoder integration as a template:
https://github.com/combust/mleap/blob/master/python/mleap/pyspark/feature.py#L51-L56

There are quite a few duplicates on this question, I am going to close this issue and keep https://github.com/combust/mleap/issues/495 open as a reference ticket.


Universal App Qr-Code Generation not working

I created a new Xamarin.Forms app with a Universal-Project. Then I added the ZXing.Net.Mobile (<IP_ADDRESS>) package via Nuget to all my platform projects.
I implemented an interface to generate a qr-image from my pcl-project (via DI). Following code shows the implementation for the UWP-Project:
var options = new ZXing.QrCode.QrCodeEncodingOptions
{
    Height = 200,
    Width = 200,
    Margin = 0,
    PureBarcode = true
};

var writer = new ZXing.Mobile.BarcodeWriter
{
    Format = ZXing.BarcodeFormat.QR_CODE,
    Options = options
};

var bitmap = writer.Write("testcontent");

It Looks like everything works fine. But when I try to show the created Image on the screen or I try to save it to the disk, the image is corrupted and can't be shown. No exception and no error in my ouput window...

You can use zxing.net directly, like this:
var content = "123456789012345678";
var writer = new ZXing.Rendering.BarcodeWriter { Format = BarcodeFormat.QR_CODE };
var bitmap = writer.Write(content);

Yep, what @redwolf2 said, or do it in the platform specific layer, or use the Forms control if you're using Xamarin.Forms...


Enable pool_pre_ping in DB connection

To avoid problems with inactive DB connections, SQLAlchemy provides a pool_pre_ping option, that is described in more detail here:
http://docs.sqlalchemy.org/en/latest/core/pooling.html#disconnect-handling-pessimistic
In Flask environments, it's enabled by subclassing SQLAlchemy, which is what I've done here.
This fixes errors like:
sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError) (2006, 'MySQL server has gone away') which results in an Error 500 in the UI.

This option loos useful to me. Merged it. Thank you for submitting the PR.


Added Trakt

Proposed Changes

Add https://trakt.tv/

Checklist

[x] Tested locally
[x] Ran yarn ci to test my code
[x] Did not add any unnecessary changes
[x] All my changes appear after other changes in each file
[x] Included a screenshot (if adding a new button)
[x] 🚀

Thank you!  Looks like some lint that needs to be fixed!

you can run yarn lint --fix to fix it

Thank you!


CPUVertexBuffer newtype

Currently it is a wrapper for Vec<f32> which asserts length is
divisible by 3, but it can be latext extended to store tuples of
four elements: (x, y, z, w).

Finally did something like this 🤣


Not scrolling to bottom

I'm doing the following, but nothing happens.
Am I missing something?
import {animateScroll}  from 'react-scroll';
...
animateScroll.scrollToBottom();

Same issue here. Anybody else?

@znat are you using this inside react component?

@znat, of course. The component is very simple as I am just trying to get it working as a test. The only thing I'm wondering is if this package doesn't work when it's inside another component/div.

@znat I went ahead and made the most simple component I could, with three divs eavh taking up the entire screen size. I can scroll this up and down with the mouse, however when I click the button to scrollToBottom it doesn't do anything. Attached is the App component as well as the logs from the scrollEvent. Any help would be greatly appreciated. Thanks.
import Scroll from 'react-scroll';

let scroll = Scroll.animateScroll;
let Events = Scroll.Events;
let scrollSpy = Scroll.scrollSpy;

export class App extends Component {

  componentDidMount() {
    Events.scrollEvent.register('begin', function(to, element) {
      console.log("begin", arguments);
    });

    Events.scrollEvent.register('end', function(to, element) {
      console.log("end", arguments);
    });

    scrollSpy.update();
  }

  // render
  render() {
    return (

        <button onClick={() => scroll.scrollToBottom()}>Scroll To Bottom</button>

    )
  }
}

export default App

The logs are as follow:

Figured it out eventually! For anyone else having problems you need to use the option props to pass in a containerId of the div you'd like to scroll in. In my above code, this would be "main", otherwise it tries to scroll the window which has a 100% height set already! Hope this helps someone else.

Ah great, glad you solved it. Closing the issue then.

Hi @luskin and @fisshy
Thank you for your comments, I was out for a few days.
Yes, I am using it inside a React component. @luskin I don't understand what you mean with use the option props to pass in a containerId of the div you'd like to scroll in ?
What did you change exactly in your code above.
Thank you


Suppress tag-source element?

Is there a way to suppress the output of div.tag-source ?
I'm using jaguarjs-jsdoc via grunt-jsdoc, and the tag source is showing the file path all the way down to the root of my OS, eg:

/Volumes/VRMiniBackup/Backups/Web/Bitbucket/ob/wp-content/themes/sitename/resources/dev/scripts/sitename.js, line 2787

This makes the div.tag-source overlap the adjacent documentation at all but the widest viewport widths.
Thanks.

I got the same problem and I think it is a bug of jaguarjs-jsdoc.
Attach my fix for your refer:
jaguarjs-jsdoc/publish.js:
exports.publish = function(){...}
line 404:
sourceFilePaths.push(resolvedSourcePath);
change to:
if (sourceFilePaths.indexOf(resolvedSourcePath) === -1) {
sourceFilePaths.push(resolvedSourcePath);
}

Any update on this?

Any update on this?

I had the same problem when generating documentation for one single file.
In publish.js, the array 'sourceFilePaths' is used to collect all source  references (path+filename).  This array is later used to find and remove the common part.  When generating doc for one .js source-file, this path+filename is always the same so the process of removing the path fails (as it includes the filename padded with a path separator).
The simple fix I found is to remove the filename from the path+filename before populating 'sourceFilePaths'.
Change 'jaguarjs-jsdoc-master/publish.js':
sourceFilePaths.push(resolvedSourcePath);
To:
sourceFilePaths.push(path.dirname(resolvedSourcePath));

I had a similar desire. While waiting for an official fix, if you just want to hide the div.tag-source element you could do so with a grunt task:
grunt.registerTask('docsPostProcessing', function () {
    var done = this.async();
    require('fs').appendFile('./[YourDocsDestination]/styles/jaguar.css', '.tag-source { display: none; }', function (err) {
        if (err) {
            grunt.fail.fatal(err);

            return;
        }

        done();
    });
});
grunt.registerTask('docs', ['jsdoc', 'docsPostProcessing']);

Hi, I have the same issue.
It seems it was fixed in "jsdoc default template" : https://github.com/jsdoc3/jsdoc/issues/590
Could it be fixed here too ?
Thanks !


Remove function and arguments length check in createHelper

Failing example
branch caused a console.error at createHelper as functions with default arguments returns incorrect length of arguments.
So this was true for branch when all arguments were provided

Fix

@wuct please review and merge

I also ran into this error when I used createHelper to build my own HOC before.
Using func.length means we lose the ability to use function default parameters, because func.length only includes parameters before the first one with a default value.
IMHO we should just remove the func.length checking, since we are not currying by default anymore.

Agree, let's remove that check.

Check removed.

Nice work!


Incorrect style order

Bug report
Description
Styles are applied in incorrect order depending on how styled component are composed.
const StyledBase - styled(...)
const Foo = styled(StyledBase, {...}) // works correctly

const Base = (props) => <StyledBase {...props} />;
const Bar = styled(Base, {...}) // StyledBase styles take precedence

Things get even more unpredictable when using Foo & Bar on the same view. Depending on the order of Foo & Bar the styles might or might not apply correctly, see reproduction below.
To Reproduce

Open the following sandbox:
https://codesandbox.io/s/nifty-blackburn-m792w?file=/src/App.js
Observe behavior by uncommenting commented out variations one by one. Make sure to refresh the built-in csb browser each time.

Expected behavior
When using styled(Foo, styleObject), rules defined in styleObject should override Foo's existing styles.
System information

OS: MacOS
Browser: Chrome, Safari, Firefox
Version of Stitches: 0.2+

Thanks for that!

Hi @tigranpetrossian,
In the code example, Bar does not extend StyledBase, leaving the injection order up to runtime conditions, when Bar renders another styled component that happens to be StyledBase.
We can resolve this by having Bar extend StyledBase.
const Bar = styled(Base, StyledBase, {...})

Fixed example:
https://codesandbox.io/s/recursing-grothendieck-phjij?file=/src/App.js

Hi @jonathantneal,
Thanks so much for the clarification. At the time of opening the issue I didn't even know styled(Component1, Component2, {...}) API existed.
However, in few use cases where I've stumbled upon this StyledBase might not be available (not exported), e.g.
// Button.js

const StyledButton = styled('button', { ...buttonStyles });

export const Button = React.forwardRef((props, ref) => {
  // additional button logic here
  return <StyledButton {...props} ref={ref} />
})

Consuming:
// App.js
import Button from `@ui/Button`

// No access to StyledButton here, since it's an unexported implementation detail of the Button
const MySpecialAppButton = styled(Button, { ...specialAppButtonStyles })

Just curious whether this is a #wontfix, or your solution is a temporary workaround.

I wouldn’t say it’s #wontfix.
Yes, it would be difficult for Stitches to reach into Button and know of StyledButton.
However, we might benefit from a new rendering order algorithm that ensures the order you expect. It seems very reasonable.
I would say, we need more time to think about this issue.

Same issue :( We've. used styled on functional components quite liberally coming from emotion. It worked well until the upgrade from v0.1.9 to v1, but finding a workaround for all the places it broke is unfortunately isn't possible, had to roll back.

We have similar use-cases and had to come up with weird workarounds in so many places

Same. Had to roll back the upgrade as the specificity of styles flipped in a lot of components causing a lot of visual regressions.

This is being worked on.

Hey, it seems like there was some kind of misunderstanding. I let y’all know a ways back that this issue is not with Stitches.
Here’s the original issue:
const StyledBase = styled('button', {
  display: 'inline-flex',
  color: 'inherit'
})

const Base = (props) => {
  return React.createElement(StyledBase, props)
}

const Test = styled(Base, {
  color: 'red'
})

How would Test know to reach into the return value of Base to extend StyledBase? I’m sorry to disappoint you all, but that’s not how JavaScript works.

Hey @jonathantneal,
Thank you for the clarification. Without knowing much about Stitches internals, I think the assumption that this would work was because a lot of us are coming from styled-components/emotion where it consistently worked that way (and in Stitches < 0.2).
To expand on the use case above, one very common scenario is where we extend UI library components with more app-specific styles:
// App.js
import Button from `@ui/Button`

// Button is a wrapper around StyledButton with extra logic, however StyledButton isn't exported.
const MyAppButton = styled(Button, { ...appButtonStyles })

Where appButtonStyles often contains app state/behavior-specific variants, e.g. isOpen, isActive, etc. Not being able to use variants here basically makes one of the coolest features unavailable.
With all that being said, is there at all a world where this can be supported, even if it’s in future versions?

one very common scenario is where we extend UI library components with more app-specific styles

That is fully supported. You should be able to do this.
I was commenting on reaching inside a functional component, which I would not like to do since that would run components out of order (running the component for side effects, then attaching the class names, versus what we do which is pass the class name into the component).
We have been working out another ordering issue, which may happen to do what this issue expects. My first response was connecting these issues, when I should have distinguished these. Let me phrase this another way with some code from the reproduction:
/* StyledBase renders "button". */
const StyledBase = styled("button", {
  display: "inline-flex",
  color: "inherit"
});

/* Base does not extend StyledBase. Base renders StyledBase. */
const Base = (props) => {
  return <StyledBase {...props} />;
};

/* Button1 extends StyledBase. Button1 styles will overwrite StyledBase. */
const Button1 = styled(StyledBase, {
  color: "red"
});

/* Button2 renders Base. It does not extend Base or StyledBase. Its styles are not necessary before/after StyledBase. */
const Button2 = styled(Base, {
  color: "red"
});

With all that being said, is there at all a world where this can be supported, even if it’s in future versions?

Oh yea! I think we can order style injection based on creation. Would this ultimately render what you expect?
/* StyledBase is created first. StyledBase styles will be ordered first. StyledBase renders "button". */
const StyledBase = styled("button", {
  display: "inline-flex",
  color: "inherit"
});

/* Base renders StyledBase. Base does not extend StyledBase. */
const Base = (props) => {
  return <StyledBase {...props} />;
};

/* Button1 is created second. Button1 extends StyledBase. Button1 styles will overwrite StyledBase. */
const Button1 = styled(StyledBase, {
  color: "red"
});

/* Button2 is created third. Button2 renders Base. Button2 styles will overwrite Button1 and StyledBase. */
const Button2 = styled(Base, {
  color: "red"
});

I originally thought this issue might be related to our "order by creation" issue, but then I saw, based on the reproduction, that it was more a side-effect.
Perhaps we should reopen this. I bet the team would be in favor! I feel I was a little stuffy in my last response, anyway (sorry)!
I’d like your thoughts, but the new presumption would be that we want the CSS to be ordered the way it was originally created.

Yes, I think ordering styles based on creation should solve this. I'd be happy to test it out if it's necessary.

I noticed what I think is the same issue with core: https://codesandbox.io/s/priceless-chatterjee-cpqij
I expected that Stitches would take the className I have passed to button({ className }) and Object.assign the two to create a new class if the class is a stitches css type, but the behaviour I'm seeing looks like Stitches is concatenating class strings.
Fela have a whole section on this issue explaining why you have to pass the "rule" through a util to ensure specificity: https://fela.js.org/docs/latest/advanced/combined-rules#problem-order-matters
Is this the same thing?

Hi everyone, we're still evaluating this issue — but it may take a rather fundamental change in how Stitches interfaces with CSS classes to make this possible. It likely won't be a quick fix. So please keep using workarounds for now and we'll keep you updated.
@tigranpetrossian and anyone that mentioned expecting this to work because you come from SC/Emotion, can you put together a quick example of exactly what you were doing?
Would it look like this?
const Button = styled.button`padding: 10px; color: red;`;

const MyButton = (props) => <Button className={props.className}>{props.children}</Button>;

const Button2 = styled(MyButton)`color: green;`;

Result from SC and the above code:

Hi @StephenHaney,
Thanks so much for keeping this on the radar.
Your example is exactly what I would put together. This has proven the most useful in cases where we extend a component with more domain specific variants like in my example above

I was pointed here from discord, and just for posterity's sake I'll copy over some of my message and the example case I put together. Hopefully more examples are helpful!
I believe there was a change in 0.2.0 with the shift to CSSOM that caused some changes in the ordering of styles.
The general problem is when you have a composition chain of components like StitchesTop > CustomReact > StitchesLow. When StitchesTop and StitchesLow share a variant (let's imagine it's color), and StitchesLow has a default variant for color, the default variant can take priority over the variant given to StitchesTop depending on the rendering order of components.
As far as I can tell this is because color is passed to StitchesTop, translated to a classname when passed to CustomReact, which then passes it down to StitchesLow as a classname, but no variant. So it uses the default variant for color. Then it's just a battle between those two variant classnames based on what order the css was inserted.
I made a demo of this here: https://codesandbox.io/s/jqbgk?file=/src/App.js. If you uncomment the first Box you'll see that the last line renders correctly as red.

What about this ?
We created a react components library with stitches and our typography (and every component) component has default styles and when we try to override these styles with styled function it won't override.
This is the example code: https://codesandbox.io/s/stitches-override-example-4yqmo?file=/src/App.js:344-346
Is this behaviour right ?  @peduarte

@frgarciames it's a known bug and @hadihallak is working on it as we speak 👀

Hey @frgarciames I just had a quick look at your sandbox and I think the behavior you're seeing is correct and isn't related to the bug reported in this issue.
You seem to have a `kind="primary" variant that's giving the H2 the red color from the css custom property and variants win over base styles even when extending so you're gonna have to not trigger the default variant or override the styles in the wrapping component.
Screenshot of the variant I'm talking about:

t

Hi @hadihallak, so the only way to have a component with default variants and override some properties is adding !important to that property ?
Or the correct way it should be to not have default variants and apply variants when use it ?

@frgarciames Taking a second look here, @hadihallak is correct. This isnt related. Can you open up a new issue about this so we dont add noise to this one? And we can discuss further. Alternatively, join our Discord and post a message in #help and I'll start a thread there.

Hi @peduarte, I think you mentioned the team is working on the Stitches style injection issues. Just wanted to share a few thoughts with regards to StyleX's atomic strategy, which I really like.
cc: @hadihallak

I think the idea of using atomic css classes paired with javascript that's responsible for ensuring no element receives conflicting atomic classes makes a lot of sense.
This can work with both runtime style injection (no tooling!) and build time style extraction (better performance!). To start, there could only be runtime injection so no need to create tooling.
This can work with the styled() function to create components (which I generally prefer over the className prop).
Using atomic class names as unique keys to represent specific styles allows for multi level styled() composition with proper style overrides, even when there are non-Styled components between two styled() calls.

General narrative: each <Styled> extracts any atomic classes (unique keys) it receives as part of its className prop; it combines the received atomic classes with the styles passed into the styled() function (when the component was created); it passes down a set of atomic classes that have no style conflicts and are ready to be rendered in the DOM or passed into another <Styled>. It doesn't matter if the resulting class names are passed to a non-Styled component that itself renders another <Styled> so long as the atomic class names are passed through.
Note that each <Styled> is autonomous, it receives styles when the component is created using the styled() function, and it receives atomic class names (unique keys) at runtime (passed down from a parent <Styled>), it then ensures that the class names it passes down have no conflicting styles and are ready to render in the DOM (or be passed to another <Styled>).

Here's an example of multi-level styled() composition, adapted from https://github.com/modulz/stitches/issues/671#issuecomment-922136265
The original example showed it was impossible to have Button2 styles overwrite StyledBase, but that is now possible with this approach.
/* StyledBase renders "button". */
const StyledBase = styled("button", {
  display: "inline-flex",
  color: "inherit"
});

/* Base renders StyledBase and passes through the className prop */
const Base = (props) => {
  return <StyledBase {...props} />;
};

/* Button1 renders StyledBase. Button1 styles will overwrite StyledBase. */
const Button1 = styled(StyledBase, {
  color: "red"
});

/* Button2 renders Base.
Button2 styles are passed to Base in the form of atomic classes as part of the className prop.
Base passes the atomic classes through to StyledBase which combines them with its own styles.
Button2 styles will overwrite StyledBase. */
const Button2 = styled(Base, {
  color: "red"
});

This is now fixed in #875 and is pending release so i'm gonna keep the issue open until we release it publicly

Thank you so much for addressing this. Deleting all the !importants is going to feel good!

@tigranpetrossian Thanks a lot for your patience and the simple reproduction of the issue🙏

Just got around testing this and looks like it works when wrapping regular functional components with styled, but not forwardRef components. For the latter, base styles still take priority, except for when both regular and forwardRef components are rendered together.
Here's a sandbox with reproduction
You'll need to reload the built-in browser after commenting/uncommenting as HMR doesn't seem to reflect correctly.

Oh right, sorry i missed that.
Will modify it on Monday so that the same ordering logic run against forward ref components.

Published under 1.2.6 🎉

Will this new behavior be available to @stitches/core?
https://codesandbox.io/s/x-e6yy7?file=/src/App.js
Maybe a cx function like https://emotion.sh/docs/@emotion/css#cx

I am suffering from what I think is the same bug in v1.2.8.
Reproduction: https://codesandbox.io/s/ecstatic-tharp-hdd6lv?file=/src/App.js
I'm not sure if this is 100% reproducible (perhaps it's flaky?), so a screenshot is included:

I think I've narrowed down the cause of the above bug; I will open a new ticket since it's an edge case of this bug.


Add commented-out example of MacOS notification and sound on build.

Adds documentation to end of build.sh with a command that can be un-commented to get a MacOS notification and sound upon build.sh completion.
Using this locally so I notice when the build finishes and am reminded to get back to testing whatever it was that built.

Might be neat if it checks which OS the user is running then uses the appropriate notification system to alert.
if os == tux
  notify-send x
else if os == macos
  osascript
else
  alert "sorry you have to use windows"

@timlevett That would definitely be neat.  Had the thought but didn't go after it.  Maybe go after that in a follow-on changeset?

:+1:

Superseded by #112  .


Provide UI Screenshots in Documentation

Within the README.md provide sample screenshots of MRA's UI related to Posts listings, search, etc. This is to provide users with an idea of what the application looks like and how it can be used to view and search their Reddit Contents.

README has been updated with screenshots. Closing.


Support generation of "slim" images

Hi there!
I noticed that there were no "slim" images in the official repository of Cypress. More specifically, I wanted a -slim image for cypress/base.
I tried to have the smallest impact possible in the code base, reusing the same CI steps.
The image would be named after the already known pattern, with the -slim suffix: cypress/base:<version>-slim.
The main difference I made in the new "generate" script was: adding the debian package procps, which is required in order to fix the following error (after cypress was executed):
 Error: spawn ps ENOENT
     at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
     at onErrorNT (internal/child_process.js:469:16)
     at processTicksAndRejections (internal/process/task_queues.js:84:21)
 Emitted 'error' event on ChildProcess instance at:
     at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
     at onErrorNT (internal/child_process.js:469:16)
     at processTicksAndRejections (internal/process/task_queues.js:84:21) {
   errno: 'ENOENT',
   code: 'ENOENT',
   syscall: 'spawn ps',
   path: 'ps',
   spawnargs: [ '-A', '-o', 'ppid,pid,stat,comm' ]
 }

This is my first time in this code base (and in a Docker project :ok_hand:), any feedback is most welcome.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

What’s the final size difference?
Sent from my iPhone

On Apr 19, 2020, at 15:14, Vincent G<EMAIL_ADDRESS>wrote:

Hi there!
I noticed that there were no "slim" images in the official repository of Cypress. More specifically, I wanted a -slim image for cypress/base.
I tried to have the smallest impact possible in the code base, reusing the same CI steps.
The main difference I made was adding the debian package procps, which is required in order to fix the following error (after cypress was executed):
Error: spawn ps ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:469:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
at onErrorNT (internal/child_process.js:469:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
errno: 'ENOENT',
code: 'ENOENT',
syscall: 'spawn ps',
path: 'ps',
spawnargs: [ '-A', '-o', 'ppid,pid,stat,comm' ]
}
This is my first time in this code base (and in a Docker project 👌), any feedback is most welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/cypress-io/cypress-docker-images/pull/292
Commit Summary
support generation with "slim" image
File Changes
A base/12.16.2-slim/Dockerfile (59)
A base/12.16.2-slim/README.md (18)
A base/12.16.2-slim/build.sh (8)
M base/README.md (1)
M circle.yml (3)
A generate-base-slim-image.js (136)
Patch Links:
https://github.com/cypress-io/cypress-docker-images/pull/292.patch
https://github.com/cypress-io/cypress-docker-images/pull/292.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi @bahmutov
https://hub.docker.com/repository/docker/vinceops/cypress-node12-slim/tags?page=1
From my first test, its compressed size is 234.78 MB. The regular cypress/base:12.16 is 474.85 MB.
 Trying to have the minimal impact was maybe not the best bet :shrug:

For the CI, when comparing the effective and the expected node versions, I decided to store "<< parameters.nodeVersion >>" in a variable expectedVersion and remove the substring -slim from its value, if any.
I'm ready to do it differently if you have a better idea! Thanks

Hi @bahmutov !
Do you think this PR has a chance to land in the repository? Let me know if it's not good enough, I'd be glad to improve it (with instructions).
Thanks for your work.

@VinceOPS to be honest unlikely. We have tried slim images before, and they were missing some OS libs that some of our tests used. These dependencies were transient, so we did not want to chase everything down. The size savings - yes, it is half the size. But for CI caching, I am not sure if the pay off is worth the risk.

@bahmutov Ok, thanks for your answer. I would suggest to, eventually, add a clear disclaimer to the "slim" image, stating that it might lead to unexpected errors due to the lack of dependencies... But I'm fine with the fact to declare that this will never be supported.

@VinceOPS thank you so much for your work on this. I'm closing it as we support this with #597 merged in.


Prohibit the use of the PHP goto language construct

While goto is rarely - if ever - used in themes, it also shouldn't be.
This sniff will safeguard against its use.

After I commented out the WordPress.Theme.CorrectTGMPAVersions rule (I guess it's not merged yet in this branch) the sniff worked fine - it detected goto and the line where goto should go, so it's OK to merge :)

After I commented out the WordPress.Theme.CorrectTGMPAVersions rule (I guess it's not merged yet in this branch) the sniff worked fine - it detected goto and the line where goto should go, so it's OK to merge :)

Could you expand on that a little more ? This branch already contains that sniff, so commenting it out shouldn't be needed.
Oh and a pro-tip: if you just want to test one particular sniff (or only a few), you can run PHPCS like so:
phpcs ./file-you-want-to-test.php --standard=WordPress-Theme --sniffs=WordPress.PHP.DiscourageGoto

I cloned this fork in my wpcs folder where my sniffs are, and when I went to write a sample code in Sublime (with the WordPress-Theme as the standard), I got the error

ERROR: Referenced sniff "WordPress.Theme.CorrectTGMPAVersions" does not exist

I tested it with WordPress standard and everything worked (goto showed error).

@dingo-d Ah, ok. I'm not familiar enough with Sublime, but this feels like it might be using a different version than your clone - maybe even a cached version ?
Could you check by running PHPCS from the command-line over your test code ? If you don't get the error when you do that, the problem is with Sublime, not with the repo.

@dingo-d Thanks for testing! Found it now. Looks like I made typo/change the sniffname and forgot to change it in the ruleset. PR #156 should fix it.

Great, you can merge it then :) :+1:


You can now create an inherited scene based on an already opened scene

Fixes #3063

The two commits ecede5a and 1e61da2 add unnecessary noise to the PR, do you think you could remove them with git rebase -i HEAD~4? Simply drop the corresponding two lines in the editor that appears and save, it should remove the two commits (and likely also the merge commit ea40fa1 as rebasing removes such unnecessary commits). Then you should be back to a branch with only the first commit (with a new hash), and you can force push with git push -f origin master.
Also feel free to use specific branches in your fork for PRs so that you can work on several things at the same time while keeping PRs atomic (like the texture name stuff you had started to work on here).

Sorry about that, sometimes I struggle with the git workflow

We all do, git has a really steep learning curve :) Thanks for the cleanup.


use of @class and @constructs leads to duplicated output of the class

Hello,
I'm working with the latest master and as soon as I use @class and @constructs, my generated documentation will contain the entire class twice. Once with a constructor without any arguments and once with the right constructor.
/**
 * @class
 * @implements {Test}
 */
var Message = {

  /**
   * @constructs
   * @param {Account} account
   * @param {ChatCore} core
   * @param {object} options
   */
  _make : function (account, core, options) {
    options = options || {};

    this.account = account;
    this.core = core;
    this.options = Make(options, MessageOptions)();
  },

  /**
   * @param {string} name
   * @private
   */
  _formatName : function (name) {

If I just use @lends Class.prototype everything works correctly, but my @extends, @implements etc. definitions are ignored.
Can you fix this so we get a correct output?

I think you want to do something like this:
var Message = /** @lends Message# */{

  /**
   * @constructs Message
   * @implements {Test}
   * @param {Account} account
   * @param {ChatCore} core
   * @param {object} options
   */
  _make : function (account, core, options) {
    options = options || {};

    this.account = account;
    this.core = core;
    this.options = Make(options, MessageOptions)();
  },

  /**
   * @param {string} name
   * @private
   */
  _formatName : function (name) {}
};

but this doesn't solve my problem. I can't add any tags to @lends, but if I use @class and @lends the class will apear twice...

Check your settings in that section and make sure you don't have some thing
clicked twice. Then check all other settings to make sure you have then
checked to function
On Nov 2, 2015 11:40 AM, "Jovan Gerodetti"<EMAIL_ADDRESS>wrote:

Hello,
I'm working with the latest master and as soon as I use @class
https://github.com/class and @constructs https://github.com/constructs,
my generated documentation will contain the entire class twice. Once with a
constructor without any arguments and once with the right constructor.
/** * @class  * @implements {Test} */var Message = {
/**   * @constructs   * @param {Account} account   * @param {ChatCore} core   * @param {object} options   */
_make : function (account, core, options) {
options = options || {};
this.account = account;
this.core = core;
this.options = Make(options, MessageOptions)();

},
/**   * @param {string} name   * @private   */
_formatName : function (name) {
If I just use @lends Class.prototype everything works correctly, but my
@extends https://github.com/extends, @implements
https://github.com/implements etc. definitions are ignored.
Can you fix this so we get a correct output?
—
Reply to this email directly or view it on GitHub
https://github.com/jsdoc3/jsdoc/issues/1105.


Make sure boss EventLoopGroups are terminated on startup fail…

Related: https://stackoverflow.com/q/58891320/55808
Motivation:
When a server fails to start up, its boss EventLoopGroup is not
terminated, leaving a dangling non-daemon thread which prevents a JVM
process from terminating itself.
Modifications:

Make sure the boss EventLoopGroups are always terminated by keeping
the boss groups created by Server.

Result:

No more dangling non-daemon threads on server startup failure

Thanks for reviewing!

Special thanks to @magnuschatt for reporting this issue via StackOverflow - https://stackoverflow.com/questions/58891320/how-to-make-armeria-exit-on-an-address-already-in-use-error


Mouse Without Borders Custom Folder for Screenshots

Description of the new feature / enhancement
Currently it forces a folder to be created on your desktop for screenshots, I think it would be best to allow a customizable directory for this. A more common directory would also be appreciated IE $USER\Pictures\MouseWithoutBorders
Scenario when this would be used?
For cloud backup and quality of life.
Supporting information
I would just like a custom directory to be allowed for the desktop folder, as it is currently forced into an awkward location.

Hi @hiringManager , thank you for the feature request. I don't clearly understand what the link between Mouse without Borders and screenshots is? Could you please clarify what exactly you mean?
/needinfo


Add a new Limits and Max configuration for values

Resolve #34

Thank you for the contribution. Great work!


bug: explore page showing testnet on livenet deployment

For some reason from time to time I see testnet spaces on explore page while I'm on the livenet deployment:

Which one is the testnet spaces ?

@wa0x6e Looks like all of them (it's top spaces on testnet).
https://testnet.snapshot.org/#/

How to reproduce ? Is that on this page https://snapshotx.xyz/#/explore without any filters/search ?

I'm not sure, it's inconsistent and it's not happening often but it's happening

I took a look at the code and I can't see how this could be possible. Environment variable looks good as well on this deployment. Lack of env variable shouldn't cause it either because s-tn is not in default list so unlikely that is issue with deployment unless we would get sx-testnet served as sx.
Might need to wait for repro 🤔

I think this happened on PR deployment, which I believe come from sx-devnet

on sx-devnet our env is:
s-tn,sep,sn-sep,s,eth,matic,oeth,arb1,sn

so both s and s-tn are enabled.

I think we should have a config var to define which env we want for the metadata like follows & profile, we can't have both

on sx-devnet our env is:
s-tn,sep,sn-sep,s,eth,matic,oeth,arb1,sn

so both s and s-tn are enabled.

Why both? ideally we should have two deployments, one for s and s-tn
we haven't enabled previews for pull requests on snapshot.box. can I enable it?

I think we should use Vercel for previews similar to snapshot.org, have less number of issues comparatively

on sx-devnet our env is:
s-tn,sep,sn-sep,s,eth,matic,oeth,arb1,sn

so both s and s-tn are enabled.

Why both? ideally we should have two deployments, one for s and one for s-tn we haven't enabled previews for pull requests on snapshot.box. can I enable it?

We already have one for testnet (testnet.snapshot.box), and one for mainnet (snapshot.box). The devnet (https://sx-devnet.on.fleek.co/) I think was made to reproduce same env as local env (yarn dev), where we could see all nets

In the local master, s-tn is not enabled though.
On PRs, we deploy only devnet right now.

We should deploy both testnet and mainnet 🤔 if we want to do both on devnet, then we should close this issue 😄

I'd say we should make it possible to use both s and s-tn at the same time, so on PR previews (and in local dev) we can test all spaces.
The fix that we need is to make alias/follows/user profiles independent of ENABLED_NETWORKS, just have second flag METADATA_NETWORK or something like this.

That would be tricky.
Alias creation is network independent, so it will never switch to mainnet/testnet, we will have to arbitrary always use one

Alias creation is network independent, so it will never switch to mainnet/testnet, we will have to arbitrary always use one

Is it? I can only follow mainnet spaces on s - eth works, sep doesn't, on the other hand with s-tn I can follow sep, but not eth.

Explore page will only show single offchain network at the time (controlled by VITE_METADATA_NETWORK env):
https://github.com/snapshot-labs/sx-monorepo/blob/e088ca6221c9ed9b04ced22476f6fed22181e20f/apps/ui/src/networks/index.ts#L82
We couldn't reproduce original issue. If it ever happens we can reopen this PR.


Clarify logging around TCK excludes files

Currenty the test harness looks for an initial excludes file and the also attempts to detect an additional one. If the additional one doesn't exist then a misleading warning is shown that states Unable to find excludes list file.
This PR adds a check for the initial excludes file but also clarifies the logging

Thanks @gdams !


convertStrings=True ignored in 0.7.2

Hello, I am having some issues with jpype version 0.7.2.
Even if I have specified convertStrings=True when starting the JVM via startJVM, java strings are not automatically cast to python strings like in the previous versions.
Is this a known issue?

Nothing in the test bench is showing an issue on this code path...
import jpype
from jpype.types import *
jpype.startJVM(convertStrings=True, classpath=["test/classes"])
fixture = JClass('jpype.common.Fixture')()
print(type(fixture.callString("hello")))

Returns type str as expected.

Ok, thank you for your answer. The issue I'm seeing must be caused by something else.


Accessibility and performance issues - Part-2

[ ] Background / Foreground color issue across multiple pages

Recipe list page - https://main--fonterra-fernleaf--hlxsites.hlx.page/en/recipes

@mkbansal1 @sselvara
I see the button colors would be updated for accessibility fixes, just fyi, the content inside button needs to be fully displayed on home page: https://main--fonterra-fernleaf--hlxsites.hlx.page/en (considering not to track this separately, we can fix this in this card itself)

@asthabh23, below are the new colors that will be used to address accessibility issues.

Button text color to support accessibility: #663300,
https://webaim.org/resources/contrastchecker/?fcolor=663300&bcolor=FEDF00

Recipe list page - Serves and duration : #595959

https://webaim.org/resources/contrastchecker/?fcolor=595959&bcolor=FFFFFF

@sselvara Lets implement it with your recommended colors.


Optionally search works by central (non-peripheral) terms only

For when a user is only interested in books that have X as a major theme, not as a minor theme.

Unfortunately, the API does not support such boolean queries as (major=X OR minor=X) AND (major=Y OR minor=Y). The best we can do is to force the user to choose major/minor for each term. Thus, the interface now has one input field for central terms and one for peripheral.
At KB they understand the need, which is also coming from other institutions, and they are looking to implement the central/peripheral distinction formally. In that, they may be able to enable more versatile "centrality" filtering like this.


chore(cleanup) - update mix dependencies

Bamboo.FallbackAdapter.deliver/2 must have ok/error signature too.
#3

@fuelen done


Allow use of ICakeContext in WithCriteria

Overload CakeTaskBuilder.WithCriteria to accept Func<ICakeContext,bool> .
I'm factoring out some common behaviors in my scripts into reusable tasks, but not having the context available in WithCriteria is causing some friction.
Anyone have a reason that context shouldn't be allowed there?

Sounds like a reasonable addition. Will make the task API more consistent as well :+1:

I am looking into this, and was wondering how I should add it to the existing CakeTask class. This class has a property that contains all existing boolean criterias: public IReadOnlyList<Func<bool>> Criterias. In the ShouldTaskExecute method in the CakeEngine class, the aforementioned Criterias property is iterated over. Should I create an additional property which signature is like this: public IReadOnlyList<Func<ICakeContext, bool>> ContextCriterias? Or should Func<bool> instances be converted to Func<ICakeContext, bool> instances and the existing Criterias property thus return IReadOnlyList<Func<ICakeContext, bool>>?

@ErikSchierboom I would prefer if we changed CakeTask.Criterias to be a IReadOnlyList<Func<ICakeContext, bool>> and converted the Func<bool> to a Func<ICakeContext, bool>.
We could also make the void AddCriteria(Func<bool> criteria) an extension method (since it's more or less a convenience method) and change the implementation in CakeTask to void AddCriteria(Func<ICakeContext, bool> criteria)

Merged via #663.


fix(clerk-js): Move Invite button above the table in every tab for …mbers page in OP

Description
Before:

After:

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

!preview

Hey @octoper, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Feb 15, 2024 01:26 PM

!preview

!preview

!preview


FLINK-1737: Kronecker product

This is preparational work related to FLINK-1737: Adds an implementation of outer/Kronecker product which can subsequently be used to compute the sample covariance matrix.

Thanks a lot for the pull request.
Sorry that nobody looked at it yet. It seems that all committers are currently very busy. I'm sure somebody will give you soon feedback.

Your build is failing due to scalastyle checks
[INFO]
[INFO] --- maven-failsafe-plugin:2.17:verify (default) @ flink-ml ---
[INFO] Failsafe report directory: /home/travis/build/apache/flink/flink-staging/flink-ml/target/failsafe-reports
[INFO]
[INFO] --- scalastyle-maven-plugin:0.5.0:check (default) @ flink-ml ---
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=101
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=108
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=111
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=118
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=125
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=132
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=136
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=139
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/DenseVectorSuite.scala message=File line length exceeds 100 characters line=146
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=151
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=158
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=162
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=169
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=176
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=180
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=183
error file=/home/travis/build/apache/flink/flink-staging/flink-ml/src/test/scala/org/apache/flink/ml/math/SparseVectorSuite.scala message=File line length exceeds 100 characters line=190
Saving to outputFile=/home/travis/build/apache/flink/flink-staging/flink-ml/scalastyle-output.xml
Processed 64 file(s)
Found 17 errors

Looks good to me except some minor issues (including things @rmetzger said). But there is no JIRA issue covered this PR. We should create JIRA issue first.

Will be fixed and I will also review what @chiwanpark suggested, though I think .toArray was called with an intend (for comprehensions yield collections of the same type as the type of the first collection put into them).

Thank you very much @daniel-pape for you contribution. Looks really good. I had only some minor comments.

Sorry for my late reply @daniel-pape. The PR looks really good. I had only one minor comment. Once this is fixed, it's good to be merged.

Thanks for the comment @tillrohrmann. Just pushed the changes.

Looks really good :-) Thanks for your contribution @daniel-pape. Will merge it.


After upgrading to doctrine-bundle 2.0 - dependency injection missed type hint

during my last composer update command, the doctrine-bundle changed to 2.0

Removing doctrine/doctrine-cache-bundle (1.3.5)
Updating doctrine/doctrine-bundle (1.11.2 => 2.0.0): Loading from cache
Updating doctrine/orm (v2.6.4 => v2.7.0): Loading from cache

From this moment on, I got the error :
!!  In TwigExtension.php line 30:
!!
!!
I found a workaround by defining manually the twig extension service as :
dh_doctrine_audit.twig_extension:
    class: 'DH\DoctrineAuditBundle\Twig\Extension'
    arguments:
        - '@DH\DoctrineAuditBundle\Twig\Extension\RegistryInterface'

I think this is not the best solution, but in the meantime I can run the web.
Regards.
Facundo.
pd.  I use Symfony 4

Hi @yspef, I'm a bit confused, what version of this bundle are you using? You can run composer show | grep "doctrine-audit-bundle" and report it back here.
I strongly encourage you to upgrade to the latest version of the audit bundle (cf. How to upgrade?)

RegistryInterface & Registry are marked deprecate since DoctrineBundle 1.12 (doctrine/DoctrineBundle#1052) and already remove in 2.0.
You must use ManagerRegistry to get doctrine on 2.0

@yspef @maxhelias This should be fixed on master branch.

composer show | grep "doctrine-audit-bundle"

It gives :
damienharper/doctrine-audit-bundle  3.0.0      This bundle creates audit logs for all doctrine ORM database related changes.

@yspef @maxhelias This should be fixed on master branch.

Upgraded to dev-master solves the issue.
Thanks.
Regards.

I am experiencing the same problem. Can you release this as 3.0.1, please?

@YetiCGN I will make a new release soon

Thanks, that's great!

I just had the same issue, but realised I was on ^2.0, updating to ^3.0 worked


[Snyk] Security upgrade requests from 2.30.0 to 2.32.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `pip` dependencies of this project.
Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

services/workshop/requirements.txt

Vulnerabilities that will be fixed
By pinning:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

83/1000  Why? Confidentiality impact: High, Integrity impact: High, Availability impact: None, Scope: Unchanged, Exploit Maturity: No data, User Interaction (UI): Required, Privileges Required (PR): High, Attack Complexity: High, Attack Vector: Local, EPSS: 0.01055, Social Trends: No, Days since published: 0, Reachable: No, Transitive dependency: No, Is Malicious: No, Business Criticality: High, Provider Urgency: Medium, Package Popularity Score: 99, Impact: 8.63, Likelihood: 0.954, Score Version: V5
Always-Incorrect Control Flow Implementation SNYK-PYTHON-REQUESTS-6928867
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.
Some vulnerabilities couldn't be fully fixed and so Snyk will still find them when the project is tested again. This may be because the vulnerability existed within more than one direct dependency, but not all of the affected dependencies could be upgraded.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Note: This is a default PR template raised by Snyk. Find out more about how you can customise Snyk PRs in our documentation.
Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Checkmarx One – Scan Summary & Details – dff20a4f-7a87-49c7-bef5-7a93469f1221
New Issues

Severity
Issue
Source File / Package
Checkmarx Insight

CVE-2023-42282
Npm-ip-1.1.8
Vulnerable Package

CVE-2023-45288
Go-golang.org/x/net-v0.0.0-20200324143707-d3edc9973b7e
Vulnerable Package

CVE-2023-50782
Python-cryptography-40.0.2
Vulnerable Package

CVE-2023-52428
Maven-com.nimbusds:nimbus-jose-jwt-9.25.6
Vulnerable Package

CVE-2023-6481
Maven-ch.qos.logback:logback-core-1.2.7
Vulnerable Package

CVE-2024-1597
Maven-org.postgresql:postgresql-42.4.0
Vulnerable Package

CVE-2024-22243
Maven-org.springframework:spring-web-5.3.13
Vulnerable Package

CVE-2024-22257
Maven-org.springframework.security:spring-security-core-5.6.0
Vulnerable Package

CVE-2024-22259
Maven-org.springframework:spring-web-5.3.13
Vulnerable Package

CVE-2024-22262
Maven-org.springframework:spring-web-5.3.13
Vulnerable Package

CVE-2024-23672
Maven-org.apache.tomcat.embed:tomcat-embed-websocket-9.0.55
Vulnerable Package

CVE-2024-23672
Maven-org.apache.tomcat.embed:tomcat-embed-core-9.0.55
Vulnerable Package

CVE-2024-24549
Maven-org.apache.tomcat.embed:tomcat-embed-core-9.0.55
Vulnerable Package

CVE-2024-26130
Python-cryptography-40.0.2
Vulnerable Package

CVE-2024-27088
Npm-es5-ext-0.10.62
Vulnerable Package

CVE-2024-27351
Python-Django-4.1.13
Vulnerable Package

CVE-2024-29180
Npm-webpack-dev-middleware-3.7.3
Vulnerable Package

CVE-2024-31573
Maven-org.xmlunit:xmlunit-core-2.8.3
Vulnerable Package

CVE-2024-34069
Python-Werkzeug-2.0.3
Vulnerable Package

CVE-2024-4067
Npm-micromatch-3.1.10
Vulnerable Package

CVE-2024-4067
Npm-micromatch-4.0.2
Vulnerable Package

CVE-2024-4068
Npm-braces-3.0.2
Vulnerable Package

CVE-2024-4068
Npm-braces-2.3.2
Vulnerable Package

Cx89a94f30-7a24
Python-sqlparse-0.2.4
Vulnerable Package

JWT_No_Signature_Verification
/services/web/src/utils.js: 21
Attack Vector

Process_Control
/services/community/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/auth/internal/gssapi/sspi_wrapper.c: 12
Attack Vector

Process_Control
/services/community/vendor/github.com/globalsign/mgo/internal/sasl/sspi_windows.c: 17
Attack Vector

CSRF
/services/workshop/crapi/mechanic/views.py: 131
Attack Vector

CVE-2024-21506
Python-pymongo-3.13.0
Vulnerable Package

CVE-2024-28849
Npm-follow-redirects-1.15.2
Vulnerable Package

CVE-2024-28863
Npm-tar-6.1.11
Vulnerable Package

CVE-2024-29041
Npm-express-4.18.2
Vulnerable Package

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 143
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/apps.py: 65
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 93
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 126
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/apps.py: 72
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 107
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 163
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/crapi/shop/tests.py: 122
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/utils/helper.py: 5
Attack Vector

Filtering_Sensitive_Logs
/services/workshop/utils/helper.py: 5
Attack Vector

Missing_HSTS_Header
/services/identity/src/main/java/com/crapi/config/JwtAuthEntryPoint.java: 44
Attack Vector

Missing_HSTS_Header
/services/workshop/crapi_site/settings.py: 1
Attack Vector

Privacy_Violation
/services/identity/src/main/java/com/crapi/utils/SMTPMailServer.java: 56
Attack Vector

Privacy_Violation
/services/identity/src/main/java/com/crapi/service/Impl/UserRegistrationServiceImpl.java: 60
Attack Vector

Privacy_Violation
/services/identity/src/main/java/com/crapi/utils/SMTPMailServer.java: 56
Attack Vector

Privacy_Violation
/services/community/api/config/Initialize_mongo.go: 27
Attack Vector

Privacy_Violation
/services/community/api/config/Initialize_mongo.go: 27
Attack Vector

Privacy_Violation
/services/community/api/config/Initialize_postgres.go: 36
Attack Vector

Privacy_Violation
/services/community/vendor/github.com/jinzhu/gorm/field.go: 25
Attack Vector

Privacy_Violation
/services/community/vendor/github.com/jinzhu/gorm/errors.go: 18
Attack Vector

Privacy_Violation
/services/community/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/auth/mongodbcr.go: 92
Attack Vector

Privacy_Violation
/services/community/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/auth/scram.go: 32
Attack Vector

SSL_Verification_Bypass
/services/workshop/crapi/shop/views.py: 128
Attack Vector

SSL_Verification_Bypass
/services/workshop/crapi/merchant/views.py: 77
Attack Vector

SSL_Verification_Bypass
/services/community/api/auth/token.go: 56
Attack Vector

SSRF
/services/workshop/crapi/user/models.py: 61
Attack Vector

SSRF
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

SSRF
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 147
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/ProfileController.java: 98
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 132
Attack Vector

Unsafe_Object_Binding
/services/identity/src/main/java/com/crapi/controller/UserController.java: 60
Attack Vector

Use_of_Cryptographically_Weak_PRNG
/services/gateway-service/main.go: 131
Attack Vector

Use_of_Cryptographically_Weak_PRNG
/services/gateway-service/main.go: 84
Attack Vector

Use_of_Cryptographically_Weak_PRNG
/services/community/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/topology/topology.go: 380
Attack Vector

Use_of_Cryptographically_Weak_PRNG
/services/community/vendor/go.mongodb.org/mongo-driver/x/mongo/driver/topology/topology.go: 336
Attack Vector

Heap_Inspection
/services/identity/src/main/java/com/crapi/model/SeedUser.java: 31
Attack Vector

Heap_Inspection
/services/identity/src/main/java/com/crapi/entity/UserPrinciple.java: 35
Attack Vector

Heap_Inspection
/services/identity/src/main/java/com/crapi/entity/User.java: 36
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ProfileController.java: 62
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 95
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/service/Impl/ProfileServiceImpl.java: 210
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ProfileController.java: 147
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/service/Impl/ProfileServiceImpl.java: 208
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/service/Impl/ProfileServiceImpl.java: 209
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 54
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 54
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/ChangeEmailController.java: 43
Attack Vector

Log_Forging
/services/identity/src/main/java/com/crapi/controller/AuthController.java: 77
Attack Vector

Use_Of_Hardcoded_Password
/services/workshop/utils/mock_methods.py: 84
Attack Vector

Use_Of_Hardcoded_Password
/services/workshop/utils/mock_methods.py: 54
Attack Vector

Use_Of_Hardcoded_Password
/services/workshop/utils/mock_methods.py: 42
Attack Vector

Use_Of_Hardcoded_Password
/services/workshop/crapi/apps.py: 72
Attack Vector

Use_Of_Hardcoded_Password
/services/workshop/crapi/apps.py: 65
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/OtpServiceImplTest.java: 240
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserServiceImplTest.java: 534
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserServiceImplTest.java: 555
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/ProfileServiceImplTest.java: 361
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/OtpServiceImplTest.java: 240
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/OtpServiceImplTest.java: 240
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserServiceImplTest.java: 571
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserServiceImplTest.java: 555
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserServiceImplTest.java: 563
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/UserRegistrationServiceImplTest.java: 124
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/test/java/com/crapi/service/Impl/ProfileServiceImplTest.java: 382
Attack Vector

Use_Of_Hardcoded_Password
/services/identity/src/main/java/com/crapi/config/MailConfiguration.java: 47
Attack Vector

More results are available on AST platform


[TEST] jenkins pipeline RHEL k8s cluster setup failed

What's the test to develop? Please describe
For RHEL >= 8.4 (tried RHEL-8.6.0_HVM-20220503-x86_64-2-Hourly2-GP2, RHEL-8.4.0_HVM-20210825-x86_64-0-Hourly2-GP2), setup k3s cluster will show the following error:
Job for k3s.service failed because the control process exited with error code.
See "systemctl status k3s.service" and "journalctl -xe" for details.
[root@ip-10-0-1-127 ~]# systemctl status k3s.service
● k3s.service - Lightweight Kubernetes
   Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2022-08-01 02:34:37 UTC; 2s ago
     Docs: https://k3s.io
  Process: 14919 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=1/FAILURE)

Aug 01 02:34:37 ip-10-0-1-127.ec2.internal systemd[1]: k3s.service: Control process exited, code=exited status=1
Aug 01 02:34:37 ip-10-0-1-127.ec2.internal systemd[1]: k3s.service: Failed with result 'exit-code'.
Aug 01 02:34:37 ip-10-0-1-127.ec2.internal systemd[1]: Failed to start Lightweight Kubernetes.

rke or rke2 fails too.
Temporarily using RHEL 8.3 (RHEL-8.3_HVM-20210209-x86_64-0-Hourly2-GP2) to run regression tests.

Ref:
https://github.com/rancher/rke2/issues/1053#issuecomment-854875902
https://rancher.com/docs/k3s/latest/en/advanced/#additional-preparation-for-red-hat-centos-enterprise-linux
After disable nm-cloud-setup.service and nm-cloud-setup.timer, It's able to successfully start k3s service manually, but when using terraform, it's still problematic, currently the worker nodes cannot join the master node. More investigation needed.
https://github.com/longhorn/longhorn-tests/commit/c606d4a733be34cde9f105e63b9499f99bb24b00

https://github.com/longhorn/longhorn-tests/pull/1122 should fix k3s error, but rke2 and rke would work or not still need further investigation (tracked by https://github.com/longhorn/longhorn/issues/4466), some combinations probably never work at the beginning.

Already confirmed rhel 9.1 + k3s and rhel 9.1 + rke2 works without problems.


minor cleanups

cleanups of minor issues found during testing of https://github.com/k8stopologyawareschedwg/resource-topology-exporter/pull/11

/lgtm


Fix crash when creating xmlHandler #5319

Fixes #5319

https://console.firebase.google.com/u/0/project/alphawallet-ios-prod/crashlytics/app/ios:com.stormbird.alphawallet/issues/69686d40b51e807d89a8355193b81989?time=last-thirty-days&types=crash&versions=3.49 (447);3.49 (446)&sessionEventKey=ea95f51e30c94a83a97184fb98111609_1714845666857954812

Yes.

Similar to the earlier comments about queue/thread-safe access, I rather we figure out a better way. But let's go with it for now :)


How to disassociate routetable from subnet ?

Hi, how can I remove route table association from existing subnet ?
For association using this:
az network vnet subnet update -g $rg -n XXX --vnet-name YYY --route-table RTNAME
What to use to remove association ?

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

ID: 385e420c-4bd0-3ddd-d9cd-a9a411ec1f7b
Version Independent ID: 65172372-f485-3d2b-64aa-57c38ac11538
Content: az network vnet subnet
Content Source: src/azure-cli/azure/cli/command_modules/network/_help.py
Service: virtual-network
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

+1

foud it, use --remove routeTable

@CharmanderJieniJieni thank you ! I would suggest to update documentation.

@jjindrich Thanks. We will take a look and improve the doc.


RTL Official support

Hi, Does the Bootstrap developers team intend to add right-to-left support for this project?
Unofficial tools are mostly out of dated or don't work properly. A great community of bootstrap users with right-to-left languages (like Persian, Arabic & ...) are facing this problem for several years. please pay attention to us 😥 .

Duplicate of #24807.

@alecpl Yes that's right, I see had seen this issue before but no clear answer was given, so I opened a new issue.

RTL and LTR version:
https://github.com/mRizvandi/AryaBootstrap/blob/master/ReadMe.En.md


Add test for creating OVM from template via oc CLI

Test for creating and running OVM from a template via external oc command
Goal
Provide test automation covering creation and execution of an OfflineVirtualMachine created from an OpenShift Template. The test has to use the external oc command.
Test cases covered

Generate OfflineVirtualMachine JSON file from a template via external oc command.
Create OfflineVirtualMachine from a template via external oc command.
Start OfflineVirtualMachine created from a template via external oc command.

Known issues of the current implementation

The test template should be generated from a struct rather than hard-coded JSON string.

Overal looks good to me !!

Can you please fix travis errors
go version go1.10 linux/amd64
/root/go/src/kubevirt.io/kubevirt/tests/oc_template_test.go:50:14: expected type, found '&'
/root/go/src/kubevirt.io/kubevirt/tests/oc_template_test.go:167:3: missing ',' in composite literal
make: *** [build] Error 2

@gszasz Hi Gabriel, I fixed and added some stuff to your PR, I think you can take it from here

check that test passed locally
maybe you can re-organize methods that I added because I just copy pasted them from tools/vms-generator/vms-generator.go

@rmohr Maybe it worth to create some common utils pkg, that tools and tests can use?

OK to test

@gszasz I see test skipped on openshift environment, can you please check it.

@cynepco3hahue It appears that "skip if no OC" is triggered if the oc binary does not appear on the system path. This is a pretty reasonable approach as the test case runs the oc command so will fail if it's not present. I assume that binary is available in CI?

@stu-gott I think @gszasz  must explicitly set oc path via argument, otherwise, it always will fail, because we do not run our tests on master

@gszasz what needs to be done next to get this merged?

Looks good overall

/release-note-none

retest this please

retest this please


database

May I ask how sun360 database is obtained?

The Sun360 dataset in our paper is from "https://github.com/lh9171338/Unified-Line-Segment-Detection".

Thank you!


Better than the official, but of course be. UWP

It might someday be UWP, also operate in windows phone.
Suggestion:
This could include a safety pin to open the app

This app is an UWP app, but as stated, it's a wrap over the web.whatsapp site. Which, since is does not look responsive, the app does not look good in the phone.
Anyways, why would you want it on your phone when you can get the official WhatsApp app?

Due to the lack of updating of the official application and without the design of windows 10 update, I see this app (WhosDows), great potential to succeed in the mobile.

Duplicate of #4


fix(linter): no-useless-escape: do not crash on backslash character

Fixes https://github.com/oxc-project/oxc/issues/6046
Unlike other escape sequences such as /\w/, this is not actually parsed as a single character: /\c/ so we incorrectly try to get the character before the backslash, which doesn't exist.

#6048  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @camchenry and the rest of your teammates on  Graphite

@Boshen This is another panic fix, if you were considering another patch release similar to 0.9.8.