New recursive comparison api

Summary
The current way comparing objects recursively is starting to pollute the api, the methods introduced for the recursive comparison don't apply for the other assertion cluttering the assertj api, ex usingComparatorForType.
I would like to introduce a separate API to use recursive comparison allowing to fine tune the comparison behavior.
API rough draft (please criticize it !)
import static RecursiveComparisonSpecification;

// ignoringNullFields() comes from RecursiveComparisonSpecification
assertThat(person).usingRecursiveComparison(ignoringNullFields()
                                           .ignoringFields("name", "age")
                                           .forcingRecursiveComparisonFor(Child.class, Sister.class))
                  .isEqualTo(expectedPersont)

Another option would be to let usingRecursiveComparison return a special Assert class (e.g. RecursiveComparisonAssert), so you could write
assertThat(person).usingRecursiveComparison()
     .ignoringNullFields()
     .ignoringFields("name", "age")
     .forcingRecursiveComparisonFor(Child.class, Sister.class)
     .isEqualTo(expectedPersont);

I do like the design! But there is something that, I believe, is misleading (actually it is already the case with current version of AssertJ): usingRecursiveComparison expression does not say anything about the fact that the recursive comparator will not be used on attributes having a type overidding equals. Of course, it becomes clear if we introduce a forcingRecursiveComparisonFor method, but all users won't see it at first glance.
So, it would be nice to have a way to clarify that for users, either by changing usingRecursiveComparison to something else, either by forcing users to call a specific method in order to get a RecursiveComparisonSpecification instance. Going a step forward: maybe that specific method could be used to specify if the recursive comparison should be forced on any type ?
Here is my proposal:
import static RecursiveComparisonSpecificationFactory;

// forcingRecursiveComparisonForAll() comes from RecursiveComparisonSpecificationFactory
assertThat(person).usingRecursiveComparison(forcingRecursiveComparisonForAll()
                                           .ignoringFields("name", "age"))
                  .isEqualTo(expectedPerson)

// forcingRecursiveComparisonFor() comes from RecursiveComparisonSpecificationFactory
assertThat(person).usingRecursiveComparison(forcingRecursiveComparisonFor(Child.class, Sister.class)
                                           .ignoringFields("name", "age"))
                  .isEqualTo(expectedPerson)

You can only get a RecursiveComparisonSpecification instance by calling one of two methods on RecursiveComparisonSpecificationFactory:

forcingRecursiveComparisonFor
forcingRecursiveComparisonForAll

This way it will be clear for users how the comparison will actually be performed. What do you think ?

@joel-costigliola usingComparatorForType and usingComparatorForFields are also used by the non-recursive field/property by field/property comparison methods (isEqualToComparingFieldByField, isEqualToIgnoringNullFields, isEqualToComparingOnlyGivenFields and isEqualToIgnoringGivenFields). In order to remove them from ObjectAssert we would have to add a similar API for non-recursive comparison.

@joel-costigliola I think you are right. Recursive comparison is one of the best feature of AssertJ and having a dedicated api make sense.
It would be nice to be able to explain the way recursive comparison should work for some attributes (for a given depth).
Maybe give a list of rules for each of those specials attributes could be a way to do so ?

thank you all for your feedback, the api and its behaviour are still opened to discussion and changes.
I wonder if the field by field comparison should be the default even for classes having overriding equals, I'd like to have your opinion on this one guys. In that case we could add a useOverriddenEquals to change that maybe with whitelist/blacklist (if that's not much).
I like @PascalSchumacher suggestion, it will make the API easier to discover, we will go that way except if we encounter technical limitations.
@pierrefevrier can you elaborate ? do you refer to add information in the error message explaining how the comparison was performed and (obviously) what went wrong ? (yes we will do this).

I think the custom equals of classes should be used by default, because otherwise it is a pain to compare two objects e.g. containing a collection object.

Hey,
what do you think about the possibility to decide whether field-by-field comparison or comparison using equals()  for certain types or attributes should be used?
For types one could specify the classes similar to @PascalSchumacher's example:
assertThat(person).usingRecursiveComparison()
     .ignoringNullFields()
     .ignoringFields("name", "age")
     .forcingRecursiveFieldByFieldComparisonFor(Child.class, Sister.class)
     .forcingRecursiveEqualityComparisonFor(Mother.class, Father.class)
     .isEqualTo(expectedPersont);

For attributes the information in which type the attribute is located might be useful.
What about something like of() or memberOf():
assertThat(person).usingRecursiveComparison()
     .ignoringNullFields()
     .ignoringFields("name", "age")
//  of() and in() are aliases for memberOf()
     .forcingRecursiveFieldByFieldComparisonForField("sister").of(Person.class)
     .forcingRecursiveEqualityComparisonForField("child").memberOf(Father.class)
     .forcingRecursiveEqualityComparisonForField("mother").in(Child.class)
     .isEqualTo(expectedPersont);

This would result in the equality-comparison being used for the child attribute of class Father, but not for class Mother.
I think sth. in this direction could work out, but I surely haven't thought through it completely.
What's your opinion? Do you see pitfalls?

As explained in #1054 :
when using isEqualToComparingFieldByFieldRecursively or isEqualToComparingFieldByField, the comparison is not done on class type, only on field value (and name).
So two POJO with the same fields, but from different classes are considered as equals.
It could be useful to test the object instance (recursively, or not)
Example
@Test
 public void test() {
     A a = new A(10);
     B b = new B(10);
     assertThat(a).isEqualToComparingFieldByFieldRecursively(b);
// I would like this line to fail because A and B are different classes
// but it is not failing
 }

 private static class A {
     int x;

     public A(int x) {
         this.x = x;
     }
 }

 private static class B {
     int x;

     public B(int x) {
         this.x = x;
     }

 }

Same too when the object contains some other object :
  private static class Something {
        InnerObject inner;  // can be A or B

        public Something(InnerObject inner) {
            this.inner = inner;
        }
    }

Something someObjectContainingA = new Something(new A(10));
Something someObjectContainingB = new Something(new B(10));
assertThat(someObjectContainingA).isEqualToComparingFieldByFieldRecursively(someObjectContainingB);

the 2 object have the same class, but they are composed of different object, and it could be interesting to check this field type.

Thanks for the great library.
I think I can also add an edge case: Shadowing variables.
public class ShadowedValuesAreComparedFlat {

  public class Super {
    private int x;

    public Super(int x) {
      this.x = x;
    }
  }

  public class Sub extends Super {
    private int x;

    public Sub(int superValue, int subValue) {
      super(superValue);
      this.x = subValue;
    }
  }

  @Test
  public void shadowed_values_are_not_considered() {
    Super instanceSuper = new Super(10);
    Sub instanceSub = new Sub(20, 10);
    // Passes the test: Should it fail instead?
    assertThat(instanceSub).isEqualToComparingFieldByFieldRecursively(instanceSuper);
  }
}

here Sub contains two values of x on two different levels.
I think the current implementation takes the first one it finds on each and compares them. So it ends up comparing super.x with sub.x, which are both 10.
I am not quite sure what the expectation would be. It depends if one wants to compare super with subclasses at all and if yes, what should be the policy to do it.
Status Quo in assertj-core 3.8.0 for the above is: the test passes.
As this ticket is about redesigning the recursive comparison, I think this would be the right place to make you aware and possible discuss, what should be the output.

