Allow Users to Submit PRs for Documentation

Currently, there is no way for outside users of Gobblin to make changes to the wiki. Only the GitHub owners are allowed to do that. There should be an easy way for users to create a PR for changes to the wiki.
Relevant Links:
https://groups.google.com/forum/#!topic/gobblin-users/FuKybhhZh8M
https://github.com/linkedin/gobblin/pull/685

Some discussion that was done internally:
Notes on Possible Approaches:

The GitHub wiki is also a git project, git://github.com/linkedin/gobblin.wiki.git

Unfortunately, you cannot fork the wiki git repo
It is possible to add the wiki git repo as a git submodule, but git submodules have a number of issues that make it hard to deal with

Many projects don't use the GitHub wiki for this reason, and instead use https://pages.github.com/ to host the documentation

The content of this page are checked into the branch called gh-pages on GitHub
This is arguably more flexible than the GitHub wiki as it allows us to make more dynamic documentation using HTML, JavaScript, etc.

Presto uses a similar approach, but most documentation is stored in rst format and then converted to html using a tool called sphinx

It seems that all the docs are in the main branch under presto-docs, and users submit PRs directly to these files
The project owners then have to manually build the docs on their own machine and then update them to the gh-pages branch

From Chavdar:

The gh-pages supports the Markdown format of the wiki so moving the pages should not be overly hard. We should make sure that we can create PRs for the gh-pages branch.
The main downside that I see to using gh-pages is losing the search box for wikis. Arguably, google should be able to take care of that.

One thing to note is that having different branches/repos for code and documentation make it difficult to have a single PR which encompasses an entire feature (code, tests, documentation, etc).  Also, hosting docs on https://readthedocs.org would provide a searchable, version-able place to host documents.  Airflow from AirBnB is an example project which had documentation there.  You can see it at: http://airflow.readthedocs.org.  The source for the documentation is in the regular github repo: https://github.com/airbnb/airflow/tree/master/docs

Sphinx and readthedocs seem interesting. Although it seems Sphinx is primarily geared towards documenting Python projects (I believe Airflow is written in Python). However, there is Java integration: http://bronto.github.io/javasphinx/

Yes, Airflow is python and sphinx was geared to python originally, but there are other non-python projects like Presto which use it.  It seems no less capable as far a documentation is concerned than the GitHub wiki or GitHub pages.  javasphinx seems nice for documenting java apis, but I have no experience with it.  The other proposed documentation approaches also don't handle documenting java apis.

Another readthedocs example: http://docs.qubole.com/en/latest/

I played around this for a while last night and for most of today, and I should have a working version that uses MkDocs and readthedocs.
Some observations:

I played around with pandoc, sphinx, mkdocs, and readthedocs
readthedocs seems geared towards sphinx support with MkDocs support added, but not fully integrated, see https://github.com/rtfd/readthedocs.org/issues/978
Sphinx requires .rst, while MkDocs uses .md
** Since we have been using MarkDown for a while now in the GitHub wiki I think it may be better to stick with MarkDown
** While pandoc can do the conversion, it will be hard to automate + more conversion = more bugs
MkDocs can only use the ReadTheDocs theme, it cannot use any of the themes built for MkDocs
** While this is a limitation I think the UI still looks good and it provides all the core features we are looking for

@kadaan, any objections to using readthedocs + MkDocs
The setup will be as follows:
./mk-docs.yml
/docs/[bunch of MarkDown files]

Does mkdocs support github flavored markdown?
On Fri, Feb 19, 2016 at 2:29 PM, sahilTakiar<EMAIL_ADDRESS>wrote:

I played around this for a while last night and for most of today, and I
should have a working version that uses MkDocs and readthedocs.
Some observations:

I played around with pandoc, sphinx, mkdocs, and readthedocs
readthedocs seems geared towards sphinx support with MkDocs support
added, but not fully integrated, see rtfd/readthedocs.org#978
https://github.com/rtfd/readthedocs.org/issues/978
Sphinx requires .rst, while MkDocs uses .md ** Since we have been
using MarkDown for a while now in the GitHub wiki I think it may be better
to stick with MarkDown ** While pandoc can do the conversion, it will be
hard to automate + more conversion = more bugs
MkDocs can only use the ReadTheDocs theme, it cannot use any of the
themes built for MkDocs ** While this is a limitation I think the UI still
looks good and it provides all the core features we are looking for

@kadaan https://github.com/kadaan, any objections to using readthedocs

MkDocs

The setup will be as follows:
./mk-docs.yml
/docs/[bunch of MarkDown files]
—
Reply to this email directly or view it on GitHub
https://github.com/linkedin/gobblin/issues/724#issuecomment-186434849.

@ibuenros it seems it does not have full support for it, I believe it uses Python Markdown, although I am not sure what the difference is: https://github.com/mkdocs/mkdocs/issues/99

It seems to be possible though: https://github.com/google/py-gfm
Docs on what Python Markdown is: https://pythonhosted.org/Markdown/

This seems great. I can't wait!

@kadaan no some of those features will probably not be available. However, Python Markdown provides a number of extensions that can be added that provide features like automatically created Table of Contents: http://pythonhosted.org/Markdown/extensions/

This sounds like a great place to start and way better than trying to use the github wiki.

@liyinan926 do you have admin privileges on the GitHub Gobblin project? I want to edit the project settings but they aren't showing up for me. Can you add me?
There should be a settings tab like below:

But I don't see one:

@sahilTakiar It seems my admin/write access has been revoked. You probably need to check with the owners of the linkedin org.

K thanks Yinan, will consult internally.
Initial version using ReadTheDocs and MkDocs: http://gobblin-sahiltakiar.readthedocs.org/en/readthedocs/
Still working out some formatting and build issues, need to get WebHooks setup too.

Looking really good!  Any idea why the the bottom left pull-put menu isn't working?
Gobblin

Airflow

Thanks!
I haven't pin-pointed the cause yet, but there is some JavaScript error when loading the footer:
Error loading Read the Docs footer
$.ajax.error @ readthedocs-doc-embed.js:1

I see a 404 when loading:
https://readthedocs.org//api/v2/footer_html/?callback=jQuery211033368984144181013_1456216601639&project=gobblin-sahiltakiar&version=readTheDocs&page=index&theme=sphinx_rtd_theme&format=jsonp&docroot=%2Fhome%2Fdocs%2Fcheckouts%2Freadthedocs.org%2Fuser_builds%2Fgobblin-sahiltakiar%2Fcheckouts%2Freadthedocs%2Fgobblin-docs&source_suffix=.md&_=1456216601640
Whereas in airflow:
https://readthedocs.org//api/v2/footer_html/?callback=jQuery20306277235785964876_1456216654291&project=airflow&version=latest&page=index&theme=sphinx_rtd_theme&format=jsonp&docroot=%2Fdocs%2F&source_suffix=.rst&_=1456216654292
returns:
jQuery20306277235785964876_1456216654291({
    "version_compare": {
        "project": "None",
        "version": "None",
        "is_highest": true
    },
    "promo": true,
    "version_active": true,
    "version_supported": true,
    "html": "\n
\n\n  \n\n      \n      \n      \n      \n\n      \n      \n
\n
Downloads
\n        \n
HTML
\n        \n
\n      \n      \n\n      \n
\n        \n
On Read the Docs
\n
\n          Project Home\n
\n
\n          Builds\n
\n
\n          Downloads\n
\n
\n      \n\n      \n\n      \n
\n
On GitHub
\n
\n          View\n
\n
\n          Edit\n
\n
\n      \n      \n\n      \n
\n
Search
\n
\n
\n            <form id=\"flyout-search-form\" class=\"wy-form\" target=\"_blank\" action=\"https://readthedocs.org/projects/airflow/search/\" method=\"get\">\n              <input type=\"text\" name=\"q\" placeholder=\"Search docs\">\n              </form>\n
\n
\n
\n      \n\n\n\n
\n      \n      Free document hosting provided by Read the Docs. \n      \n\n      \n\n
\n",
    "promo_data": {
        "text": "Thanks for supporting Read the Docs!",
        "image": "",
        "link": "",
        "id": "gold-user"
    }
});

hmm I still need to investigate, there are a few outstanding issues like this I'm trying to resolve before making the PR.

Post Commit Webhooks work, push to the readthedocs branch now automatically trigger a build.
Couldn't find out why the ReadTheDocs footer is not loading so opened an issue the ReadTheDocs GitHub page: https://github.com/rtfd/readthedocs.org/issues/2015

Initial PR: https://github.com/linkedin/gobblin/pull/788

New documentation system is live: http://gobblin.readthedocs.org/en/latest/


Create a pod of containers sharing volume

Right now the way we do conversion is more of one to one mapping. But when two services/containers share volume in docker-compose file we need to put those two containers in a single pod and make them share volume on kubernetes as well.
for e.g.: the following two services should be wound up into a single pod, by which I mean we will only create one deployment, which has one pod and both of those containers, and single service on top of them, if ports provided:
version: '2'

services:
  db:
    image: postgres
    volumes:
      - data:/var/lib/postgresql/data

  foosvc:
    image: foosvcimage
    volumes:
      - data:/var/lib/my/mount/point

volumes:
  data:
    external: true

That would be great if you can take it. I filed this issue before but have never tried. https://github.com/skippbox/kompose/issues/14

@ngtuna oops sorry for the duplicate will close this, will work on #14 !


