[Linux][Proton >= 5.13] pressure-vessel uses different number of arguments

While trying to test #6, I hit another problem that seems introduced by some recent updates to either Steam or pressure-vessel itself: pressure-vessel is started with fewer arguments which, apparently, breaks the detection of cbLaunchDir here.
Comparing to your tests, the arguments --deploy=soldier and --suite=soldier seem to not be used anymore. Here are the logs from Proton 5.13 and Experimental. Just to be sure I also tested with both Steam Beta and the stable version.
2021-03-20 16:26:48.521 +02:00 [DBG] Args: [|"/home/+redacted+/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point";
  "--verb=waitforexitandrun"; "--";
  "/home/+redacted+/.local/share/Steam/steamapps/common/Proton 5.13/proton";
  "waitforexitandrun";
  "/home/+redacted+/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe";
  "/Steam"; "/novr"; "/autoquit"; "/EDH"|]
2021-03-20 16:26:48.628 +02:00 [DBG] Reading settings from '/home/+redacted+/.config/min-ed-launcher/settings.json'
2021-03-20 16:26:48.959 +02:00 [DBG] Settings: Ok
  { Platform = Dev
    DisplayMode = Pancake
    AutoRun = false
    AutoQuit = true
    WatchForCrashes = false
    ProductWhitelist = set ["edh"]
    ForceLocal = false
    Proton =
            Some
              { EntryPoint =
                            "/home/+redacted+/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point"
                Args =
                      [|"--verb=waitforexitandrun"; "--";
                        "/home/+redacted+/.local/share/Steam/steamapps/common/Proton 5.13/proton";
                        "waitforexitandrun"; "python3";
                        "/home/+redacted+/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe";
                        "/Steam"|] }
    CbLauncherDir = "/"
    PreferredLanguage = None
    ApiUri = https://api.zaonce.net/
    Restart = (false, 3000L)
    Processes = [] }
2021-03-20 16:26:48.968 +02:00 [ERR] Unable to get version: Unable to find CBViewModel.dll in directory /

2021-03-20 16:31:25.774 +02:00 [DBG] Args: [|"/home/+redacted+/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point";
  "--verb=waitforexitandrun"; "--";
  "/home/+redacted+/.local/share/Steam/steamapps/common/Proton - Experimental/proton";
  "waitforexitandrun";
  "/home/+redacted+/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe";
  "/Steam"; "/novr"; "/autoquit"; "/EDH"|]
2021-03-20 16:31:25.864 +02:00 [DBG] Reading settings from '/home/+redacted+/.config/min-ed-launcher/settings.json'
2021-03-20 16:31:26.249 +02:00 [DBG] Settings: Ok
  { Platform = Dev
    DisplayMode = Pancake
    AutoRun = false
    AutoQuit = true
    WatchForCrashes = false
    ProductWhitelist = set ["edh"]
    ForceLocal = false
    Proton =
            Some
              { EntryPoint =
                            "/home/+redacted+/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point"
                Args =
                      [|"--verb=waitforexitandrun"; "--";
                        "/home/+redacted+/.local/share/Steam/steamapps/common/Proton - Experimental/proton";
                        "waitforexitandrun"; "python3";
                        "/home/+redacted+/.local/share/Steam/steamapps/common/Elite Dangerous/EDLaunch.exe";
                        "/Steam"|] }
    CbLauncherDir = "/"
    PreferredLanguage = None
    ApiUri = https://api.zaonce.net/
    Restart = (false, 3000L)
    Processes = [] }
2021-03-20 16:31:26.257 +02:00 [ERR] Unable to get version: Unable to find CBViewModel.dll in directory /

I'm sorry that I can't contribute directly a patch, but it's the first time I look at F# code. One general idea that comes to my mind—and most likely you've thought about it yourself—is to have a more flexible matching. I don't know if this would make sense: if our initial assumption of where EDLaunch.exe should be located in the arguments array (say, arr[n]) fails, to try also, as sort of a fallback, regex matching the launcher in the neighbouring 2-3 arguments (arr[n-2]..arr[n+2]). This seems to me like a way to avoid having to constantly adjust the expected number of arguments if they continue changing in the future. But maybe this doesn't make sense at all—again, I'm afraid I don't have the knowledge to understand well your code—so feel free to just ignore this.
Last but not least, thank you very much for the time and effort to create and maintain this wonderful project!

Thanks for the depth. I've pushed a fix to both branches that should handle any number of soldier arguments going forward.
Updated binaries for master and frontier-auth can be downloaded from CI builds.


neonvm: Add support for spec-defined sysctl settings

Adds a new field, Guest.Settings, in case there's other tunables aside from sysctl that we may want to change later.
The motivation is so that we can test things like disabling memory overcommit as a feature flag in the control plane, rather than e.g. changing it the compute image globally.
Ref https://neondb.slack.com/archives/C03TN5G758R/p1696359675029629
Tested locally by adding some sample settings to vm-deploy.yaml:
settings:
  sysctl:
    - 'vm.overcommit_ratio = 30'
    - 'vm.panic_on_oom = 1'

LGTM


Improving performance of concatenating target region VCF files to all single VCF.

Hi,
For some of our variant callings concatenating the per target region VCF files to a single VCF file has become a bottle neck.  Read alignment and variant calling take some days and can be made faster by using more cpu.  concatenating also takes a few days but runs on a single cpu and can't be made faster by using more cpu.
I tested a couple of options for doing the concatenating on a subset of a big variant calling:
gatk CatVariants on vcf files: 47m
bcftools concat on vcf files: 25m
bcftools concat on bcf files: 52m
bcftools naive concat on bcf files: 0m11s

Currently bcbio uses gatk CatVariants, bcftools concat is already almost twice as fast in my test.
Would replacing gatk CatVariants with bcftools concat be an option?
The latest version of bcftools also has extremely fast "naive concat" functionality for bcf.gz files.
See this documentation from bcftools:
Concatenate BCF files without recompression. This is very fast but requires that all files have the same headers. This is because all tags and chromosome names in the BCF body rely on the implicit order of the contig and tag definitions in the header. Currently no sanity checks are in place and only works for compressed BCF files. Dangerous, use with caution.
I think the headers of the target regions vcf files are always identical in bcbio?
So this avoids the dangerous part of naive BCF concat?
I tested after the bcftools naive concat that bcftools stats could be run on the resulting concatenated bcf.gz  file without errors.
Adding a bcftools view -O z to convert the concatenated BCF.gz to VCF.gz  negates the advantage of the naive concat, total wall time is again 52 miniutes.
Using the bcftools naive concat would need additional changes:

Change freebayes variant calling pipe to output BCF (extra bcftools view -O b on the end of the pipe)
All tools downstream of the concatenated BCF file need to be able to read BCF. BCFtools stats does, but I am guessing there are also other downstream tools possible which maybe can't read BCF.

Would switching to bcftools vcf.gz concat or bcftools bcf.gz naive concat  be an option?
Or are there other possible ways to improve the target regions vcf concat step?
Thank you.

Neill;
Thanks for the benchmarking and suggestions on swapping over to bcftools concat. It would be great to get the speedups here especially with the native concat but I've been hesitant to move over to bcftools for concatenation due to this issue that causes incompatibilities of the outputs with any downstream processing through GATK derived tools:
http://gatkforums.broadinstitute.org/wdl/discussion/4956/error-message-java-lang-integer-cannot-be-cast-to-java-lang-double
https://github.com/samtools/htslib/pull/395#issuecomment-251101177
It's not clear if the naive concat causes that as well, but bcftools concat definitely does. I'm also not sure bcf buys us much because of the necessity of converting back to vcf.gz at some point in the process.
Maybe another voice on the samtools or GATK side will help resolve that issue and then I'd be happy to explore doing this. Thanks again for starting this discussion.