That's really an edge case ! Thanks for reporting it.
The philosophy of the recursive is to provide a data comparison of actual and expected but should it look at the data values only or also at the data graph structure (i.e. where do the data values come from) ?
In the "the data values only" case, the assertion should pass because if you ask the subclass instance for its x value it will always return its own and not super.x so from this point of view super.xis like it does not exist.
If we want to consider the data structure  then the assertion should fail because Sub has two fields whereas Super only one. We could also go further and only compare instances of the same class only.
I'm not overly opinionated on this but I think that we should go data values only and make sure we get the values from the subclasses field first (which we do), I also think that edge case comes from a bad coding practice (why anyone would shadow a parent field ?) and thus I don't think we should cater for it (I'm happy to change my mind if you can show me a relevant use case for shadowing fields).

I agree that this is both an edge case and likely bad practice.
My intention was to make you aware of it, to make an aware decision for the new API. Depending on the definition of equals in  a class doing this, it could or could not be consistent with what isEqualToComparingFieldByFieldRecursively is doing.

We could also go further and only compare instances of the same class only.

 However in a previous issue I saw you opting for not walking that path, though I am not sure if this holds true for the new API as well?
In the case where subclassing is allowed, one needs a policy for dealing with this.

Differentiate between equal named variables steeming from different classes
Regard only the outer appearance of the objects
Make it configurable with the downside of complicating the API

I also have no strong opinion about it. Normally I would go for "do not consider different classes as equal" to begin with. That that's a strong opinionated approach which is maybe not suitable for a library which wants to support different developer.
My gut feeling is that I would not support this and shy away from the effort of making a path dependent aware equality check and would just support the "no subclassing at all" and "subclassing without shadowing" cases.
However I think it might be worth documenting that this case is not supported.

I'm not keen of verifying instances are of the same class since it is something that users can do easily if they want to before performing the recursive comparison.
As you suggested, the behavior should be clearly documented.

Note: to keep the API simple once a comparator for a given type is registered it should be used at any level, collection element or collection element field. At the moment we can register comparators that are only applied at the collection element field level and others that are applied at both element and element's field levels - too complicated !

Requirement:
Come with good description to clearly state which comparators were used.

isDeepEqualTo() is what I was looking for in AssertJ when I arrived at #1002.
I think I'll stick with DeepEquals from https://github.com/jdereg/java-util
Or the technique I've been using for fifteen years via XStream:
assertEqual(xstream.toXML(expected), xstream.fromXML(actual));

^^ I just updated the test to have Dto versions of all type (HomeDto, AddressDto) and it worked fine (I have pushed that commit though).

I've made a simple demo to reproduce the mentioned error. If you're interested in I can provide it as maven project.
But in the meantime it's getting more cleaner to me:
1: There were a difference I was not aware of.
2. I'd like to have an option to ignore fields / regex in all (nested / associated) objects regardless of the path. This could be very helpfull if the types of one site have some fields in a base class but the types of the other side not.
3. Improvement  of the output. In the debugger I've seen that the "ComparisonDifference" object contains detailed informaion about which fields (of an nested / associated object) differ. But these information are not (fully ?) printed out in a AssertionError (".. it lacks these ....").
Hoe that helps

@merlin-hst a small project would be great or if it is simpler just create a PR on top of this branch.
I'll look into the stack overflow error, thanks again for you feedback.

@merlin-hst I have pushed a fix for the recursive error, the test you gave me fails with the error below.

I'd like to have an option to ignore fields / regex in all (nested / associated) objects regardless of the path.

Isn't that achievable with regexes ?

Improvement of the output. In the debugger I've seen that the "ComparisonDifference" object contains detailed informaion about which fields (of an nested / associated object) differ. But these information are not (fully ?) printed out in an AssertionError (".. it lacks these ....").

I did not understand this one, can you clarify with an example ?
java.lang.AssertionError:
Expecting:
  <AEntity [id=1887776889599131648]>
to be equal to:
  <de.demo.assertj.recursivetest.model.ADocument@731a74c>
when recursively comparing field by field, but found the following 2 differences:

field/property 'content' differ:
- actual value   : de.demo.assertj.recursivetest.model.AContentEntity@3327bd23
- expected value : de.demo.assertj.recursivetest.model.AContentDocument@210366b4
de.demo.assertj.recursivetest.model.AContentEntity can't be compared to de.demo.assertj.recursivetest.model.AContentDocument as AContentDocument does not declare all AContentEntity fields, it lacks these:[id, event]

field/property 'details' differ:
- actual value   : [de.demo.assertj.recursivetest.model.ADetailEntity@31dc339b]
- expected value : [de.demo.assertj.recursivetest.model.ADetailDocument@66480dd7]

The recursive comparison was performed with this configuration:
- the following fields were ignored in the comparison: id, isMarkedForTermination, isTerminated, creationDate, creationUser, updateDate, updateUser
- the fields matching the following regexes were ignored in the comparison: .*creation[\D]+, .*update[\D]+
- overridden equals methods were used in the comparison
- these types were compared with the following comparators:
  - java.lang.Double -> DoubleComparator[precision=1.0E-15]
  - java.lang.Float -> FloatComparator[precision=1.0E-6]
- actual and expected objects and their fields were compared field by field recursively even if they were not of the same type, this allows for example to compare a Person to a PersonDto (call strictTypeChecking(true) to change that behavior).

I'll provide you a working version.
But as I already mentioned in my opinion the error message is a little bit to abstract. It indicates that the fields 'content' and 'details' of AEntity and ADocument differs. But because both fields are complex objects I'd like to know why they differ. When I inspect the ComparisonDifference objects in the debugger I can see that there is a field called 'additionalInformation' with some more information about the difference, for example what exactly is missing (AContentDocument does not declare all AContentEntity fields, it lacks these:[id]]). So for me it looks like that the information of these field should be available too in the AssertError message.
Second using 'ignoringFieldsMatchingRegexes' could be sometimes too much. When I'd like to ignore a field called 'id' regardless of the path I can use '.*id' as pattern. But that would match all fields ending with 'id' which might not what I wanted. So from my point of view an option to ignoring specific fields regarding of the path could be very convenient.

Hi,
I see that there is a case for ignoring order for arrays and it has been already implemented
(Iterable/array support section -  ignores order in comparison (by default elements are compared in order for ordered collection).)
I have one more example)
Let's consider the following Objects
data class AccountServiceFeaturesMetaInfo(     var serviceFeatures: List<ServiceFeatureMetainfo?>?,     ... ) data class ServiceFeatureMetainfo(     var hasParent: Int?,     var flagValue: String?,     var attributes: List<Attribute?>? ... )

I need to ignore one field for recursive comparison for array of ServiceFeatureMetainfo, e.g. hasParent
How to ignore order for attributes array
How to ignore some fields for several arrays, e.g. some field of Attributes object

It would be great to implement something like this:
assertThat(response)                 .usingRecursiveComparison()                 .ignoringFields("serviceFeatures[].hasParent") <<<                  .ignoreOrderFor("serviceFeatures[].attributes[]")

Hello, first of all amazing framework !
I have two questions :
I'd like to know if it is possible, when asking for a strict type checking, to discard it for lambda expressions ?
Also is there a way to provide a custom comparator for some fields matching a regex ? The regex builder for discarding some fields is very useful as I am now dealing with a code that has some cyclical pointing in it, but I would need the same kind of logic for applying a custom comparator to those fields. Is there already a way to do so please ? Currently I have a work around with just discarding them in a first place and then looking for them explicitly but this is hardly extensible.
Thank you very much !

hey thanks for the kind words!

I'd like to know if it is possible, when asking for a strict type checking, to discard it for lambda expressions ?
it's not supported at the moment, can you give us a concrete use case? (with an example if possible)
create a new issue for it, it will be easier to discuss about it.

Also is there a way to provide a custom comparator for some fields matching a regex ?
Not supported, but we can add that, same as my other comment, create a new issue for it and provide a concrete example (will be helpful for testing)

closing this as the recursive comparison has reached a decent state


Impossible to run test with the help of plugin: Cannot resolve path to file

I am using plugin version 0.3.0 (installed from disk) and I expected to get a fix of this issue in the latest version but still it's impossible to start the test using plugin. The error is: "Cannot run program k6 (in directory "/Users/xxx/Projects/performance"): error=2, No such file or directory."
The same command works successfully in console.
I have Webstorm on macOS Ventura. K6 version is v0.42.0.

The same command works successfully in console.
do you mean the exact command as it shown in the IDE run view? Or there might be any difference like full path-relative path or different current working directory?
Also, there might be some issues with different system users and permissions for the k6 launcher file.

Here is the console command: "k6 run app/scenarios/testApplication.js"  - works fine.
Here is setting in run configuration:
absolute: /Users/yanab/Documents/Projects/performance/app/scenarios/testApplication.js - doesn't work
relative: app/scenarios/testApplication.js - doesn't work as well

@ianabogapova
could you check if it works when you set the k6 installation path in the settings:

closing as no response received


dvdauthor: 0.7.1 -> 0.7.2

Description of changes
Patches became obsolete with the "new"/latest release (from Dec. 2016).
dvdauthor optionally depends on imagemagick6, which is marked insecure. imagemagick7 could be supported with patches, but since upstream disabled the feature by default, it seems easier to remove it. (see https://github.com/ldo/dvdauthor/issues/24)
In addition, the previous release's Nix package listed imagemagick(7) as dependence, but it was not recognized and not used due to an error in the dvdauthor build script. Nobody complained about the lack of this feature so far.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

11 packages built:

bombono
brasero
brasero-original
devede
devede.dist
dvd-slideshow
dvdauthor
dvdbackup
dvdstyler
rhythmbox
sound-juicer

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3096

Result of nixpkgs-review pr 268421 run on x86_64-linux 1

11 packages built:

bombono
brasero
brasero-original
devede
devede.dist
dvd-slideshow
dvdauthor
dvdbackup
dvdstyler
rhythmbox
sound-juicer

LGTM


Add Bryan Mason to Contributors list

@flymason, for future reference, you gotta remove <<<<<<<, =======, >>>>>>> lines when resolving merge conflict
I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added social share  to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.


fix: workflow linting check ruff usage

Sorry, didn't notice your commit conventions, at first.

Oh yea no prob. I already changed these so probably will be overwritten. Thanks!


Still relevant?

👋
Given that there's not much activity on this gem I'm wondering if the approach is still relevant? Does it turn out in practice that it's most often worth it to just always eager load (or the reverse, ignore the n+1's) because there's not much to gain in most cases? Or is this gem just feature complete?
I was looking for anyone writing about the tradeoffs of eager loading (or not) with russian doll caching and this gem and your blog post about it are all I've found so far on this topic of dealing with n+1's with russian doll caching, so I'm curious.
Thanks!

Yep, the approach should still be relevant. The gem is extremely simple, so there shouldn't be much to add.
In the past few years, I haven't worked on websites that have a big public-facing component, which is where I find heavy russian doll caching most useful, so I haven't kept up with any changes that might be necessary --  but I also haven't heard of anything that still needs to be done!


Fix usage of undefined variable.