Log in - When clicking on Resent Link, the error message is displayed instead of “Link has been resent” with a green dot

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

In the login screen, enter an email that doesn't have an Expensify account yet
In the "Resent link" page - Disable the internet connection in the device
Verify the "Resend link" button is disabled and there's a notice that the user is currently offline
Go back online and click/tap on the "Resend Link" button

Expected Result:
User should see  “Link has been resent” with a green dot on the left after click on "Resend Link" button
Actual Result:
When clicking on Resent Link, the error message is displayed instead of “Link has been resent” with a green dot
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/202714526-aa71fe0e-e570-4e31-a416-aca870e1f6bd.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

I can't reproduce this bug and I assume it is because it is not a bug, it's a feature that does not allow you to login/ask for reset link more than X times in Y period of time.


feat(datepicker): add inline visualization option

Would be nice if was possible to configure datepicker to be displayed inline

sample please

https://jqueryui.com/datepicker/
Datepicker is only open when user click on the input
Thank's for your attention

What I did : On click on the calendar Icon, i show the datepicker component as a toggle.
Template:

Component:
public clicked:boolean = false;
public toggleDP():boolean {
    this.clicked = !this.clicked;
    return !this.clicked;
  }

It's not exactly the same as in JQuery UI, but it's with the same intent.

Many easy workarounds. I simply use a ngIf for toggling.

Yes, there are many workarounds, but original Bootstrap accounts for a datepicker-inline attribute. I think TS is referring to this.

available in new datepicker from v1.9.2
http://valor-software.com/ngx-bootstrap/#/datepicker


How to implement load_root_certificates in the README

from appstoreserverlibrary.models.Environment import Environment
from appstoreserverlibrary.signed_data_verifier import VerificationException, SignedDataVerifier

root_certificates = load_root_certificates()
enable_online_checks = True
bundle_id = "com.example"
environment = Environment.SANDBOX
signed_data_verifier = SignedDataVerifier(root_certificates, enable_online_checks, environment, bundle_id)

try:
    signed_notification = "ey.."
    payload = signed_data_verifier.verify_and_decode_notification()
    print(payload)
except VerificationException as e:
    print(e)

In the Verification Usage section, there is a load_root_certificates function, but I don't find the implementation. How should I implement this correctly?

load_root_certificates is meant to be a stand-in for a function that will load the value of the certificates you download from https://www.apple.com/certificateauthority/ under the Apple Root Certificates section. Because these can be passed different ways, via a file, environment argument, or some other type of loader, the specific implantation is left to the user

@alexanderjordanbaker thanks for the reply, there are four root certificates listed on the website, but I don't find any description to describe the difference. Do I need to download all of them or is it sufficient to download just one?

If you were to decode a cert today you would find the G3 root cert, but we recommend downloading all of them. It does take an array of certs in the constructor.

@alexanderjordanbaker Okay, it would be better to have this information on the README as well, thanks again for the help.

For any future readers, here is one possible implementation of load_root_certificates() where the 3 .cer files (https://www.apple.com/certificateauthority/) are loaded from the filesystem:
def load_root_certificates():
    cert_paths = [
        'certs/AppleRootCA-G3.cer',
        'certs/AppleRootCA-G2.cer',
        'certs/AppleIncRootCertificate.cer',
    ]
    certs = []
    for path in cert_paths:
        file = open(path, 'rb')
        cert = file.read()
        file.close()
       certs.append(cert)

    return certs

This is by no means the only implementation (or even necessarily a 'good' one, what with the hardcoded file paths). But it will enable you to get started with the App Store Server Library in Python.


make Scan::execute return an iterator

Main things that should happen:

scan should return a lazy iterator
Internally in the file_replay_iter we should represent each "item" as EngineData + a selection vector (for which rows to process)
Only when getting an item out of the scan should we inspect the EngineData to get the needed items out of selected rows (i.e. the add file paths and deletion vectors), read the underlying data, and return the data plus dv mask.

Also relevant:
https://github.com/delta-incubator/delta-kernel-rs/pull/109#discussion_r1501270956

Some extra context: https://github.com/delta-incubator/delta-kernel-rs/pull/146#discussion_r1535567168


PushingToViewsBlockOutputStream: process blocks concurrently

The current model is to process blocks for attached views in sequence.
This is not ideal when the processing time for each view varies, or is blocking (for example with replicated tables), as processing of next-in-line view is blocked by wait in it's predecessor.
This commit changes the behavior to process 2 or more attached views concurrently.
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
cc @bocharov @dqminh

I could add it as a setting, but I'm not sure what would be a use case for that. Do you have a preference @ztlpn  @alexey-milovidov ?

I could add it as a setting, but I'm not sure what would be a use case for that. Do you have a preference @ztlpn @alexey-milovidov ?

Better to add a setting just to allow switch to previous behaviour in some edge cases.

Almost Ok.

Missing test that shows that it works with both values of setting.
Could you please make a separate PR with this test?

Will do @alexey-milovidov


Add a Gitter chat badge to README.md

SumoLogic/shellbase now has a Chat Room on Gitter
@cddude229 has just created a chat room. You can visit it here: https://gitter.im/SumoLogic/shellbase.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

I'll move it to a location consistent with elasticsearch-client once I have the others set up.


Issue with mapping of memories due to missing reset signal inference

After a couple really small changes to the RTL I managed to have the Sargantana core totally parsed. But when trying to synthesize for FPGA (ECP5 in this case) I'm facing this error, which is related to the module rtl/datapath/rtl/exe_stage/rtl/div_unit.sv:
2.26. Executing MEMORY_LIBMAP pass (mapping memories to cells).
found attribute 'ram_style = logic' on memory div_unit.cycles_counter, forced mapping to FF
Rejected candidates for mapping memory div_unit.cycles_counter:
can't map to logic: ports have different write clock domains
ERROR: no valid mapping found for memory div_unit.cycles_counter

I took a look at the RTL and this seems to be caused by a pattern equivalent to this:
module multiport_mem #(
    parameter integer NUM_COUNTERS = 2,
    localparam integer NUM_COUNTERS_BITS = NUM_COUNTERS == 1 ? 0 : $clog2(NUM_COUNTERS)-1
) (
    input logic clk_i,
    input logic rstn_i,
    input logic [NUM_COUNTERS_BITS:0] sel_i,
    input logic sync_rst_i,
    output logic [5:0] count
);
    logic [5:0] counter [NUM_COUNTERS-1:0];

    assign count =  counter [sel_i];

    always_ff @( posedge clk_i or negedge rstn_i ) begin : blockName
        if (~rstn_i) begin
            for (integer i =0; i < NUM_COUNTERS; i++) begin
                counter[i] <= 6'd0;
            end
        end else if (sync_rst_i) begin
            counter[sel_i] <= 6'd0;
        end else begin
            for (integer i =0; i < NUM_COUNTERS; i++) begin
                if (counter[i] != 6'd0) begin
                    counter[i]   <= counter[i] - 6'd1;
                end
            end
        end
    end
endmodule

As you can see, the counter memory is not totally reset, but only the part selected by sel_i. I checked the RTLIL and found out that for the async reset, the clock of the memory cell is the rstn_i signal, and the regular write port uses clk_i as expected.
On the other hand, I'm seeing that for the read side, the synchronous and asynchronous reset inputs are always tied to 0. I assume for correctly setting the resets we would need to detect which signal is a reset (i guess the most simple heuristic would be if it is inside the sensitivity list and also enables writes to the memory).

I noticed this is independent of the sync reset, it seems to happen whenever there's an async reset. Let me check if theres any memory with async reset that is being correctly inferred...

Oops, I just noticed that 1) async reset detection is already implemented as proc_arst at RTLIL level, and 2) that pass was not being called by the frontend.

So, going back to what I thought about previously. Add the current UpdateTiming to SignalEvalContext and infer the reset by checking if the signal is in the sensitivity and also drives the memory write port. The only thing I found a bit annoying but probably has a reason is that we have to infer the async-reset signal from the $memwr cell, but use it as input for $memrd

The only thing I found a bit annoying but probably has a reason is that we have to infer the async-reset signal from the $memwr cell, but use it as input for $memrd

I don't think this transformation is functionally correct. The ARST input on $memrd_v2 does not reset the memory content, only the current output of the read port, if the read port is a synchronous one.
The way out here is to make sure variables are not inferred as memories if they are written to from the asynchronous branch of the async always_ff pattern.

Okay, sorry. I didn't know about the implications of memory cells. Then if its async reset, disqualify for inference and go for plain DFFs right?

Yes, exactly!

Fixed in 5aaa6e7


RFC: Generic member access for dyn Error trait objects

Rendered
Also, I've mocked up the proposal in this repository - https://github.com/yaahc/nostd-error-poc/

@burdges this is a general restriction on Any and downcast on Error types, I don't think it's currently possible to downcast types that aren't : 'static
The second design with the a Provider miiight work with this, not sure.