Hi Brad. Thank you for the information. It would be very nice if bcftools could fix this at their side,  GATK does not seem to consider this a priority.
Ins't Freebayes produced VCF already incompatible with GATK?
Or incompatible because of this float formatting issue and the use of bcftools in the freebayes pipe?
https://github.com/chapmanb/bcbio-nextgen/blob/master/bcbio/variation/freebayes.py#L146
We can wait for the fix from bcftools as we don't do these large variant calling that often.
If that takes very long it would be nice to have the option to use bcftools for the concat.
With the warning that this trades concat speed against compatibility with GATK (which we currently don't use downstream, which is the same for most Freebayes users?).
As far as I know this does not affect compatibility with PicardTools as I have used that in the past with VCF processed by bcftools.
Use of bcftools for concat is already in place as a backup option.
https://github.com/chapmanb/bcbio-nextgen/blob/98c12fdaa8ce6ab9c6c1fdfb4db39df9c7b548ff/bcbio/variation/vcfutils.py#L306
As mentioned before we are fine waiting for some time for bcftools to hopefully fix this issue at their side.
Naive BCF concat would be really nice but it would be good for the functionality to develop to include sanity checking if the headers are compatible. Also having a overview of which downstream tools can and can't read BCF is needed. For us BCF would be an acceptable end point, we only convert to VCF.gz per chromosome or after doing queries on the BCF.
Thank you again for the information.

Neill;
Thanks again for this. FreeBayes output has been GATK compatible despite the filtering step so I guess the output doesn't trigger the issue or it only happens as part of concatenation. As you said, we already have bcftools concat in place so could switch over to it if we get this issue resolved. We could also build in special cases like only using CatVariants with GATK calling, but that always makes debugging issues harder and more complex so we would rather have one standard way of doing it. If you ping the htslib/bcftools folks on that issue and mention this is a priority for you it might be them to look at it quicker. Thanks again.

Thank you from the information Brad. I'll ask for an update in the bcftools / htslib ticket.
I will also do a test run with bcftools naive concat hacked in to the bcbio pipeline.  And then compare to existing results of the bcbio pipeline for the same samples / fastq files.
Test Implementation:
Replace the last element of the freebayes variant calling pipe from:
bgzip > output_file to bcftools view -O b -o output_file
https://github.com/chapmanb/bcbio-nextgen/blob/master/bcbio/variation/freebayes.py#L199
Remove GATK concat block and always run bcftools concat
https://github.com/chapmanb/bcbio-nextgen/blob/98c12fdaa8ce6ab9c6c1fdfb4db39df9c7b548ff/bcbio/variation/vcfutils.py#L306
Change bcftools concat to naive bcftools concat:
https://github.com/chapmanb/bcbio-nextgen/blob/98c12fdaa8ce6ab9c6c1fdfb4db39df9c7b548ff/bcbio/variation/vcfutils.py#L348
If that works this would increase the performance of the concat ca 100X and the performance of QC stage ca 5x (by running per sample bcftools stats on BCF instead of VCF, See https://github.com/chapmanb/bcbio-nextgen/issues/1556 ).
Main issue is this works is that not all downstream tools are compatible with BCF.
But for our situation I think we are compatible downstream and it would be a huge performance increase for our 2 remaining performance bottlenecks.

The naive concat also avoid the float formatting / GATK compatibility  issue I was just told in the bcftools / htslib ticket.

I'm not sure I understand what concat is doing that makes it so slow.
The naive concat claims it is dangerous as it doesn't check headers, but presumably it could check them?  I envisage a concat which is:

Read all the headers and check for consistency across files.
Emit new header.
Read/write loop on files; either for BCF or VCF - no parsing / transcoding necessary.

What am I missing here that makes this process take 20+minutes?  The only case I can think of is when we're also transcoding - eg VCF to BCF or vice versa.

In my test (see opening comment) the naive bcftools bcf.gz concat  only took 11 seconds.  Much faster than any of the other options.  25 minutes is what the normal bcftools vcf.gz concat took.
Checking the headers before doing the naive concat would be very nice.
This would make sense to do just before the naive concat in bcftools.
For this we depend on the bcftools development team.
I think the freebayes variant calling pipe is build the same way for all analysis blocks.
https://github.com/chapmanb/bcbio-nextgen/blob/master/bcbio/variation/freebayes.py#L145
So unless freebayes produces random order in the header or any post processing tools in the pipe change some order the headers they should be identical (except for the analysis block bed file used. )  This would be similar for the other supported variant callers.

Hi @chapmanb .
I think the easiest way to improve the concat performance is to replace GATK CatVariants with BCFTools VCF.gz naive concat .
BCFTools VCF.gz naive concat is available in the current bcftools development version. (https://github.com/samtools/bcftools)
I tested the performance of BCFTools VCF.gz naive concat  on one of our large variant callings:
bcftools_latest_dev_version/bcftools concat  --naive -f ../Project_large_VC-files.list  -O z -o Project_large_VC-freebayes.vcf.gz
Instead of a week with GATK CatVariants this finished in 15 minutes, the output is a ca 350GB VCF.gz file.
On a smaller smaller variant calling (40 GB VCF.gz) I verified that the output of BCFTools VCF.gz naive concat is the same as  GATK CatVariants:

BCFTools stats and Picard Genotype concordance confirm that the variants and genotypes are identical in both concatenated VCF files.
EBI vcf-validator gives the same kind of warning for both the concatenated VCF files. They are slightly different though because GATK CatVariants does an extensive reformatting of the VCF file.

I did not test if GATK (SelectVariants + JEXL expression) can read the concatenated VCF file produced by bcftools VCF.gz naive concat. This because I don't have access to GATK.
Could you test if the bcftools naive VCF.gz concat also works for you and with GATK if you have acces?
There is a slight risk that the output of the Freebayes analysis block variant callings is already incompatible with GATK SelectVariants but that the GATK CatVariants fixes this problem by doing the reformatting of the VCF (e.g. converting float 10 to float 10.0  )
In that case some of  the bcftools naive VCF.gz concat performance upgrade would still be possible by doing the GATK CatVariants reformatting per chromosome and then use bcftools naive VCF.gz concat to concat the per chromosome VCF.gz files.
We will probably use bcftools VCF.gz naive concat already as a manual work around for the variant callings were we need it.
It would be nice if it can be supported by bcbio somewhere in the future.

Neill;
Thanks so much for investigating. Replacing with bcftools naive concat makes good sense and I'd be happy to do this. My only concern in doing it immediately is depending on a development version of bcftools since it's used so extensively. Did you get any sense of a timeline for a new bcftools release? It's been a while since the last so maybe one is due, but if not then we can try and test and investigate with a development release. Thanks again.

Hi Brad, timeline for new bcftools release is inclear, but current DEV should be stable.

The new release is tied with changes in htslib and the timeline there is unclear, therefore I don't know, sorry! The current bcftools github version is considered stable.

Hi @chapmanb . BCFTools 1.4 with the naive concat version for vcf.gz is about to be released.
At least all the docs and release notes are being prepared.
https://github.com/samtools/bcftools/commit/e9bacd1e80e442f2776a10df64b762d81eb2df2b#diff-ff4e2dc4962dc25a1512353299992c8dR71

Neill -- brilliant, thanks for the heads up. When the new release is out we'll test, update and then tackle adding this in. Thanks much.

Neill;
Thanks again for all the work and benchmarking on this. Now that the pysam team resolved incompatibilities preventing use of 1.4 I tested and swapped bcbio over to use htslib/bcftools/samtools 1.4. The latest development version now uses bcftools concat --naive for combining regional files. Thank you again for pushing this and please let us know if you run into any problems.

Thank you for implementing this. It will make a big difference for our larger variant callings.


import/no-unresolved: Unable to resolve path to module

Hello,
I have a private repo in which I have an app directory and in that directory the issue is not present. In the same repo I have another directory called packages inside it there multiple components/modules in which each of them is a separate "app" when I'm inside any of these directories, I face the issue that all my imports have the error import/no-unresolved: Unable to resolve path to module although code completion works when I want to import any package.
coc-config:
  "eslint.autoFixOnSave": true,
  "eslint.filetypes": ["javascript", "javascriptreact", "typescript", "typescriptreact"],
  "coc.preferences.formatOnSaveFiletypes": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],
  "tsserver.formatOnType": true,
  "coc.preferences.formatOnType": true,
  "coc.preferences.rootPatterns": [".git",".hg",".projections.json","tsconfig.json",".prettierrc",".eslintrc.js","lerna.json"],
  "eslint.packageManager":"yarn"
}

the exact error message:
[eslint import/no-unresolved] [E] Unable to resolve path to module

although when I trigger doHover action, it can find the package.
I'm not sure how to go about this, if there's anything else I can provide, I'd be happy to.
Thanks for the great work you've done here :)

You have to configure eslint

I do have configurtion for eslint in .eslintrc.js in each subdirectory inside packages, the configuration works for vscode for example

This extension doesn't affect eslint

I see, ok. Thanks for the quick responses.


Suggestions for Resources filtering

Add an "Educational" high-level filter button to add things like Open Science MOOC, the Turing Way Handbook, and other great educational/training platform that spans the entire set of filters (Open data, Open code, Open ...)

We discussed this among the team and will go forward with it when we have time.

Add a drop-down list of Keywords which help narrow down What do you want to do?/ What exactly is this useful for?

Rationale: It is not clear what a resource is for. It is clear from the small descriptions when hovering, but it may become unwieldy and overwhelming when we add more and more Resources. For instance, Select Open Code and Neuroimaging -> You get a bunch of Open Source Analysis packages, and some platform and software where you can share your code. These are very different things but can't be separated using the existing filters. Similarly for Open Data, it doesn't distinguish between Open Data sources to find data, Data Standards to organize (meta)data, and platform to share data.

Proposal: Not sure. Maybe a list of broad Keywords that can help narrow down, such as: [Find, Share, Organize, Collaborate, Publish, Analyze, Collect, Pre-Print, Pre-Register, ]

Downside: it may be a little award and not intuitive for some things (like Open Publishing). Ideally the list could change depending on the selected high-level filter, but this would get a little complicated, for now.

Add an Outreach/SciComm high-level filter button. There is no such thing yet, and this is quite an important part of Open Science.

I don't know that many resources that could go in there, but there is Neurolingo from Neuro/McGill folks. Maybe some podcasts? BrainReach maybe.


As a developer, write tests in CON_ContactMerge to cover multi-person households, one2one contacts, and org accounts

Included in beta release version 3.39 (Beta 2) and higher

Included in production release version 3.39


Support for no_proxy environment variable

It looks like https://github.com/github/hub/blob/master/github/http.go#L171-L193 is reimplementing the proxy logic from net/http/transport.go but it's missing the sections that support setting no_proxy.

Good catch! Wanna take a stab at implementing it?

Sure! I'll give it a shot since it's been causing a ton of pain for me having to mix proxy settings between git and hub. I'm a newbie at go so might take me a few weeks.

@woneill Just out of curiousty: how are you using http_proxy and no_proxy in your dev environment and at which point does it break in hub?

We have a site-wide proxy for all internet access but internal websites can/should be accessed directly. And we have github enterprise setup internally. So when I have HTTP_PROXY=http://proxy and NO_PROXY=.mydomain.com set, 'stock' git access works but anything handled by 'hub' (usually pull request generation) fails until I undefine HTTP_PROXY.

BTW, I have the no_proxy code from golang ported over, just trying to figure out a good way to write a cucumber test around it.

:+1: on this issue, can not use hub with my local github enterprise without this feature.

+1 facing the same issue - no_proxy and NO_PROXY env vars are being ignored

+1

Here's the commit explaining why this was re-implemented. Maybe worth exploring if this is still a concern, and if so, updating the comment so it's a bit more clear why this was done.

@woneill, I'm thinking I might pick this up. Do you have some existing code I can start from?

@mislav, given the support for github.localhost introduced in 67ba00ae6653ef37a78f240b158418e727750f2d is the separate proxy implementation introduced in 9a7d6fadf80893967e01a1c4525a2e3db1e1b95b for proxying to localhost or a loopback IP support still relevant?

@elovelan The support for github.localhost was added mostly for Hubbers like me and is not very useful for anyone who doesn't work at GitHub. It has nothing to do with proxy implementation.
If the current support for proxying and related environment variables lacking, PRs welcome!

@mislav, in your commit where you implemented this custom proxy logic, you said the following which seems to reference the exact use case that github.localhost is used for:

Go otherwise respects HTTP_PROXY environment variables by default, but special-cases requests made to "localhost" or <IP_ADDRESS> by disabling proxy for them, which makes me a sad panda since I want to debug the requests hub makes to our local test server.

I'm happy to open a PR with a clarifying comment if there are other use cases you're thinking of for avoiding the proxy logic from Go's stdlib.

you said the following which seems to reference the exact use case for github.localhost that you mentioned above

Ah yes, thanks for digging that up. I do a lot of local testing/hacking, some using localhost and some using github.localhost (they are treated differently on my machine, though).
I haven't touched the proxy-handling code in a while, and I'm unsure if there are any blind spots that we still have, but as I said, if you find anything that's broken/unclear, I'd appreciate PRs. Bonus points if we can remove my proxy hacks in favor of Go stdlib (note that hub still keeps compatibility with Go 1.8)

Actually, I'd prefer to keep the implementation of reading proxy-related environment variables in hub just so that we can ensure that hub's proxy handling stays the same across Go versions 1.8–1.11 (and future ones). It would be great if no_proxy was respected!

+1 on this. hub should respect no_proxy.

+1


Elegant way to auto_register things in different sections?

I have my checks divided up into multiple modules and one extra module to tie them together like this:
import fontbakery.checkrunner
import fontbakery.specifications.ufo_sources

import damacheck.constants
import damacheck.dama_conditions
import damacheck.ufo.anchors
import damacheck.ufo.components
import damacheck.ufo.conditions
import damacheck.ufo.hinting
import damacheck.ufo.kerning
import damacheck.ufo.misc
import damacheck.ufo.outline
import damacheck.ufo.spacing
import damacheck.ufo.unicode
import damacheck.util

specification = fontbakery.specifications.ufo_sources.UFOSpec(
    iterargs={"font": "fonts"},
    derived_iterables={"ufo_fonts": ("ufo_font", True)},
)
specification.merge_specification(fontbakery.specifications.ufo_sources.specification)
specification.auto_register(globals())
specification.auto_register(damacheck.dama_conditions.__dict__)
specification.auto_register(damacheck.ufo.conditions.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Anchors")
specification.auto_register(damacheck.ufo.anchors.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Components")
specification.auto_register(damacheck.ufo.components.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Hinting")
specification.auto_register(damacheck.ufo.hinting.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Kerning")
specification.auto_register(damacheck.ufo.kerning.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Miscellaneous")
specification.auto_register(damacheck.ufo.misc.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Outlines")
specification.auto_register(damacheck.ufo.outline.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Spacing")
specification.auto_register(damacheck.ufo.spacing.__dict__)
specification._default_section = fontbakery.checkrunner.Section("Unicode")
specification.auto_register(damacheck.ufo.unicode.__dict__)
specification._default_section = None
specification.test_expected_checks(
    [
        "com.daltonmaag/check/ufolint",
        "com.daltonmaag/check/ufo-required-fields",
        "com.daltonmaag/check/ufo-recommended-fields",
        "com.daltonmaag/check/ufo-unnecessary-fields",
    ]
)

I want to put each module into its own section to make it easier to generate a report ordered by sections. auto_register just dumps stuff into the default section, so I'm setting the default section manually. Is there a more elegant way or should I extend auto_register?

Isn't this doong the thing?
https://github.com/googlefonts/fontbakery/blob/027a58150afb5a4c135a0896b23fd5048a2e0ddd/Lib/fontbakery/specifications/googlefonts.py#L20-L25

In [4]: s=fontbakery.checkrunner.get_module_specification(damacheck.ufo)

In [5]: s.sections
Out[5]: odict_values([<Section: damacheck.ufo>])

Nope.

The googlefonts spec seems to do what you are asking for:
In [1]: from fontbakery.specifications import googlefonts

In [2]: googlefonts.specification
Out[2]: <fontbakery.fonts_spec.FontsSpec at 0x7f04a3fbe518>

In [3]: googlefonts.specification.sections
Out[3]: odict_values([<Section: Google Fonts>, <Section: fontbakery.specifications.general>, <Section: fontbakery.specifications.cmap>, <Section: fontbakery.specifications.head>, <Section: fontbakery.specifications.os2>, <Section: fontbakery.specifications.post>, <Section: fontbakery.specifications.name>, <Section: fontbakery.specifications.hhea>, <Section: fontbakery.specifications.dsig>, <Section: fontbakery.specifications.hmtx>, <Section: fontbakery.specifications.gpos>, <Section: fontbakery.specifications.gdef>, <Section: fontbakery.specifications.kern>, <Section: fontbakery.specifications.glyf>, <Section: fontbakery.specifications.fvar>, <Section: fontbakery.specifications.loca>])

Interdasting. More digging tomorrow. Giving the section a sensible name would be nice though, maybe I can think of something nice.

Also: Writing Specifications tries to describe how all this works and how to get rid of the automation.
Maybe, your sub-modules don't define themselves a specification, that's needed I think.

Can we close this?

Probably. Will reopen if I can't make it work.


Continuous high CPU usages by pre-loader animation.

This is a (multiple allowed):

[x] bug

[ ] enhancement

[ ] feature-discussion (RFC)

Swiper Version: 5.4.5

Platform/Target and Browser Versions: Windows 10, Edge/Chrome

What you did
I have a page with multiple swiper (~10) and each swiper contains 10 to 15 image slides. The page loads fine and when loading animation ends, I still see continuous high CPU usages in Browser's task manager.
Expected Behavior
CPU usages should come back to normal after page load.
Actual Behavior
Continuous high CPU usages even after page finishes loading.
Here is my swiper initialization code.
function init() {
	new Swiper('.swiper-container', {
		cssMode: false,
		roundLengths: true,
		preloadImages: false,
		loop: true,
		lazy: true,
		pagination: {
			el: '.swiper-pagination',
			dynamicBullets: true
		},
		navigation: {
			nextEl: '.swiper-button-next',
			prevEl: '.swiper-button-prev'
		},
	})
}

For now I have disabled loading animation by removing following code, and CPU usages is as expected.

Closing as not related to Swiper


Change package name

The package name should be changed to com.vitpunerobotics.netra

https://stackoverflow.com/a/29092698/8146933
For reference


add: logseq-msk-toc plugin, logseq-msk-enhanced theme

@mschmidtkorth I tried to install logseq-msk-toc but failed, it seems that the package.json file can't be parsed.
@xyhp915 Any ideas?

@mschmidtkorth I tried to install logseq-msk-toc but failed, it seems that the package.json file can't be parsed.
@xyhp915 Any ideas?

I found the released package (logseq-msk-toc) missing package.json file. Maybe a Github action to build this project is helpful, here’s a sample link https://github.com/xyhp915/logseq-journals-calendar/blob/main/.github/workflows/publish.yml
Ping me anytime if need some help 🙂


kitty-themes: 0-unstable-2024-06-12 -> 0-unstable-2024-06-26

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for kitty-themes is: Themes for the kitty terminal emulator
meta.homepage for kitty-themes is: https://github.com/kovidgoyal/kitty-themes
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0-unstable-2024-06-26 in filename of file in /nix/store/hh6by4585y1rkvy0jhk4mhn47v2cr21d-kitty-themes-0-unstable-2024-06-26

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

kitty-themes

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/hh6by4585y1rkvy0jhk4mhn47v2cr21d-kitty-themes-0-unstable-2024-06-26 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/a630861eb547efc267621e3bc7cdaf08aa7dec82#kitty-themes

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hh6by4585y1rkvy0jhk4mhn47v2cr21d-kitty-themes-0-unstable-2024-06-26
ls -la /nix/store/hh6by4585y1rkvy0jhk4mhn47v2cr21d-kitty-themes-0-unstable-2024-06-26/bin

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

1 package built:

kitty-themes

Maintainer pings
cc @Sigmanificient for testing.

@Nixos/nixpkgs-merge-bot merge

@NixOS/nixpkgs-merge-bot merge


SharePoint PNP fails in batch sizes over 1

The  Connect-PnPOnline  commandlet always fails with larger batch sizes.  Not sure if it's an issue with the library or the powershell support

This is a question that would be better on the MSDN forums. Please post on https://aka.ms/func-forum


Information regarding the power scheduler

Hi @josepheichers95, you may find power schedule description into community documentation on Power Schedules page. If you have a specific question, please create an issue and describe what you need.


Made ValueForwarder.IValueListener internal

The docs generator tried to create links to this interface because it is
implemented by some public classes (like With, although they are
explicitly implemented). I guess this should be considered a bug in the
docs generator, but if this is an OK change anyway, its an easier fix
for now.

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

@kristianhasselknippe: This is definitely a bug in the docs generator. The current code is sane as-is, and I don't want to have to live with limitations like this forever, as we're going to end up breaking similar things in the future, and playing catch-up like this is frustrating.
So while this should be OK for now, we need to make sure this gets fixed in the docs generator. This would include adding a uno-issue for it.
Thanks for a thorough commit message. One small nit, though; we prefer imperative, present tense for commit messages. So that would be "Make ValueForwarder.IValueListener internal". But I would also name the motivation in the subject rather than the mechanism. So how about "Work around docs-generator bug". And we should also have a link to the uno-issue.

@kristianhasselknippe: By the way, this code seems to be identical on release-1.0, didn't docs-generation work for that branch? Or is newer uno/docs-generator more picky somehow?

@kusma: i'm actually not quite sure. I'll take a closer look at the generator

We don't need to merge this now that i think of it. I'll just use it for docs generation and then i'll look into fixing it in the generator instead.


LightFlare banding as well

The light flare has a banding effect now as well after 3.9:
http://duion.com/files/temp/screenshot_TG_Fields_dawn020-00001.png
http://duion.com/files/temp/screenshot_TG_Fields_dawn020-00001-c.png //with high contrast to see it better
here a comparison old version vs new version:
old:
http://duion.com/files/temp/screenshot_012-00001.png
new (with banding bug):
http://duion.com/files/temp/screenshot_TG_DesertRuins_dawn021-00001.png

Seems to be caused by HDR, it does not happen, if you start the engine with HDR turned off.


Some netcdf functions are not in the doxygen documentation on-line.

Looking at the docs here:
http://www.unidata.ucar.edu/software/netcdf/docs/
The following functions appear to be missing from the doxygen documentation:
nc_inq_unlimids()
nc_def_grp()
nc_inq_ncid()

Thanks for pointing those out, I'll get the documentation updated.

I'm not finding nc_inq_unlimids() anywhere, can you point me to it? Or, did you perhaps mean nc_inq_unlimdims? That would make sense, as the latter isn't documented either (but should/will be).

Howdy Ward!
Sorry, typed it wrong. I meant this one (from netcdf.h):
/* The next function is for NetCDF-4 only */
EXTERNL int
nc_inq_unlimdims(int ncid, int *nunlimdimsp, int *unlimdimidsp);
This function is necessary because netCDF-4 files can have more than one unlimited dimension.

No problem; it's funny, "Fill in documentation for group-related functions" has been languishing on my todo for a while; nice to finally get that and these other things out of the way.

Such functions should not appear in netcdf.h; rather

thename should be something like NC_inq_unlimdims
it should be defined in e.g. ncdispatch.h
=Dennis

On 7/11/2016 1:26 AM, Imperial Fleet Commander Tarth wrote:

Howdy Ward!
Sorry, typed it wrong. I meant this one (from netcdf.h):
/* The next function is for NetCDF-4 only */
EXTERNL int
nc_inq_unlimdims(int ncid, int *nunlimdimsp, int *unlimdimidsp);
This function is necessary because netCDF-4 files can have more than one
unlimited dimension.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/277#issuecomment-231660335,
or mute the thread
https://github.com/notifications/unsubscribe/AA3P20ZETdr_NXKD2esMKD0Fd8uTcs4sks5qUfAagaJpZM4I6IXM.

Dennis,
Why should it not appear in netcdf.h? Is it not a fully supported part of the API?
Ed

I did not think it was part of the official API.
On 7/12/2016 4:47 AM, Imperial Fleet Commander Tarth wrote:

Dennis,
Why should it not appear in netcdf.h? Is it not a fully supported part
of the API?
Ed
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/277#issuecomment-232004735,
or mute the thread
https://github.com/notifications/unsubscribe/AA3P2z2BuX6UiscB-ilA_Qj3T_6k9fRhks5qU3DGgaJpZM4I6IXM.

I believe it is and should be availabe for all netcdf files. (Though obviously only netcdf4/hdf5 files can have more than one unlimited dimension.)

The functions discussed here have been stubbed in in the dev. branch, and I'm looking at toggling the 'warnings' option in the doxygen configuration.  Closing this out for now, will reopen if it looks like I've missed something.


$Buy/Sell Crypto Modal on Mobile not fully displayed

Overview
When selecting the $Buy/Sell Crypto option in mobile, the modal cuts off the 'Sell' option so it looks like Buy may be the only option. You can move the screen across to see it but on initial viewing it looks incomplete.
This was noticed after the merge of release branch:
https://github.com/shapeshift/web/pull/1800
References and additional details

Open app.shapeshift on mobile (iOS or Android)
Connect to any wallet.
In the menu drop down list find the "$Buy/Sell Crypto" option and select.
Notice in the Buy or Sell Crypto modal that the 'sell' option isn't displayed on screen but you have to move the screen across before being able to select it.

Acceptance Criteria
It would be nice to view both Buy and Sell options easily when opening the Buy or Sell Crypto modal
Need By Date
No response
Screenshots/Mockups
No response
Ownership

[X] If my bounty needs engineering or needs product I have added the respective labels on the right
[X] As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

Estimated effort
1 hour
Sponsor / Stakeholder
No response
Bounty Hunters

Join our discord
Include an expected timeline for you to complete work in the work plan when you apply for this bounty!
Please refer to this link for some basic info
Please do not start work on this issue until you are approved in Gitcoin.

on mobile, can we remove the "buy" "sell" tags to decrease the width of the modal

?

@reallybeard seeing as though @DiggyDiggy2 is away are you, or someone else from product, able to please advise a sponsor for this bounty as we have had a bounty hunter apply for it in Dework. Thank you

@MBMaria  happy to sponsor/review

Thanks @DiggyDiggy2 . I've sent you a link on Discord to invite you to join Dework so I can add you as the sponsor.

Does this look good ?

This looks good. Just curious as to why Banxa is not showing up? I want to make sure the change is applied to both

the feature flag for Banxa was disabled

nice, is there a dev environ URL where i can take a look?

probably this - https://bafybeia6r4wsdkkqk66clvdbju3lz4fxp4zjkduonpoqdj2mpdfinxsara.on.fleek.co/

looks great! Thanks. @Lychbot to double check. Otherwise, looks GTG.

Link to the PR - https://github.com/shapeshift/web/pull/1909


Documentation📄: Fix lint warnings

What is the current documentation state?
As discussed in #175  there are only a few pages remaining in this docs repo that have obvious lint errors.
This issue will fix some lint / formatting warnings

docs/admin/accessing_logs.md
docs/installing/fdo.md
docs/installing/watson_speech.md
docs/troubleshoot/troubleshooting.md
docs/user_management/gdpr.md
docs/using_edge_services/cpu_load_example.md
docs/using_edge_services/using_patterns.md

Where is this stated?
No response
Why do you want to improve the statement?
No response
Proposed Statement
No response
Additional context.
No response

I inspected and confirmed these pages look good after the #433 PR was merged.

docs/admin/accessing_logs.md - https://open-horizon.github.io/docs/admin/accessing_logs/
docs/installing/fdo.md - https://open-horizon.github.io/docs/installing/fdo/
docs/troubleshoot/troubleshooting.md - https://open-horizon.github.io/docs/troubleshoot/troubleshooting/
docs/user_management/gdpr.md - https://open-horizon.github.io/docs/user_management/gdpr/
docs/using_edge_services/cpu_load_example.md https://open-horizon.github.io/docs/using_edge_services/cpu_load_example/
docs/using_edge_services/using_patterns.md - https://open-horizon.github.io/docs/using_edge_services/using_patterns/

I did notice a rendering issue with this page....  The  {:target=”_blank”}{: .externalLink} is visible.

docs/installing/watson_speech.md - https://open-horizon.github.io/docs/installing/watson_speech/

I'll sweep this watson_speech.md extraneous whitespace into a future PR.


Annotation completion

Annotation completion was mentioned as a useful feature.

@christinem this is the "big picture" of what I had you working on today

Note: #2577 seems to search for all annotations, not the ones for the current assignment. That should be fixed (@christinem if you have time).


OsvFunTest: Update expected results for NPM::glob-parent:5.1.1

Signed-off-by: Sebastian Schuberth<EMAIL_ADDRESS>

Merging despite the unrelated ConanFunTest failure.


error when using python-3.13

Description
Homeasistant 2024.12 deprecated python-3.12. Using python-3.13 this integration fails because the ovnif package is not compatible.
Logger: homeassistant.setup
Source: setup.py:334
First occurred: 2:22:13 PM (1 occurrences)
Last logged: 2:22:13 PM

Setup failed for 'onvif': Unable to import component: No module named 'cgi'
Traceback (most recent call last):
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/setup.py", line 334, in _async_setup_component
    component = await integration.async_get_component()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/loader.py", line 1034, in async_get_component
    self._component_future.result()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/loader.py", line 1014, in async_get_component
    comp = await self.hass.async_add_import_executor_job(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        self._get_component, True
        ^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/home/homeassistant/.pyenv/versions/3.13.0/lib/python3.13/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/loader.py", line 1074, in _get_component
    ComponentProtocol, importlib.import_module(self.pkg_path)
                       ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/util/loop.py", line 200, in protected_loop_func
    return func(*args, **kwargs)
  File "/home/homeassistant/.pyenv/versions/3.13.0/lib/python3.13/importlib/__init__.py", line 88, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 1022, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/homeassistant/components/onvif/__init__.py", line 9, in <module>
    from onvif.exceptions import ONVIFError
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/onvif/__init__.py", line 1, in <module>
    from onvif.client import ONVIFService, ONVIFCamera, SERVICES
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/onvif/client.py", line 11, in <module>
    from zeep.client import Client, CachingClient, Settings
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/zeep/__init__.py", line 1, in <module>
    from zeep.client import AsyncClient, CachingClient, Client
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/zeep/client.py", line 6, in <module>
    from zeep.transports import AsyncTransport, Transport
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/zeep/transports.py", line 11, in <module>
    from zeep.utils import get_media_type, get_version
  File "/home/homeassistant/.homeassistant/venv313/lib/python3.13/site-packages/zeep/utils.py", line 1, in <module>
    import cgi
ModuleNotFoundError: No module named 'cgi'

Is there any workaround?
I am using an aarch64 core installation which was working fine on python3.12.
Reproduction Steps
Start homeassistant
Expected behavior
Load integration properly
If applicable, add error logs.
.
Device Firmware
1.3.9 Build 231019
Integration Version
5.8.6
Using stream component
Yes
Does camera work via official integrations?
Yes
Camera has all attributes filled out in developer tools
Yes
HASS Environment
core-2024.12.1
Search for similar issues
Yes
Additional information
No response

If HA does not manage dependencies for you and an unrecommended install method is used, you will need to install them dependencies manually.
Integration works on Python3.13 and latest HA without any issues on both HA OS and Docker where HA handles dependencies.

Thanks for the confirmation that it is supposed to be working on python-3.13. I will try to solve it myself then and report back the solution if needed.


New version: Mozilla.Firefox.DeveloperEdition.ka version 132.0 (132.0b4)

Created by 🥟 Dumplings.
Microsoft Reviewers: Open in CodeFlow

Verify by proxy: https://github.com/microsoft/winget-pkgs/pull/179431#issuecomment-2400690391


Textbox cursor alignment fix

Fix for the textbox cursor position to the center of the textbox when there is no text in the textbox.

Looks great! I'll merge it into devel.


chore(demo): link to next demo app

PR Checklist
Please check if your PR fulfills the following requirements:

[X] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[X] Refactoring (no functional changes, no api changes)
[ ] Other... Please describe:

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[X] No

@waterplea Thanks for comments! I fixed them all.


Demo

It might be handy to have a demo showing the graphs that come out of the box with this.

+1 yes, visuals would help make clear how each component is to be used.

Absolutely agree. We're planning on creating a site full of "recipes" and examples. Already tracking this concern on #3


remove RELEASE_6 hack

https://github.com/twosigma/beaker-notebook/blob/771ff3519bfe28df93fd7f917104cac249664346/core/src/main/java/com/twosigma/beaker/core/rest/StreamGobbler.java#L82
org.antlr has the unfortunate property that it has been marked as qualified to run only with java6.
hence we get a runtime warning since we use java 7, and this must be hidden from the users by the StreamGobbler.
when antlr is fixed we should remove the hack.

This has been moved from the StreamGobbler into the std output handler


ci: improve CI workflows

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


why *16384 when reverse gamma correction for sRGB

reverse gamma correction for sRGB
  img = (img / 255.0) ** 2.2 * 16384

as we all known,when gamma correction
y=(x/255) ** (1/2.2) * 255
so ,I think(if wrong ,correct me) x=(y/255) ** 2.2 * 255 if we want to reverse gamma correction
and your training data is 16bit while test image is 8 bit ,16384==2**14,Could you please tell me why 16384,did this number a scale to invert img from 8bit to 16 bit ,but,why....

Why 16384: as far as I remember the inputs are actually 14bits, which is true for most high-end commercial digital cameras.
For the gamma correction, is probably converting sRGB to linear color space, where CC algorithms work in.

but in you README you said input is 16bit
for Shi's and in datasets.py you* 65535 I have not watch each number in img ,do do not know clearly

but in you README you said input is 16bit
for Shi's and in datasets.py you* 65535 I have not watch each number in img ,do do not know clearly

14-bit numbers are typically stored using 16-bit for alignment :-)


Set MIME type for files requested via raw api

Closes #8152.
This change sets the media type for text files requested via API /repos/{owner}/{repo}/raw/{filepath} if the type can be deduced from the file extension.
Alternatively, one could set the Content-Type header already in function GetRawFile and streamline the code a little bit more in function ServeData.

Codecov Report

Merging #9305 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #9305      +/-   ##
==========================================
+ Coverage   41.19%   41.19%   +<.01%
==========================================
  Files         559      559
  Lines       73073    73078       +5
==========================================
+ Hits        30100    30108       +8
- Misses      39199    39200       +1
+ Partials     3774     3770       -4

Impacted Files
Coverage Δ

routers/repo/download.go
42.34% <100%> (+2.15%)
:arrow_up:

routers/api/v1/repo/file.go
71.2% <100%> (+0.07%)
:arrow_up:

modules/task/migrate.go
25% <0%> (-3.95%)
:arrow_down:

models/error.go
33.33% <0%> (-1.18%)
:arrow_down:

models/repo.go
47.93% <0%> (+0.05%)
:arrow_up:

modules/migrations/gitea.go
9.45% <0%> (+0.63%)
:arrow_up:

models/repo_list.go
74.07% <0%> (+0.92%)
:arrow_up:

modules/migrations/migrate.go
25.4% <0%> (+1.62%)
:arrow_up:

modules/process/manager.go
78.31% <0%> (+3.61%)
:arrow_up:

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 7f0d7c0...5edcae5. Read the comment docs.

I don't know exactly the details but I remember that it could be a bad idea to do so. For example, someone could store js file that could be interpreted by the browser since they are under the same domain and with good content-type. I would suggest to only allow a restricted list of content-type.

I've also moved this to the 1.12 milestone so that while the discussions happen we don't block the release (we can move it back to 1.11 milestone if discussions finish before an RC is made).

I think there are two mostly orthogonal concerns at play here.
The reason why I created this PR is because I exactly want my gitea instance to serve web resources like JS or CSS files from a git repository in a way that they are usable in a third-party context, that is, via CORS in another web application. In my small work group consisting of people with different skills this would make life a lot easier than, for example, having to host these resources on a separate server (and update with every push to gitea). For the same reason, restricting this PR to a list of content types that are deemed safe is not an option for me as this would surely exclude JS files.
Now, I totally understand the security concerns especially when talking about public gitea instances!
The simplest solution I can think of is adding a configuration option for gitea that would have to be set in order to activate the logic in this PR. In terms of (pseudo) code this could be as easy as changing the added line in routers/api/v1/repo/file.go to:
ctx.Context.Data["IsRawApi"] = <boolean config: deliver MIME types for raw API>
For this change, I would only need to check how configuration options are handled in gitea.
Serving raw API requests from another domain would also be an option for me. At the moment, however, I would not know what changes are needed to achieve this.

@danielappelt what about setting a proxy (on another domaine) serving the raw file of the api. This seems to satisfy jour use case (and other seems to have the same if I look at paste issue). If it is ok with you, choose a webserver (nginx, apache, caddy, ...)  and I am sure we can find a configuration that could be added in the docs.

@sapk, thank you for the offer. I would then try to use nginx as a proxy server. As far as I can tell, injecting the right MIME type in this scenario is not straight forward though.

maybe we can check here that domain name for requested url here is different from gitea configured full url doamin and then set mime type as proposed here. This way it would be possible to configure additional domain for raw files

Codecov Report

Merging #9305 into master will increase coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #9305      +/-   ##
==========================================
+ Coverage   41.50%   41.52%   +0.02%
==========================================
  Files         569      569
  Lines       74289    74294       +5
==========================================
+ Hits        30835    30853      +18
+ Misses      39616    39601      -15
- Partials     3838     3840       +2

Impacted Files
Coverage Δ

routers/api/v1/repo/file.go
71.20% <100.00%> (+0.07%)
:arrow_up:

routers/repo/download.go
42.34% <100.00%> (+2.15%)
:arrow_up:

routers/repo/view.go
39.47% <0.00%> (+0.87%)
:arrow_up:

modules/process/manager.go
78.31% <0.00%> (+3.61%)
:arrow_up:

models/unit.go
67.56% <0.00%> (+5.40%)
:arrow_up:

modules/indexer/code/indexer.go
55.26% <0.00%> (+10.52%)
:arrow_up:

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 d644934...5d5fa63. Read the comment docs.

Please resolve the conflicts

Please resolve the conflicts

I think we can close this as there is now a configurable mechanism that users can use at their own risk. Please reopen if I am incorrect about this.

Thanks for your work @danielappelt


Add type annotations

Hi,
I want to contribute to open-source projects and learn how to collaborate and work in a team.
I have been programming with Python for the last 6 years and I know Java.
I just want to ask whether it is okay to add type annotations to this project and maybe do some refactoring.
Just respond with a short answer.
And if I'm 'needed' anywhere else, please tell me :)

join our discord server https://discord.gg/Nmpdj9MQ7U
we will talk there

you can Dm me privately on this on discord we can have a convo about it.


api-easy version (0.1.0) not found

Hi,
First, I want to say this project(s) looks beautiful.
The generated package.json has the api-easy version => 0.1.0. This is not found by the npm install. I changed it to 0.3.2 and the install worked. Here is the command line error output:
$ npm install
npm ERR! Error: version not found: 0.1.0 : api-easy/0.1.0
npm ERR!     at Request._callback (/usr/local/lib/node_modules/npm/lib/utils/npm-registry-client/request.js:180:12)
npm ERR!     at Request.callback (/usr/local/lib/node_modules/npm/node_modules/request/main.js:99:22)
npm ERR!     at Request. (/usr/local/lib/node_modules/npm/node_modules/request/main.js:361:18)
npm ERR!     at Request.emit (events.js:67:17)
npm ERR!     at IncomingMessage. (/usr/local/lib/node_modules/npm/node_modules/request/main.js:327:16)
npm ERR!     at IncomingMessage.emit (events.js:88:20)
npm ERR!     at HTTPParser.onMessageComplete (http.js:137:23)
npm ERR!     at CleartextStream.ondata (http.js:1125:24)
npm ERR!     at CleartextStream._push (tls.js:363:27)
npm ERR!     at SecurePair.cycle (tls.js:679:20)
npm ERR! Report this entire log at:
npm ERR!     http://github.com/isaacs/npm/issues
npm ERR! or email it to:
npm ERR<EMAIL_ADDRESS>npm ERR!
npm ERR! System Darwin 11.3.0
npm ERR! command "node" "/usr/local/bin/npm" "install"
npm ERR! cwd /Users/rkoberg/Documents/workspace/flatiron-test
npm ERR! node -v v0.6.3
npm ERR! npm -v 1.0.106
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /Users/rkoberg/Documents/workspace/flatiron-test/npm-debug.log
npm not ok

Actually this is a bug. I'm going to fix it now.

OK, I am new to nodejs (a few days), so these might be an off topic questions for a project like flatiron and its sub/standalone projects. How do I reinstall? I haven't done much yet and I can just blow away the webapp and start fresh. However, if I had a good chunk of work done and I needed to do a reinstall my guess is that I would need to rename my project (e.g. flatiron-test.bak), then do:
$ flatiron create  flatiron-test
and copy over my custom code. Or this is a very rare thing because it is dealing with the package.json and npm update would normally handle things?
This brings up other issues (I can create separate threads if you like):

what are or where do I find the boilerplate types (create myproj  )? It is not readily apparent what types are available.
is there a 'kitchen sink' create boilerplate type?
Are there more complete examples of how to use the flatiron projects together rather than the standalone, simplistic examples in the sub projects? I have read the nodejs docs, but surely there are best practices for a project like flatiron in setting up a real world app.
when I first started with nodejs (a few days ago) I quickly found expressjs and then expressling. expressling was an extremely helpful project in seeing how to work with node and the express project. But I did not like any of the template engines. Your plates projects is exactly what I am looking for (Did you know there is a plate project? https://github.com/chrisdickinson/plate which caused me some initial confusion when doing some general searches about how to integrate with express). Anyway, how do you use plates within flatiron? (I only see examples for the browser)
I would be happy to work off the latest git master and provide feedback. What is the best way to do that? (and have other released node modules in my projects handled by npm update)

I really liked what I read in your blog posts. For example http://blog.nodejitsu.com/introducing-flatiron :
"In Node.js we have npm, which has allowed a diverse ecosystem of modules to develop. This has fostered a philosophy of creative experimentation, but not made it any easier to make these choices."
and
"A full-stack web application development framework which packages these tools together to make isomorphic and stream-based application development easier." -- how?
So far, and again it is probably just my inexperience with nodejs, but it is not clear how to take advantage of flatiron (only a few hours).
I would be happy to pay for some consulting or training on this. I/we have several projects that need collaborators or the ability to hand off completely. (main client: http://pearsonfoundation.org - new site coming in a couple of days: http://pf.contentupdates.com/)
FWIW, my back ground is with java, xsl, client side JS and server side JS with Rhino. Because, nobody can seem to write or even understand XSL I have been looking around for alternatives over the last couple of years. Recently, I tried Drupal hoping it would be easier for my teams to develop in (it is not). We have done around 10 relatively complex projects in the last 6 months centered around group interactions (Organic Groups).


Allow to install Hubble in one command

Proposal / RFE
At the moment, enabling Hubble is done is two steps.
It would be useful to have --enable-hubble and --enable-hubble-ui flags directly in the cilium install command, so it can all be installed in one command.

I think this is a duplicate of https://github.com/cilium/cilium-cli/issues/425

Duplicate of #425


Update README.md

Browser.Browser is invalid

Thanks for taking the time for a PR, but I don't think this is correct. Browser is a namespace containing an interface named Browser. So you'd want the interface by specifying Browser.Browser.
Browser.Browser reads a bit confusing, I agree, but still the readme is correct here.. Feel free to argue against this with something I can reproduce.

Nevermind, I see the problem now. There is another issue with the sample code though: Circular definition of import alias 'Browser' on line 1.
What seems to work for both cases on my end is this:
import type Browser from "webextension-polyfill";

declare global {
    const browser: Browser.Browser;
}

Can you verify this works for you as well?

The types export both a Browser namespace as default and a Browser interface as a named export:
https://user-images.githubusercontent.com/1402241/158057495-286790b3-409e-48d2-bd0c-78c3f7d67ebd.mov
Your intent was probably import type Browser but wrote import type { Browser.
Either way works:
import type Browser from "webextension-polyfill";

declare global {
    const browser: Browser.Browser;
}

import type { Browser } from "webextension-polyfill";

declare global {
    const browser: Browser;
}

Given that the latter is shorter, that's what I prefer

This is what I get when I try your approach:

Not sure if it has to do with me using that in a project not properly set up for ES6 module loader.

That's likely because you're adding that file to this project 😅

No, I added it to https://github.com/Lusito/dict.cc-translation


Allow more flexible output time steps

Currently the nowcast methods implemented in pysteps produce outputs having the same time step with the inputs. Several users have expressed their interest to relax this requirement. This would be needed for computing nowcasts of accumulated rainfall. For instance, if the time interval between the inputs is 5-15 minutes, the output time step is too coarse for computing accurate hourly accumulations.
Basically the above would require a modification of the nowcast interface to allow user-supplied output time steps. This could be implemented by adding an optional keyword argument. The extrapolation interface already supports arbitrary time steps, so the above can be trivially done for the extrapolation-only nowcast. For S-PROG, STEPS and ANVIL, one would also need to modify the autoregressive model (also discussed in Issue #115). The easiest (but not optimal) approach would be to apply linear time-weighted interpolation to the outputs of the AR model.

#191 was merged, can we close this? @pulkkins


Resizeable spell icons

What do you guys think about a runelite plugin to implement resizeable spell icons? I can look into it, perhaps as part of a spell icon rearrangement plugin. Perhaps it would be similar to implement as the prayer icon rearrangement.

https://github.com/runelite/runelite/wiki/Rejected-or-Rolled-Back-Features
I'm gonna guess resizing spells would fall under this too since it failed a poll

We're not really interested in implementing features which failed ingame polls.

Sure Jordan, but what if I implemented it?
On Fri, 1 Mar 2019, 1:22 pm Jordan<EMAIL_ADDRESS>wrote:

We're not really interested in implementing features which failed ingame
polls.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/runelite/runelite/issues/8054#issuecomment-468546564,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMGLvDEWNT4U67_WK6O6ZXPdrT6OHWfNks5vSLkJgaJpZM4bYKpR
.

The issue isn't who does the work, it's that they don't want the feature period

Ah damn, okay. Got it
On Fri, 1 Mar 2019, 1:31 pm ShaunDreclin<EMAIL_ADDRESS>wrote:

The issue isn't who does the work, it's that they don't want the feature
period
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/runelite/runelite/issues/8054#issuecomment-468548042,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMGLvJZtmvU5KeQp5y8qrskdclrjOYTvks5vSLsigaJpZM4bYKpR
.


fixed typo in bootstrap.json - closes #4661

Note:  You should probably not file bug fixes from your staging branch.  As soon as you pull down an update it's going to blow it away.  You should always submit from a branch.


add EPS payment method

Changes proposed in this Pull Request:

add redirect flow based payment method EPS: https://stripe.com/docs/sources/eps
this is pretty much equivalent to Giropay, but only supports banks in Austria

Thanks Thor!


Component-class with @observer doesn't dispose reaction if render() is hot-swapped

[mobx-react version: 6.1.4]
For a React component-class with the @observer decorator, instances of the class do not dispose their MobX reactions, if their render() method is overridden.
For example:
class MyButton extends Component {
	render() {
		return <button>MyButton</button>;
	}
	render_withLogging() {
		console.log("Start");
		return <button>MyButton</button>;
		console.log("End");
	}
	componentDidMount() {
		if (window.enableLogging) {
			this.render = this.render_withLogging;
		}
	}
}

Since the component above hot-swaps the render function, the this.render[mobxAdminProperty] attachment becomes inaccessible to the following code in mobx-react's patched version of componentWillUnmount(): https://github.com/mobxjs/mobx-react/blob/a4099e86f07b3c0778da92663a82746c077c1756/src/observerClass.js#L36-L40
Become the reaction (stored under the mobxAdminProperty key) is inaccessible, the call to [reaction].dispose() is short-circuited, meaning it never gets cleaned up.
For reference, here is where that special property is first attached: (it only runs the first time the component is rendered, so its hot-swapping of the render function is not guaranteed to be final) https://github.com/mobxjs/mobx-react/blob/a4099e86f07b3c0778da92663a82746c077c1756/src/observerClass.js#L88-L89
Real-world library conflicts
The reason I discovered the issue is because I've been using this library to enable hooks in react class-components: https://github.com/salvoravida/react-class-hooks
It conflicts because, as alluded to above, the library hot-swaps the render function of component instances just like mobx-react does, except it does it even later than mobx-react. (when a hook is first used, rather than when the render function merely begins)
Potential solutions

Attach the reaction (ie. value under mobxAdminProperty) to the class instance rather than the render function.
Patch the this.render to be a getter+setter rather than a property, and code the setter such that, if the value gets replaced, the special mobxAdminProperty property (ie. the reaction) gets transferred from the old render-function to the new one.

I favor the first solution since it doesn't add another level of indirection.
Thoughts?

Huh, hot-swapping render? Sounds like a nasty hack :) Never understood this weird desire to have hooks in classes. It's messed up an idea imo to have two ways of handling side effects and state.
In my personal opinion, I don't think this should be supported in the library. If you are feeling for it, make a PR with proper tests and let's see what happens next.

I was afraid of mentioning the react-universal-hooks library because of this sort of response. XD
This issue was opened because of the potential memory leaks (and slowdown from persistent, unneeded reactions) caused by "late hot-swapping" from any source -- not just react-universal-hooks specifically.
Want an example of library other than react-universal-hooks that uses the "nasty hack" of hot-swapping render? You're looking at it -- this library. :P
The conflict only happens because both libraries are using hot-swapping, and mobx-react uses fragile hot-swapping -- that is, it assumes it's the only one hot-swapping the function. (That is, it attaches data to its override and assumes it will remain hoisted at this.render)
That's an unwarranted assumption imo, and its conflict with react-universal-hooks is just an example of it.

Yea, as I said, feel free to make a PR with a solution and if it turns out not invasive too much without breaking too many things, we might consider merging it.

Okay, sounds good.
I suspect it is as simple as changing the two lines that attach/retrieve from this.render[mobxAdminProperty] to instead attach/retrieve from this[mobxAdminProperty], but we'll see.

Just do the swapping / if check inside the render? Or copy all own members
of the original function onto your new render function?
On Tue, Nov 12, 2019 at 8:05 AM Stephen Wicklund<EMAIL_ADDRESS>wrote:

For a React component-class with the @observer decorator, instances of
the class do not dispose their MobX reactions, if their render() method
is overridden.
For example:
class MyButton extends Component {
render() {
return MyButton;
}
render_withLogging() {
console.log("Start");
this.render();
console.log("End");
}
componentDidMount() {
if (window.enableLogging) {
this.render = this.render_withLogging;
}
}
}
Since the component above hot-swaps the render function, the
this.render[mobxAdminProperty] attachment becomes inaccessible to the
following code in mobx-react's patched version of componentWillUnmount():
https://github.com/mobxjs/mobx-react/blob/a4099e86f07b3c0778da92663a82746c077c1756/src/observerClass.js#L36-L40
Become the reaction (stored under the mobxAdminProperty key) is
inaccessible, the call to [reaction].dispose() is short-circuited,
meaning it never gets cleaned up.
For reference, here is where that special property is first attached: (it
only runs the first time the component is rendered, so its hot-swapping of
the render function is not guaranteed to be final)
https://github.com/mobxjs/mobx-react/blob/a4099e86f07b3c0778da92663a82746c077c1756/src/observerClass.js#L88-L89
Real-world library conflicts
The reason I discovered the issue is because I've been using this library
to enable hooks in react class-components:
https://github.com/salvoravida/react-class-hooks
It conflicts because, as alluded to above, the library hot-swaps the
render function of component instances just like mobx-react does, except it
does it even later than mobx-react. (when a hook is first used, rather than
when the render function merely begins)
Potential solutions

Attach the reaction (ie. value under mobxAdminProperty) to the
class instance rather than the render function.
Patch the this.render to be a getter+setter rather than a property,
and code the setter such that, if the value gets replaced, the special
mobxAdminProperty property (ie. the reaction) gets transferred from
the old render-function to the new one.

I favor the first solution since it doesn't add another level of
indirection.
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/797?email_source=notifications&email_token=AAN4NBC2NU7UAIAWMZZ75FDQTJPUPA5CNFSM4JL7WR72YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HYTZBFA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBHK7J2AKUGBTUXXTMDQTJPUPANCNFSM4JL7WR7Q
.

Just do the swapping / if check inside the render?

I'm not sure what you mean.

Or copy all own members of the original function onto your new render function?

If the only source of this.render swapping were the project developer, this could work. However, some libraries rely on modifying/wrapping this.render. For example, mobx-react, react-universal-hooks, and some custom (in npm-module) decorators I use.

For reference, I've created this test to make clear what's going wrong: (the test is currently failing)
test("#797 - replacing this.render should not break disposing of reaction", () => {
    @observer
    class Component extends React.Component {
        render() {
            return

        }
        swapRenderFunc() {
            this.render = () => {
                return
            }
        }
    }

    const compRef = React.createRef()
    const { unmount } = render(<Component ref={compRef} />)

    const reaction = compRef.current[$mobx]
    expect(reaction.isDisposed).toEqual(false)

    compRef.current.swapRenderFunc()
    unmount()
    expect(reaction.isDisposed).toEqual(true)
})

Or copy all own members of the original function onto your new render function?

That would probably look like:
	componentDidMount() {
		if (window.enableLogging) {
                         const source = this.render
			this.render = this.render_withLogging;
                         for (let key in source) this.render[key] = this.source[key]
		}
	}

(might need a different way of enumeration depending on the enumerability of the original function)
By the way, I doubt that doing the above actually will enable logging reliable, as mobx-react IIRC captures the original render in it's reaction closure, so a swapped render will probably totally be ignored when a re-render is caused by an observable change.
(That all being said, I personally don't get why one would want hooks in a component class (I mean, wouldn't just refactoring the then not be a lot more intuitive). But I even less get that why do that for an observer component, as you can leverage all mobx primitives for managing side effects already)

I agree that the usefulness of hooks in component classes goes down a lot when integrating MobX. My project used to use Redux, so I wasn't able to use external state as liberally (since connect functions have a higher overhead than MobX dependency trees), leading to me using local class variables for some complex behavior.
One place where hooks are still useful in component classes is for the "useCallback" hook -- enabling you to only have a callback updated when a variable it uses is changed. This improves performance by having letting the children components use React.PureComponent to not re-render if no props have changed.
But anyway, that's just the library that made me detect this issue; even if react-universal-hooks did not exist, I'd still think it's worth fixing this issue for other libraries that might try to use swapping of this.render.

Just as a head up: We probably won't accept a PR unless it is a really trivial change on our side, for the simple reason that the above library isn't significant enough yet to warrant the significant additional complexity on maintenance of this one while there are clear work arounds (such as splitting the component in 2, using <Observer> instead, etc.
Btw, not patching render methods is a documented limitation of mobx-react (the simple case of render = () => { } is already forbidden in observer components).

That would probably look like: [...]

Yeah, I think that would work fine for a project developer's own swapping of this.render, but it's not really a solution for cases where third-party libraries perform the swapping.

(That all being said, I personally don't get why one would want hooks in a component class (I mean, wouldn't just refactoring the then not be a lot more intuitive). But I even less get that why do that for an observer component, as you can leverage all mobx primitives for managing side effects already)

I agree that the usefulness of hooks in component classes goes down a lot when integrating MobX. My project used to use Redux, so I wasn't able to use external state as liberally (since connect functions have a higher overhead than MobX dependency trees), leading to me using local class variables for some complex behavior.
One place where hooks are still useful in component classes is for the "useCallback" hook -- enabling you to only have a callback updated when a variable it uses is changed. This improves performance by having letting the children components use React.PureComponent to not re-render if no props have changed.
But anyway, that's just the library that made me detect this issue; even if react-universal-hooks did not exist, I'd still think it's worth fixing this issue for other libraries that might try to use swapping of this.render.

We probably won't accept a PR unless it is a really trivial change on our side

Well, I created this PR for it just now: https://github.com/mobxjs/mobx-react/pull/798
The modification used to make the fix seems pretty straight-forward/trivial to me; it's just attaching the reaction to the class instance instead of the render function.

Note to self: check compatibility with devtool packages, to probably pick
the meta data from render instead, making this a breaking change.
On Tue, Nov 12, 2019 at 10:58 AM Stephen Wicklund<EMAIL_ADDRESS>wrote:

That would probably look like: [...]
Yeah, I think that would work fine for a project developer's own swapping
of this.render, but it's not really a solution for cases where third-party
libraries perform the swapping.
(That all being said, I personally don't get why one would want hooks in a
component class (I mean, wouldn't just refactoring the then not be a lot
more intuitive). But I even less get that why do that for an observer
component, as you can leverage all mobx primitives for managing side
effects already)
I agree that the usefulness of hooks in component classes goes down a lot
when integrating MobX. My project used to use Redux, so I wasn't able to
use external state as liberally (since connect functions have a higher
overhead than MobX dependency trees), leading to me using local class
variables for some complex behavior.
One place where hooks are still useful in component classes is for the
"useCallback" hook -- enabling you to only have a callback updated when a
variable it uses is changed. This improves performance by having letting
the children components use React.PureComponent to not re-render if no
props have changed.
But anyway, that's just the library that made me detect this issue; even
if react-universal-hooks did not exist, I'd still think it's worth fixing
this issue for other libraries that might try to use swapping of
this.render.
We probably won't accept a PR unless it is a really trivial change on our
side
Well, I created this PR for it just now: #798
https://github.com/mobxjs/mobx-react/pull/798
The modification used to make the fix seems pretty
straight-forward/trivial to me; it's just attaching the reaction to the
class instance instead of the render function.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/797?email_source=notifications&email_token=AAN4NBFUJ5AQ6Z2FEFPIR23QTKD4BA5CNFSM4JL7WR72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZ3VTY#issuecomment-552843983,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBGF5UUNX5W5ZRMMJBTQTKD4BANCNFSM4JL7WR7Q
.

Did you check if the logging now actually works? As said I suspect the
swapping is a no-op when it comes to reactively triggered renders
On Tue, Nov 12, 2019 at 11:05 AM Michel Weststrate<EMAIL_ADDRESS>wrote:

Note to self: check compatibility with devtool packages, to probably pick
the meta data from render instead, making this a breaking change.
On Tue, Nov 12, 2019 at 10:58 AM Stephen Wicklund <
<EMAIL_ADDRESS>wrote:

That would probably look like: [...]
Yeah, I think that would work fine for a project developer's own swapping
of this.render, but it's not really a solution for cases where third-party
libraries perform the swapping.
(That all being said, I personally don't get why one would want hooks in
a component class (I mean, wouldn't just refactoring the then not be a lot
more intuitive). But I even less get that why do that for an observer
component, as you can leverage all mobx primitives for managing side
effects already)
I agree that the usefulness of hooks in component classes goes down a lot
when integrating MobX. My project used to use Redux, so I wasn't able to
use external state as liberally (since connect functions have a higher
overhead than MobX dependency trees), leading to me using local class
variables for some complex behavior.
One place where hooks are still useful in component classes is for the
"useCallback" hook -- enabling you to only have a callback updated when a
variable it uses is changed. This improves performance by having letting
the children components use React.PureComponent to not re-render if no
props have changed.
But anyway, that's just the library that made me detect this issue; even
if react-universal-hooks did not exist, I'd still think it's worth
fixing this issue for other libraries that might try to use swapping of
this.render.
We probably won't accept a PR unless it is a really trivial change on our
side
Well, I created this PR for it just now: #798
https://github.com/mobxjs/mobx-react/pull/798
The modification used to make the fix seems pretty
straight-forward/trivial to me; it's just attaching the reaction to the
class instance instead of the render function.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/797?email_source=notifications&email_token=AAN4NBFUJ5AQ6Z2FEFPIR23QTKD4BA5CNFSM4JL7WR72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZ3VTY#issuecomment-552843983,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBGF5UUNX5W5ZRMMJBTQTKD4BANCNFSM4JL7WR7Q
.

Good point. Just tested, and component renders triggered by MobX do not call into a newly-swapped-in this.render function.
For example this fails:
test("#797 - replacing this.render should not break disposing of reaction", () => {
    let newRenderFuncCalled = false
    @observer
    class Component extends React.Component {
        @observable
        thing = 1

        render() {
            return

        }
        swapRenderFunc() {
            this.render = () => {
                newRenderFuncCalled = true
                return {this.thing}
            }
        }
    }

    const compRef = React.createRef()
    const { unmount } = render(<Component ref={compRef} />)

    const reaction = compRef.current[mobxAdminKeyForRender]
    expect(reaction.isDisposed).toEqual(false)

    compRef.current.swapRenderFunc()
    //compRef.current.forceUpdate()         // new render-func runs if triggered by this
    compRef.current.thing = 5               // but not if by this
    expect(newRenderFuncCalled).toEqual(true)

    unmount()
    expect(reaction.isDisposed).toEqual(true)
})

I suppose that a proper fix would therefore require a more substantial reworking of mobx-react's render-func wrapping. (while my PR fixes the particular bug in MobX, it doesn't solve the wider problem of MobX not having a reference to the new this.render in order to have it actually called)
I don't have time/motivation for that "proper fix" right now, so I'll close the pull-request since it's incomplete.
Will leave this issue open for now though, since I think mobx-react should at least log a warning if something tries to modify the render function after mobx accesses and wraps it, as it can lead to silent memory leaks as mentioned earlier.
It seems the fix would be as simple as adding this to the componentWillUnmount function:
if (this.render[$mobx] == null) {
    console.warn(`The render function for an @observer component (${this.constructor.name}) was modified after MobX attached. This is not supported, since the new function can't be triggered by MobX.`);
}

Feel free to make a PR with a warning, otherwise, I don't think we are too keen supporting something like that. Perhaps it will help other people to realize that trying to mix hooks and classes is a bad idea :)

The warning sounds good. I think we have a similar check already in place
to check for render = () => { } at mounting time. But that obviously
misses this case :) (btw, note that cWU can be swapped out at exact the
same way as render and then you'd end up with the very same problem (both
in mobx-react and your lib). Which is kinda the problem hooks fundamentally
solve)
On Tue, Nov 12, 2019 at 11:27 AM Daniel K<EMAIL_ADDRESS>wrote:

Feel free to make a PR with a warning, otherwise, I don't think we are too
keen supporting something like that. Perhaps it will help other people to
realize that trying to mix hooks and classes is a bad idea :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/797?email_source=notifications&email_token=AAN4NBAMDM5HAFLHCY6IGPLQTKHLNA5CNFSM4JL7WR72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZ6GYQ#issuecomment-552854370,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBDXXFLCE7JYAKWAB4LQTKHLNANCNFSM4JL7WR7Q
.

Okay, a warning would be good enough for me. (assuming the "proper fix" would require a substantial mobx-react rework)
I mainly just didn't want others to hit the "hidden bug" of lots of MobX reactions unknowingly leaking / persisting past component lifecycle.

Created a pull-request (#799) that adds a warning for the issue (replacing this.render after MobX has attached).
If one needs to do so anyway, here is a complete example of how you can, while preventing the leaking/persistence of the MobX reaction for the component:
@observer
class Test1 extends Component<{}, {}> {
	render() {
		return
;
	}
	componentDidMount() {
		setTimeout(()=>this.swapRenderFunction(), 1000); // simulate delay
	}
	swapRenderFunction() {
		const oldRender = this.render;
		this.render = function () {
			// <<< add wrapper code here
			return oldRender.apply(this, arguments);
		};

		// copy over mobx administration object
		for (const symbol of Object.getOwnPropertySymbols(oldRender)) {
			this.render[symbol ] = oldRender[symbol ];
		}
	}
}

A better way than the above (because of issue 2 mainly), is actually just to make sure the wrapper you want to place around this.render, is applied prior to the first time this.render is called (since that is when MobX attaches its own wrapper).
Actually, that won't work currently because the class-decorator stores a reference to the class prototype's render function even prior to the first call to render. This workaround would be enabled if mobx-react changed this:
const baseRender = target.render
target.render = function() {
    return makeComponentReactive.call(this, baseRender)
}

To this:
target.render = function() {
    return makeComponentReactive.call(this, this.render)
}

Is the fix above straight-forward enough to be accepted as a PR? It would enable compatibility with other libraries (or custom code) that modify this.render (prior to first render), without causing any architectural changes in mobx-react.

Since I don't see a clear path forward to making mobx-react compatible with hot-swapping of this.render, I will close this issue.
If someone thinks of a good solution (that isn't confusing like the last option listed above), feel free to bring it up.
As of now, I'll find some other way to integrate the libraries that use this.render hot-swapping (perhaps by making pull-requests for them that use alternate ways of implementing their behavior).


Anvil Chunk saving

Description
Add Chunk saving via the Anvil format.
More details on how the formats works can be found at https://minecraft.fandom.com/wiki/Region_file_format

Testing

Checklist
Things need to be done before this Pull Request can be merged.

[x] Write header (size & compression scheme)

[x] Code is well-formatted and adheres to project style guidelines: cargo fmt

[x] Code does not produce any clippy warnings: cargo clippy

[ ] All unit tests pass: cargo test

[ ] I added new unit tests, so other people don't accidentally break my code by changing other parts of the codebase. How?

For some reason currently loading vanilla chunks does not work when writing, when early return in the write_chunk then it works


Add Project Links

Closes #15

@IonBazan I haven't done the GitHub Formatter yet, as I'm unsure how it'll render urls.
For the markdown ones, I've put them as the package name rather than a new column

Looks nice! Just need to add some more coverage and it will be good to go.
For the GitHub formatter, I think it would not look good with the links as they are not clickable so let's leave it as is.

Thanks @giggsey! Your changes were released as https://github.com/IonBazan/composer-diff/releases/tag/v1.6.0

Thanks for the prompt reviews


Clarification on Resource Callbacks

I'm trying to utilize JR's resource callbacks but am having trouble understanding when these callbacks fire.
When attempting to modify relationship links that are returned to include authorization details (token, timestamp, etc), I plan to first use the create_to_many_link event to call a method that will generate the authentication credentials, however the method doesn't seem to fire.
For example:
class ProductResource < JSONAPI::Resource
  attributes :name, :price

  has_many :images

  after_create_to_many_link :generate_credentials

  def generate_credentials
    # credential stuff
  end
end

Am I invoking this incorrectly? Is there a better way to control relationship links?
(jsonapi-resources 0.7.0)

@namack I'm experiencing the same thing.  None of the link callbacks seem to fire.  Did you have any luck getting this sorted?

Is this not getting called during a create or update request? If so try replace_to_many_links or replace_to_one_link. Those are the methods that are being called when the relationships are set along with other fields. If that's the case I'll see what I can do to clear that up.

@lgebhardt for myself (and I think for @namack), I'm hoping to create a custom link for a has_one relationship when I GET the resource.
In my case I have something like:
  class MachineResource < BaseResource
    attribute :name
    has_one :current_execution_plan, class_name: 'ExecutionPlan'
    has_many :execution_plans
  end

  class Machine < ActiveRecord::Base
    has_many :execution_plans

    def fetch_current_plan
      ... logic, logic, logic ...
    end
  end

Which renders the following on a GET to /machines/9
{
  "data": {
    "id": "9",
    "type": "machines",
    "links": {
      "self": "http://localhost:8080/machines/9"
    },
    "attributes": {
      "name": "Machine 9"
    },
    "relationships": {
      "current-execution-plan": {
        "links": {
          "self": "http://localhost:8080/machines/9/relationships/current-execution-plan",
          "related": "http://localhost:8080/machines/9/current-execution-plan"
        }
      }
    }
  }

I'm trying to change the following link on the relationship from:
self: http://localhost:8080/machines/9/relationships/current-execution-plan
to:
self: http://localhost:8080/execution-plants/current?machine_id=9
Such that it can be served by this controller:
  class ExecutionPlansController < JSONAPI::ResourceController
    prepend_before_action :swap_id_for_current, only: [:show]

    def swap_id_for_current
      return unless params[:id] == 'current'
      return unless params[:machine_id]
      expires_now

      machine = Machine.find(params[:machine_id])
      current_plan = machine.fetch_current_plan
      params[:id] = current_plan.try(:id)
    end
  end

Admittedly, not the most elegant, but I'd thought I could have used one of the has *_to_one_link callbacks to set that up.

These callbacks are fired when resources are being updated or created. It sounds like you are looking to customize the serialization process. There isn't really an easy way to do this now, though I'm looking to expand the serialization stage to allow for customizations.

@lgebhardt thanks for the clarification.  @namack if this inline with what you were trying to achieve as well, perhaps we can close this issue.

@utilityboy Yes, this is inline with what I was trying to do at the time. We have since shifted strategies (to not have to customize the serialization) but it would be great to have access to customizing serialization behavior in the future.
Thanks for all the hard work @lgebhardt - this is a really great gem! We recently switched over our entire existing API to JSONAPI and we couldn't have done it without JR.

@namack Glad to hear it's proven useful. Hopefully I'll get some time to work on the serialization soon.


Adding Users?

Hi
it would be great if the rest of features listed for every other language on the https://firebase.google.com/docs/admin/setup, where available in the library, specifically, creating users?
Thank you

Eventually we'd like to support all user management capabilities in this SDK. You can help speed things up by providing pull requests.

Fixed in #67


directives ssl_ciphers and proxy_ssl_ciphers doesn't work with ssl_protocols TLSv1.3;

Environment
Include the result of the following commands:

nginx -V
1.24
uname -a
Linux 1a91f4bbe39b 6.6.32-linuxkit #1 SMP PREEMPT_DYNAMIC Thu Jun 13 14:14:43 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Description
Synopsys: you can't choose cipher with TLSv1.3 right now
directives ssl_ciphers and proxy_ssl_ciphers doesn't work with ssl_protocols TLSv1.3;
consider:
https://docs.openssl.org/master/man3/SSL_CTX_set_cipher_list/#synopsis
SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) only for ssl.
for TLSv1.3 you should use SSL_CTX_set_ciphersuites()
in function ngx_ssl_ciphers is used command for tls1.2
changing it from SSL_set_cipher_list to SSL_CTX_set_ciphersuites solves the problem for work with tls1.3.
https://github.com/nginx/nginx/blob/stable-1.26/src/event/ngx_event_openssl.c#L887
launching nginx with bellow config will print
[emerg] SSL_CTX_set_cipher_list("TLS_AES128-GCM-SHA256") failed (SSL: error:1426E0B9:SSL routines:ciphersuite_cb:no cipher match)
Problem solves quite easy by adding extra directive for list of ciphers for TLS1 1.3
ex:
ssl_protocols TLSv1.3;
ssl_ciphers_tls TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
ssl_ciphers_tls - because ciphers in TLS 1.3 starts with TSL

[x] The bug is reproducible with the latest version of nginx
yep, it will
[x] The nginx configuration is minimized to the smallest possible
to reproduce the issue and doesn't contain third-party modules
yep

nginx configuration
# Your nginx configuration here
error_log /opt/nginx/logs/error.log;
daemon off;
master_process off;
# worker_processes 1;

events {}

http {
    ssl_certificate /home/nginx/ssl/server.crt;
    ssl_certificate_key /home/nginx/ssl/server.key;
    ssl_protocols TLSv1.3;
    ssl_ciphers TLS_AES_128_GCM_SHA256;
    proxy_ssl_ciphers TLS_AES_128_GCM_SHA256;

    log_format main '$ssl_cipher $remote_addr - $remote_user [$time_local] "$request"'
        '$status $body_bytes_sent "$http_referer"'
        '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /opt/nginx/logs/access.log main;

    upstream firstMock {
        server <IP_ADDRESS>:10001;
    }

    server {
        listen 10000 ssl;
        location / {
            proxy_pass https://firstMock;
        }
    }
}

or share the configuration in gist.
nginx debug log
It is advised to enable
debug logging.
# Your nginx debug log here

or share the debug log in gist.

We do not consider adding TLSv1.3 ciphers support for these directives.
Rather the underlying library should support this.
Meanwhile you can use the ssl_conf_command directive for this purpose.
See for details: https://trac.nginx.org/nginx/ticket/1529

Correct the documentation, not a word that this directive does not support TLS 1.3


Dev

Codecov Report

Merging #47 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
+ Coverage   94.16%   94.17%   +0.01%
==========================================
  Files           7        7
  Lines         514      515       +1
==========================================
+ Hits          484      485       +1
  Misses         30       30

Impacted Files
Coverage Δ

src/num.c
96.15% <100%> (+0.15%)
:arrow_up:

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 438e37c...b1a196f. Read the comment docs.


Quick fix for mypy 0.620 behavior

With the new release of mypy 0.620, the mypy part of the test started failing (an example here):
qcodes/instrument/parameter.py:1046: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1052: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1055: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1059: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1224: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1229: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1233: error: The type alias is invalid in runtime context
qcodes/instrument/parameter.py:1237: error: The type alias is invalid in runtime context

~I did not want to spend a time on figuring out why, so here is the fix that disables this new version.~
See more on mypy github https://github.com/python/mypy/issues/5354 - it might be related.
The edits in the code make the type objects be type-annotated which makes the new mypy 0.620 happy 😄 👍 🥇

@jenshnielsen , you're right ...