What's this PR do?
@aaronschachter reported getting a white-screen error on his profile on Thor & Production, and passed along this stack trace:
Notice: Undefined variable: user in dosomething_user_preprocess_user_profile() (line 86 of /var/www/www.dosomething.org/releases/20180618150533/lib/modules/dosomething/dosomething_user/dosomething_user.theme.inc).
Notice: Trying to get property of non-object in dosomething_user_preprocess_user_profile() (line 86 of /var/www/www.dosomething.org/releases/20180618150533/lib/modules/dosomething/dosomething_user/dosomething_user.theme.inc).
GuzzleHttp\Exception\ServerException: Server error: `GET https://rogue-thor.dosomething.org/api/v2/posts?filter%5Bnorthstar_id%5D=5547be89469c64ec7d8b518d&include=signup&as_user=5547be89469c64ec7d8b518d` resulted in a `500 Internal Server Error` response: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" co (truncated...) in GuzzleHttp\Exception\RequestException::cre

The $user variable referenced here doesn't exist. This PR replaces it with $uid, which does.
How should this be reviewed?
👀
Any background context you want to provide?
🍃
Relevant tickets
Slack conversation
Checklist

[ ] Documentation added for new features/changed endpoints.
[ ] Tested on staging.
[ ] Pinged a PM if this is a larger PR that would benefit from some additional testing love
[ ] Post a message in #phoenix if this includes something that causes a rebuild!

Excellent Drupaling!


[Session] Add new session form command

Description
Add a new form-based command to create a new session. @jamesjlyons
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi!
Thank you for your contribution! My name is Milena and I will be reviewing it today.
I have two minor things about this change:

What is the unit of time for the duration? Maybe it would be best to put a info by the input or, better yet, some pre-selected times.
Are this categories synced with Session? If so, shouldn't this be setup and retrieved from the app?

Other than that, it looks good to me. @jamesjlyons what do you think?

@mil3na Thanks Milena!

What is the unit of time for the duration? Maybe it would be best to put a info by the input or, better yet, some pre-selected times.

Minutes! I think the beauty of this productivity app is that you can deeply customize, so I'm thinking it might be best to leave it as freetext, happy to hear other suggestions though!

Are this categories synced with Session? If so, shouldn't this be setup and retrieved from the app?

Unfortunately there is no way to retrieve data from Session via an API or something like that at this time :/ so this solution, with the semicolon-separated list in preferences, seems to be the best right now. Let me know if there are other solutions that folks have implemented for something like this!

I don't mind the free text, my concern is the user not knowing which unit of time they should use. So, some kind of indication on what to input would be appreciated.

If the categories are not synced with the app, what is the goal of having them?

I don't mind the free text, my concern is the user not knowing which unit of time they should use. So, some kind of indication on what to input would be appreciated.

Yep I'll add that after we gather all feedback!

If the categories are not synced with the app, what is the goal of having them?

In the Session app UI, the user selects a category for the intention like a particular project, area, etc. In the app's analytics view it summarizes activities/time spent by category. This information is not exposed via an API but is accepted in the URL scheme. So when creating the session in Raycast, I'd like to be able to tell Session what category the intention belongs to.
You can how this works on this documentation page.

@benkates Thanks for contributing to this! Much appreciated 🙌
One of the reasons I didn't include the categories was because we can't pull them via an API, but it is a big downside to not have them accessible. I like how you're giving us the option to bring them in. Only concern from a UX perspective is that it could be easy for the list to fall out of sync with the main app. But since we have no other option, I think it might be the only good way to handle it!
I'm good with this addition. I'm curious though, did you explore adding these as optional arguments to the main "Start New Session" command? Not sure if it would work, but it could reduce confusion around having multiple new session commands.

Thanks @jamesjlyons - great to hear from you. Agreed on bad UX but hoping us powerusers can keep them in sync ourselves!
I love the idea of removing the form alltogether and using the command arguments interface!! What do you think about the three arguments being: intent (text), category (dropdown), and duration (text)?

@benkates Ah I see. Yeah in that case the form will don!
How do you feel about changing the title of the command to something like "Start Custom Session"? Not sure if "with form" will be clear to users what is offers before trying the command.

@mil3na added the unit of time
@jamesjlyons changed the command name
Let me know if ya'll have any other feedback!

@benkates nice! I've been thinking, and curious what you think, could this new command possibly just replace the "Start new session" command? It really just adds one extra cmd + enter if a user wants to use the defaults.
I haven't been using this extension much lately, so wondering what you think as someone who's been using it more.

@jamesjlyons I hear that - I'm always one for more options/customization, the user can always disable one or the other if they have a preference (I do this for 75% of the raycast extensions I use) - so I think keep as-is in the PR!

@benkates Having the option makes sense! Thanks again for contributing to this 🙌
@mil3na Good to go for me!


BUG: Datareader index name shows unicode characters

Fixes #8967

@dstephens99 this looks ok, pls rebase.
alos note that we are moving the dataread stuff to a separate package, pandas-datareade, i'll send you an invite to the repo

Can this get ported to datareader? Or should I submit a pull request there as well?

@dstephens99 this needs to be merged to pandas? or no

No, it got merged in with #9358

@dstephens99 gr8 thankns!


GLOB_BRACE support on Alpine and others musl-based distros

Seems that Alpine doesn't support GLOB_BRACE since it is using musl libc instead of GNU libc.
This module is affecting some installations since it depends on it. Is there a chance to work around it?

Is there a chance to work around it?

Seems like calling glob() multiple times and then doing an array_merge() is the solution for those systems. We cannot support it ourselves though, as we'd have to rewrite a glob implementation in userland then :(

@Ocramius thanks for your super fast response!!
Well, seems you already have a fallback, but in fact seems that the system isn't complaining about the implementation but instead about the non declarated use.
  [Exception]
  Notice: Use of undefined constant GLOB_BRACE - assumed 'GLOB_BRACE' in /magento/vendor/zendframework/zend-stdlib/src/Glob.php on line 64

Shouldn't this have a defined('GLOB_BRACE') check?