One thing I'm uneasy with reusing the object-provider API is the double lifetime:
fn get_context<'r, 'a>(&'a self, request: Request<'r, 'a>) -> ProvideResult<'r, 'a> {  ...  }

Having one explicit lifetime can still be managed, but having two or more correlated lifetimes becomes mentally challenging.
IMO we shouldn't need to copy the object-provider API entirely.
Firstly, the return type ProvideResult<'r, 'a> is unnecessarily complex in order to support ?. This type actually only has 2 states: fulfilled or not. This is isomorphic to a bool. So why not just make it a bool?
fn get_context<'a>(&'a self, request: Request<'_, 'a>) -> bool {
    request.provide::<Backtrace>(&self.backtrace) ||
        request.provide::<SpanTrace>(&self.span_trace) ||
        request.provide::<dyn Error>(&self.source) ||
        request.provide::<Vec<&'static Location<'static>>>(&self.locations) ||
        request.provide::<[&'static Location<'static>]>(&self.locations)
}

But type safety maybe a concern (e.g. user might have used && instead of ||), so we could absorb that bool into the Request and use the builder pattern
fn get_context<'_, 'a>(&'a self, request: &mut Request<'_, 'a>) {
    request
        .provide::<Backtrace>(&self.backtrace)
        .provide::<SpanTrace>(&self.span_trace)
        .provide::<dyn Error>(&self.source)
        .provide::<Vec<&'static Location<'static>>>(&self.locations)
        .provide::<[&'static Location<'static>]>(&self.locations);
}

In fact, unless you're only want to keep the first T1 in request.provide::<T1>(&t11).provide::<T1>(&t12);, even the boolean check is unnecessary, since LLVM is able to optimize that chain involving lots of if TypeId::of::<T>() == self.type_id() into a switch table.
Secondly, Request<'r, 'a> has two lifetimes essentially because it represents a &'r mut &'a Any. Perhaps we could shave off the outer reference? It is actually possible through an extern type. This further simplifies get_request into a single lifetime
fn get_context<'a>(&'a self, request: &mut Request<'a>) {
    ...
}

The diff is a bit long, I've pushed it to https://github.com/yaahc/nostd-error-poc/compare/yaahc:eaa45d4...kennytm:dbd5f03?w=1 for reference.

There was a specific soundness issue which caused @mystor to add the double lifetime, though I don't remember what it was. Overall I'm definitely in favor of removing the double lifetime if possible but we should check with nika first probably.

Firstly, the return type ProvideResult<'r, 'a> is unnecessarily complex in order to support ?. This type actually only has 2 states: fulfilled or not. This is isomorphic to a bool. So why not just make it a bool?

entirely in favor of simplifying the result type

In fact, unless you're only want to keep the first T1 in request.provide::<T1>(&t11).provide::<T1>(&t12);, even the boolean check is unnecessary, since LLVM is able to optimize that chain involving lots of if TypeId::of::<T>() == self.type_id() into a switch table.

I do feel it is important to keep the explicit type parameter rather than manually doing the type id comparisons, assuming that's what you mean here. By using the explicit type parameter you get compile errors when they mismatch and it works as a coercion site which makes the API more convenient to use and less error prone overall.

@yaahc I agree that it's not a good idea to manually compare TypeId. What I mean is that, after all inlining, the generated code in get_context() will look like
if request.type_id() == TypeId::of::<T1>() {
    /* code for T1 */
}
if request.type_id() == TypeId::of::<T2>() {
    /* code for T2 */
}
if request.type_id() == TypeId::of::<T3>() {
    /* code for T3 */
}
...

which LLVM will notice that all the type_id is immutable and optimize into
match request.get_type_id() {
    const { TypeId::of::<T1>() } => { /* code for T1 */ }
    const { TypeId::of::<T2>() } => { /* code for T1 */ }
    const { TypeId::of::<T3>() } => { /* code for T1 */ }
    ...
}

and thus the short-circuit property of ? and || are not necessary to produce the optimal code.

As I mention in that old comment, the &mut approach also requires a second lifetime, but it's hidden on the &mut itself. The original approach in the object-provider crate actually used a similar design.
The main drawback with the bare &mut Request type is unsoundness due to mem::swap. Take, for example, the following code, which can fulfill the outer request with a NonZeroUsize, despite it requesting a &'static u8 (untested, but I believe something similar can be written):
let x: NonZeroUsize = ...;
let bad_pointer = Request::with::<&'static u8>(|ra| {
    Request::with::<NonZeroUsize>(|rb| {
        mem::swap(ra, rb);
    });
    ra.provide::<NonZeroUsize>(&x);
}).unwrap();
// `bad_pointer` is invalid

I believe this unsoundness can be avoided by using Pin, and some of the PhantomData shenanigans to make the 'out lifetime invariant aren't necessary when it's behind a &mut, so it's at least a bit simpler to use.
#[repr(C)]
 pub struct Request<'out> {
    type_id: TypeId,
    _pinned: PhantomPinned,
    _marker: PhantomData<&'out ()>,
}

// ...
fn get_context<'a>(&'a self, request: Pin<&mut Request<'a>>) {
    ...
}

The remaining downside with this simplified Pin-based design is that it doesn't provide any sort of of single-use guarantee, but I think that's an acceptable trade-off for the perceived simplicity, especially as most call-sites will chain .provide method calls.

@yaahc  @mystor Yes there is an implicit second lifetime in &mut Request<'a>, but being implicit makes it easier to deal with — you could mostly ignore that lifetime when reading.
I think we could workaround the unsoundness by making Request::with private (pub(crate)), since Request::with is only used in <dyn Error>::context. This ensures there cannot never be two Request instances simultaneously in the same thread.
But if we have to keep Request::with public, I agree that the Pin-based design is the best solution.
(Or we should restart the progress on #1861 so we could add a thin unsized tail to Request, which also properly makes mem::swap not callable.)

Adding something like core::any::Request, and making it's soundness require that it is only used by Error seems unfortunate to me, so I'd greatly prefer the Pin solution, even if we choose not to initially stabilize a method like Request::with.
Adding a thin unsized tail would also be nice, and this exact sort of use-case is why I was interested in #1861 and #1993. I worry a bit about creating a dependency on solving thin unsized types for this RFC, though, as it has proven to be difficult to solve in a satisfying manner.

I lean towards preferring a design that makes Request generally usable, but I otherwise agree with all of your changes @kennytm, so I'm going to pull in your branch and add Pin and update the RFC to match.

@kennytm @yaahc I actually wrote a branch for a potential 0.2.0 version of the object-provider crate which also uses Pin<&mut T> internally. I think there are a few behaviour differences between the two. https://github.com/mystor/object-provider/tree/pin_variant

Note that @withoutboats proposed to stabilize Error::backtrace in rust-lang/rust#72981.

Has there been any consideration of core::task::Context in this API? It has a similar need for user-defined types, and (if they were added) would ideally use the same mechanism as Error.
It would seem the major differences are that Context would typically use a &mut reference, and also have a greater need for types that borrow from the Context.
It'd be possible to express with a trait, at a cost to ergonomics:
/// Implemented on a type to enable it to be used with `context`
trait Request<'a>: 'static {
    /// The type returned by `context` calls
    type Out;
}

Would it be possible to add a TypeId that used the same id for types with different lifetimes? The implementation wouldn't need to be public API

Has there been any consideration of core::task::Context in this API? It has a similar need for user-defined types, and (if they were added) would ideally use the same mechanism as Error.

Not particularly, and I'm sorry but I'm not really following you on how Context is related to this API or how it has similar needs for user-defined types. Could you explain what you mean? Is the Context in this case filling the same role as the &dyn std::error::Error type in the generic member access API?

Right. Futures are all tied to a specific reactor that manages their resources (Like sleeping and spawning other futures), and there have been a few proposals for giving them a generic way to communicate with the executor they're running in. The Request type added in this PR functions similarly to some of those proposals.
pub mod hook {
    pub struct Sleep {
        pub dur: Duration,
        marker: PhantomPinned,
    }
    impl Future for Sleep {
        type Output = ();
        fn poll(self: Pin<&mut Self>, cx: &mut Context) -> Poll<Self::Output> {
            cx.context::<dyn FnMut(Pin<&mut Sleep>) -> Poll<()>>().expect("no sleeping implementation")(self)
        }
    }
}
pub async fn sleep(dur: Duration) {
    hook::Sleep { dur, marker: PhantomPinned }.await
}

It would now be the caller's choice how to manage sleeping futures (allowing them to choose between designs like async-io, tokio, glommio, and easily mock the entire io stack).
There's no room in this PR for a sudden addition to Context, but I bring it up because the current 'static bound would heavily restrict these executor APIs. A typical backend for sleep would be expected to queue the running Future up to run again after Duration, and would need mutable access to some form of task list. Without a lifetime, it will have to use something like Arc<Mutex<Tasks>> instead of simply borrowing from its scope. This would be especially difficult in embedded async.
All this is mostly out of the RFC's scope, and I only mentioned it out of curiosity. Sorry for the confusion 😜

There's no room in this PR for a sudden addition to Context, but I bring it up because the current 'static bound would heavily restrict these executor APIs. A typical backend for sleep would be expected to queue the running Future up to run again after Duration, and would need mutable access to some form of task list. Without a lifetime, it will have to use something like Arc<Mutex<Tasks>> instead of simply borrowing from its scope. This would be especially difficult in embedded async.

I see. I'm still a little confused on the reasoning for a 'static bound on being too restrictive. For request that only applies to the type being accessed, but it should still be possible to get a &mut T so long as T: 'static. I'm under the impression that this is unavoidable because you cannot downcast to types with lifetimes in them. I guess, could you go into more detail on a specific example that won't work with the Request proposed and show how your alternative fixes it?

As far as I'm aware, the 'static restriction only applies to TypeId and Any as a consequence of them only using runtime checks. Context has its own lifetime that can be used to ensure types live long enough at compile time.
To demonstrate why arbitrary lifetimes would be useful, here's an example. I've excluded a lot of the code that would be involved in a real-world implementation, but I hope this gets the idea across. Playground link
This shows how an executor might build up a record of the events it needs to wait for (in this case, minimum_sleep). To do this, it needs to be able to modify its local state - that is, it needs a &'a mut _. It's certainly possible to use Arcs and locks to achieve this at runtime, but that would come with a performance penalty and platform restrictions.
As for "fixing" this... the trait I mentioned in https://github.com/rust-lang/rfcs/pull/2895#issuecomment-735713486 would allow us to the the TypeId of Self to uniquely identify the type constructor for Out and build types with lifetimes in them. I think it might be possible extend this and avoid needing to add the type annotations like so:
pub trait Identified {
    type Id: 'static;
}
impl<'a, T: ?Sized + 'static> Identified for &'a T {
    type Id = Ref<T>;
}
pub struct Ref<T: ?Sized>(core::marker::PhantomData<*const T>);

