[v1] options for plugins

Summary
How are users supposed to pass options for plugins?
Description
For now, we have only one plugin @algolia/autocomplete-plugin-recent-searches. User might want to customize it by overriding the part of source returned by the plugin, or the templates. We do not have an API at the moment.
There are two approaches.
1. Let plugins handle them
We can have a contract that plugins must accept a prop "source" and it will override the part of sources being returned by the plugin.
For example,
import { createRecentSearchesPlugin } from '@algolia/autocomplete-plugin-recent-searches';

const recentSearches = createRecentSearchesPlugin({
  key: 'recent',
  source: {
    getSuggestionUrl: ...,
    templates: {
      header: ...
    }
  }
});

The burden of merging them are delegated to the plugins, meaning that all the plugins will have the similar code.
2. Let the core handle them
When users add the plugin, they can specify the options.
const recentSearches = createRecentSearchesPlugin({ key: 'recent' });

autocomplete({
  ...
  plugins: [{ plugin: recentSearches, source: { ... } } ]

It's similar to what Gatsby does:
module.exports = {
  plugins: ['gatsby-plugin-mdx'],
}

// or

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-mdx`,
      options: {
        defaultLayouts: {
          posts: require.resolve("./src/components/posts-layout.js"),
          default: require.resolve("./src/components/default-page-layout.js"),
        },
      },
    },
  ],
}

User can either pass a plugin itself or an object containing the plugin and the source option. And the core will deal with merging the source.
I'm more in favor the second way. What do you think?

what if plugins are functions instead of objects, and they deal with the options themselves?

I think that we should remove this concern as a whole by moving this responsibility to plugin authors. If they need to support options, they would export a factory:
const plugin = createPlugin({ ...options, source: {} });

Perhaps the problem you had in mind was rather how to leverage the Autocomplete lifecycle in plugins? That's a harder one because we need to spec that.
Example of spec with a getSources option
// Notice `sources` here which are the original sources from the plugin.
function pluginGetSources({ query, sources }) {
  if (!query) {
    return [];
  }

  return sources.map(transformOriginalSource);
}

const plugin = createPlugin({ ...options, getSources: pluginGetSources });

what if plugins are functions instead of objects, and they deal with the options themselves?

We can do that, or since we already accept options
import { createRecentSearchesPlugin } from '@algolia/autocomplete-plugin-recent-searches';

const recentSearches = createRecentSearchesPlugin({
  // ... here

We can let plugin authors accept more options there.

@francoischalifour If we

remove this concern as a whole by moving this responsibility to plugin authors

then why do we need
autocomplete({
  // ...
  plugins: [recentSearches, [customPlugin, { getSources: customPluginGetSources }]]
});

syntax? We already have a plugin factory function like createRecentSearchesPlugin which takes options:

Let's take the example of the Recent Searches plugin.
There are multiple case for this experience (that we still need to accurately define). The two that I have in mind right now:

Same-page experience. The recent search item triggers a function in onSelect (e.g., refine() for InstantSearch).
Redirect-page experience. The recent search redirects to the results page with getSuggestionUrl and a template modification that's wrapped in a tags.

If we go with the solution where plugin authors need to implement an options API to support these case, we open the ecosystem to (1) inconsistencies and potentially more (2) bugs.
If we go with the [plugin, pluginOptions] syntax, we create a spec that reduces (1) and (2).
import {
  createRecentSearchesPlugin,
  getSourcesSamePageExperience,
  getSourcesRedirectPageExperience,
} from '@algolia/autocomplete-plugin-recent-searches';

const recentSearches = createRecentSearchesPlugin({
  /* ... */
});

autocomplete({
  // ...
  plugins: [[recentSearches, { getSources: getSourcesSamePageExperience }]],
});

This is the dilemna with "APIs vs. Specs", a.k.a., "give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime".
Perhaps there are points that I miss—let me know if that's the case.

Closing this since we went for (1) letting plugins handle options themselves.


jack module: init

Motivation for this change
Currently tested applications with default module settings:

Bitwig, Ardour, MuseScore, ADLplug standalone via native JACK
VLC, Firefox, Chrome, QMMP, aplay, uade123, openmpt123, munt via pcm plugin and loopback device
hardware.pulseaudio.enable both true and false

Things done

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

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

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

@oxij The only sad thing is that I have not found a way to make jack1 work correctly in promiscuous mode:
http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-March/001876.html
https://github.com/jackaudio/jack1/issues/87

cc @bobvanderlinden for alsa-plugins change

Nice! Thanks for putting effort into NixOSifying this.
The first patch LGTM.
The second patch:

first line of the commit message should be "nixos/jack: init" or similar,
extraPackages option looks superfluous to me,
enable32BitAlsaPlugins should be an option, like hardware.pulseaudio.support32Bit and hardware.opengl.driSupport32Bit, the current definition is always true AFAICS.
"/home/jackaudio" -> "/var/lib/jackaudio",
that user needs a static uid, I think,
you can't use createHome there, the home directory needs to be created on every startup if it does not exist, else things are very easy to break.

From the top of my head, see the tor service module for how to do all these user- and home-related things properly.
I would also rename

services.jack.pcmPlugin -> services.jack.alsa.enable
services.jack.dbusSupport -> services.jack.dbus.enable`
both startupOptions -> extraOptions

as common in other modules.
I would also add services.jack.a2jmidid.package option for completeness and put all jackd options under services.jack.jackd for homogeneity.

The only sad thing is that I have not found a way to make jack1 work correctly in promiscuous mode:

Hm, I had it working before, I'll play with it sometime later.

@oxij
Thank you! Applied changes.

you can't use createHome there, the home directory needs to be created on every startup if it does not exist, else things are very easy to break

Tor module uses createHome too.

I would also add services.jack.a2jmidid.package option for completeness

We only have one version and also JACK1 has this functional builtin

Hm, I had it working before, I'll play with it sometime later.

Would be really glad if you let me know how to make it work (no necessity to test this PR, just an instruction on how to kick it will be enough). For me only control functions do work with jack1 in promiscuous mode. If I try to user programs there are errors "subgraph starting at ADLplug timed out (subgraph_wait_fd=9, status = 0, state = Triggered, pollret = 0 revents = 0x0)". If I run jack client from the same user as jack server user then everything works.

you can't use createHome there, the home directory needs to be created on every startup if it does not exist, else things are very easy to break.

Just a hint (hope that helps): The systemd directives StateDirectory and StateDirectoryMode can be used to create a "home" directory for a service in /var/lib (or in the user's home directory if it is a user service). The directory will be owned by the user account that is used for the service and it persists when the service or the machine is restarted. See systemd.exec(5) for details. If the service actually needs a $HOME environment variable, it must be defined with the Environment systemd directive.

@Yarny0 applied, thanks!

Will reopen after some rework

@oxji Hi! Did you get a chance to look into jack1 promiscuous mode?
Meanwhile I've reworked this module to make it more robust and simpler to maintain.

Removed user service. Because of #21460 and also for simplicity and maintainability
Added loopback device option in addition to ALSA PCM plugin. Makes setup work in sandboxed environments like Steam
Added session option so user could do initialization here. Default session just starts a2jmidid if JACK2 is used
Used jack_wait and jack_lsp to check for server/port availability instead of unreliable delays in services
JACK service is now brought not by sound.target but by udev rule when real sound card appears in order not to trigger on loopback device availability

@Infinisil Thank you for review! Could you please tell me more about moving defaults to config?
What if user wants to drop these defaults? Should he use lib.mkForce then?
I personally keep defaults with options like this
  services.xserver.windowManager.i3.extraPackages = with pkgs;
    options.services.xserver.windowManager.i3.extraPackages.default ++ [ spectacle ];

  programs.sway.extraPackages = with pkgs;
    options.programs.sway.extraPackages.default ++ [ qt5.qtwayland grim ];

Just can't conclude which approach is better:

to set defaults in config, so user likely needs mkForce if he wants to overwrite them
or to set defaults in options and let user use options...default is he wants to extend defaults

I think if the default makes sense to always be present, because otherwise the module doesn't properly work, then setting it in the config section and requiring the user to use mkForce if they really want to remove that is good.
On the other hand for defaults that aren't necessary for the module to work, and users are encouraged to change them, then assigning a default in the option makes more sense. Note that the users could still keep those defaults by assigning their values with mkOptionDefault, which is a bit weird, but simpler than using the options argument, but sometimes also doesn't work.
(The option value gets determined with a priority system, the assignments of highest priority get merged together to result in the final value, mkForce has high priority, mkOptionDefault very low priority, mkDefault low priority, and without any of those it gets a default priority in the middle).
I've written down something similar for NixOS/rfcs#42: https://github.com/Infinisil/rfcs/blob/config-option/rfcs/0042-config-option.md#defaults
In this case I'd think putting the defaults in the config section always makes more sense, because these default values encode part of the functionality of this module, and without them certain options couldn't do their thing.
The biggest annoyance is that these defaults don't show up in the manual. In the future this might get fixed.

@Infinisil Got it, thank you! I've applied requested changes.

Hm I just wanted to test this, but I'm not sure it works as intended. I enabled services.jack.jackd.enable = true;, but because there's no wantedBy = [ "multi-user.target" ] or so for the jackd service, it doesn't even start. Is that right? How do I test this?

@Infinisil it will start only on reboot by udev rule, when real sound card will be added, sound.target is not suitable, since that way loopback device could be initialized before real sound card, and so service will fail. udev rule doesn't trigger on loopback device

Could someone finally merge this?

While I'd have liked for another person to test it, especially somebody who wants to use jack, you seem to have tested it well enough already, so let's merge.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/firewire-audio-not-working/3976/4


Boolean indexing doesn't work with subclass and TypeVar

Describe the bug
A suggested on https://github.com/pandas-dev/pandas-stubs/issues/908#issuecomment-2132279017 I'm trying to use DataFrameT = TypeVar("DataFrameT", bound=DataFrame),
but with boolean indexing instead of a pipe.
To Reproduce

from typing import TypeVar, reveal_type

from pandas import DataFrame, Series

class SubDF(DataFrame):
    # https://pandas.pydata.org/pandas-docs/stable/development/extending.html#override-constructor-properties
    @property
    def _constructor(self):
        return SubDF

    @property
    def _constructor_sliced(self):
        return Series

sub = SubDF({'a': [1, 2, 3]})

DataFrameT = TypeVar("DataFrameT", bound=DataFrame)

def func(df: DataFrameT) -> DataFrameT:
    index = Series([True, False, True])

    df_ = df.loc[index]
    reveal_type(df_)

    return df_  # Type "DataFrame" is not assignable to return type "DataFrameT@func"

reveal_type(func(sub))

pyright:
  /workspaces/ng/repro.py:27:17 - information: Type of "df_" is "DataFrame"
  /workspaces/ng/repro.py:29:12 - error: Type "DataFrame" is not assignable to return type "DataFrameT@func"
    Type "DataFrame" is not assignable to type "DataFrameT@func" (reportReturnType)
  /workspaces/ng/repro.py:32:13 - information: Type of "func(sub)" is "SubDF"
1 error, 0 warnings, 2 informations

Please complete the following information:

OS: Linux
OS Version 20.04.6
python version 3.12.2
version of type checker 1.1.390
version of installed pandas-stubs <IP_ADDRESS>126

Additional context
Repro inspired by:

https://github.com/pandas-dev/pandas-stubs/issues/908

Might be same root cause as:

https://github.com/pandas-dev/pandas-stubs/issues/453

It's not a .loc issue.  You get a similar result with any DataFrame method that returns a DataFrame, e.g.:
def func2(df: DataFrameT) -> DataFrameT:
    df_ = df.query("x <= 10")

    return df_   # Type "DataFrame" is not assignable to return type "DataFrameT@func"

reveal_type(func2(sub))

The type revealed is still correct (SubDF) in this case.
That particular example can be fixed by changing query() to return Self instead of DataFrame.  I imagine we'd have to do that with any of the methods in class DataFrame that currently return DataFrame  - i.e., change them to return Self
But loc is different, because it is returning the class _LocIndexerFrame, so I think that  latter class would have to become generic with Self passed in as a parameter, so it is a subclass of Generic[_T]
I tried this idea and it worked on your example.
PR with tests welcome.


Resident evil 2

Version
3.2.3 (5e89e20)
Seed
R721-LGFM-ZNHHJ0M5Y9Y0007JZZZZZZZ5ZZZZZZZZZZZZZZZZZZZZZZZZZ
Scenario
RE 2 (Claire A)
Player Character
jill
What happened?
after you blow up that door where the helicopter blocking and when you go through that door it will lead you to a long cutscene but when the cutscene happens you are getting attack by 4 nemmys and you can't do nothing so you end up died and i check if there's any other way round it and there isn't

Duplicate of #800


Removing dmsfeedback alias reference.

I'm the Senior PM assigned to all things DMS, please contact me if you have questions or comments about this change.

@dbamaster : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@pochiraju
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Implement a PSR in the example folder

For example
https://github.com/DENG-MIT/NN-PSR/blob/main/node_pyrolysis.jl

Example at
https://github.com/DENG-MIT/NN-PSR/blob/eb5b934fa9d5f6e9c75dbf2500988fd42e117703/PSR.jl#L1
https://github.com/DENG-MIT/NN-PSR/blob/main/PSR.jl
Validation with Cantera

Host the example in the separated repo is a good idea to keep this repo clean.


[Release] Sync main from stage 1/4/2024

Syncing following PRs from stage to Main

https://github.com/adobecom/cc/pull/219
https://github.com/adobecom/cc/pull/244
https://github.com/adobecom/cc/pull/250
https://github.com/adobecom/cc/pull/255

Test URLs:
Before - https://main--cc--adobecom.hlx.live
After - https://stage--cc--adobecom.hlx.live

Codecov Report
Attention: Patch coverage is 47.82609% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 86.69%. Comparing base (6e09f6d) to head (c1085a2).
Report is 3 commits behind head on main.

Files
Patch %
Lines

creativecloud/scripts/utils.js
20.00%
12 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #256      +/-   ##
==========================================
- Coverage   87.68%   86.69%   -1.00%
==========================================
  Files           9        9
  Lines         934      947      +13
==========================================
+ Hits          819      821       +2
- Misses        115      126      +11

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Validation done in stage on below url :
https://www.stage.adobe.com/products/firefly/features/text-effects.html
https://www.stage.adobe.com/products/firefly/features/text-to-image.html
https://www.stage.adobe.com/products/photoshop/generative-fill.html

https://www.stage.adobe.com/products/firefly.html

https://www.stage.adobe.com/downloads.html

https://www.stage.adobe.com/careers.html


Provide an API for parsing hostnames

Currently, the API provides an IPv4Address.ParserResult type, which returns either success, failure, or "notAnIPAddress". The latter is supposed to mean that the hostname should not be interpreted as an IPv4 address, and perhaps as a domain or opaque hostname instead. The idea was that this API could be useful for applications which accept a user-provided hostname or read a hostname from a configuration file.
Recent changes to the URL Standard make it impractical to make this distinction at the IPv4 parser level, and it doesn't cover other forms of addresses such as IPv6, so the previous API will be deprecated. Instead, it might be better to provide a more complete host-parsing API. This would also perform IDNA once we support that.
Since the allowed kinds of hosts depend on the URL's scheme, we would probably assume a network (i.e. non-opaque), non-file host, and parse the given hostname in the same way we would parse an HTTP URL.

https://karwa.github.io/swift-url/0.4.0/documentation/weburl/weburl/host-swift.enum/init(_:scheme:)


Features/no overwrite config

Builds on #378 but:

uses : ${var=thing} instead of : ${var:=thing} for scalars and [[ -z "${var+x}" ]] instead of (( ! ${#var} )) for arrays so that we only set the config params if they are in fact unset, and not if they are just null (e.g. empty string, empty array).
updates specs to set options before the plugin is sourced instead of after.

@ericbn What do you think?

Hi @ericfreese. I would go with checking if the arrays are not set with ! ${+VAR} as in
(( ! ${+ZSH_AUTOSUGGEST_STRATEGY} )) && ZSH_AUTOSUGGEST_STRATEGY=(history)

This will keep the same behavior of ${VAR=default} used for the scalar variables. From zshexpn(1):
${+name}
       If name is the name of a set parameter `1' is substituted, otherwise `0' is substituted.

${name=word}
...
       In the first form, if name is unset then set it to word;

So both
: ${VAR=default}
(( ! ${+VAR} )) && VAR=default

mean exactly the same thing: if VAR is unset, then set it to default.

Updated. Thanks @ericbn!

Cool! Looking forward to seeing this change in the master branch.


docs: fix usePreviewMode code and note

🔗 Linked issue
none
❓ Type of change

[x] 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
correctly closes code block and uses new note block, as it currently looks a bit weird...

📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have added tests (if possible).
[ ] I have updated the documentation accordingly.

closing in favor of https://github.com/nuxt/nuxt/pull/26303


[Docs]

Documentation Link

The Introduction part in appsmith-docs contains broken markdown making it confusing for readers.

Describe the improvement

Maybe I can add an anchor markdown with preview image of the youtube link in the readme.md file as shown below:

Please assign me for the following issue

@kalpeshT101 this issue only exists on github. Our docs which are hosted on https://docs.appsmith.com rely on this syntax to render custom components

I see that someone has made the required changes  that I recommended , then why is my PR invalid?

@kalpeshT101 I don't see a PR related to this issue can you share the PR?


A potential way to save space for genomes smaller than 2^32nt.

Consider the following genome of three 20nt long chromosomes:
>chr1
AGACGCAGCGAGACGCAGCG
>chr2
TGCGTTAGTACGATTGCATC
>chr3
CCTTTAGTACGATTGCATCT

Instead of representing the seed location as e.g. (chr3, 10) for position 10 on chr3, we could concatenate the strings and represent it as position 50. The only time this needs to be 'converted back' to (chr3, 10) is for the sam alignments.  Such an offset vector could be implemented [0,20,40], storing the offset positions of each chromosome in the concatenated string. One can do binary search over the very small vector to find the right chr_id. The index in the offset vector is the index of our chromosome id (and we already have an index-> chromosome name vector.
How about our hash table (call it H)? Currently, H contains seed hash value as keys and two different values:
If unique seed: stores reference chr_id and packed seed offset in 4 bytes and chromosome position in 4bytes.
If repetitive: store position in a vector with repetitive seeds (4 bytes), and the count of the seed (4bytes).
I think we can use only 4-bytes in H for both cases.
If unique seed: If one is willing to discard the packed strobe 2 position (taking 8 bits) we could go from 8 bytes down to 4 bytes. Here, the 4 bytes would simply be the position in the concatenated string. The strobe 2 position is, from what I remember, only used for checking if distance between the two strobes are the same on query and reference. If yes, first try hamming distance. otherwise go directly to alignment. We could instead always try hamming distance first as nearly no cost.
If repetitive seed: We could store only the offset position in the vector in 4 bytes in H. The count could instead be fetched by having a (new) hash map M : {hash_value -> hash_value_next} which is obtained after sorting the vector on hash values. M should be fairly succinct as is only need to store one key-value pair for each repetitive seed. Getting the count (i.e., number of positions to iterate over in the vector) for a seed with the i:th smallest hash value h_i  would require four operations:

Obtain offset o_i of h_i from querying H
Obtain the next hash value h_{i+1} throughM
Obtain offset o_{i+1}of h_i+1 in H
count = o_{i+1} - o_i

The operations 1-3 of course comes at a cost in runtime compared to only have one lookup. I wonder how much if e.g. computation of prefetched data sa suggested in #203.
Edit:  The packed strobe 2 position is also used for merging hits into 'merged hits' (called NAMs in the code). Two seed hits are merged if they overlap on both the query and the reference in the same order. To detect overlap, we use the length of the seed, where the position of the second strobe is needed. The extent to which the exact length of seeds is needed (or whether an approximate seed-length can be used) remains to be explored.

Just documenting an idea down, not a priority. But would be interesting to hear you opinion about this @marcelm.

(Note: I try to use the term "contig" to describe a single record in the input reference FASTA because I find "reference" to be ambigous – it can also be used to describe the entire input FASTA, i.e. the set of contigs).
Concatenating the contigs and using a single integer as position is a good idea. I think BWA does this, and it is how it was done in an experimental read mapper I worked on a long time ago. It makes a lot of sense, but may require quite a bit of changes. (Or maybe not?)
I think the actual contig index is needed earlier than at the time when writing out the SAM record, but that’s not a problem because the binary search is probably very fast. For example, we would need to avoid that an alignment extends from one contig into another. That could be done at the seed or extend stage, but either way, one would need to know where the boundary to the next contig is.
Maybe we could add a couple of N characters between the contigs to at least prevent randstrobes from spanning across contigs.
BTW, I think a better way to think about the "reference chr_id and packed seed offset in 4 bytes and chromosome position in 4bytes." data structure (currently called RefRandstrobe) is to say that it consists of three fielsds, a 24-bit chromosome id, an 8-bit seed offset, and a 32-bit chromosome position. The fact that this is actually somehow packed into two 32-bit fields is an implementation detail. There’s even C syntax for bitfields which would make this even clearer in the code. (But I haven’t gotten around to send in a PR for that.)
The extra hash table for the "next hash offset" sounds good.

Great. Thanks for feedback. Will note it down as a potential thing to try.

It's funny, I came to ask how strobealign will work with collections of many genomes (we have an immediate application). That would completely not work with this optimization!

Good point. This optimization would definitely need to be made optional. We regulaly test on rye, for example, which is already larger than $2^{32}$ bp (6 Gbp).

Agreed, perhaps the same idea/approach could be used with 64bit ints, or template depending on reference database size?

The way we store randstrobes has changed since this issue was opened, but the idea could still be relevant. Here’s an additional point to consider in case this is ever implemented.
The elements of the randstrobes vector are RefRandstrobe structs that have a size of 16 bytes. As a consequence of C/C++ alignment requirements, we would still need 16 bytes even if the size of that struct was reduced to 12 bytes (because the 8-byte hash value needs to start at a memory address divisible by 8). This can be changed with compiler #pragmas (but not all CPUs support unaligned memory accesses) or manually by splitting the hash value up into two 32-bit values.


New package: FiniteDifferences v0.7.0

Registering package: FiniteDifferences
Repository: https://github.com/JuliaDiff/FiniteDifferences.jl
Created by: @nickrobinson251
Version: v0.7.0
Commit: 25491aee9f8ce7a743c3c66b696d3be5727f2daf
Reviewed by: @nickrobinson251
Reference: https://github.com/JuliaDiff/FiniteDifferences.jl/commit/25491aee9f8ce7a743c3c66b696d3be5727f2daf#commitcomment-34591293

This is being registered as new package because there was no concensus on how else to reanme a package (invenia/FDM.jl -> JuliaDiff/FiniteDifferences.jl)
The version number is 0.7 because it continues the version numbering from FDM (https://github.com/JuliaDiff/FiniteDifferences.jl/releases)
Please let me know if anything else needs doing :)

Note: this replaces https://github.com/JuliaRegistries/General/pull/2438
because according to @KristofferC  that can't work


Add sts dependency to fs2-aws-s3

Added sts dependency to fs2-aws-s3
We widely use assume roles when performing s3 operations. So far, we have manually added the sts library to our project dependencies but it would be nice if it comes within this library so we don't need to worry about aws client versions.
What's the rationale for sts being part of some of the modules and not all of them as a fs2-aws-core dependency?

hello. I tend to keep the dependencies at a minimum. in fact, not every client needs sts. i would refrain from adding sts to this library

Hi,
Keeping dependencies to the minimum looks great. However, AFAIK sts is a cross feature for whoever wants to use temporary credentials to access AWS resources. Checking other libraries generated from this project, both
https://github.com/laserdisc-io/fs2-aws/blob/0a3ddb7bca43bdd117bd05367b6bdf315bf16a0a/build.sbt#L158 and https://github.com/laserdisc-io/fs2-aws/blob/0a3ddb7bca43bdd117bd05367b6bdf315bf16a0a/build.sbt#L176 include the sts dependency while assuming roles is not strictly needed for their usage (please correct me if I'm wrong).
What would be the thumbs up rule, as users, to know when we'll find the sts library as part of the package?
thanks

#921


Add wayland primary selection support

Fixes https://github.com/jwilm/alacritty/issues/2510
Adds wayland primary selection support through the primary selection protocol
Hopefully if this PR seems to work for people then I can merge https://github.com/Smithay/smithay-clipboard/pull/4 and release smithay-clipboard 0.3v. Right now it links to the smithay clipboard primary branch and trimental/rust-clipboard

Selecting to copy and middle-clicking to paste works as expected. Is there anything else I should test?

@cole-h Does it work both between Alacritty instances and between Alacritty and a third-party app?

@chrisduerr Middle-click to paste doesn't work in a third-party app (I tested using Firefox, Evolution, and Cantata, all on Wayland) but Ctrl-V does paste the selection.

@cole-h It looks like trimental has swapped the implementations of primary and secondary around here. Does this work if you swap them?

diff --git a/alacritty_terminal/src/clipboard.rs b/alacritty_terminal/src/clipboard.rs
index 0904e819..1c2427f9 100644
--- a/alacritty_terminal/src/clipboard.rs
+++ b/alacritty_terminal/src/clipboard.rs
@@ -39,8 +39,8 @@ impl Clipboard {
     pub fn new(display: Option<*mut c_void>) -> Self {
         if let Some(display) = display {
             return Self {
-                primary: unsafe { Box::new(PrimaryWaylandClipboardContext::new_from_external(display)) },
-                secondary: unsafe { Some(Box::new(WaylandClipboardContext::new_from_external(display))) },
+                primary: unsafe { Box::new(WaylandClipboardContext::new_from_external(display)) },
+                secondary: unsafe { Some(Box::new(PrimaryWaylandClipboardContext::new_from_external(display))) },
             };
         }

If the above diff is what you meant: middle-clicking still does not work between Alacritty and third-party apps, but still works between three Alacritty instances (one running master, and two running this patch).

@trimental I've tried to make some bigger changes, moving the rust-clipboard crate into Alacritty to make it easier to contribute. Judging by the activity of the crate I don't expect our changes to get merged in the near future.
I've also cleaned up the implementation of the rust-clipboard trait for Wayland a bit, removing some unnecessary duplication and making it more similar to X11.
You can find that here: https://github.com/chrisduerr/alacritty/tree/clipboard-fork
If you disagree with any decisions, let me know. Otherwise it would probably be best to change this PR to my fork.

@chrisduerr agreed. I've release smithay-clipboard 0.3.0v so if you update your fork to that version I think that it should be in a mergable state as long as there's no bugs discovered :)

I've created a follow-up PR here: https://github.com/jwilm/alacritty/pull/2519


Add extraDeps for Binding.scala

This should close https://github.com/scalafiddle/scalafiddle-core/issues/10

What if I want to change the artifact from dom to binding, and turn dom into extraDeps?

You can add deps to previous versions. I assume in this case the dom dep actually pulled in binding too? So it's ok to change the main dep to binding and then add dom as the extraDep.

Actually, dom depends on binding. Does that matter?

It works as expected as this is just as you would do in SBT. You need to define the minimum set of libs and their deps are pulled in automatically.

Hi @ochrons , I have added 9.0.0 back. Could you review PR this again?

@ochrons You are right.
Now I fixed it.


Example test case for testing speech detection TF-lite model

Hi All,
I am trying to port my speech detection TF lite model on arm-NN for CPU acceleration.
But unfortunately there is no existing example test case on v21.05 that could be modified for testing/profiling my speech detection model.
Could anyone point me to a test case that use any speech detection TF-lite model?
Thanks

Hi @supratimc239
You can run tflite models with ArmNN's ExecuteNetwork and use the -e option enable the profiler.
Please see https://github.com/ARM-software/ComputeLibrary/issues/950
Have you tried running your model with ExecuteNetwork?

Hi @morgolock ,
Thank you very much for your response. I could see that the vision.py tool provides a very good insight about kernels while executing a mode.
The model I am working on takes as input a ".wav" file and provides txt output. Will the ExecuteNetwork work for such requirements?
If so, is there a test case similar TfLiteMnasNet-Armnn/TfLiteMnasNet-Armnn.cpp that could be used for testing my speech model?
Thanks

Hi @supratimc239,
We have a how-to-guide for speech recognition. Please see Perform Automatic Speech Recognition (ASR) with Wav2Letter using PyArmNN and Debian Packages Tutorial
Best Regards,
Sadik

Hi Sadik,
Thank you for your response. But this guide is not using Tflite model for ASR. Do you have guide for Tflite model of ASR?
Kind regards
Supratim

Hi Sadik,
Sorry for the late follow-up. I looked at the links you have sent and they seem to be relevant to python. I am trying to find a framework in C++ that will take input as .wav or any other format for getting raw speech data and after executing network provide output that will indicate if there is any voice activity on the received speech input.
Please let me know if there is any such example framework I could refer to for my implementation.
Kind regards
Supratim

@supratimc239 Here is the link to the same example above but the c++ version: https://github.com/ARM-software/armnn/tree/branches/armnn_22_02/samples/SpeechRecognition

Hi @TeresaARM ,
Yes I could use the ExecuteNetwork framework for executing my TF-lite model. Sorry for the late response.
Kind regards
Supratim

Hi @supratimc239
thank you to you!! I will close this ticket. Please let us know if you find any other difficulties.
Kind Regards


Address (most*) golint issues

Silence all complaints when golint ./... is run, except for those caused by generated gRPC code in rpc.pb.go, as well as the OP_CHECKSEQUENCEVERIFY opcode in script_utils.go
Fixed:
peer.go:58:2: struct field peerId should be peerID
rpcserver.go:36:6: func newRpcServer should be newRPCServer
server.go:145:10: var remoteId should be remoteID
chainntfs/chainntfs.go:5:1: comment on exported type ChainNotifier should be of the form "ChainNotifier ..." (with optional leading article)
chainntfs/chainntfs.go:22:6: exported type NotificationTrigger should have comment or be unexported
chainntfs/btcdnotify/btcd.go:15:1: comment on exported type BtcdNotifier should be of the form "BtcdNotifier ..." (with optional leading article)
chainntfs/btcdnotify/btcd.go:40:1: comment on exported function NewBtcdNotifier should be of the form "NewBtcdNotifier ..."
chainntfs/btcdnotify/btcd.go:60:1: comment on exported method BtcdNotifier.Start should be of the form "Start ..."
chainntfs/btcdnotify/btcd.go:74:1: comment on exported method BtcdNotifier.Stop should be of the form "Stop ..."
chainntfs/btcdnotify/btcd.go:216:1: comment on exported method BtcdNotifier.RegisterSpendNotification should be of the form "RegisterSpendNotification ..."
chainntfs/btcdnotify/btcd.go:233:1: comment on exported method BtcdNotifier.RegisterConfirmationsNotification should be of the form "RegisterConfirmationsNotification ..."
chainntfs/btcdnotify/source.go:8:1: comment on exported type ChainConnection should be of the form "ChainConnection ..." (with optional leading article)
channeldb/channel.go:26:2: comment on exported var ActiveNetParams should be of the form "ActiveNetParams ..."
channeldb/channel.go:30:1: comment on exported type Payment should be of the form "Payment ..." (with optional leading article)
channeldb/channel.go:36:1: comment on exported type ClosedChannel should be of the form "ClosedChannel ..." (with optional leading article)
channeldb/channel.go:40:1: comment on exported type OpenChannel should be of the form "OpenChannel ..." (with optional leading article)
channeldb/channel.go:100:1: comment on exported method DB.PutIdKey should be of the form "PutIdKey ..."
channeldb/channel.go:102:14: func PutIdKey should be PutIDKey
channeldb/channel.go:111:1: comment on exported method DB.GetIdAdr should be of the form "GetIdAdr ..."
channeldb/channel.go:112:14: func GetIdAdr should be GetIDAdr
channeldb/channel.go:128:1: comment on exported method DB.PutOpenChannel should be of the form "PutOpenChannel ..."
channeldb/channel.go:143:1: comment on exported method DB.FetchOpenChannel should be of the form "FetchOpenChannel ..."
channeldb/channel.go:218:1: comment on exported method OpenChannel.Encode should be of the form "Encode ..."
channeldb/channel.go:309:1: comment on exported method OpenChannel.Decode should be of the form "Decode ..."
channeldb/db.go:20:1: comment on exported type DB should be of the form "DB ..." (with optional leading article)
channeldb/db.go:29:1: comment on exported method DB.Wipe should be of the form "Wipe ..."
channeldb/db.go:38:1: comment on exported function New should be of the form "New ..."
channeldb/db.go:45:1: comment on exported function Open should be of the form "Open ..."
channeldb/db.go:51:1: comment on exported function Create should be of the form "Create ..."
cmd/lncli/commands.go:13:6: func printRespJson should be printRespJSON
cmd/lncli/commands.go:24:5: exported var ShellCommand should have comment or be unexported
cmd/lncli/commands.go:32:5: exported var NewAddressCommand should have comment or be unexported
cmd/lncli/commands.go:50:5: exported var SendManyCommand should have comment or be unexported
cmd/lncli/commands.go:76:5: exported var ConnectCommand should have comment or be unexported
cmd/lnshell/commands.go:11:1: comment on exported function RpcConnect should be of the form "RpcConnect ..."
cmd/lnshell/commands.go:12:6: func RpcConnect should be RPCConnect
cmd/lnshell/commands.go:41:1: exported function LnConnect should have comment or be unexported
cmd/lnshell/lnshellmain.go:56:1: exported function Shellparse should have comment or be unexported
elkrem/elkrem.go:37:1: comment on exported type ElkremNode should be of the form "ElkremNode ..." (with optional leading article)
elkrem/elkrem.go:39:6: type name will be used as elkrem.ElkremNode by other packages, and that stutters; consider calling this Node
elkrem/elkrem.go:44:6: exported type ElkremSender should have comment or be unexported
elkrem/elkrem.go:44:6: type name will be used as elkrem.ElkremSender by other packages, and that stutters; consider calling this Sender
elkrem/elkrem.go:50:6: exported type ElkremReceiver should have comment or be unexported
elkrem/elkrem.go:50:6: type name will be used as elkrem.ElkremReceiver by other packages, and that stutters; consider calling this Receiver
elkrem/elkrem.go:56:1: exported function LeftSha should have comment or be unexported
elkrem/elkrem.go:59:1: exported function RightSha should have comment or be unexported
elkrem/elkrem.go:85:1: comment on exported function NewElkremSender should be of the form "NewElkremSender ..."
elkrem/elkrem.go:98:1: comment on exported function NewElkremReceiver should be of the form "NewElkremReceiver ..."
elkrem/elkrem.go:105:1: comment on exported method ElkremSender.Next should be of the form "Next ..."
elkrem/elkrem.go:112:1: comment on exported method ElkremSender.AtIndex should be of the form "AtIndex ..."
elkrem/elkrem.go:118:1: exported method ElkremReceiver.AddNext should have comment or be unexported
elkrem/elkrem.go:143:1: exported method ElkremReceiver.AtIndex should have comment or be unexported
lndc/conn.go:18:1: comment on exported type LNDConn should be of the form "LNDConn ..." (with optional leading article)
lndc/conn.go:49:1: comment on exported function NewConn should be of the form "NewConn ..."
lndc/conn.go:54:1: comment on exported method LNDConn.Dial should be of the form "Dial ..."
lndc/conn.go:56:2: method parameter myId should be myID
lndc/conn.go:56:42: method parameter remoteId should be remoteID
lndc/conn.go:150:2: method parameter myId should be myID
lndc/conn.go:199:2: method parameter myId should be myID
lndc/listener.go:14:1: comment on exported type Listener should be of the form "Listener ..." (with optional leading article)
lndc/listener.go:23:1: comment on exported function NewListener should be of the form "NewListener ..."
lndc/listener.go:118:2: method parameter myId should be myID
lndc/lnadr.go:14:1: comment on exported type LNAdr should be of the form "LNAdr ..." (with optional leading article)
lndc/lnadr.go:16:2: struct field lnId should be lnID
lndc/lnadr.go:28:6: var encodedId should be encodedID
lndc/lnadr.go:38:1: comment on exported function LnAddrFromString should be of the form "LnAddrFromString ..."
lnstate/lnstate.go:45:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:45:2: exported const MAX_STAGED_HTLCS should have comment (or a comment on this block) or be unexported
lnstate/lnstate.go:46:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:47:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:72:2: comment on exported const ADD_PRESTAGE should be of the form "ADD_PRESTAGE ..."
lnstate/lnstate.go:73:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:74:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:75:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:76:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:77:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:79:2: comment on exported const TIMEOUT_PRESTAGE should be of the form "TIMEOUT_PRESTAGE ..."
lnstate/lnstate.go:80:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:81:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:82:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:83:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:85:2: comment on exported const SETTLE_PRESTAGE should be of the form "SETTLE_PRESTAGE ..."
lnstate/lnstate.go:86:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:87:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:88:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:89:2: don't use ALL_CAPS in Go names; use CamelCase
lnstate/lnstate.go:101:6: exported type LNChannel should have comment or be unexported
lnstate/lnstate.go:150:6: exported type PaymentDescriptor should have comment or be unexported
lnstate/lnstate.go:201:4: should replace l.ourLastKey += 1 with l.ourLastKey++
lnstate/lnstate.go:205:4: should replace l.ourLastKey += 1 with l.ourLastKey++
lnstate/lnstate.go:216:1: exported method LNChannel.CreateHTLC should have comment or be unexported
lnstate/lnstate.go:225:21: error strings should not end with punctuation
lnwallet/channel.go:19:2: comment on exported const MaxPendingPayments should be of the form "MaxPendingPayments ..."
lnwallet/channel.go:28:1: comment on exported type LightningChannel should be of the form "LightningChannel ..." (with optional leading article)
lnwallet/channel.go:83:2: var fundingTxId should be fundingTxID
lnwallet/channel.go:95:1: comment on exported type PaymentDescriptor should be of the form "PaymentDescriptor ..." (with optional leading article)
lnwallet/channel.go:107:1: comment on exported type ChannelUpdate should be of the form "ChannelUpdate ..." (with optional leading article)
lnwallet/channel.go:127:1: comment on exported method ChannelUpdate.RevocationHash should be of the form "RevocationHash ..."
lnwallet/channel.go:141:1: comment on exported method ChannelUpdate.SignCounterPartyCommitment should be of the form "SignCounterPartyCommitment ..."
lnwallet/channel.go:163:1: comment on exported method ChannelUpdate.PreviousRevocationPreImage should be of the form "PreviousRevocationPreImage ..."
lnwallet/channel.go:179:1: comment on exported method ChannelUpdate.VerifyNewCommitmentSigs should be of the form "VerifyNewCommitmentSigs ..."
lnwallet/channel.go:219:1: comment on exported method ChannelUpdate.Commit should be of the form "Commit ..."
lnwallet/channel.go:266:1: comment on exported method LightningChannel.AddHTLC should be of the form "AddHTLC ..."
lnwallet/channel.go:420:1: comment on exported method LightningChannel.SettleHTLC should be of the form "SettleHTLC ..."
lnwallet/channel.go:525:1: comment on exported method LightningChannel.CancelHTLC should be of the form "CancelHTLC ..."
lnwallet/channel.go:530:1: comment on exported method LightningChannel.OurBalance should be of the form "OurBalance ..."
lnwallet/channel.go:537:1: comment on exported method LightningChannel.TheirBalance should be of the form "TheirBalance ..."
lnwallet/channel.go:544:1: comment on exported method LightningChannel.ForceClose should be of the form "ForceClose ..."
lnwallet/channel.go:549:1: comment on exported method LightningChannel.RequestPayment should be of the form "RequestPayment ..."
lnwallet/channel.go:555:1: comment on exported type PaymentRequest should be of the form "PaymentRequest ..." (with optional leading article)
lnwallet/config.go:32:1: comment on exported type Config should be of the form "Config ..." (with optional leading article)
lnwallet/config.go:39:2: struct field RpcHost should be RPCHost
lnwallet/config.go:40:2: struct field RpcUser should be RPCUser
lnwallet/config.go:41:2: struct field RpcPass should be RPCPass
lnwallet/reservation.go:157:1: comment on exported method ChannelReservation.ProcessContribution should be of the form "ProcessContribution ..."
lnwallet/reservation.go:200:1: comment on exported method ChannelReservation.CompleteReservation should be of the form "CompleteReservation ..."
lnwallet/reservation.go:227:1: comment on exported method ChannelReservation.TheirSignatures should be of the form "TheirSignatures ..."
lnwallet/script_utils.go:14:2: comment on exported var SequenceLockTimeSeconds should be of the form "SequenceLockTimeSeconds ..."
lnwallet/script_utils.go:17:2: exported var SequenceLockTimeMask should have comment or be unexported
lnwallet/setup.go:37:2: a blank import should be only in a main or test package, or have a comment justifying it
lnwallet/wallet.go:40:2: comment on exported var ErrInsufficientFunds should be of the form "ErrInsufficientFunds ..."
lnwallet/wallet.go:44:2: comment on exported var ActiveNetParams should be of the form "ActiveNetParams ..."
lnwallet/wallet.go:64:2: comment on exported const SEGWIT should be of the form "SEGWIT ..."
lnwallet/wallet.go:67:2: comment on exported const SIGHASH should be of the form "SIGHASH ..."
lnwallet/wallet.go:70:2: comment on exported const CSV should be of the form "CSV ..."
lnwallet/wallet.go:73:2: comment on exported const CSV_RESERVE should be of the form "CSV_RESERVE ..."
lnwallet/wallet.go:75:2: don't use ALL_CAPS in Go names; use CamelCase
lnwallet/wallet.go:77:2: comment on exported const CLTV_RESERVE should be of the form "CLTV_RESERVE ..."
lnwallet/wallet.go:78:2: don't use ALL_CAPS in Go names; use CamelCase
lnwallet/wallet_test.go:100:9: should omit 2nd value from range; this loop is equivalent to `for i := range ...`
lnwire/close_complete.go:11:6: exported type CloseComplete should have comment or be unexported
lnwire/close_complete.go:18:1: exported method CloseComplete.Decode should have comment or be unexported
lnwire/close_complete.go:34:1: comment on exported function NewCloseComplete should be of the form "NewCloseComplete ..."
lnwire/close_complete.go:39:1: comment on exported method CloseComplete.Encode should be of the form "Encode ..."
lnwire/close_complete.go:56:1: exported method CloseComplete.Command should have comment or be unexported
lnwire/close_complete.go:60:1: exported method CloseComplete.MaxPayloadLength should have comment or be unexported
lnwire/close_complete.go:65:1: comment on exported method CloseComplete.Validate should be of the form "Validate ..."
lnwire/close_request.go:11:6: exported type CloseRequest should have comment or be unexported
lnwire/close_request.go:18:1: exported method CloseRequest.Decode should have comment or be unexported
lnwire/close_request.go:34:1: comment on exported function NewCloseRequest should be of the form "NewCloseRequest ..."
lnwire/close_request.go:39:1: comment on exported method CloseRequest.Encode should be of the form "Encode ..."
lnwire/close_request.go:56:1: exported method CloseRequest.Command should have comment or be unexported
lnwire/close_request.go:60:1: exported method CloseRequest.MaxPayloadLength should have comment or be unexported
lnwire/close_request.go:65:1: comment on exported method CloseRequest.Validate should be of the form "Validate ..."
lnwire/commit_revocation.go:8:1: comment on exported type CommitRevocation should be of the form "CommitRevocation ..." (with optional leading article)
lnwire/commit_revocation.go:26:1: exported method CommitRevocation.Decode should have comment or be unexported
lnwire/commit_revocation.go:42:1: comment on exported function NewCommitRevocation should be of the form "NewCommitRevocation ..."
lnwire/commit_revocation.go:47:1: comment on exported method CommitRevocation.Encode should be of the form "Encode ..."
lnwire/commit_revocation.go:62:1: exported method CommitRevocation.Command should have comment or be unexported
lnwire/commit_revocation.go:66:1: exported method CommitRevocation.MaxPayloadLength should have comment or be unexported
lnwire/commit_revocation.go:70:1: comment on exported method CommitRevocation.Validate should be of the form "Validate ..."
lnwire/commit_signature.go:10:1: comment on exported type CommitSignature should be of the form "CommitSignature ..." (with optional leading article)
lnwire/commit_signature.go:37:1: exported method CommitSignature.Decode should have comment or be unexported
lnwire/commit_signature.go:59:1: comment on exported function NewCommitSignature should be of the form "NewCommitSignature ..."
lnwire/commit_signature.go:64:1: comment on exported method CommitSignature.Encode should be of the form "Encode ..."
lnwire/commit_signature.go:82:1: exported method CommitSignature.Command should have comment or be unexported
lnwire/commit_signature.go:86:1: exported method CommitSignature.MaxPayloadLength should have comment or be unexported
lnwire/commit_signature.go:90:1: comment on exported method CommitSignature.Validate should be of the form "Validate ..."
lnwire/error_generic.go:8:1: comment on exported type ErrorGeneric should be of the form "ErrorGeneric ..." (with optional leading article)
lnwire/error_generic.go:18:1: exported method ErrorGeneric.Decode should have comment or be unexported
lnwire/error_generic.go:32:1: comment on exported function NewErrorGeneric should be of the form "NewErrorGeneric ..."
lnwire/error_generic.go:37:1: comment on exported method ErrorGeneric.Encode should be of the form "Encode ..."
lnwire/error_generic.go:51:1: exported method ErrorGeneric.Command should have comment or be unexported
lnwire/error_generic.go:55:1: exported method ErrorGeneric.MaxPayloadLength should have comment or be unexported
lnwire/error_generic.go:60:1: comment on exported method ErrorGeneric.Validate should be of the form "Validate ..."
lnwire/funding_request.go:11:6: exported type FundingRequest should have comment or be unexported
lnwire/funding_request.go:56:1: exported method FundingRequest.Decode should have comment or be unexported
lnwire/funding_request.go:99:1: comment on exported function NewFundingRequest should be of the form "NewFundingRequest ..."
lnwire/funding_request.go:104:1: comment on exported method FundingRequest.Encode should be of the form "Encode ..."
lnwire/funding_request.go:142:1: exported method FundingRequest.Command should have comment or be unexported
lnwire/funding_request.go:146:1: exported method FundingRequest.MaxPayloadLength should have comment or be unexported
lnwire/funding_request.go:151:1: comment on exported method FundingRequest.Validate should be of the form "Validate ..."
lnwire/funding_response.go:11:6: exported type FundingResponse should have comment or be unexported
lnwire/funding_response.go:41:1: exported method FundingResponse.Decode should have comment or be unexported
lnwire/funding_response.go:83:1: comment on exported function NewFundingResponse should be of the form "NewFundingResponse ..."
lnwire/funding_response.go:88:1: comment on exported method FundingResponse.Encode should be of the form "Encode ..."
lnwire/funding_response.go:126:1: exported method FundingResponse.Command should have comment or be unexported
lnwire/funding_response.go:130:1: exported method FundingResponse.MaxPayloadLength should have comment or be unexported
lnwire/funding_response.go:135:1: comment on exported method FundingResponse.Validate should be of the form "Validate ..."
lnwire/funding_signaccept.go:9:6: exported type FundingSignAccept should have comment or be unexported
lnwire/funding_signaccept.go:16:1: exported method FundingSignAccept.Decode should have comment or be unexported
lnwire/funding_signaccept.go:35:1: comment on exported function NewFundingSignAccept should be of the form "NewFundingSignAccept ..."
lnwire/funding_signaccept.go:40:1: comment on exported method FundingSignAccept.Encode should be of the form "Encode ..."
lnwire/funding_signaccept.go:57:1: exported method FundingSignAccept.Command should have comment or be unexported
lnwire/funding_signaccept.go:61:1: exported method FundingSignAccept.MaxPayloadLength should have comment or be unexported
lnwire/funding_signaccept.go:66:1: comment on exported method FundingSignAccept.Validate should be of the form "Validate ..."
lnwire/funding_signcomplete.go:10:6: exported type FundingSignComplete should have comment or be unexported
lnwire/funding_signcomplete.go:17:1: exported method FundingSignComplete.Decode should have comment or be unexported
lnwire/funding_signcomplete.go:35:1: comment on exported function NewFundingSignComplete should be of the form "NewFundingSignComplete ..."
lnwire/funding_signcomplete.go:40:1: comment on exported method FundingSignComplete.Encode should be of the form "Encode ..."
lnwire/funding_signcomplete.go:54:1: exported method FundingSignComplete.Command should have comment or be unexported
lnwire/funding_signcomplete.go:58:1: exported method FundingSignComplete.MaxPayloadLength should have comment or be unexported
lnwire/funding_signcomplete.go:63:1: comment on exported method FundingSignComplete.Validate should be of the form "Validate ..."
lnwire/htlc_addaccept.go:8:6: exported type HTLCAddAccept should have comment or be unexported
lnwire/htlc_addaccept.go:13:1: exported method HTLCAddAccept.Decode should have comment or be unexported
lnwire/htlc_addaccept.go:27:1: comment on exported function NewHTLCAddAccept should be of the form "NewHTLCAddAccept ..."
lnwire/htlc_addaccept.go:32:1: comment on exported method HTLCAddAccept.Encode should be of the form "Encode ..."
lnwire/htlc_addaccept.go:47:1: exported method HTLCAddAccept.Command should have comment or be unexported
lnwire/htlc_addaccept.go:51:1: exported method HTLCAddAccept.MaxPayloadLength should have comment or be unexported
lnwire/htlc_addaccept.go:56:1: comment on exported method HTLCAddAccept.Validate should be of the form "Validate ..."
lnwire/htlc_addreject.go:8:6: exported type HTLCAddReject should have comment or be unexported
lnwire/htlc_addreject.go:13:1: exported method HTLCAddReject.Decode should have comment or be unexported
lnwire/htlc_addreject.go:30:1: comment on exported function NewHTLCAddReject should be of the form "NewHTLCAddReject ..."
lnwire/htlc_addreject.go:35:1: comment on exported method HTLCAddReject.Encode should be of the form "Encode ..."
lnwire/htlc_addreject.go:50:1: exported method HTLCAddReject.Command should have comment or be unexported
lnwire/htlc_addreject.go:54:1: exported method HTLCAddReject.MaxPayloadLength should have comment or be unexported
lnwire/htlc_addreject.go:59:1: comment on exported method HTLCAddReject.Validate should be of the form "Validate ..."
lnwire/htlc_addrequest.go:8:1: comment on exported type HTLCAddRequest should be of the form "HTLCAddRequest ..." (with optional leading article)
lnwire/htlc_addrequest.go:40:1: exported method HTLCAddRequest.Decode should have comment or be unexported
lnwire/htlc_addrequest.go:64:1: comment on exported function NewHTLCAddRequest should be of the form "NewHTLCAddRequest ..."
lnwire/htlc_addrequest.go:69:1: comment on exported method HTLCAddRequest.Encode should be of the form "Encode ..."
lnwire/htlc_addrequest.go:88:1: exported method HTLCAddRequest.Command should have comment or be unexported
lnwire/htlc_addrequest.go:92:1: exported method HTLCAddRequest.MaxPayloadLength should have comment or be unexported
lnwire/htlc_addrequest.go:98:1: comment on exported method HTLCAddRequest.Validate should be of the form "Validate ..."
lnwire/htlc_settleaccept.go:8:1: comment on exported type HTLCSettleAccept should be of the form "HTLCSettleAccept ..." (with optional leading article)
lnwire/htlc_settleaccept.go:18:1: exported method HTLCSettleAccept.Decode should have comment or be unexported
lnwire/htlc_settleaccept.go:32:1: comment on exported function NewHTLCSettleAccept should be of the form "NewHTLCSettleAccept ..."
lnwire/htlc_settleaccept.go:37:1: comment on exported method HTLCSettleAccept.Encode should be of the form "Encode ..."
lnwire/htlc_settleaccept.go:51:1: exported method HTLCSettleAccept.Command should have comment or be unexported
lnwire/htlc_settleaccept.go:55:1: exported method HTLCSettleAccept.MaxPayloadLength should have comment or be unexported
lnwire/htlc_settleaccept.go:60:1: comment on exported method HTLCSettleAccept.Validate should be of the form "Validate ..."
lnwire/htlc_settlerequest.go:8:1: comment on exported type HTLCSettleRequest should be of the form "HTLCSettleRequest ..." (with optional leading article)
lnwire/htlc_settlerequest.go:21:1: exported method HTLCSettleRequest.Decode should have comment or be unexported
lnwire/htlc_settlerequest.go:42:1: comment on exported function NewHTLCSettleRequest should be of the form "NewHTLCSettleRequest ..."
lnwire/htlc_settlerequest.go:47:1: comment on exported method HTLCSettleRequest.Encode should be of the form "Encode ..."
lnwire/htlc_settlerequest.go:62:1: exported method HTLCSettleRequest.Command should have comment or be unexported
lnwire/htlc_settlerequest.go:66:1: exported method HTLCSettleRequest.MaxPayloadLength should have comment or be unexported
lnwire/htlc_settlerequest.go:71:1: comment on exported method HTLCSettleRequest.Validate should be of the form "Validate ..."
lnwire/htlc_timeoutaccept.go:8:1: comment on exported type HTLCTimeoutAccept should be of the form "HTLCTimeoutAccept ..." (with optional leading article)
lnwire/htlc_timeoutaccept.go:18:1: exported method HTLCTimeoutAccept.Decode should have comment or be unexported
lnwire/htlc_timeoutaccept.go:32:1: comment on exported function NewHTLCTimeoutAccept should be of the form "NewHTLCTimeoutAccept ..."
lnwire/htlc_timeoutaccept.go:37:1: comment on exported method HTLCTimeoutAccept.Encode should be of the form "Encode ..."
lnwire/htlc_timeoutaccept.go:51:1: exported method HTLCTimeoutAccept.Command should have comment or be unexported
lnwire/htlc_timeoutaccept.go:55:1: exported method HTLCTimeoutAccept.MaxPayloadLength should have comment or be unexported
lnwire/htlc_timeoutaccept.go:60:1: comment on exported method HTLCTimeoutAccept.Validate should be of the form "Validate ..."
lnwire/htlc_timeoutrequest.go:8:1: comment on exported type HTLCTimeoutRequest should be of the form "HTLCTimeoutRequest ..." (with optional leading article)
lnwire/htlc_timeoutrequest.go:18:1: exported method HTLCTimeoutRequest.Decode should have comment or be unexported
lnwire/htlc_timeoutrequest.go:32:1: comment on exported function NewHTLCTimeoutRequest should be of the form "NewHTLCTimeoutRequest ..."
lnwire/htlc_timeoutrequest.go:37:1: comment on exported method HTLCTimeoutRequest.Encode should be of the form "Encode ..."
lnwire/htlc_timeoutrequest.go:51:1: exported method HTLCTimeoutRequest.Command should have comment or be unexported
lnwire/htlc_timeoutrequest.go:55:1: exported method HTLCTimeoutRequest.MaxPayloadLength should have comment or be unexported
lnwire/htlc_timeoutrequest.go:60:1: comment on exported method HTLCTimeoutRequest.Validate should be of the form "Validate ..."
lnwire/lnwire.go:14:5: don't use ALL_CAPS in Go names; use CamelCase
lnwire/lnwire.go:14:5: exported var MAX_SLICE_LENGTH should have comment or be unexported
lnwire/lnwire.go:16:1: comment on exported type PkScript should be of the form "PkScript ..." (with optional leading article)
lnwire/lnwire.go:19:6: exported type HTLCKey should have comment or be unexported
lnwire/lnwire.go:20:6: exported type CommitHeight should have comment or be unexported
lnwire/lnwire.go:22:1: comment on exported type CreditsAmount should be of the form "CreditsAmount ..." (with optional leading article)
lnwire/lnwire.go:440:22: error strings should not end with punctuation
lnwire/lnwire.go:502:22: error strings should not end with punctuation
lnwire/lnwire.go:524:22: error strings should not end with punctuation
lnwire/lnwire.go:538:22: error strings should not end with punctuation
lnwire/lnwire.go:606:1: comment on exported function ValidatePkScript should be of the form "ValidatePkScript ..."
lnwire/lnwire_test.go:19:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:1:1: package comment should be of the form "Package lnwire ..."
lnwire/message.go:14:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:15:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:17:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:18:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:20:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:22:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:23:2: don't use ALL_CAPS in Go names; use CamelCase
lnwire/message.go:29:7: exported const MaxMessagePayload should have comment or be unexported
lnwire/message.go:32:2: comment on exported const CmdFundingRequest should be of the form "CmdFundingRequest ..."
lnwire/message.go:34:2: exported const CmdFundingResponse should have comment (or a comment on this block) or be unexported
lnwire/message.go:38:2: comment on exported const CmdCloseRequest should be of the form "CmdCloseRequest ..."
lnwire/message.go:42:2: comment on exported const CmdHTLCAddRequest should be of the form "CmdHTLCAddRequest ..."
lnwire/message.go:48:2: comment on exported const CmdHTLCSettleRequest should be of the form "CmdHTLCSettleRequest ..."
lnwire/message.go:53:2: comment on exported const CmdHTLCTimeoutRequest should be of the form "CmdHTLCTimeoutRequest ..."
lnwire/message.go:57:2: comment on exported const CmdCommitSignature should be of the form "CmdCommitSignature ..."
lnwire/message.go:61:2: comment on exported const CmdErrorGeneric should be of the form "CmdErrorGeneric ..."
lnwire/message.go:65:1: comment on exported type Message should be of the form "Message ..." (with optional leading article)
lnwire/message.go:168:1: exported function WriteMessage should have comment or be unexported
lnwire/message.go:222:1: exported function ReadMessage should have comment or be unexported
lnwire/message.go:232:43: error strings should not end with punctuation
lnwire/message.go:253:43: error strings should not end with punctuation
shachain/shachain.go:25:1: comment on exported type HyperShaChain should be of the form "HyperShaChain ..." (with optional leading article)
shachain/shachain.go:38:1: comment on exported function New should be of the form "New ..."
shachain/shachain.go:44:1: comment on exported function NewFromSeed should be of the form "NewFromSeed ..."
shachain/shachain.go:98:1: comment on exported method HyperShaChain.GetHash should be of the form "GetHash ..."
shachain/shachain.go:117:1: comment on exported method HyperShaChain.AddNextHash should be of the form "AddNextHash ..."
shachain/shachain.go:147:1: comment on exported method HyperShaChain.CurrentPreImage should be of the form "CurrentPreImage ..."
shachain/shachain.go:154:1: comment on exported method HyperShaChain.CurrentRevocationHash should be of the form "CurrentRevocationHash ..."
shachain/shachain.go:162:1: comment on exported method HyperShaChain.LocatePreImage should be of the form "LocatePreImage ..."
shachain/shachain.go:173:1: comment on exported method HyperShaChain.Encode should be of the form "Encode ..."
shachain/shachain.go:178:1: comment on exported method HyperShaChain.Decode should be of the form "Decode ..."
uspv/eight333.go:19:2: comment on exported const NETVERSION should be of the form "NETVERSION ..."
uspv/eight333.go:22:2: exported const VERSION should have comment (or a comment on this block) or be unexported
uspv/eight333.go:29:6: exported type SPVCon should have comment or be unexported
uspv/eight333.go:48:1: exported method SPVCon.Open should have comment or be unexported
uspv/eight333.go:142:1: exported method SPVCon.PongBack should have comment or be unexported
uspv/eight333.go:149:1: exported method SPVCon.SendFilter should have comment or be unexported
uspv/eight333.go:154:1: exported method SPVCon.AskForHeaders should have comment or be unexported
uspv/eight333.go:197:1: exported method SPVCon.IngestHeaders should have comment or be unexported
uspv/eight333.go:277:1: exported method SPVCon.AskForMerkBlocks should have comment or be unexported
uspv/header.go:93:1: exported function CheckHeader should have comment or be unexported
uspv/header.go:182:1: comment on exported function CheckRange should be of the form "CheckRange ..."
uspv/mblock.go:9:1: exported function MakeMerkleParent should have comment or be unexported
uspv/txstore.go:13:6: exported type TxStore should have comment or be unexported
uspv/txstore.go:20:6: exported type Utxo should have comment or be unexported
uspv/txstore.go:28:6: exported type MyAdr should have comment or be unexported
uspv/txstore.go:33:1: comment on exported method TxStore.AddAdr should be of the form "AddAdr ..."
uspv/txstore.go:42:1: comment on exported method TxStore.AddTxid should be of the form "AddTxid ..."
uspv/txstore.go:51:1: comment on exported method TxStore.GimmeFilter should be of the form "GimmeFilter ..."
uspv/txstore.go:63:1: comment on exported method TxStore.IngestTx should be of the form "IngestTx ..."
uspv/txstore.go:89:1: comment on exported method TxStore.AbsorbTx should be of the form "AbsorbTx ..."
uspv/txstore.go:123:1: comment on exported method TxStore.ExpellTx should be of the form "ExpellTx ..."

Left as-is:
lnrpc/rpc.pb.go:35:6: exported type SendManyRequest should have comment or be unexported
lnrpc/rpc.pb.go:39:1: exported method SendManyRequest.Reset should have comment or be unexported
lnrpc/rpc.pb.go:41:1: exported method SendManyRequest.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:42:1: exported method SendManyRequest.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:44:1: exported method SendManyRequest.GetAddrToAmount should have comment or be unexported
lnrpc/rpc.pb.go:51:6: exported type SendManyResponse should have comment or be unexported
lnrpc/rpc.pb.go:55:1: exported method SendManyResponse.Reset should have comment or be unexported
lnrpc/rpc.pb.go:57:1: exported method SendManyResponse.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:58:1: exported method SendManyResponse.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:60:6: exported type NewAddressRequest should have comment or be unexported
lnrpc/rpc.pb.go:63:1: exported method NewAddressRequest.Reset should have comment or be unexported
lnrpc/rpc.pb.go:65:1: exported method NewAddressRequest.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:66:1: exported method NewAddressRequest.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:68:6: exported type NewAddressResponse should have comment or be unexported
lnrpc/rpc.pb.go:72:1: exported method NewAddressResponse.Reset should have comment or be unexported
lnrpc/rpc.pb.go:74:1: exported method NewAddressResponse.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:75:1: exported method NewAddressResponse.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:77:6: exported type ConnectPeerRequest should have comment or be unexported
lnrpc/rpc.pb.go:78:2: struct field IdAtHost should be IDAtHost
lnrpc/rpc.pb.go:81:1: exported method ConnectPeerRequest.Reset should have comment or be unexported
lnrpc/rpc.pb.go:83:1: exported method ConnectPeerRequest.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:84:1: exported method ConnectPeerRequest.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:86:6: exported type ConnectPeerResponse should have comment or be unexported
lnrpc/rpc.pb.go:90:1: exported method ConnectPeerResponse.Reset should have comment or be unexported
lnrpc/rpc.pb.go:92:1: exported method ConnectPeerResponse.ProtoMessage should have comment or be unexported
lnrpc/rpc.pb.go:93:1: exported method ConnectPeerResponse.Descriptor should have comment or be unexported
lnrpc/rpc.pb.go:110:6: exported type LightningClient should have comment or be unexported
lnrpc/rpc.pb.go:120:1: exported function NewLightningClient should have comment or be unexported
lnrpc/rpc.pb.go:153:6: exported type LightningServer should have comment or be unexported
lnrpc/rpc.pb.go:159:1: exported function RegisterLightningServer should have comment or be unexported
lnrpc/rpc.pb.go:163:6: don't use underscores in Go names; func _Lightning_SendMany_Handler should be _LightningSendManyHandler
lnrpc/rpc.pb.go:175:6: don't use underscores in Go names; func _Lightning_NewAddress_Handler should be _LightningNewAddressHandler
lnrpc/rpc.pb.go:187:6: don't use underscores in Go names; func _Lightning_ConnectPeer_Handler should be _LightningConnectPeerHandler
lnrpc/rpc.pb.go:199:5: don't use underscores in Go names; var _Lightning_serviceDesc should be _LightningServiceDesc

lnwallet/script_utils.go:18:2: don't use ALL_CAPS in Go names; use CamelCase

Hey Paul, thanks for another PR!
It's correct that all the golint errors generated by the auto-generated .pb.go files should be ignored. Additionally, the added alias to CSV in lnwallet/script_utils.go should be left alone as well.
Also, it's worth nothing that many of these lint errors exist, simply because much of the code in lnwire, and lnstate are in a draft stage, and unfinalized.
Could you rebase this to catch it up to the latest master? The merge may be a bit hairy as Tadge, and I have recently merged some development branches into master...

@Roasbeef I mostly wanted a good excuse to take a stroll through the whole lnd code base (and also wanted to perhaps help out in setting things up for some btcd-level documentation)... and, I personally hate the linter warnings I get when perusing files, so wanted to get rid of them as much as possible :)
I get that the lnd code base is gonna be in bigtime flux (obviously), happy to do new PR with updated lint fixes if it's not totally annoying for you guys to deal with right now—otherwise I'm completely cool with waiting till things settle down a bit more to push for better linting/docs ;)

Closing this out for now to avoid merge headache (when I get some free time I may go through lnd with golint again against the most recent master commit—would do so in a separate PR though).


feat: adding swiftlint

Lint consistency in iOS is a pain at the moment, and frankly we should have one uniform approach to stuff anyway. This PR adds the usage of Swiftlint, a popular linting tool for the code base. It adds it as a script to lint it from the JS side.
You need to have Swiftlint installed on your machine (updated the contributing guide) and can do it with:
brew install swiftlint

The ideal next step is probably a small github action that has Swiftlint, running it on PR commits.

Maybe it's a good idea to add this to pre-commit hook.

Not a huge fan of pre-commit hooks in general, but might be a good idea in this case. Give this comment a thumbs up and i will add it

End result:
1-Number of lines limitation is off for now, (frankly, i don't see us needing it enough to go through the hassle of enabling it, and it doesn't bring that much value with the amount of code we have)
2-Variable name limitation is off, doesn't make sense to limit our variable names
3-I addressed the force cast issue. @matinzd Please take a look at b91fb6e and let me know what you think. TS should stop them from ever making such a mistake, but frankly i rather be safe than sorry
4-I dealt with fall through by setting render mode automatic as the default case, along with any other garbled values that they might push through. The better way to do it is to make the value be an enum, not a string, but maybe that is something we can work on next? (The codegen type definitions are marking them as string for both this and the resizeMode, but based on https://github.com/reactwg/react-native-new-architecture/discussions/91#discussioncomment-5904287, we might be able to just give it a basic string union and expect it to work)
5- Much like number 1, i feel like while it helps improve readability, being too stringy with it is kind of dumb. The new rule set gives warnings at 300 lines and above for the size of the body, and at 400, it will turn into an error, asking the creator to refactor their code. I feel like we can test this for now and figure out along the way, but considering we can write extensions, i don't think it is that big of an issue

Agree with that
We don't need a lot of restrictions here
Have you tried testing color filters and text filters prop? Is it still working without an issue?
Enum is not possible for now. We can think of it later.

I separated two scripts one for linting and the other for fixing lint issues.


IExecutor current returns bare pointer to ITimer*, should it?

It would probably be safer to return std::shared_ptr.
Canceling a timer would then be idempotent, and the timer would remain in memory until all instances are released.

A timer lives for the duration of itself. A weak_ptr would be my first choice. But it makes sense to make it live while we still hold one, but it doesn't really make sense to cancel an already expired one... So why hold it in the first place?

weak_ptr is a good suggestion. This would allow the memory to be freed immediately after the timer fires or is canceled, but would turn a seg-fault into std::bad_weak_ptr if someone misuses the timer.
You would never intentionally hold onto a timer after it fires. I'm just looking to make the interface safer in case someone does do it.

I like that, +1

https://github.com/automatak/openpal/blob/master/cpp/libs/include/openpal/executor/Timer.h


The mature filter is not working

Description

Search for something setting the mature filter to true, e.g.: https://api-dev.openverse.engineering/v1/images/?q=car&mature=true
This returns items that have mature=false in them.
Additional context

The check for mature parameter being a boolean works correctly. When I use mature as the value for mature query parameter, it returns an error:
GET /v1/images/?q=car&mature=mature

HTTP 400 Bad Request
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept
{
    "detail": {
        "mature": [
            "Must be a valid boolean."
        ]
    }
}

Resolution

[ ] 🙋 I would be interested in resolving this bug.

Closing as won't do. mature is deprecated, and the include_sensitive_results has a much clearer name here (specifically, that it includes sensitive results, rather than only searches sensitive results).


Add a proposal for worker Pods in KMM

Add an enhancement proposal that addresses a number of pain points in the way KMM loads kernel modules in v1.
/cc @yevgeny-shnaidman @mresvanis @ybettan @hershpa

/hold

@yevgeny-shnaidman @mresvanis @ybettan @hershpa PTAL

Do we want to move to api/v2alpha1/ instead of api/v1beta1 as part of the change?

Do we want to move to api/v2alpha1/ instead of api/v1beta1 as part of the change?

Why? we are not changing the API.

LGTM
@ybettan if you are happy , then please lgtm

/lgtm

@qbarrand Can we unhold?

/unhold


No constraint on what a target should be => need to say this is implementation-dependent?

In the examples, the target may be a VOID data or a DCAT dataset. Yet there is no constraint here.
So how should a processor know whether the target is given by void:dataDump or dcat:downloadURL or anything else?
If this is implementation-dependent, then it should be stated explicitly.

I agree that a set of default descriptions would be good, but keeping it open as well.
Will make a proposal.


Removed rule no-else-return

The no else return rule can cause issues during refactoring.
It hides the fact of the else branch
It makes it difficult to write full expressions when more then two cases (ternary)

Can we force the inverse of the rule?

I can't find it, but it would be awesome:
https://eslint.org/docs/rules/
Maybe we should invest in it.


Changing from cat & weighting to "Categories Only" and back removes all set percentages

When "Categories & Weighting" have been set up, change the setting to "Categories Only" and save. Then switch back to "Categories & Weighting." The percentages have all reverted to 0, and the subtotal will still display as 100%:

Ideally, the old percentages would return. If that is not possible, the subtotal should display as 0%.

Confirmed!


Use a fork of Heroku's Ruby buildpack to work around Bundler issues

Heroku's Ruby buildpack sets the Bundler configuration BUNDLE_FROZEN=1.
While intended to prevent the app's Gemfile.lock from being modified,
this has the side effect of preventing Bump from using the Bundler gem
to generate new lockfiles as part of its process of bumping
dependencies.
This commit changes the default configuration to use a fork of Heroku's
buildpack which sets BUNDLE_FROZEN=0 at the end of the deployment
process.

@hmarr thoughts?

Is there any other way to do this without forking the standard buildpack?

If you discover one I'd be really interested to see it! Sadly the whole thing is a little bit of a hack because we're re-using the Bundler used to build the app inside the app itself, which is a weird thing to do.

Would it be enough to just set Bundler.settings[:frozen] to false when we boot bump? Seems like we shouldn't need to make this change at the buildpack level.

Think I tried that and it kept getting overridden. Worth double checking though

Superseded by https://github.com/gocardless/bump/pull/156


Update gRPC to 1.15.0

Codecov Report

Merging #582 into master will increase coverage by 0.83%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #582      +/-   ##
============================================
+ Coverage      74.2%   75.03%   +0.83%
- Complexity      905      935      +30
============================================
  Files           176      177       +1
  Lines          4047     4090      +43
  Branches        316      323       +7
============================================
+ Hits           3003     3069      +66
+ Misses          893      869      -24
- Partials        151      152       +1

Impacted Files
Coverage Δ
Complexity Δ

...api/gax/grpc/InstantiatingGrpcChannelProvider.java
65.38% <0%> (-9.81%)
26% <0%> (+1%)

...le/api/gax/retrying/ScheduledRetryingExecutor.java
92.3% <0%> (-7.7%)
3% <0%> (ø)

...va/com/google/api/gax/retrying/RetryAlgorithm.java
85.71% <0%> (-7.15%)
7% <0%> (-1%)

...oogle/api/gax/retrying/DirectRetryingExecutor.java
78.94% <0%> (-4.39%)
6% <0%> (ø)

...om/google/api/gax/httpjson/HttpJsonStatusCode.java
28.2% <0%> (-2.57%)
7% <0%> (-1%)

...le/api/gax/retrying/ExponentialRetryAlgorithm.java
97.43% <0%> (-0.07%)
10% <0%> (ø)

.../com/google/api/gax/rpc/OperationCallableImpl.java
100% <0%> (ø)
5% <0%> (ø)
:arrow_down:

.../api/gax/retrying/CallbackChainRetryingFuture.java
88.37% <0%> (ø)
6% <0%> (ø)
:arrow_down:

...ava/com/google/api/gax/retrying/RetrySettings.java
31.25% <0%> (ø)
2% <0%> (ø)
:arrow_down:

...rc/main/java/com/google/api/gax/rpc/Callables.java
68.18% <0%> (ø)
7% <0%> (ø)
:arrow_down:

... and 14 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fffc665...e402509. Read the comment docs.


Temporarily applied changes for the SSB standalone meeting

This PR makes some necessary changes to Klados for the SSB standalone meeting (Jan 3, 2020). It combines all the changes made in PR #184 and #185. My plan is to squash-merge this into master for the workshop, and then to remove that squashed change so that we can merge those two PRs through the regular review process. As before, you can test this PR at http://www.ggvaidya.com/curation-tool/.

I've deleted the squash-merged commit from master, and will proceed to add these improvements back in through PR #184 and PR #185.


not running autostart.sh script in dwm

I have this patch installed in dwm, and it doesnt run the autostart.sh file on login.
the file is as following:
#! /bin/bash
lxsession &
picom &
dwmblocks &
/usr/bin/emacs --daemon &
xrandr --output HDMI1 --mode 1920x1200 --primary --left-of eDP1
nitrogen --restore
setxkbmap -layout us, cz -option 'grp:alt_shift_toggle'
it shows some errors after login, but doesnt show them long enough

is the file named autostart.sh and in the ~/.dwm/ directory? i have the dwm-autostart-20210120-cb3f58a.diff patch installed and working with ly


Change default replication factor to -1

Binder now uses a default value of -1 for replication factor signaling the
broker to use defaults. Users who are on Kafka brokers older than 2.4,
need to set this to the previous default value of 1 used in the binder.
In either case, if there is an admin policy that requires replication factor > 1,
then that value must be used instead.
Resolves https://github.com/spring-cloud/spring-cloud-stream-binder-kafka/issues/808

And cherry-picked to 3.0.x


Update inf-addsoftware-directive.md

Documenting the flags for AddSoftware. Please do not publish this until we have internal signoff on the wordage.

@tedhudek @duncanmacmichael @barrygolden
Making sure you see this:
Please do not publish this until we have internal signoff on the wordage.

Yep, got it. I'll publish when the word is given. :)


Null check operator used on a null value on release or profile mode when use flutter 3.22.0

On flutter 3.22.0, this package works fine in debug mode, but when run in release or profile mode, the package breaks due to framework errors! I tested on your example, it really fails...

I also confirm this issue

Hello I will check this later @ohdonpiano @lehoangkhang4869

I tried to get this error in profile mode on an iPhone 15 but couldn't reproduce it. How did you provoke this error? @ohdonpiano @lehoangkhang4869

I used flutter_reorderable_grid_view 4.0.0 and it worked fine in version 3.19.*. However, after upgrading flutter to 3.22 and uploading the app to the store, I discovered that the grid was not loading properly. I tried in debug mode and didn't see any errors, then I tried in release and profile mode and found this error. I tried cloning your project and running the example in profile mode, and the following error still appears:

I/flutter (21307): Null check operator used on a null value
I/flutter (21307): #0      SliverMultiBoxAdaptorElement.createChild. (package:flutter/src/widgets/sliver.dart:840)
I/flutter (21307): #1      BuildOwner.buildScope (package:flutter/src/widgets/framework.dart:2845)
I/flutter (21307): #2      SliverMultiBoxAdaptorElement.createChild (package:flutter/src/widgets/sliver.dart:837)
I/flutter (21307): #3      RenderSliverMultiBoxAdaptor._createOrObtainChild. (package:flutter/src/rendering/sliver_multi_box_adaptor.dart:360)
I/flutter (21307): #4      RenderObject.invokeLayoutCallback. (package:flutter/src/rendering/object.dart:2688)
I/flutter (21307): #5      PipelineOwner._enableMutationsToDirtySubtrees (package:flutter/src/rendering/object.dart:1097)
I/flutter (21307): #6      RenderObject.invokeLayoutCallback (package:flutter/src/rendering/object.dart:2688)
I/flutter (21307): #7      RenderSliverMultiBoxAdaptor._createOrObtainChild (package:flutter/src/rendering/sliver_multi_box_adaptor.dart:349)
I/flutter (21307): #8      RenderSliverMultiBoxAdaptor.insertAndLayoutChild (package:flutter/src/rendering/sliver_multi_box_adaptor.dart:497)
I/flutter (21307): #9      RenderSliverGrid.performLayout (package:flutter/src/rendering/sliver_grid.dart:653)
I/flutter (21307): #10     RenderObject.layout (package:flutter/src/rendering/object.dart:2577)
I/flutter (21307): #11     RenderSliverEdgeInsetsPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:121)
I/flutter (21307): #12     RenderSliverPadding.performLayout (package:flutter/src/rendering/sliver_padding.dart:327)
I/flutter (21307): #13     RenderObject.layout (package:flutter/src/rendering/object.dart:2577)
I/flutter (21307): #14     RenderViewportBase.layoutChildSequence (package:flutter/src/rendering/viewport.dart:601)
I/flutter (21307): #15     RenderViewport._attemptLayout (package:flutter/src/rendering/viewport.dart:1516)
I/flutter (21307): #16     RenderViewport.performLayout (package:flutter/src/rendering/viewport.dart:1427)
I/flutter (21307): #17     RenderObject._layoutWithoutResize (package:flutter/src/rendering/object.dart:2416)
I/flutter (21307): #18     PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:1051)
I/flutter (21307): #19     PipelineOwner.flushLayout (package:flutter/src/rendering/object.dart:1064)
I/flutter (21307): #20     RendererBinding.drawFrame (package:flutter/src/rendering/binding.dart:577)
I/flutter (21307): #21     WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:1138)
I/flutter (21307): #22     RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:443)
I/flutter (21307): #23     SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1392)
I/flutter (21307): #24     SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1313)
I/flutter (21307): #25     SchedulerBinding._handleDrawFrame (package:flutter/src/scheduler/binding.dart:1171)
I/flutter (21307): #26     _invoke (dart:ui/hooks.dart:312)
I/flutter (21307): #27     PlatformDispatcher._drawFrame (dart:ui/platform_dispatcher.dart:419)
I/flutter (21307): #28     _drawFrame (dart:ui/hooks.dart:283)

Flutter doctor:

[√] Flutter (Channel stable, 3.22.0, on Microsoft Windows [Version 10.0.22631.3593], locale en-US)
• Flutter version 3.22.0 on channel stable at C:\SDK\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 5dcb86f68f (9 days ago), 2024-05-09 07:39:20 -0500
• Engine revision f6344b75dc
• Dart version 3.4.0
• DevTools version 2.34.3
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
• Android SDK at C:\Users\Admin\AppData\Local\Android\sdk
• Platform android-34, build-tools 33.0.2
• Java binary at: D:\Setup\AndroidStudio\jbr\bin\java
• Java version OpenJDK Runtime Environment (build 17.0.10+0--11572160)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.9.1)
• Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
• Visual Studio Community 2022 version 17.9.34616.47
• Windows 10 SDK version 10.0.22621.0
[√] Android Studio (version 2023.3)
• Android Studio at D:\Setup\AndroidStudio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 17.0.10+0--11572160)
[√] VS Code (version 1.89.1)
• VS Code at C:\Users\Admin\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.88.0
[√] Connected device (4 available)
• 22081283G (mobile) • <IP_ADDRESS>:38195 • android-arm64  • Android 12 (API 31)
• Windows (desktop)  • windows            • windows-x64    • Microsoft Windows [Version 10.0.22631.3593]
• Chrome (web)       • chrome             • web-javascript • Google Chrome 124.0.6367.208
• Edge (web)         • edge               • web-javascript • Microsoft Edge 124.0.2478.105
[√] Network resources
• All expected network resources are available.

I got the error on both Android and IOS. I don't know why it happens, and since it only appears on profile and release mode there's no way I can debug :<

New discovery: you have to drag an item for the error to appear

Ah I see, could you try version 5.0.0-dev.10? There are some breaking changes in that version but also a lot of improvements, I think the error should disappear with that version.
In a couple of weeks I will release the version 5.0.0 officially @ohdonpiano @lehoangkhang4869


How to run it offline on local ubuntu machine

I want to run this plugin and run it locally like you showed in the demo. help me with the exact working steps to do so.
Thank you.

Quite simple buddy. follow the below steps:

clone the repo using git clone https://github.com/pearcetm/GeoTIFFTileSource.git
Nevigate to the demo directory using cd GeoTIFFTileSource/demo
Run the Website:

To view the website, simply open the HTML (demo.html) file in your preferred web browser. You can do this by double-clicking on the demo.html file in your file explorer, or by right-clicking and selecting "Open with" and then choosing your web browser.

In addition to the steps @Rjaat mentioned to clone the repo, you will likely need to run a local web server as well in order for the local javascript code to work. See https://askubuntu.com/a/520612 for one easy option for this.


Add functionality to search by Auto SR in the games side of the site

Added some test games and the functionality to search by Auto SR in the games results

Please see my email - this PR needs to be resubmitted with no merge conflicts.


Figures in notebooks tutorials are not showing up properly

Example: https://autoresearch.github.io/autora/tutorials/theorist/

the figures need to be "attached" to the cells rather than linked as external images.

PyCharm doesn't support adding attachments, as far as I can tell, so you'll need to open the notebook outside of PyCharm using the terminal command:
jupyter notebook .

... and then modify using that interface.