@cusspvz that should be quite easy to fix, yes (@DASPRiD built some workarounds before 2.0 to support old UNIX systems that didn't have GLOB_BRACE). Can you attempt a fix?
Also, remember to always link absolute code reference: using just master causes links to be broken on long term (due to code moving around)

Also, remember to always link absolute code reference: using just master causes links to be broken on long term (due to code moving around)

@Ocramius can you please explain what you meant here? Didn't understood, sorry.

@cusspvz look at the links in your comment above: I modified them to point at a specific SHA1 of the repo

Ohh, I got it now! Thanks!!


Allow enabling DNS UPDATE support

Thanks @kiall, looking good! Let me know if there's anything we can help you with.


Adyens monolog version crashes with standard vendors monolog version

Describe the bug
We make use of the monolog version provided by symfony that is provided with  standard shopware installation ( currently version <IP_ADDRESS>).
After installing the adyen plugin (version 3.12.1) our shop crashes with 500 Error
Versions
Shopware version:  <IP_ADDRESS>
Plugin version:  3.12.1
monolog version in Adyen Plugin:  2.9.1
monolog version in shopware vendor : 3.3.1

Since 6.5 you only need to require the dependencies in the composer.json and not add a vendors folder. If you follow this https://github.com/shopware/platform/blob/<IP_ADDRESS>/UPGRADE-6.5.md#new-executecomposercommands-option-for-plugins the dependencies will be installed in the root vendor folder and you will not have duplicate monolog.

Yes but the  adyen plugin zip brings its own dependencies as described above that collide with the shop's vendor directory.

Yes, I know. My description is meant for Adyen on how to solve it in next version.

Due to an incredibly disappointing decision by Adyen to deny us onboarding,
I am closing this issue.
It is now irrelevant to us, and we can't help but feel profoundly let down by the outcome.


Allow submessage callbacks only on error

When we make a submessage, we can handle both success and errors from the released message. However, this comes at a cost of paying the instantiation gas cost of the original module for each submessage.
For some use cases, eg. mapping errors in #762, we only want to handle if an error arises, and don't care about the return values. Since we assume errors are not the normal case, we add a lot of gas overhead to all the callbacks we ignore. It would be more efficient to be able to filter these out in Go, and just get callbacks on error if that is what we want.
In particular, I want to extend SubMsg with one more field:
#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
pub struct SubMsg<T = Empty>
where
    T: Clone + fmt::Debug + PartialEq + JsonSchema,
{
    pub id: u64,
    pub msg: CosmosMsg<T>,
    pub gas_limit: Option<u64>,
    pub only_error: Option<bool>,
}

If only_error is set to true, then we only make the response callback if there was an error (incl running out of gas), otherwise, just handle it like a message.
I made only_error as an Option because I feel it is usually unset and we can make the normal JSON smaller (and use less gas) by simply omitting the field. Some(true) may be a bit wordy, but None and false are the same, which is the typical case. (I can change it to just bool if there is disagreement)

Sounds good. I would just make clear that this is about the reply, not about the SubMsg itself. What about reply_on_success?

I made only_error as an Option because I feel it is usually unset and we can make the normal JSON smaller (and use less gas) by simply omitting the field. Some(true) may be a bit wordy, but None and false are the same, which is the typical case. (I can change it to just bool if there is disagreement)

I would avoid representing a a two state flag in a 3 state type. Option's in Rust do not allow omitting them so they are not like field?: boolean in TypeScript. Also, only_error: None is serialized as "only_error":null, which saves a single byte compated to "only_error":false.

Option's in Rust do not allow omitting them so they are not like field?: boolean in TypeScript.

Ah, I did not know that, good point.

no_message_is_good_message: bool

Sounds good. I would just make clear that this is about the reply, not about the SubMsg itself. What about reply_on_success?

Hmm... I don't see a use for that one (basically no need to optimize gas for unhandled errors). But maybe you could convince me otherwise. Oh, wait you mean for a name for this field?
I like no_message_is_good_message: bool (default false)

Oh, wait you mean for a name for this field?

Yes. I think it better describes what you build. You want to toggle the reply based on success/error, not the sub message execution.

I will think more on naming, but it seems that we are in agreement on everything but a good name

reply_on_success negates your flag. It would be set to true in most cases. I think it is more direct than only_error = ignore_reply_on_error.

If we are going for complete, let's make a 3 way flag: reply_on: "all" | "success" | "error" in ts syntax. (I can make a more rusty version if you like the idea)


Incorrect prompts when using loras within combinations on batch size > 1

Given this prompt: {<lora:A:1>|<lora:B:0.{1|9}>}, the parser will return either  <lora:A:1>, <lora:B:0.1> or <lora:B:0.9> on each image within the same bach.
However, lets say that the first image received <lora:A:1> - all the other images on the same batch will still be using that even if the parser returned something else. So we might get images that show <lora:B:0.1> in their metadata even though they were actually created with <lora:A:1> instead.
The same applies for weights: if <lora:B:0.1> was picked first then any image that shows <lora:B:0.9> was actually created with 0.1 weights.
Due to the way SD works I'm not sure its possible to actually make this work as one would want - but at least the incorrect prompts should be fixed. Also, although I haven't tested yet, this probably also occurs with the other types of external networks.

This works for me, but I'm using webui and extension from before the whole gradio update mess. Changing lora using {} as you described or inside wildcards both take effect correctly. Can someone confirm if this broke? Not really willing to update yet especially if this is a new issue.

I should've given more details.
I'm using ported A1111 UI to work with DirectML on AMD (windows): https://github.com/lshqqytiger/stable-diffusion-webui-directml. Its essentially the same as the native A1111 (same features and they all seem to work so far) but it is possible that could be the cause of this issue. Also I'm running with --lowvram which splits some stuff and loads/unloads them only when necessary to keep VRAM usage low - this could also be a cause.
On top of that, I have the Additional Networks and Locon extensions both which have an impact on LoRAs - but then again I was not using any of their settings, just directly adding the loras to the prompt.
I'll try the native A1111 on CPU using a commit before the last buggy update with both those extensions disabled and update this issue with my findings.

I've just finished testing it on a clean, safe version of native A1111 (commit a9fed7c364061ae6efb37f797b6b522cb3cf7aa2) without any other extension except for this one - the issue still occurs.
Since I had to do it on CPU (AMD card here) I tested with low steps, low res images but its pretty easy to tell anyway:

Notice how the second image generated in the batch size = 2 is not using the right lora.

My bad, I was doing batch count, not batch size. That indeed doesn't work, but I wouldn't expect it to ever work since it would need to load and use 2 different models at the same time. Even if it was possible it would probably cancel out any speed benefit from using batch size.

A feature request occured to me that could also be a possible fix for this issue so I'll post here:
Detect loras (maybe other types of external networks as well) within combinations, wildcards, etc... randomize only on the first prompt and port the results of those randomizations for all other prompts within the same batch. (every randomization that does not contain external networks as a possibility should still be regenerated on all the other prompts)
This would allow us to do lora combinations throughout multiple batchs while fixing the incorrect prompts per batch at the same time.

I'm not sure I understand your suggestion, but the core of the problem is that when you apply a lora, you are modifying the weights of the whole 2 or 4+gb model in memory, I think. If you want to do a batch size of multiple images generating at the same time with different loras or lora weights, you'd have to double/triple/etc the entire vram/ram usage, and even if you could do it, I think the speed would suffer from each generation accessing a different model.
Again just to confirm, this is for batch size, the one that generates multiple images at the same time. Batch count should work fine for the most part.

@scrumpyman As you said, its not really possible to make multiple different loras working on individual images within the same batch - and even if it was it would very easily cause out of memory errors.
So this issue is not about getting that to work - but rather fixing the metadata prompts that show incorrect loras as a result of this.
When you make a batch size of 2 you are sending 2 prompts. Both run through a code that parses combinations, etc...
My suggestion is to detect if a combination (,etc...) has at least 1 lora as a possibility and if so the choice given to the first prompt of that batch must persist throughout all other images of that batch.
Example:
{0.25::<lora:A:1>|0.25::<lora:B:0.5|0.5::by __artist__}, {tag1|tag2},
Lets say the first returned prompt was:
<lora:A:1>, tag1,
Then every other prompt for that batch must straight out replace {0.25::<lora:A:1>|0.25::<lora:B:0.5|0.5::by __artist__}, with <lora:A:1> before the parsing takes place (or the parser could just force the choice somehow). Images of that batch will all have lora:A:1 and either tag1 or tag2.
Additionally even if the choice for the first prompt was not a lora it doesnt change anything as the choice must still be ported nonetheless.

Oh, hm. That seems like a hacky fix for a very specific issue though. Detecting if batch size is on, detecting if extra network is in a choice, saving all these choices and forcibly applying them in other prompts of the same "batch size" but not "batch count" if both are selected.
And what if you have {tagA lora:A:0.5 | tagB loraB:0.5}, maybe with lots of tags with the lora, would it always be desired to freeze that choice in a batch? It probably would be better for most things, since in something like a character list with character loras and associated trigger words and description tags, you wouldn't want it to have the wrong lora applied, but it might not be so for every kind of choice. What if the lora is the same, or just has slightly different weights? Maybe add as an option.

I just ran into this as well. @GreenLandisaLie's suggestion seems like the best short term fix here.  As they note, this is already exactly what happens, the problem is the other items in the batch write the wrong thing into the image's metadata.

Oh, hm. That seems like a hacky fix for a very specific issue though. Detecting if batch size is on, detecting if extra network is in a choice, saving all these choices and forcibly applying them in other prompts of the same "batch size" but not "batch count" if both are selected.
And what if you have {tagA lora:A:0.5 | tagB loraB:0.5}, maybe with lots of tags with the lora, would it always be desired to freeze that choice in a batch? It probably would be better for most things, since in something like a character list with character loras and associated trigger words and description tags, you wouldn't want it to have the wrong lora applied, but it might not be so for every kind of choice. What if the lora is the same, or just has slightly different weights? Maybe add as an option.

The point here is that by definition, we cannot change the lora within a batch.  It's not technically feasible with how batches work, which is running the same loaded model in parallel on multiple images.  So while the ideal fix would be to make it work as expected, the best that can really be done with how everything presently works is to just reflect what actually happens in the PNG info (and maybe update the docs to warn about this)

There are still multiple ways to make PNG info match the used prompt in batch size:

freeze choices that could output extra networks in their entirety (what if for example you use a huge complex nested wildcard that can output a lora 3 wildcard layers deep with 0.01% probability, is that always frozen?)
only freeze the extra networks (effectively what happens already) but correctly write PNG info to reflect the behavior, parsing out extra networks for image 2+ and writing the ones in effect from the first image's choice, at the end or beginning of the other choices.

I don't think this should be added if it's not an option. And it seems too obscure of an issue to add an option for.

only freeze the extra networks (effectively what happens already) but correctly write PNG info to reflect the behavior, parsing out extra networks for image 2+ and writing the ones in effect from the first image's choice, at the end or beginning of the other choices.

This seems like the best fix, and what I was imagining.  You're right that if the choices are mixed in with non-lora components, then trying to freeze them together with the loras just changes it to a different set of unexpected behavior.

I don't think this should be added if it's not an option. And it seems too obscure of an issue to add an option for.

Agree assuming you're referring to (1) for this?  For (2) there's no behavioral change to configure.

There's also the issue where you might have a choice that really doesn't make sense if a lora from option 1 is used with the tags from option 2, in which case freezing the entire choice might be preferable. What I meant is there should be an option to select fix 1 or 2. But I guess implementing fix 2 would at least be an improvement on current behavior.

I made a childish modification to my dynamic_prompting.py file to allow freezing combinations that use @{ | }@ per batch and it works but then I ran into an issue.
After a couple of batches I get out of memory crashes because SD is not unloading the external networks used in the previous batches so they keep stacking on memory - at least that's my theory.
I'm not sure if this is something that can be solved through an extension and if its not then Im no longer sure how to solve this issue.

Some kind of general option to make a variant only change per batch would be nice to have. Possibly only an option to have the same start seed per batch (though that might be out of scope).


Layout action does not work on the distorted S-group members

Steps to Reproduce

Launch Ketcher

Open
clean_Sgroups (1).zip

Distort structures

Click the 'Layout' button

Expected behavior
S-group brackets aren't moved away from the structure after Layout actions.
S-group properties are correct after the Layout actions.
Actual behavior
Nothing changes on the canvas.
Screenshots

Additional
clean_diffprop.zip

Release/2.3 The issue is closed as fixed.


Force brew upgrade to treat arguments as casks if --cask is passed.

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

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

Fixes https://github.com/Homebrew/homebrew-cask/issues/90236.

Thanks @reitermarkus ❤


[WIP]: Creating web style guide

This is where we intend to put bootstrap styles for MAST / STScI websites.
Fixes #46

/ cc @bourque  @cmesh-stsci

@cmesh-stsci @Jenneh Sorry that it took me so long to push out any edits to this PR.  I've added some content on Typography, Colors, Iconography, and Buttons.  Do you have any thoughts on Padding, or any other sections we should add to this?


Regression in 0.1.15 Causes Incorrect Token Slicing in 'Role' Blocks

The bug
A regression was introduced in version 0.1.15 of the Guidance Library. Within 'role' blocks, the responses stored via 'capture' are missing tokens at the beginning and include extra tokens at the end, indicating incorrect slicing of the output. This issue does not occur in version 0.1.14.
To Reproduce
Give a full working code snippet that can be pasted into a notebook cell or python file. Make sure to include the LLM load step so we know which model you are using.
import os

import guidance
from guidance import models, user, capture

relpath = ".\llmdata~\mistral-7b-instruct-v0.2.Q4_K_M.gguf"

fullpath = os.path.abspath(relpath)
if not os.path.isfile(fullpath):
    print("ERROR! The model file is not at "+relpath+" and we tried to create the absolute path: "+fullpath)

# 0.1.14
# Works as expected!
#guidance_lm = models.MistralChat(fullpath, n_gpu_layers=-1, temperature=0.7, max_tokens=8194, n_batch=8194, top_p=0.95, n_ctx=8194, verbose=True, echo=False)

# 0.1.15
# Broken output (includes unwanted stop tokens, missing tokens at the beginning equal to number of extra stop tokens at end)
guidance_lm = models.LlamaCpp(fullpath, n_gpu_layers=-1, temperature=0.7, max_tokens=8194, n_batch=8194, top_p=0.95, n_ctx=8194, verbose=True, echo=False)

def tokenizer_issue():
    TokenizerTest = guidance_lm + capture("""This is a test of something we're going to move from place to place.""", "remember")
    alt_string = TokenizerTest["remember"]
    with user():
        test_lm =  guidance_lm + capture(TokenizerTest["remember"], "output")
        test_two = guidance_lm + capture(alt_string, "output_two")
        #Also occurs when NOT capturing LM state...
        test_three = guidance_lm + capture("This is an example to show that this issue only occurs within the role blocks...","output_three")

    confirm_lm = guidance_lm + capture(TokenizerTest["remember"], "finale")

    # Prints normally
    print("Works at start:")
    print(TokenizerTest["remember"])
    # Missing beginning, extra output characters that shouldn't be included at the end
    print("First error:")
    print(test_lm["output"])
    print("Second error:")
    print(test_two["output_two"])
    print("Third error:")
    print(test_three["output_three"])
    # Prints normally
    print("Works:")
    print(confirm_lm["finale"])

    #0.1.14 output:
    # Running LM Test...
    # ---------
    # Works at start:
    # This is a test of something we're going to move from place to place.
    # First error:
    # This is a test of something we're going to move from place to place.
    # Second error:
    # This is a test of something we're going to move from place to place.
    # Third error:
    # This is an example to show that this issue only occurs within the role blocks...
    # Works:
    # This is a test of something we're going to move from place to place.

    #0.1.15 output:
    # Running LM Test...
    # ---------
    # Works at start:
    # This is a test of something we're going to move from place to place.
    # First error:
    # a test of something we're going to move from place to place. [/INST]
    # Second error:
    # a test of something we're going to move from place to place. [/INST]
    # Third error:
    # an example to show that this issue only occurs within the role blocks... [/INST]
    # Works:
    # This is a test of something we're going to move from place to place.

if __name__ == "__main__":
    print("Running LM Test... ")
    print("---------")
    tokenizer_issue()

System info (please complete the following information):

OS: Windows 11
Guidance Version (guidance.__version__): 0.1.15

Looking further into it, this appears to be an issue only with the capture() function when used on text - using capture on functions or grammar does not appear to cause this issue in most circumstances.
E.g. this functions as expected:
    gen_test = guidance_lm + "Please repeat the following sentence: 'The quick brown fox jumped over the lazy dog.'"

    with user():
        gen_test += capture(gen(),"response")

    print(gen_test["response"])
    # Prints 'The quick brown fox jumped over the lazy dog.' correctly, no missing tokens or incorrect appended tokens.

I believe I have fixed this issue with pull request 858:
https://github.com/guidance-ai/guidance/pull/858
I would definitely appreciate some eyes on this from folks a bit more involved in the code base - it's possible this was done like this intentionally.

Updated my pull request with a much more robust solution, which adapted some functionality from _model.py. It might be a better idea to share the functionality (or at least the regex) between both files?


ARROW-16594: [R] Consistently use "getOption" to set nightly repo

The behavior can be seen in action here where I build this branch with the daily version number 20220517 which does not yet exists in the s3 bucket.

@nealrichardson as suggested


wireless: 1.0.1-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository wireless to 1.0.1-1:

upstream repository: https://github.com/clearpathrobotics/wireless.git
release repository: https://github.com/clearpath-gbp/wireless-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.2
previous version for package: null

wireless_msgs

No changes

wireless_watcher
* [wireless_watcher] Switched to underscores to get rid of usage of dash-separated warning.
* Contributors: Tony Baltovski

Holding for a Humble sync


Fix substitution bug when subject synonym is a substring of a node.text

Example problem:
title: Business method patent
sentence: Business method patents are a class of patents which disclose and claim new methods of doing business.
[subject: subject_number_0s [def: class [of: patents]], [def: patents]]

Notice how the subject ("Business method patent") is a substring of the root node's text ("Business method patents"). Reverse substitution was not able to resolve this before. Now the output is correctly:
title: Business method patent
sentence: Business method patents are a class of patents which disclose and claim new methods of doing business.
[subject: Business method patents [def: class [of: patents]], [def: patents]]

Fix #67, fix #68

Current coverage is 95.51%

Merging #72 into master will increase coverage by +0.01% as of 76a5db3

@@            master     #72   diff @@
======================================
  Files           12      12
  Stmts          445     446     +1
  Branches         0       0
  Methods          0       0
======================================
+ Hit            425     426     +1
  Partial          0       0
  Missed          20      20

Review entire Coverage Diff as of 76a5db3

Powered by Codecov. Updated on successful CI builds.

lgtm :ship:


Id widget refactor

#4460

Should we be using yarn or pnpm to build the storybook? This one uses yarn, whereas we use pnpm for Volto docs when invoked by .readthedocs.yaml.

@stevepiercy At present, we expect development of volto itself to be done using pnpm, but we still expect yarn for projects built by the volto generator, which is what that test is checking. (On the other hand, the new cookiecutter for volto projects sets up a project using pnpm.)

Linkcheck fails because https://www.lanku.eus/ is not reachable. Site is by CodeSyntax, so @erral?

@davisagli let's see if it still fails, after updating with main.

@stevepiercy Well, I assume so, since I updated it within the past hour and only merged one other unrelated PR since then.

@davisagli does this error mean anything to you? I don't have a clue, and my DuckDuckFu does not lead me anywhere useful.
=> Failed to build the preview
SB_BUILDER-WEBPACK5_0002 (WebpackInvocationError): Module not found: Error: Can't resolve 'prop-types-exact/build/helpers/isPlainObject' in './node_modules/airbnb-prop-types/build/helpers'

@stevepiercy No, it doesn't. That's why I asked @sneridagh about it above.

Linkcheck fails because https://www.lanku.eus/ is not reachable. Site is by CodeSyntax, so @erral? I also sent an email to their info@ email.

site is up again!

@davisagli LOL they're all green now, even though nothing really changed after @Tishasoumya-02 merged main to this branch.
I found this possible solution:
yarn cache clean

It appears that we use cache in our GitHub Actions, but I don't know whether that is related. For our future selves, we can clear caches from GitHub Workflows, if something totally inexplicable with GitHub Actions recurs again. Reference: https://stackoverflow.com/a/64819132/2214933


Trust Wallet not installed Error

Hi. I posted before as well regarding this issue. I tried both the example and made my own app too but i keep on getting (Trust wallet is not installed) even tho it is installed on my phone.
Can someone guide me in how to resolve this?

This is my android app scheme code

and this is my main file code

the response i get
{"app": {"AppStoreURL": "https://itunes.apple.com/us/app/trust-ethereum-wallet/id1288339409", "GooglePlayURL": "https://play.google.com/store/apps/details?id=com.wallet.crypto.trustapp", "name": "Trust", "scheme": "trust://"}, "callbackId":<PHONE_NUMBER>400, "callbackScheme": "com.web3example://", "rejectors": {}, "resolvers": {}}
Any sort of help will be appreciated.

may I know your android app version? will take a look soon

may I know your android app version? will take a look soon

Trust Wallet version 1.11.5
I'm using react native version 0.62.2
{
"name": "web3example",
"version": "0.0.1",
"private": true,
"scripts": {
"android": "react-native run-android",
"ios": "react-native run-ios",
"start": "react-native start",
"test": "jest",
"lint": "eslint ."
},
"dependencies": {
"@react-native-community/masked-view": "^0.1.10",
"@react-navigation/native": "^5.6.1",
"@react-navigation/stack": "^5.6.2",
"@trustwallet/rn-sdk": "^0.2.2",
"@trustwallet/wallet-core": "0.0.6",
"buffer": "^5.6.0",
"ethers": "^5.0.5",
"node-libs-browser": "^2.2.1",
"react": "16.11.0",
"react-native": "0.62.2",
"react-native-gesture-handler": "^1.6.1",
"react-native-nfc-manager": "^2.1.9",
"react-native-reanimated": "^1.9.0",
"react-native-safe-area-context": "^3.0.6",
"react-native-screens": "^2.9.0",
"react-navigation": "^4.4.0",
"web3": "^1.2.9"
},

We have identified the root cause, will update soon

Okay. Thank you
I will be waiting for the update. May I know what can be causing this?

I am having the same issue, when will it be rectified?

probably in 2 weeks, android sdk implementation is not consistent with iOS

probably in 2 weeks, android sdk implementation is not consistent with iOS

Hi. Any luck so far for the android version?

The code was merged, Android beta build will be released soon

you can test the apk from here: https://trustwallet.com/dl/apk

I installed the APK you provided with my example app. But the issue still remains. It is still giving me trust wallet is not installed error.
Even tho my code is exactly the same as in your example.
{"app": {"AppStoreURL": "https://itunes.apple.com/us/app/trust-ethereum-wallet/id1288339409", "GooglePlayURL": "https://play.google.com/store/apps/details?id=com.wallet.crypto.trustapp", "name": "Trust", "scheme": "trust://"}, "callbackId":<PHONE_NUMBER>023, "callbackScheme": "trust-rn-example://", "rejectors": {}, "resolvers": {}}
my android manifest file related code

sorry, it turned out that build isn't latest code, will update this issue once new build is ready

sorry, it turned out that build isn't latest code, will update this issue once new build is ready

no problem. will wait. let us know whenever it is prepared
thank you for your time.

Can someone

sorry, it turned out that build isn't latest code, will update this issue once new build is ready

Is the new build ready yet? Sorry for bieng pushy I am working on a hard deadline and this has already caused enough delay.

Can someone

sorry, it turned out that build isn't latest code, will update this issue once new build is ready

Is the new build ready yet? Sorry for bieng pushy I am working on a hard deadline and this has already caused enough delay.

You can try to wrap native android sdk here: https://github.com/trustwallet/TrustSDK-Android (it's activity based), react native (or web) will wail until deep link id done

Can someone

sorry, it turned out that build isn't latest code, will update this issue once new build is ready

Is the new build ready yet? Sorry for bieng pushy I am working on a hard deadline and this has already caused enough delay.

You can try to wrap native android sdk here: https://github.com/trustwallet/TrustSDK-Android (it's activity based), react native (or web) will wail until deep link id done

hi. any update on the deep link issue for android? I tried to wrap native android sdk but didn't work.


Feedback

Extraneous "|" at the end of this link: "Azure AD Service updates|"

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

ID: 6fd16cf1-63d4-4bbd-a13c-bfb8ab051e18
Version Independent ID: f6b27e10-2190-82e2-4999-eb782171c4eb
Content: Azure Marketplace SaaS Applications Technical Publishing Guide
Content Source: articles/marketplace/marketplace-saas-applications-technical-publishing-guide.md
Service: marketplace
GitHub Login: @keithcharlie
Microsoft Alias: keithcharlie

@iyerss Thanks for the feedback. We are actively investigating and will get back to you soon.

@iyerss the doc bug has been fixed. Thanks again for bringing this to our attention. we will now close this issue.


The pwsh CLI should support the -l / --login option for macOS compatibility, e.g. in VSCode

Related: #3743
On macOS, unlike on Linux, all (user-)default shell instances are started as login shells.
There are two mechanisms for invoking a shell as a login shell: (a) setting its argv[0] to contain - as the 1st character (that's what Terminal.app does) or (b) passing the -l (or --login) option to the shell executable.
If you make pwsh your default shell on macOS, certain applications may invoke pwsh with -l, which currently breaks the invocation.
Specifically, Visual Studio Code does that, so on a macOS system that uses /usr/bin/pwsh as the default shell, the integrated terminal fails to load (unless you happen to have the PowerShell extension installed and happen to open a *.ps1 file).
It would be sufficient for pwsh to accept -l / --login and otherwise simply ignore it, as the behavioral implications of this option in the context of bash don't apply to PowerShell.
Steps to reproduce
pwsh -l
pwsh --login

To see the problem in action with Visual Studio Code:

Add /usr/local/bin/pwsh to /etc/shells
Make PowerShell your default shell with chsh -s /usr/local/bin/pwsh
Open a new terminal and close existing Visual Studio Code windows.
Use code <file> to open a file for editing, where <file> must not be a PowerShell file.
Try to access the integrated terminal, which crashes due to invoking pwsh with -l.

Expected behavior
An interactive PowerShell session should start, as if the option hadn't been specified.
Actual behavior
Invalid argument '-l', did you mean:
...

The argument '--login' is not recognized as the name of a script file. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
...

Environment data

PowerShell Core v6.1.0-rc.1 on macOS 10.13.6
PowerShell Core v6.1.0-rc.1 on Ubuntu 16.04.4 LTS
PowerShell Core v6.1.0-rc.1 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)
Windows PowerShell v5.1.17134.165 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)

If we add the -l whether users expect that we fully support PowerShell Core as login shell?

We would have to document that it is an effective no-op.
De facto using pwsh as the default shell already works fine on macOS, after applying the workaround described in https://github.com/PowerShell/PowerShell/issues/6027#issuecomment-360638685
Eventually we'll need a documentation topic that describes all limitations with respect to using pwsh as the default shell on Unix-like platforms, currently summarized here: https://github.com/PowerShell/PowerShell/issues/975#issuecomment-331049792

@mklement0  Could you please clarify about

Technically, for PowerShell to detect being invoked as a login shell it must examine the equivalent of $0 (argv[0]) - the invocation name - to look for - as the 1st char.

Is it pwsh -?
Can this resolve the Issue too?

Seems we have already discussed that we could use different file names to address such scenarios (login shell, hide console windows, graphical shell and etc.). For the Issue we could create pwshl or pwsh_login runner.

That would add unnecessary complexity:

It requires creating, maintaining, shipping, documenting  a new executable, even though its sole purpose would be to ignore the -l / --login options.

User will need to know and remember that they must specify that a different executable when changing their default shell to PowerShell with chsh -s, which is far from obvious (adding the right executable to /etc/shells as a prerequisite should be done by the installer, which may already be happening).

With -l option we only fix VS Code issue not Terminal.app
I found the PowerShell Committee approvement https://github.com/PowerShell/PowerShell/issues/992#issuecomment-384455760

There is nothing to fix for Terminal.app or any other tools that use the --prefix convention, because PowerShell doesn't and need not care about what argv[0] truly contains - it simply has no impact.
The approval you link to is in a way the opposite of what we're discussing here: a dedicated pwsh-np would suppress loading of profiles, whereas option -l in POSIX-like shells explicitly loads profiles (even in non-interactive shells).

These settings are not for end users.
in this case, the end user does not need to know that another file is being launched.

That would be nice, but it's already not true for pwsh-np: As a script author, you must know to use that as the executable in the shebang line in order to get predictable behavior that doesn't load $PROFILE.
Unfortunately, backward-compatibility concerns leaves us no choice there, so a separate executable is required.
Similarly, as stated, the end user would need to know that it's not pwsh, but pwshl (or whatever it would be) that must be passed to chsh -s in order to make PowerShell the default shell.
Fortunately, in this case we do have the option to support that with the existing executable, by implementing -l / --login as no-op switches.

Modern devices is locked - owners haven't root permissions. Corporate users too. Special devices (net devices, storage systems and so in) is locked too. Only a manufacturer configure the device. Or there is a config tools. Or installer. If user has a root permission one is high quality professional user. On windows systems we traditionally have GUI that helps eliminate errors in the configuration. In PowerShell we can add cmdlets to configure shells, schedule tasks and so on in right way.
Posix discribes Bash behaviors. If somebody want to implement something Posix-compatible one have to implement or port new-Bash. For any other shell like PowerShell we are forced to seek a compromise and implement only what is possible.
If the team published PowerShell specifications under Posix, we would be so Posix-compatible :-)
I think real way is to develop and publish RFC to standardize PowerShell shell behavior. Then any manufacturer of distributions and systems can embed PowerShell in a standard and compatible manner. It may even be quite different than Posix/Bash.
It should also be noted that in the 6.x version we must comply with backward compatibility, but we can do some useful workarounds (like you suggest). But this should be done so that in next 7.x version we could make more significant changes.