I'll try to flesh this out with updated signatures for provide_context and context

I'll try to flesh this out with updated signatures for provide_context and context

hype. Incase it helps, https://github.com/mystor/object-provider/pull/3 is the working copy of the changes in object-provider used for the new API.

@Plecra I talked to @mystor about your suggestion and it turns out she had suggested essentially the same design back in august and I'd shot it down because it seemed overly complicated at the time, I was definitely mistaken.
Hows this version look to you? https://discord.com/channels/414933673545039883/727251312986816523/784602437519933460

@Plecra I talked to @mystor about your suggestion and it turns out she had suggested essentially the same design back in august and I'd shot it down because it seemed overly complicated at the time, I was definitely mistaken.
Hows this version look to you? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a4c9aa1c309fede3ffaf0357ce6dc233

That's pretty much it, yea! When trying to create the example, I hit the small snag that Component is an unsafe trait. The implementor basically has to ensure transmute<OtherTypesWithThisIdType<'a>, Self<'a>>() is valid. It might be possible to use a derive macro for most cases, but there's also the problem of how this system interacts with variance which honestly goes over my head.
Written out like that, though, I'm surprised by how well it works 😁 I also like that it removes the distinction between value and reference types in the API.

That's pretty much it, yea! When trying to create the example, I hit the small snag that Component is an unsafe trait. The implementor basically has to ensure transmute<OtherTypesWithThisIdType<'a>, Self<'a>>() is valid. It might be possible to use a derive macro for most cases, but there's also the problem of how this system interacts with variance which honestly goes over my head.
Written out like that, though, I'm surprised by how well it works grin I also like that it removes the distinction between value and reference types in the API.

yea, nika originally had this version using an unsafe trait and a MBE macro to define the trait and add an assertion for invariance: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c42239eda4c3270c13397ad70ed4f71e. She went over it for a bit and was fairly confident that the unsafe trait and variance restrictions weren't necessary, and yea, the logic behind it goes way over my head too, for now... >:D

I've put together a (super rough) simplified version of the core idea behind the proposal in https://github.com/rust-lang/rfcs/pull/2895#issuecomment-739123333 here: https://github.com/mystor/dyno.
The Request API which roughly maps to the existing object_provider crate is in the provider submodule, and is built on top of the core Tag and Tagged traits.

Hiya! Seems like this RFC has stalled a little - what's blocking progress at the moment?

Just personal life events, had a surgery + vacation + just started a new job last week. I intend to update this RFC this week time permitting and I have the following changes on my todo list for that update before I'm ready to start pushing the libs team for review and approval.

[ ] update downcast code to be based on dyno rather than object-provider
[ ] add an example use case based on traits used in rustc's compiler error reporting and formatting framework

For the second one there's a specific struct/trait I recall @anp linking to me a little while back that I felt was basically serving the same role as generic member access, though I can't recall exactly what it was atm, so the first step will be digging up the forgotten context.