@iSazonov:
Honestly, I have no idea what your first paragraph is talking about and how it relates to this discussion.
As for the second paragraph:

Posix discribes Bash behaviors.

As an aside: No, POSIX comprises a specification for a shell, whose executable is /bin/sh. Bash is a POSIX-like shell, but even when you run it in POSIX compatibility mode it isn't fully POSIX-compliant.

For any other shell like PowerShell we are forced to seek a compromise

And implementing -l / --login as quiet no-op options is exactly such a compromise.
No one is looking for 100% POSIX compatibility, which fundamentally cannot be achieved by PowerShell.
What matters is that in practice you can use it as your default shell on all of the supported platforms, and the proposed change is a step in that direction.
If someone wants to take on the work of formalizing the extent to which PowerShell is POSIX-compatible, that's great, but doing so is not a prerequisite for the change proposed here.

@mklement0 Thanks for great discussion!
Yes, adding '-l' we resolve the Issue with VS Code.
My main fear was and is that with getting '-l' users will expect that we implementfully fully functional login shell. So first of all we need to create RFC and describe all shell modes. This will allow Community to use PowerShell in the standard way.
It is a question for PowerShell Committee.

@PowerShell/powershell-committee would accept adding -l that output a warning message akin to: "The -l switch was used to indicate starting a login shell, however, PowerShell Core 6 does not currently support this meaning that certain environment variables will not be available or complete.".  This would allow tools that expect -l to be there to work and pwsh to startup and allows us to support the complete work of a login shell in the future.

Resolved in #9528


[NEON] Add qtbl/qtbx polyfills for A32V7

Similar to _mm_shuffle_epi8, qtbl/qtbx now split up to multiple shuffles on A32V7. With multi-vector shuffles, two tables are created, the indexes are subtracted, and either TBX'd on the result of the other table or ORR'd together (TBX is mandatory for qtbx, but ORR is chosen when the lookups would be theoretically dual issued).
The code seems like a lot but it really boils down to in the worst case
vmov.i8 tmp, #32
vsub.i8 idx_hi, idx, tmp
vtbx.8 lo(a), {t0-t3}, lo(idx)
vtbx.8 hi(a), {t0-t3}, hi(idx)
vtbx.8 lo(a), {t4-t7}, lo(idx_hi)
vtbx.8 hi(a), {t4-t7}, hi(idx_hi)

Note that there are compile errors with A32V7 in other files (is there even a test vector?) but the qtbl/qtbx tests pass when the errors are fixed.

for the reference, existing A32V7 bugs I immediately noticed:

cvtn is not a thing on v7-a
ld1_f64_xN is not a thing on v7-a
Clang assumes 256 byte alignment on x4 (even though alignof(uint64x2x4_t) == 16) and bus errors (not detectable on qemu)

Thanks for the heads up, silly copy paste error of mine.
 However I can throw together a quick benchmark on some AArch64 devices in 32-bit mode.