Do the parts regarding error reporting have any interaction with the proposed {:!} error formatting specifier? More generally, how does this RFC fit into the error handling blog post (https://github.com/rust-lang/blog.rust-lang.org/pull/799)? I assume this is one step on the "move Error into core" process?

Do the parts regarding error reporting have any interaction with the proposed {:!} error formatting specifier? More generally, how does this RFC fit into the error handling blog post (rust-lang/blog.rust-lang.org#799)? I assume this is one step on the "move Error into core" process?

Indirectly they could, depending on how we implement it. One idea for the reporting proposal is to have a fmting trait that is associated with {:!} and has a default impl for all types that implement Error, but then can be custom implemented for types that dont (e.g. anyhow::Error / eyre::Report). The default reporting would not exercise generic member access, and would only access the context needed for the common case, error messages, source, and maaaybe backtrace. The custom reporting types on the other hand would be able to hook in all of their application specific logic that looks up any odd context that is relevant to their usecases.

This RFC feels very complex and I am a bit uncomfortable with adding so much API surface to std just for the Error trait.
I wonder if it is possible to offload some of the complexity of this API to crates.io, similar to how proc_macro only exposes a basic interface (just a token stream) while most of the functionality for building proc macros is located in the syn and quote crates which are not part of the standard library and can evolve independently of it.

I wonder if it is possible to offload some of the complexity of this API to crates.io, similar to how proc_macro only exposes a basic interface (just a token stream) while most of the functionality for building proc macros is located in the syn and quote crates which are not part of the standard library and can evolve independently of it.

The new API is a fairly fundamental extension to the Any trait. The bulk of the API is to do with enabling dynamic downcasts including lifetimes.
There are some parts of the API that could be trimmed at the cost of ergonomics, but I think the new API should be thought of similarly to the Pin API. It's being added to enable an std API we want, and will likely be useful in implementing other crates in the ecosystem (more safe pinning/downcasts). We'd include the simpler provide_... methods for the same reason we have the Deref implementations on Pin and the debug_struct APIs (and on and on): It makes it easier for users to do the right thing

WRT "update RFC to be based on dyno design", can someone give a brief summary of the advantages of this new design over the old one?

WRT "update RFC to be based on dyno design", can someone give a brief summary of the advantages of this new design over the old one?

I think this reply summarizes it best but the main difference is dyno uses a proxy type that itself only has a phantom data, and so it is 'static and gets a TypeID and a trait with an associated type that is the actual type being erased, where as the old design required the type being erased to itself be 'static. The new design allows for closures containing mutable references to be requested as shown in this earlier comment, which could be used in an executor to request a callback that then modifies state in the executor on the other side of the trait object.

This RFC feels very complex and I am a bit uncomfortable with adding so much API surface to std just for the Error trait.
I wonder if it is possible to offload some of the complexity of this API to crates.io, similar to how proc_macro only exposes a basic interface (just a token stream) while most of the functionality for building proc macros is located in the syn and quote crates which are not part of the standard library and can evolve independently of it.

@Amanieu fwiw I'm already working on extracting the type tagged downcasting part of this RFC into it's own independent RFC, which should hopefully make both RFCs much easier to review.

This looks fantastic! ❤
What is the likely timeline for this to reach stable?  Given that it hasn't hit nightly yet, I'm guessing this will be gated behind a Rust 2024 edition?

This looks fantastic! ❤
What is the likely timeline for this to reach stable? Given that it hasn't hit nightly yet, I'm guessing this will be gated behind a Rust 2024 edition?

There's no timeline but it won't be gated being any edition. Everything in this RFC should be backwards compatible.

Reminder for myself: Once this lands I would like to update the example in the docs added in https://github.com/rust-lang/rust/pull/95356 to instead use generic member access to grab the ExitCode from the error.

maybe this proposal need updated to reflect that fact?


[Event Request] codeunit 99000854 "Inventory Profile Offsetting" - OnBeforeInsertTempTracking

Can we please get the following event?
local procedure InsertTempTracking(var FromTrkgReservEntry: Record "Reservation Entry"; var ToTrkgReservEntry: Record "Reservation Entry")
var
    NextEntryNo: Integer;
    ShouldInsert: Boolean;
    IsHandled: Boolean;
begin
     //+Event
    OnBeforeInsertTempTracking(FromTrkgReservEntry, ToTrkgReservEntry, IsHandled);
    if IsHandled then
        exit;
     //-Event
    if FromTrkgReservEntry."Quantity (Base)" = 0 then
        exit;
    NextEntryNo := TempTrkgReservEntry."Entry No." + 1;

    ....

end;

[IntegrationEvent(false, false)]
local procedure OnBeforeInsertTempTracking(var FromTrkgReservEntry: Record "Reservation Entry"; var ToTrkgReservEntry: Record "Reservation Entry"; var IsHandled: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


feat(settings): added option to disable menu particle effects

Didn't like the effects when entering no-clip, so I added the option to disable it, using the already existing Convar

Sorry, but not enough people complained for me to add it to the settings page.

Any particular reason why you shouldn't have the option to disable the particle effects. I'm just wondering. There is already a convar made for this purpose I just thought it would be nice to add the option to control this convar.

I want the settings page to be as simple as possible;
I don't want to deal with the config vault, it's a clusterfuck;
As soon as I turn it into a setting, it's done and I can never touch it again for technical reasons;
I like the effect, and it helps prevent admin abuse (turning on god mode during pvp);

Ok, that's understandable. ill just keep using the convar in my own server.cfg, but could you look at the changes in the scripts/menu/client/cl_player_mode.lua file if the convar could remove the particle effects locally as well. Because now the convar will only remove particles for other players, and not for yourself.

This issue has been solved, you just need to update to v4.11


Refine looking up aot function with index

Is it because DefPointer(WASMExportFuncInstance *, export_functions); now are sorted by names instead of function indexes?

Is it because DefPointer(WASMExportFuncInstance *, export_functions); now are sorted by names instead of function indexes?

No, event if the export_functions isn't sorted by names, it doesn't mean that it will be sorted by function index, it's in random order. This PR's optimization is suitable no matter whether export_functions is sorted by names or not.

Totally true. It sticks to the order given by the export section context, which is based on toolchains and seems random now.
So, we now need to sort the list export_functions by name and store them in that order, and then search by both name and function index.

Totally true. It sticks to the order given by the export section context, which is based on toolchains and seems random now.
So, we now need to sort the list export_functions by name and store them in that order, and then search by both name and function index.

Yes, sort export_functions by name, and create another map array whose element is <func_idx, export_ith> and sort the array by func_idx.


Replace select filter with govuk component

This pull request replaces the select_filter with the option-select-component from http://github.com/alphagov/static, bringing full circle some work begun in January to componentise the select_filter to allow it to be used across GOV.UK without replication of code.
This PR:

Deletes all of the code that has now been moved to static (JavaScript, CSS, HTML)
Adds a method to the select_filter model to provide lists of options for the option-select
Adds the call to the partial
Adds a small amount of CSS to correct the margins for the component.

\o/ w00t!
Really glad this change is happening. Also "+24 −498", pretty rad diff stats.

This is ace :+1:
I have one minor bit of feedback and those diff stats are unreal, but I think this is the first bit of work that ports functionality to be powered by a component. Obviously we aren't able to test this with the component being rendered (which is what that test failure is about) but maybe there needs to be a discussion about how we ensure functionality being powered by components doesn't break?

:balloon: :tada:  :balloon: :tada:  :balloon: :tada:  :balloon:
@tommyp Thats a good question, and not one we have a solid answer to yet with components and the contracts static has with clients. Worth more discussion.
Pulling in components/static during tests is possible (not dissimilar to content-schemas), but needs some thought about how that would work in practice, and any performance impact on tests.
In the mean time, the tests could be re-written, so that:

Anything that is asserting a value is present in a filter (eg, an option rendered/selected) should be able to do so from the JSON dump of arguments passed to a component.
Interactions with component UI (like select_filters) could construct/visit URLs directly, rather than being tied to the component.

Where we're using complex components it might be worth adding Smokey tests to give us some full integration testing.

@dsingleton I think the latter option is probably the easiest in the short term, but it may be better to look into rendering the actual component as I'm sure that as we port more functionality to be components this kind of stuff could become more brittle.

@tommyp @dsingleton OK, I've fixed the failing test with an equivalent action.

🎉🎉🎉

:+1: :dancer: :8ball:


unable to analyze local podman image on Linux

On Linux Fedora,
When building an image locally with podman:
$ podman build . -t quay.io/user/myimage:v0.0.1

Then trying to analyze the image:
doa analyze -i quay.io/user/myimage:v0.0.1
1 - Analyze error (critical): unable to analyze quay.io/user/myimage:v0.0.1
 - error Can't resolved umage quay.io/user/myimage:v0.0.1

When debugging, I can see the following error is returned:
// pkg/decompiler/podman/decompiler.go#50

ctx, err := bindings.NewConnectionWithIdentity(context.Background(), uri, identity, false)

failed to read identity "/home/phmartin/.ssh/podman-machine-default": open /home/phmartin/.ssh/podman-machine-default: no such file or directory"

On Linux, as I don't use a podman machine, this file is not expected to exist

It's very likely that the connection to podman is based on remote


Implementing Binary Search in Python

This pull request is for issue number #31

Thanks for your contribution! You should be able to see your code live on the corresponding post in a few minutes. :smile:


Roll Flutter Engine from d44462a42d73 to c28192426797 (3 revisions)

https://github.com/flutter/engine/compare/d44462a42d73...c28192426797
2024-04-05<EMAIL_ADDRESS>Reverts "Roll Dart SDK from 0ac840ba1f0b to 31ddd6924103 (5 revisions) (#51924)" (flutter/engine#51926)
2024-04-05<EMAIL_ADDRESS>Roll Dart SDK from 0ac840ba1f0b to 31ddd6924103 (5 revisions) (flutter/engine#51924)
2024-04-04<EMAIL_ADDRESS>Manual Dart roll to 0ac840ba1 and update frontend server snapshot filename (flutter/engine#51921)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC matanl@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


fix(react-email): Default props override props in Row and Section

Addresses #1726
Issue:

The component props were being destructured into table elements before the default cellPadding, cellSpacing and border attributes, thereby, overriding these attributes if they are passed as props.
Affected Packages: Row, Section

Fix:

Moved the props destructuring to be done after assigning cellPadding, cellSpacing and border.

Moved the role attribute and added changeset. Please take a look.


DRILL-5906: java.lang.NullPointerException while quering Hive ORC tables on MapR cluster

Upgrade drill to 1.2.0-mapr-1707 hive.version.

+1, LGTM.


format on demand vs auto formatting

Thanks for creating this handy plugin, quick question. Can you add the ability to ignore the pasting and instead allow us to "format as JSX" instead.
this would be helpful when i have to switch between projects that use JSX and ones that don't. Right now i could just enable the package on a per project basis but like the idea of just having this as a setting/shortcut
Thanks,
Jeff

Yeah I thought about this, what do you think about a quick toggle in the bottom status bar?
I could implement that pretty easily.

that would be better than having to do it on per project, so yeah. ideally it would be cool to just highlight what you want and then open command palette and just type jsx or something like that. However, I would imagine the LOE would be much more than a simple button, so i say whatever is easiest for you.

What do you think about adding a setting that toggles the "mode" you are in:

automatic mode automatically detects HTML in your clipboard and converts it to HTML
on-demand mode does not do any detection and only converts your clipboard when you execute an action from the command palette

I added the option for on-demand mode in version 0.3.0.
If you think a command that would turn selected HTML to JSX is still needed, please open another issue. I thought about it and currently don't see a use case where the conversion of selected text would be more ergonomic than clipboard conversion.
And thanks for the feedback btw!

agreed, i think this should do the trick. Thanks again and if i have more feedback i'll let you know. Cheers!


should ignore inline code and code blocks

code should be ignored

Support for code blocks has been added in v0.0.7.

Created another issue for the inline code blocks


Enable Travis builds for Python 3.5

Following suggestion of @mp4096, add Python 3.5 to .travis.yml.  Sorry @slivingston, you merged #102 before I could push this there.

Coverage remained the same at 76.004% when pulling 531df8137020107f84e390bdb9c4047504888b3f on roryyorke:rory-python35 into d0528fd1c6a607b480483ed1f344a3c98e8ce686 on python-control:master.

Thanks for adding Python 3.5 as a target. This is also motivated by #105. We should next add
Programming Language :: Python :: 3.5

to setup.py.

re https://github.com/python-control/python-control/pull/109#issuecomment-239573286
In 58a3ff2036aab49b63d07684c60a35d59cb395f3, I add 3.5 to the list of supported Python versions. For reference, the classifiers that are currently recognized on PyPI are https://pypi.python.org/pypi?%3Aaction=list_classifiers


[Bug]: GeoLocator does not work on MacOs

Please check the following before submitting a new issue.

[X] I have searched the existing issues.
[X] I have carefully read the documentation and verified I have added the required platform specific configuration.

Please select affected platform(s)

[ ] Android
[ ] iOS
[ ] Linux
[X] macOS
[ ] Web
[ ] Windows

Steps to reproduce
Make all configurations and after you have permission, call getCurrentPosition(desiredAccuracy: LocationAccuracy.high).
Expected results
Get the position
Actual results
Stuck and show this message error:  LOCATION UPDATE FAILURE:Error reason: (null)Error description: The operation couldn’t be completed. (kCLErrorDomain error 0.).
Android mobile works fine.
Code sample
Code sample
 var   serviceEnabled = await Geolocator.isLocationServiceEnabled();
    if (!serviceEnabled) {
          var  permission = await Geolocator.requestPermission();
           Position _position =   await Geolocator.getCurrentPosition(desiredAccuracy: LocationAccuracy.high);
}

Screenshots or video

Screenshots or video demonstration
[Upload media here]

Version
12.0.0
Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.19.6, on macOS 14.5 23F79 darwin-x64, locale en-BR)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.1)
[✓] IntelliJ IDEA Ultimate Edition (version 2024.1.4)
[✓] Connected device (2 available)
[✓] Network resources

• No issues found!

Looks like a duplicate of (https://github.com/Baseflow/flutter-geolocator/issues/1534)


Improve MBOX Parser

From<EMAIL_ADDRESS>on November 06, 2013 09:35:22
The current MBOX parser fails to parse attachments properly and doesn't handle some recipient formats.
Original issue: http://code.google.com/p/foam-framework/issues/detail?id=49

No longer relevant, I think. @adamvy to close this unless there's reason to still do this.

Obsolete.


Bump sbt to use 1.3.0-RC4

https://www.lightbend.com/blog/sbt-1.3.0-release needs update as well.

@mkurz It should be now.


[W4.5][T11-A4]Eka Buyung Lienadi

May I get a review on this LO?
This was submitted last week but, unfortunately, to an incorrect repo.
Thank you.
P.S. submitted to this repo
https://github.com/se-edu/addressbook-level2/pull/338

@yungyung04 Some comments added. Please close the PR after reading comments.
Seems like you only throw the exception without handling it. If so, this is the incorrect implementation.


Differences in installation results depending on the version of the aws-eks-gpu-node AMI image

I have an eks cluster with Kubernetes version 1.25, and I am testing to upgrade to version 1.28.
When running a GPU node using the aws-eks-gpu-node-1.28 AMI Image, nvidia-driver is not installed properly.
If you use the aws-eks-gpu-node-1.25 AMI Image, the scripts in /etc/eks will be executed normally and the nvidia-driver will be installed.
When you install a node through aws-eks-gpu-node-1.28 AMI Image, it looks like this.
$ nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

$ journalctl -u configure-nvidia.service
~~
 4월 04 11:12:59 localhost systemd[1]: Starting Configure NVIDIA instance types...
 4월 04 11:12:59 localhost configure-nvidia.sh[2177]: + gpu-ami-util has-nvidia-devices
 4월 04 11:13:00 localhost configure-nvidia.sh[2177]: true
 4월 04 11:13:00 localhost configure-nvidia.sh[2177]: + /etc/eks/nvidia-kmod-load.sh
 4월 04 11:13:00 localhost configure-nvidia.sh[2177]: true
 4월 04 11:13:00 localhost configure-nvidia.sh[2177]: curl: (7) Failed to connect to <IP_ADDRESS> port 80 after 0
 4월 04 11:13:00 localhost configure-nvidia.sh[2177]: curl: (7) Failed to connect to <IP_ADDRESS> port 80 after 0
 4월 04 11:13:00 localhost systemd[1]: configure-nvidia.service: main process exited, code=exited, status=1/FAILURE
 4월 04 11:13:00 localhost systemd[1]: Failed to start Configure NVIDIA instance types.
 4월 04 11:13:00 localhost systemd[1]: Unit configure-nvidia.service entered failed state.
 4월 04 11:13:00 localhost systemd[1]: configure-nvidia.service failed.

The service contents of the aws-eks-gpu-node-1.28 AMI Image are as follows.
$ cat /etc/systemd/system/configure-nvidia.service
[Unit]
Description=Configure NVIDIA instance types
Before=docker.service containerd.service nvidia-fabricmanager.service nvidia-persistenced.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/etc/eks/configure-nvidia.sh

[Install]
WantedBy=multi-user.target docker.service containerd.service

The service contents of the aws-eks-gpu-node-1.25 AMI Image are as follows.
[Unit]
Description=Configure NVIDIA instance types
# the script needs to use IMDS, so wait for the network to be up
# to avoid any flakiness due to races
After=network-online.target
Wants=network-online.target
Before=docker.service containerd.service nvidia-fabricmanager.service nvidia-persistenced.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/etc/eks/configure-nvidia.sh

[Install]
WantedBy=multi-user.target docker.service containerd.service

The difference between the two seems to be that the unit does not check whether network-online.target is present.
It seems that the normal nvidia-driver installation fails as the query to <IP_ADDRESS> port 80 fails before the network comes up normally.
I wonder if the deletion was intentional.
Environment:

AWS Region: ap-northeast-2
Instance Type(s): g4dn.xlarge
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion):  eks.11
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): v1.25 and v1.28
AMI Version: aws-eks-gpu-node-1.25 / aws-eks-gpu-node-1.28
Kernel (e.g. uname -a):

Linux ip-172-31-13-206.ap-northeast-2.compute.internal 5.10.210-201.855.amzn2.x86_64 #1 SMP Tue Mar 12 19:03:26 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Release information (run cat /etc/eks/release on a node):

BASE_AMI_ID="ami-09bffa74b1e396075"
BUILD_TIME="Fri Feb 17 21:58:10 UTC 2023"
BUILD_KERNEL="5.10.165-143.735.amzn2.x86_64"
ARCH="x86_64"

This is fixed in the latest release 👍


Fix Boost 1.72 header name deprecation

This PR was implemented by @ulidtko . It addresses compile warnings in test code:
/usr/include/boost/test/auto_unit_test.hpp:17:1: note: ‘#pragma message: This header is deprecated. Use This header is deprecated. Please use <boost/test/unit_test.hpp> instead. instead.’
   17 | BOOST_HEADER_DEPRECATED( "This header is deprecated. Please use <boost/test/unit_test.hpp> instead." )
      | ^~~~~~~~~~~~~~~~~~~~~~~

I've split the commit into a separate PR to simplify the larger #2151

[ ] Did you create an Apache Jira ticket?  (not required for trivial changes)
[ ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

Hey Mario, thanks for splitting this off, I'd dropped the commit there. There's also #2158.

#2158 and #2164 (this PR) are the exact same patch proposed by different people. One should be merged, and the other just closed. @stale keep both alive.

I've rebased this on latest master. It should go through the CI without problems, keeping fingers crossed!

Checked, the build errors in Travis are all unrelated. Ready for review and merge...

This can be closed, since #2158 has been merged.

Closing as fixed in master.


How to use the 1.8.0 Kotlin version❓

Question
How to use the 1.8.0 Kotlin version ?
Today, when we try to use this version we have this following error :
> Task :react-native-vision-camera:compileDebugKotlin FAILED
e: The Android extensions ('kotlin-android-extensions') compiler plugin is no longer supported. Please use kotlin parcelize and view binding.

Most of librairies with RN > 71 support uses 1.8.0 version of Kotlin so I can't use the 1.6.20 for example :/
What I tried
No response
VisionCamera Version
2.15.4
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar questions in the issues page as well as in the discussions page and found none.

I have the same issue! @adscud how did you manage to fix this issue?

@christophemenager
Hello,
In the android/build.gradle
buildFeatures {
    viewBinding = true
    if (REACT_NATIVE_VERSION >= 71) {
      prefab true
    }
  }

what if im using expo?

what if im using expo?

You can use patch-package to patch the build.gradle file in node_modules/react-native-vision-camera/android/src folder as @adscud described.

I'm also experiencing this problem. Have tried the above steps, but I feel I'm going round in circles now! Here's the initial error I get:
> Task :react-native-vision-camera:compileDebugKotlin FAILED
I had already deleted the "apply plugin" lines in build.gradle, suggested above and tried to add the buildFeatures object, but then I get the following error:
Could not find method buildFeatures() for arguments [build_5euaw2kj96akw3m9uzpd5dunz$_run_closure1$_closure5@19b82ba4] on object of type org.gradle.api.internal.initialization.DefaultScriptHandler.
And if I delete that, I get this error:
Execution failed for task ':react-native-vision-camera:compileDebugKotlin'.
> A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
I'm using Kotlin 1.8.0 (in gradle.properties.). I did try rolling back to 1.6.20, but then I get this error:
The Kotlin Gradle plugin was loaded multiple times in different subprojects, which is not supported and may break the build. This might happen in subprojects that apply the Kotlin plugins with the Gradle 'plugins { ... }' DSL if they specify explicit versions, even if the versions are equal. Please add the Kotlin plugin to the common parent project or the root project, then remove the versions in the subprojects. If the parent project does not need the plugin, add 'apply false' to the plugin line. The Kotlin plugin was loaded in the following projects: ':react-native-gesture-handler', ':react-native-safe-area-context', ':react-native-screens', ':react-native-vision-camera'

@pauldcollins I have the same problem as you, did you manage to solve it?

Hi @Henriquehlr sadly no I have not solved it. I parked the Android build for now. Would love to find a solution!


Auto-generate "mixin GodotNativeLibrary!"

Original godot-d seemed to do it automatically, maybe do same?
Also why it's a template

It isn't, there is a tool for generating that mixin by invoking dub run :pregenerate.
I haven't updated it for godot4 though.


all: Enable auto-merge for dependabot

Description of the feature request
Problem statement
Today dependabot PRs require manual approval, which consists of checking if the PR builds succeeded and then merging the changes.
Summary of the feature
By enabling auto-merge for a dependabot pull requests we can reduce the required maintenance time, and focus our time on more creative tasks.
To auto-merge your pull requests, we can use GitHub's auto-merge functionality. This enables the pull request to be merged when all required tests and approvals are successfully met.
The auto-merge functionality lets us configure under which conditions we want to enable auto-merge. This lets us start with a list of trusted dependencies (e.g. aws-sdk) and a certain version type (e.g. patch). The example below limits auto-merge to patches of aws-sdk.
      - name: Enable auto-merge for Dependabot PRs
        if: ${{contains(steps.metadata.outputs.dependency-names, 'aws-sdk') && steps.metadata.outputs.update-type == 'version-update:semver-patch'}}
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}

Auto-merge requires permissions to write to PRs, as shown below:
permissions:
  pull-requests: write
  contents: write

Code examples
Below is an example that I copied from the Github docs and switched the trusted library to aws-sdk. I did not dive deep into the step Dependabot metadata yet.
name: Dependabot auto-merge
on: pull_request_target

permissions:
  pull-requests: write
  contents: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses<EMAIL_ADDRESS>        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: ${{contains(steps.metadata.outputs.dependency-names, 'aws-sdk') && steps.metadata.outputs.update-type == 'version-update:semver-patch'}}
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

Benefits for you and the wider AWS community
Maintainers spend less time on chores, and have more time to engage with the community.
Describe alternatives you've considered
I have not yet investigated alternatives, as this seems to be the recommended approach for Github.
With this issue I am not suggesting that we should enable the auto-merge feature through the GitHub UI.
Additional context
None yet.
Related issues, RFCs
None yet.

Given that we have disabled Dependabot updates in #992 is not relevant anymore. Closing it.


Placeholder text does not appear for search bar when expanded

This repository's issues are reserved for feature requests and bug reports.
Do you want to request a feature or report a bug?
bug
Feature Request
please first make sure your request falls under the official Material Design spec guidelines https://material.google.com/
Bug Report
please provide steps to reproduce and if possible screenhots or animated Gifs.
you can easily create animated Gif with this free PC/OSX App: http://www.cockos.com/licecap/
Screenshots or link to CodePen/Plunker/JSfiddle

What is the expected behavior?
I'd think the placeholder text should appear when the search is expanded so that they know what the field is for. I ended up adding a block of text to the side for the time being until I play with it more.
What is the motivation / use case for changing the behavior?
^
Which version of Angular and Material, and which browser and OS does this issue affect?
I'm on the latest build (with 2.4.1) and using chrome
Did this work in previous versions of Angular / Material?
Please also test with the latest stable and snapshot versions.
Haven't checked the others
Other information
(e.g. detailed explanation, stacktraces, related issues, suggestions how to fix)

The problem is we autofocus when you click on the icon and we hide the placeholder when focused.. we might need to add an attribute to make that optional though.
Can you please create this issue or at least link it in https://github.com/Teradata/covalent/issues?

Yeah I deduced that after playing with it for a minute. I just edited it to not focus, but an option would be great to have.

Yeah I deduced that after playing with it for a minute. I just edited it to not focus, but an option would be great to have.

Sure, we can continue our talk in the covalent issues
Ill close this issue in favor of https://github.com/Teradata/covalent/issues/226


SubForm documentation

@HauklandJ Is this duplicated by https://github.com/Altinn/altinn-studio-docs/issues/1752?


GraphQL-Interfaces error with SPQR-Annotations

I have got Java types with SPQR-Annotations the following manner:
@GraphQLInterface(name = "IAnimal", implementationAutoDiscovery=true)
public interface IAnimal {
	@GraphQLQuery(name = "name")
	public String getName();
}

@GraphQLType(name = "IBat")
@GraphQLTypeResolver(DummyTypeResolver.class)
public interface IBat extends IAnimal {
	@GraphQLQuery(name = "wingSpan")
	public int getWingSpan();
}

@GraphQLType(name = "ICat")
@GraphQLTypeResolver(DummyTypeResolver.class)
public interface ICat extends IAnimal {
	@GraphQLQuery(name = "smart")
	public boolean isSmart();
}

@GraphQLType(name = "ICow")
@GraphQLTypeResolver(DummyTypeResolver.class)
public interface ICow extends IAnimal {
	@GraphQLQuery(name = "leiteira")
	public boolean isLeiteira();
}

@GraphQLType(name = "Dog")
@GraphQLTypeResolver(DummyTypeResolver.class)
public class DogImpl implements IAnimal{

	@Override
	@GraphQLQuery(name = "name")
	public String getName() {
		return "dog";
	}

	@GraphQLQuery(name = "color")
	public String getColor() {
		return "black";
	}

}

@Service
public class ServiceAnimal {
	@GraphQLQuery(name = "zoo")
	public List<IAnimal> getAnimals() {
		List<IAnimal> retval = new ArrayList<>();
		retval.add(new BatImpl());
		retval.add(new CatImpl());
		retval.add(new CowImpl());
		return retval;
	}

	@GraphQLQuery(name = "zoocomplet")
	public List<IAnimal> getAnimalsCompleto() {
		List<IAnimal> retval = new ArrayList<>();
		retval.add(new BatImpl());
		retval.add(new CatImpl());
		retval.add(new CowImpl());
		retval.add(new DogImpl());
		return retval;
	}

	@GraphQLQuery(name = "cat")
	public ICat getCat() {
		return new CatImpl();
	}

	@GraphQLQuery(name = "bat")
	public IBat getBat() {
		return new BatImpl();
	}

	@GraphQLQuery(name = "cow")
	public ICow getCow() {
		return new CowImpl();
	}

	@GraphQLQuery(name = "dog")
	public IAnimal getDog() {
		return new DogImpl();
	}
}

When executing the query in spqr 0.9.6 the error occurs:
{"query":"{__type(name:\"IAnimal\"){name, possibleTypes { name } }}"}
{data={__type={name=IAnimal, possibleTypes=[{name=IBat}, {name=ICat}, {name=ICow}]}}}
---------------------
{"query":"{zoo{name, ... on ICat { smart }, ... on IBat {wingSpan}, ... on ICow {leiteira}}}"}
{data={zoo=[{name=bat, wingSpan=18}, {name=cat, smart=false}, {name=cow, leiteira=true}]}}
---------------------
{"query":"{zoocomplet{name, ... on ICat { smart }, ... on IBat {wingSpan}, ... on ICow {leiteira}, ... on Dog{color}}}"}
{errors=[{message=Validation error of type UnknownType: Unknown type Dog, locations=[]}]}

The Dog type does not appear in the list of possible types.
The query that does not return the Dog type works correctly, but the query that has the Dog object occurs the unknown type error.
In the spqr 0.9.9:
{"query":"{__type(name:\"IAnimal\"){name, possibleTypes { name } }}"}
{data={__type={name=IAnimal, possibleTypes=[{name=Dog}, {name=ICow}, {name=IBat}, {name=ICat}]}}}
---------------------
{"query":"{zoo{name, ... on ICat { smart }, ... on IBat {wingSpan}, ... on ICow {leiteira}}}"}
{data={zoo=[null, null, null]}, errors=[{message=Can't resolve '/zoo[0]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoo'. Runtime Object type 'BatImpl' is not a possible type for 'IAnimal'., path=[zoo, 0]}, {message=Can't resolve '/zoo[1]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoo'. Runtime Object type 'CatImpl' is not a possible type for 'IAnimal'., path=[zoo, 1]}, {message=Can't resolve '/zoo[2]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoo'. Runtime Object type 'CowImpl' is not a possible type for 'IAnimal'., path=[zoo, 2]}]}
---------------------
{"query":"{zoocompleto{name, ... on ICat { smart }, ... on IBat {wingSpan}, ... on ICow {leiteira}, ... on Dog {cor}}}"}
{data={zoocompleto=[null, null, null, {name=dog, cor=black}]}, errors=[{message=Can't resolve '/zoocompleto[0]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoocompleto'. Runtime Object type 'BatImpl' is not a possible type for 'IAnimal'., path=[zoocompleto, 0]}, {message=Can't resolve '/zoocompleto[1]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoocompleto'. Runtime Object type 'CatImpl' is not a possible type for 'IAnimal'., path=[zoocompleto, 1]}, {message=Can't resolve '/zoocompleto[2]'. Abstract type 'IAnimal' must resolve to an Object type at runtime for field 'null.zoocompleto'. Runtime Object type 'CowImpl' is not a possible type for 'IAnimal'., path=[zoocompleto, 2]}]}

Here the Dog type does appear in the list of possible types.
But the ICat, IBat, and ICow types are returned as null and the Dog type is returned the data correctly.
So there is a different behavior in spqr versions.
Any idea what might be happening?

What does your schema generator look like?
I currently have the follow and it seems to work for me (though our code base is different). Hope this helps.
final GraphQLSchema schema = new GraphQLSchemaGenerator()
                .withInterfaceMappingStrategy(new InterfaceMappingStrategy() {
                    @Override
                    public boolean supports(final AnnotatedType interfase) {
                        return interfase.isAnnotationPresent(GraphQLInterface.class);
                    }

                    @Override
                    public Collection<AnnotatedType> getInterfaces(final AnnotatedType type) {
                        @SuppressWarnings("rawtypes")
                        Class clazz = ClassUtils.getRawType(type.getType());
                        final Set<AnnotatedType> interfaces = new HashSet<>();
                        do {
                            final AnnotatedType currentType = GenericTypeReflector.getExactSuperType(type, clazz);
                            if (supports(currentType)) {
                                interfaces.add(currentType);
                            }
                            Arrays.stream(clazz.getInterfaces())
                                    .map(inter -> GenericTypeReflector.getExactSuperType(type, inter))
                                    .filter(this::supports).forEach(interfaces::add);
                        } while ((clazz = clazz.getSuperclass()) != Object.class && clazz != null);
                        return interfaces;
                    }
                }).withOperationsFromSingletons(service)// register the service
                .generate(); // done ;)

        graphQL = new GraphQL.Builder(schema).build();

You have a rather complicated and confusing setup here, as you sometimes use classes and sometimes interfaces as concrete implementations. Still, there's nothing strictly wrong with it, it's just difficult to untangle the expected behavior.
Now, where it gets strange is implementationAutoDiscovery. What it does, when enabled, is scan the classpath for concrete implementations, and registers them with the schema. Additionally, all the discovered implementation are tracked for automatic type resolution. This in your case means CatImpl, DogImpl, BatImpl and CowImpl are discovered and added.  Now, because you also have queries that directly expose ICat, ICow and IBat, those get added to the schema and tracked as implementations as well.
What this means is that both e.g. ICat (mapped as Cat GraphQL type) and CatImpl (mapped as CatImpl GraphQL type) get registered as possible implementations of IAnimal and the default TypeResolver (DelegatingTypeResolver) will check the returned instance as try to uniquely match it to a known subtype. So when you return a CatImpl, 2 GraphQL types match, so it looks for a custom TypeResolver to decide. It looks on the current type (CatImpl) and the interface type (IAnimal), but in your case, it doesn't find it anywhere, because the annotation is on ICat. So it checks if there's a type directly matching the instance type (CatImpl) and it finds a match, so it returns the CatImpl GraphQL type as the result. Now, there's a limitation/bug in SPQR that only the directly implemented interfaces get mapped. So for CatImpl, only ICat is analyzed, it doesn't match (because it's mapped as an object type), so no GraphQL interfaces get mapped. As a result, you get an explosion - because CatImpl is the detected implementation, but in the schema CatImpl doesn't implement IAnimal.
As you see, this is super-convoluted... your best option is to simply disable implementationAutoDiscovery as you don't actually need to track Impl classes, as you already directly expose the implementations. You might also want to move @GraphQLTypeResolver(DummyTypeResolver.class) to IAnimal...
I'm also investigating fixing the _only direct interfaces issue.

@Kirintale The current default InterfaceMappingStrategy seems identical to what you're doing there, so you might be able to remove the customization.

Ah cool. I'll try to remove it and see what happens.

@pmbdias I've pushed a commit fixing the bug I explained above (where only direct interfaces would be taken into account). Now all interfaces should be mapped as expected.
@Kirintale As a result of addressing the bug discussed here, the default InterfaceMappingStrategy has changed a bit, to also go into all transitive interfaces, so the logic now differs slightly from yours.

@kaqqao Thank you for your interest in helping me.
I have managed to solve the interface problem when the object is in the same project as the schema generator. However, I am trying to apply graphql to an old project, it is a monolithic system that is being broken into smaller ear's and so I am having more difficulties.
I have a graphql project that generates the schema and I will call it main. However I have interfaces annotated with graphl in another jar that is declared as maven dependency of the main graphlql project. These interfaces declared in this other jar are not being mapped in the schema. For the interfaces declared in the main graphql project the mapping is correct and working.
Is there a way to map in the graphql schema the interfaces (@GraphQLInterface) that are declared in another jar?

@kaqqao  I posted on github a project for you to better understand the problem I described in the post above. https://github.com/pmbdias/graphql
When objects are in the same project that generates the schema, attributes that are of type interface are recognized. However, when objects come as a dependency on another project, the interfaces are not mapped, the other concrete types are.
Run the org.mountcloud.graphql.GraphqlClientMain from the graphql-client-master project to view both the working and non-working cases.
Do you have any idea what might be happening?

This is almost certainly a classloading issue. Do you have 2 SPQR jars on your classpath? E.g. once in your EAR and once in your WAR? I've seen this happen before. The annotation would be loaded twice, by different classloaders, so they wouldn't be equal to each other when compared.

I can neither figure out how to start the web application that the org.mountcloud.graphql.GraphqlClientMain expects to exist nor what the expected output should be.
But, since I'm 99% sure this is a classloading issue, try removing this dependency. The web project already depends on the EJB project which depends on SPQR. If you double-declare your dependencies, you run exactly into this type of problem as different classloaders are used to load the annotations and the service classes.

The reported problem was not the existence of 2 SPQR jars on my classpath. But it was classloading problem.
I was packing SPQR jar in war, so when I moved it to lib from ear it solved the problem.
Thank you very much.
You have any indication of java client for consumption of queries and graphql mutations?
I am looking for a client so that other applications can consume my graphql application.
I found the link (https://github.com/MountCloud/graphql-client ) but realized missing treatment when you want to pass parameter like GraphQLInputObjectType. Example: input: {email<EMAIL_ADDRESS>firstName: "David"}
Do you have any sugestion?

In EAR packages, multiple classloaders are used to load different deployment units. And if the packaging isn't done exactly right, you can end up in your situation where a class (the @GraphQLInterface annotation in your case) apparently does match itself.
As for the client, I'm not aware of anything particularly good. Apollo Android is maybe the easiest to use. There's also AmericanExpress' Nodes GraphQL client but I've personally never a use-case matching theirs.
Shopify has a very cool Java client generator but it needs Ruby for generating the code. Satisfying this via JRuby JAR could be an interesting approach.
Someone also made a simple SPQR-aware client but I can't seem to find it right now...

@kaqqao I have one more difficulty now regarding mutation. I don't know passing complex parameter which has interface type attribute. How to define in mutation what is the implementation of the interface I want to pass.
Example:
{"query":"mutation{addPerson(person:{name:\"John\",identification:{identification:\"02674859902\"}}){name}}"}
I have the Person object that has two attributes:  name and identification. But the identification attribute is type IdentificationIf which has two implementations IdentificationCPF and IdentificationCNPJ.
In the query I can get the right result using spred:
{"query":"query{person{name, identification{... on IdentificationCPF{identification}}}}"}
I need to call a mutation passing the Person object but I don't know how to enter the identification due to the type being an Interface.
Can you help me?

Try generator.withAbstractInputTypeResolution(). That will automatically add a discriminator field and configure Jackson to use it during deserialization.

E.g. given the interface IdentificacaoIf, if two implementation types are discovered IdentificacaoCPF and IdentificacaoCNPJ
What is the mutation syntax to indicate which concrete object will be passed?
When I mutate this way:
"mutation{addPerson(person:{name:\"John\",identification:{identification:\"02674859902\"}}){name}}"
This error occurs:
"Validation error of type WrongType: argument 'person.identification' with value 'ObjectValue{objectFields=[ObjectField{name='name', value=StringValue{value='John'}}, ObjectField{name='identification', value=ObjectValue{objectFields=[ObjectField{name='identification', value=StringValue{value='02674859902'}}, ObjectField{name='statusIdentCPF', value=NullValue{}}]}}]}' contains a field not in 'IdentificationIfInput': 'identification' @ 'addPerson'"
I understand that this way there is no way for graphql to know which object it needs to instantiate. But I don't know how to indicate the concrete object in the mutation.
Could you show an example of how to make the mutation call?

@pmbdias
@kaqqao
I have exactly the same problem here and have no idea how to solve it.
@Data
@GraphQLInterface(name = "AssetChild", implementationAutoDiscovery = true)
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "_type_")
@JsonSubTypes( {
        @JsonSubTypes.Type(value = BuildingChild.class, name = "BuildingChild")
    }
)
public abstract class AssetChild {
  String s1;
}

@Data
@Dependent
@EqualsAndHashCode(callSuper = true)
public class BuildingChild extends AssetChild {
  String s2;
}

@GraphQLMutation
public AssetChild save(AssetChild input) {
  return input;
}

mutation {
  save(input: {
    _type_:BuildingChild
    s1: "s1-val"
  }) {
   s1
    __typename
  }
}

This works. But its typ is BuildingChild and I want to set s2 too which is not possible.
Use SPQR 0.10.1 and Quarkus here.
Thanks in advance.


MH-13498 Improve icons and wording in video editor

This patch improves the usability of the video editor by:

removing unnecessary buttons
improving the wording in some places
removing confusing button icons
replacing some icons with more suitable ones
adding some button tooltips
dynamically changing tooltips of show/hide buttons of segments

Before:

After:

This work is sponsored by SWITCH.

@KatrinIhler thanks for the review.
We decided to keep the "hide/show" button as well as the "split" button in order to not have too controversial changes in this PR. However, we basically agree that these buttons could be removed. Maybe someone can create a separate PR for this.
I think all your findings should be fixed/answered.

Just one thing:
The last segment in the timeline is not deletable, so no x is shown, however, the eye for hiding is shown even when no hiding is possible, it just doesn't do anything. We should choose one behavior here. Same goes for the list of segment: x is greyed out, the eye isn't, both don't do anything if it's the last unhidden segment. (Whether that's correct is another question, I think the UI should be consistent here even if we're going to change that behaviour later.)

@staubesv Do you have a preference here? Greying out the eye-icon is quite hard to implement as far as I remember. Should we just undo the visibility changes regarding the x-icon of the last segment?

@krinnewitz I suggest to raise another PR based on this one that resolves https://opencast.jira.com/browse/MH-13576 as there is not much point in trying to fix something that we will change just once this PR has passed anyway. @KatrinIhler Agree?

Whoops, approved a bit prematurely, there still is that one change missing. But sounds like a good plan, I will merge once it's done!

@KatrinIhler done.

@KatrinIhler I think the ball is on your side, isn't it?


gui(installer): use fixed keys ordering

This is to fix #1439. It follows the same approach as used in the settings to ensure consistent ordering when iterating over keys.

I think it would be cleaner to change the keys alias map for a BTreeMap for which iterators always respect an order.


add poli MT MOO

Hi Richard, I've add the changes we discussed. Let me know if it works and feel free to edit away.
It would be amazing if we could add a simple test of sorts. You could add it to the test_pr.py file (since that's the one that runs on the pr env. This should be low in your priority list, though.


[Feature Request]:  changing text colour green of navbar items on hover

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
changing text colour to green

Use Case
makes it beautiful
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

would look good, have assigned the issue @dhairyagothi