@easyaspi314 even a Compiler Explorer dump showing a reduced number of instructions is probably a good enough sanity check for me. I'm not an expert at all, I'm just the cheerleader / co-maintainer :-)

Well I was wrong about the register allocation (GCC is stupid) but even still it is no contest. I can set up a godbolt later today.

Well I was wrong about the register allocation (GCC is stupid, clang is not) but even still it is no contest compared to scalarization. I can set up a godbolt later today.

Thanks! By then https://github.com/simd-everywhere/simde/commit/2ed0d0e70c472ebd7342f353ba59d758ea8a0e67 will be merged into the trunk, so we can confirm the test results
FYI: https://github.com/emscripten-core/emscripten/pull/19304 may be of interest to you (I can refresh it when you're done with your optimizations, etc..)

I had some free time so I pushed the memcpy changes.
Later today I can work on banging out the other A32V7 bugs but these changes don't directly affect emscripten (although it seems like it is missing a simd128 fallback anyways)

@easyaspi314 Are you ready for me to queue this up for merging? Or did you want to double check with Compiler Explorer first?

https://godbolt.org/z/bfqaPajMe
Here is a godbolt for vqtbx4q_u8, the most complex function. As you can see there is no contest.
The loads in the loop are solely because calling convention forces the uint8x16x4_t to the stack.


space footer contents

Fixes #129
Type of Change:

Code
User Interface

Checklist:

[ ] My PR follows the style guidelines of this project
[ ] I have performed a self-review of my own code or materials

@aashimgarg Review this PR

@aashimgarg Review this PR

lgtm @anubhavsingh16 !!


Regen for GString support

@philn Maybe it early to regen all gtk-rs crates:
we have possibly unfinished works on class refactoring.
@sdroege You think that we ready for full regen?

@sdroege You think that we ready for full regen?

Sure, it all works. I'll have patches for another regen ready some time late next week probably, better to regen things now too.

@philn Thanks, 👍

Nighlly 3.4 travis failing by clippy errors, maybe we need add more allow.

Ah, I see cast_ptr_alignment errors here. Are you talking about those?

and wrong_self_convention too.
Also maybe need add prefix "clippy:" to all of this to remove warning completely.
Not sure if this really needed now.
@sdroege, @GuillaumeGomez what you think?

Seems to be a consequence of https://github.com/gtk-rs/gir/pull/673

Also maybe need add prefix "clippy:" to all of this to remove warning completely.

If you add that, then 1.31 is the earliest version things will compile with at all :)

@sdroege Yes, and that is very sad.

So what's the action point here?

Add the missing use glib; :)

For this PR I think Sebastian is preparing a PR for the gir codegen slippy warnings, so I'll wait :)

@philn IMHO you just can add 2 ignore for clippy (without prefix).


issue-4135: updated-mysql-connection-json

Describe your changes :

I worked on the updating mysql connection json

Type of change :

[x] Bug fix
[x] Improvement

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have commented on my code, particularly in hard-to-understand areas.

Reviewers
@open-metadata/ingestion

@darth-coder00 @Sachin-chaurasiya let us know if this is good to merge pls 🙏


Update README.md

Actualize documentation for simpleAutoImport

simpleAutoImport is removed
I have updated the readme accordingly
thanks for bringing this into my attention

Good luck


LFQ loss is negative?

Does this have an effect on traning?

I meet the same problem? Have you solved that?

@lqniunjunlper could you try turning this on?

I can confirm that using experimental_softplus_entropy_loss=True leads to a positive loss.


[nrf fromtree] manifest: openthread upmerge up to commit 2e625bfe

OpenThread upmerge with new transmit frame header updated flag.
Depends on:

[ ] https://github.com/nrfconnect/sdk-zephyr/pull/585

Now applied to the upmerge branch.
The manifest update conflicted with the cherry-pick of 4f35a4eaa9e7282f1933500de237401091dd60bb, so I reverted that. Also the third fromtree did not apply to the upmerge branch so I recreated it by cherry-picking the original upstream commit. Please recheck my branch to make sure it contains the right commits; thanks.


@ave regridding  to fully-enclosed cell should exactly copy enclosing cell's value

Reported by andrew wittenberg on 23 May 2013 01:37 UTC
I ran across this in writing a script to locate multiple extrema in a time series.
When regridding from a coarse grid to a fine grid, and a cell on the target grid is fully enclosed by a cell on the source grid, @ave regridding to that cell should simply copy the source cell's value to the target cell.  In addition to saving computation, it would also avoid the round-off errors seen in the following example (shown here in SINGLE PRECISION FERRET).
 	NOAA/PMEL TMAP
 	FERRET v6.725
 	Linux 2.6.18-274.12.1.el5 64-bit - 04/10/12
 	22-May-13 21:29

yes? def ax/x/edge xax = {0,31,61,92}
yes? def ax/x/edge xax_coarse = {0, 92}
yes? let vdat = {3.034547, 3.078104, 3.059311}
yes? let v = vdat[let v_coarse = v[gx=xax_coarse@max](gx=xax@asn]
yes?)
yes? list v eq v_coarse[            VARIABLE : V EQ V_COARSE[GX=V@AVE](gx=v@ave]
)
             SUBSET   : 3 points (X)
 15.5 / 1:  0.0000
 46   / 2:  0.0000
 76.5 / 3:  0.0000
yes? list/p=20 v, v_coarse[            X: 0 to 92
 Column  1: V is VDAT[GX=XAX@ASN](gx=v@ave]
)
 Column  2: V_COARSE[X@AVE](G=on) is V[GX=XAX_COARSE@MAX] (regrid: on X@AVE)
                          V       V_COARSE
15.5 / 1:  3.034547090530396  3.078104019165039
46   / 2:  3.078104019165039  3.078104257583618
76.5 / 3:  3.059310913085938  3.078104019165039

Note the difference in the 8th significant digit of the value at i=2.  Similar issues occur in the double-precision version of Ferret; I just haven't taken the time to find a double-precision case that demonstrates the error.  Such errors affect the results maybe 2% of the time; perhaps a test with random axis data and random variable values could demonstrate this.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2070

Comment by ansley.b.manke on 7 Jun 2013 18:59 UTC
The behavior (in this example) shows up on a 64-bit machine running single-precision Ferret. A 32-bit machine with single precision Ferret returns correct results, and double-precision Ferret returns correct results. This indicates that what's going on here is also the question of what we mean by
v EQ v_coarse[gx=v@ave]
The expressions are different but only in the 8th digit which is not significant when doing single-precision arithmetic.  EQ should really be computed as "equals, to within the precision of the numbers involved".  This is a moot issue with double-precision Ferret.
However I do agree that regridding a source cell that encloses the destination cell should be done by just copying the value, removing that cause of computational precision loss.
I've made that change, only for regridding along 1 axis (not the 2D regridding that takes into account the correction for area on the globe). The change does not affect our benchmark results, and the same fix for single-precision Ferret does fix the example reported above.


Flaky e2e suite: Failed to create ResourceFlavor

What happened:
The creation of the default ResourceFlavor failed
What you expected to happen:
To succeed
How to reproduce it (as minimally and precisely as possible):
https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kueue/466/pull-kueue-test-e2e-main-1-23/1605115464738934784
Anything else we need to know?:
No idea how this would happen. There is only one test that creates a ResourceFlavor, as far as I can see.
But a couple of notes:

In AfterEach, we issue the delete call, but we don't wait for the object to be deleted. Waiting is important (we do in integration tests), because deleting a ResourceFlavor is asynchronous.
I don't see why we can't create the RF once for the entire suite.

Environment:

Kubernetes version (use kubectl version):
Kueue version (use git describe --tags --dirty --always):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

cc @kannon92

The one thing I notice about resource flavors is that they won't delete if something is still using them.  I notice that they have a finalizer and you have to remove the CQ and Queues completely before you can remove a resource flavor.
I don't think there is much effort in deleting a resource flavor so I wonder if CQ or Queue are still being utilized in that test.
So I can fix this by deleting CQ and Queue.  And then verifying that these are completely deleted before aiming to delete the resource flavor.
How should I detect if CQ and Queue are deleted completely?  Just check if they still exist?

The one thing I notice about resource flavors is that they won't delete if something is still using them. I notice that they have a finalizer and you have to remove the CQ and Queues completely before you can remove a resource flavor.
I don't think there is much effort in deleting a resource flavor so I wonder if CQ or Queue are still being utilized in that test.
So I can fix this by deleting CQ and Queue. And then verifying that these are completely deleted before aiming to delete the resource flavor.
How should I detect if CQ and Queue are deleted completely? Just check if they still exist?

@kannon92, In integration tests, we just check their existence.
Maybe, below helps you.
https://github.com/kubernetes-sigs/kueue/blob/ed57453794e53f6a74e7363be83c663873729f03/test/integration/framework/framework.go#L341-L349

I don't think there is much effort in deleting a resource flavor so I wonder if CQ or Queue are still being utilized in that test.

Even if you delete the CQ and LQ, the controllers might see those updates a bit later and take some time to react.
I was about to share the same link as @tenzen-y :)
Still, I don't understand why the test failed if there is only one that uses a RF. Are we running the suite more than once?

This is mostly a code quality question.  Is it correct to use frameworks in the integration tests in the e2e tests?  Or should they be moved to a common utility for both?  I used the utils for making jobs but I was wary of pulling in utilites that were defined in the integration test suite?
I think we could replace the delete with the corresponding deletes with the link you all sent if there is no objection.

Still, I don't understand why the test failed if there is only one that uses a RF. Are we running the suite more than once?

I'm not entirely sure if the runs are completely isolated.  I think the test would fail if the resource flavor finalizers were still set and they weren't updated.  Maybe higher load on the runner?  I don't think these are completely isolated from one another.

I'm fine having a common framework for e2e and integration in test/framework

I don't think these are completely isolated from one another.

What I'm trying to say is that I didn't see another test where we create a RF. Did I miss something?

I don't think these are completely isolated from one another.

What I'm trying to say is that I didn't see another test where we create a RF. Did I miss something?

No I don't think you missed anything.
I more mean that the different jobs are not completely isolated in prow.  I don't think a job gets an isolated CI runner.  So I think maybe some runs could be slower than others.  And maybe the delete of CQ or queue didn't completely finish and that caused the RF to not be deleted.
I'll push up a change to use a common framework and utilize those utilites for any cleanup.
/assign @kannon92

but wouldn't each prow job create its own kind cluster?


Got error when new version is published

Hi --
I got error as following when I published new version. Please kindly check. Thanks!
Repositories

is-up
json
ip-address
is-online
public-ip

You have been banned for squatting module names. Email me if you want to work it out.


Carefully move some internal methods of recurrent.py to a dedicated utils file

Before trying to tackle #161 I thought it can be helpful to a bit simplify navigation in recurrent.py by reducing the number of lines of code there.
Carefully extracting few internal methods to another file seemed to be a quick win in that sense. So I decided to come up with this PR. Hopefully, it is useful for the maintainability of recurrent.py.
Changes

Moved following methods from recurrent.py to a new file recurrent_internals.py :

Method

_check_inputs_dtype

_safe_where

_ unstack_input_sequence

_specialize_per_device

_rnn_step

_lstm_fn

Added recurrent_internals.py as a dependency to the Bazel src/BUILD
Aligned the usage of recurrent_internals with the usage of utils

The tests are passing locally
Questions
It was quite a useful journey for me and it would be great if you find the outcome useful as well:) I've also got a few questions while implementing the changes.

[ ] Is recurrent_internals.py a good enough name? Please feel free to suggest a nicer or more consistent one.
[ ] I’ve noticed quite a few TODOs in recurrent.py. Maybe you have some refactoring plans or ideas for this file which should be considered in the current or next PRs?
[ ] Are there more places in code that should know about the newly added file?

@googlebot I fixed it.

@googlebot I consent.

@googlebot I consent.

Sorry for the mess with the commit authors, a bit an unexpected issue but seems to be solved :)

Thanks for the PR, Sergey!
I understand your concerns regarding the size of recurrent.py. Big modules could be tricky to work with, but I'm not sure that splitting recurrent.py into multiple smaller modules would significantly improve readability/maintainability. Having internal functions defined closer to the usage sites makes refactoring easier; _ names clearly indicate that these are not designed for use outside of Sonnet. So, all in all, I'd rather not merge this. I hope it's okay. That said, please do not hesitate to tackle #161, we'd welcome a fix for that!

I’ve noticed quite a few TODOs in recurrent.py. Maybe you have some refactoring plans or ideas for this file which should be considered in the current or next PRs?

I don't think we have any refactoring planned atm. Most TODOs are there to provide context or serve as a reminder, but none are critical to implement/fix.

Thank you @superbobry !
Sure, there is no problem to skip the changes. Or maybe to restructure them…
I think I was a bit unclear about the reasoning for this PR, even to myself. So let me try to rewrite it :)
The selection of recurrent.py as a refactoring target is not random. When thinking where my contribution could be the most useful I’ve run a great code BI tool against the repository and it revealed that recurrent.py is actually a significant outlier across the entire project.

(Legend: Circles are files in folders, their size - number of lines of code, color insensitivity - commit frequency)
It has the highest change frequency and the biggest size.

So the major reason to think of refactoring this file not just the size, but the frequency of changes/fixes. (Because we commit when we need to fix or modify something )
Zooming a bit deeper the analysis identified that there is quite a high chances that static_unroll and dynamic_unroll methods are problematic:

( __init__ and __call__ seems to be aggregated through all the classes so we can skip their results)
And when I was trying to reproduce the example from #161 something was failing in dynamic_unroll for me.
Intuitively, these two methods are actual targets of my refactoring.  My intuitive plan was:

(current PR) Clean up a bit before the extraction and get familiar with the code and not break anything.
Extract static_unroll and dynamic_unroll to a dedicated file like: recurrent_internals.py or unroll.py.

But seems like I completely formulated this plan only now :)
The idea of this refactoring is to extract static_unroll and dynamic_unroll with their internals to a separate file like unroll.py.
And I can see 3 major benefits from that:

Better isolate most frequently changed code, which can help to focus maintenance effort in the future.
recurrent.py will contain only classes of networks that with time seems to be only getting added, not modified.
Better align the structure with usage. From the code usages the methods seem to be called like: snt.dynamic_unroll() with no recurrent in the path. While structure-wise, currently, the methods belong to recurrent.py.

Of course, this refactoring idea is based only on numbers without knowing the details of your challenges :)
So if you think the extraction of unroll methods can make sense I would be happy to shift the focus of this PR and implement the change. Otherwise, no problem to close this branch.
How do you think?


Organization by discrete definitions/specs

If crocks will use the common terms of category theory such as Functor, Monoid and Monad, then in order to illustrate the face value of each crock, should there be organization (in the readme, source, or elsewhere) for better API documentation and overall quality?

Do you have an sample of what you are thinking?

If you mean mark the containers labels like:
Implements
Setoid, Functor, Apply, Applicative, Chain, Monad
Then a page could be made to describe the constraints of each?
I say this is a good idea!!

One thing I would disagree with is creating a page that lists or organizes (and then links to) specific ADTs.
So this would be Bad News Bears:
Setiod
Maybe
Either
Pair
...

Yes! To your second reply;  possibly above the description so it would go,

Crock a

Implements

Description/example

Constructor/instances

sigs

But also avoiding writing specs or duplicating fantasy-land/[insert spec lib].
Since interoperability between certain types is key, I think there may be a more soluble answer here so I'll leave this issue open for now until the API is more fleshed out.

Thinking this over, giving breathing room [minimal api] would make for a better tomorrow.  I'm going to leave this open for if anyone has more intuitive ideas, but i want to say it's too early to make these guesses.

I am closing this out. no reason to have this taking up valuable space.
We can revisit later


dependencies: bump app-rdm and rdm-records for release 0.7.0

Same as https://github.com/inveniosoftware/cookiecutter-invenio-rdm/pull/60

Coverage remained the same at ?% when pulling 310c54aa632a659572813ee1c8cf31552b342346 on ppanero:release into 2ecc7eee52b28132e12d893672004074131e8b69 on inveniosoftware:v0.7.0.

Perfect, closing this then :)


Support GitHub default branch in Repositories

Description of the PR:
Problem: currently, if a repo default branch is anything other than "master", the Repositories view cannot show the repo content.
This change adds the ability to read a repo default branch from GitHub and use it to display its content as expected.
Note: this branch also contains the fix #278, this change would not make sense without that fix because Repositories is unable to show any content, regardless of the default branch used.
Additional context:

@lostintangent I just noticed the Release action does not update the extension version and I have not change it in package.json; that will generate another version 0.4.0 but the last run for this Action failed so it may not go through automatically this time either
- name: Publish to VS Marketplace
  run: npx vsce publish