Function component renders incorrectly after Fast Refresh

I've encountered at least one scenario where a function component rendered after a Fast Refresh looks wrong and requires a hard refresh to fix. Changing it to a class component fixes this.
GIF:

React Native version:
System:
    OS: macOS 10.15.2
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
    Memory: 17.85 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 13.7.0 - /var/folders/7q/w_rts5kx5gzfk051cpw8vlzh0000gn/T/yarn--1579912407030-0.8849373494224462/node
    Yarn: 1.21.1 - /var/folders/7q/w_rts5kx5gzfk051cpw8vlzh0000gn/T/yarn--1579912407030-0.8849373494224462/yarn
    npm: 6.13.6 - ~/.nvm/versions/node/v13.7.0/bin/npm
  SDKs:
    iOS SDK:
      Platforms: iOS 13.2, DriverKit 19.0, macOS 10.15, tvOS 13.2, watchOS 6.1
  IDEs:
    Android Studio: 3.5 AI-191.8<IP_ADDRESS>10548
    Xcode: 11.3.1/11C505 - /usr/bin/xcodebuild
  npmPackages:
    react: ~16.9.0 => 16.9.0
    react-native: https://github.com/expo/react-native/archive/sdk-36.0.0.tar.gz => 0.61.4

Steps To Reproduce

Pull down this project: https://github.com/mxhold/rn-fast-refresh-bug
Open app in iOS simulator with Fast Refresh turned on.
Uncomment the commented line in App.tsx that sets flexGrow.
Save the file, triggering a refresh. Note the border is unchanged, as expected.
Comment out the same line (returning the file to its original contents).
Save the file again, triggering a refresh again.  Note the border has collapsed as if flex: 1 was not set (!).
Press Cmd-R to refresh. Note the border goes back to the original position.

Describe what you expected to happen:
It is surprising that after step 6 the screen renders incorrectly and requires a hard refresh to render correctly.
I would have expected that after step 6, the border would have stayed in the same position but instead the view is rendered as if flex: 1 was not set at all.
Notes

This example doesn't work if you change App to a class component. It has to be a function component.
This doesn't seem to be reproducible in a Snack.

I just saw this (for future reference, please @-mention me instead of assigning because I don't see assignments anywhere). Unfortunately, since I already read this issue, it has already disappeared from my notifications, so I won't see it again unless someone pings me. Please ping me again next week! Thank you.

@gaearon

This has sit stale for awhile. Issues with Fast Refresh can be frustrating for inner loop efficiency. Does this still repro on latest?

Bump

Bump

Is that a yes? Were you able to repro on latest? This issue was opened against 61.

I may be encountering the same or a related issue. I have a function component that works fine when first loaded. If I edit the file and the component is fast refreshed it starts an infinite loop. Even after a reload it still infinite loops. Only way to break the loop is to close the app on the emulator and open it again, seems some sort of bad state is persisted even across reload? Working on nailing down a repro to see if it's the same kind of issue as reported here.
@gaearon

@AndrewMorsillo This sound quite bizarre! (I don't think it has any relation to this issue btw.)

Is that a yes? Were you able to repro on latest? This issue was opened against 61.

No, I just haven't got a confirmation that this either doesn't repro or that it was fixed.

Actually I wonder if this case is related to conflicting values between long and shorthand flex property notation.
We warn for this in the DOM because it's broken: https://reactjs.org/blog/2020/02/26/react-v16.13.0.html#warnings-for-conflicting-style-rules
Maybe RN has the same problem?


cached_property issue / descriptor issue

Feature
I have a class like this:
from functools import cached_property
def f(v):
    # do something
    ...

class C:
    def __init__(self, data: dict):
        self.data = data

    @cached_property
    def calculated_data(self) -> dict:
         return {k: f(v) for k, v in self.data.items()}

(For the exact implementation see ep12/PyOPM, but the implementation is not really important in this case.)
Something like
c = C(some_dict)
for k, v in c.calculated_data.items():
    # do something
    ...

results in an error:
Traceback (most recent call last):
  File "basic.py", line 17, in <module>
    m = p.match({0, 1, 2})  # not a dict -> m is None
  File "/home/simon/git/PyOPM/pyopm/core.py", line 263, in match
    for kt, v in self.compiled_pattern.items():
  File "/home/simon/git/RustPython/Lib/functools.py", line 951, in __get__
    "Cannot use cached_property instance without calling __set_name__ on it.")
TypeError: Cannot use cached_property instance without calling __set_name__ on it.

I think it might be related to the descriptor implementation, but __set_name__ does not seem to be called using rustpython. Everything works fine with cpython and pypy.
Since the cached_property implementation of rustpython and cpython is exactly the same, this might be an internal issue. I think that cached_property.__set_name__ should be called with name=func.__name__ (which is 'calculated_data', of course)... I think python itself performs this call (I could not find a line of python where __set_name__ gets called), so maybe the rustpython implementation does not do that at the moment.
I haven't looked at the rustpython source code (my rust skills are extremely limited) but maybe someone else knows where to have a look...
Python Documentation
cpython doc: implementing descriptors

Thanks for the bug report, this definitely looks weird! I'll look into it.

Oh, I think CPython calls __set_name__ on all of the descriptors in a class declaration, that shouldn't be too hard to do.

Fixed (I think) in #1835

I don't know that much about the python spec / implementation in this regard, but my code works with #1835!
(It fails a couple of lines below...
Can I open a series of issues until my code works with rustpython? I know this project is young, but maybe those real world tests would be a good thing?
My small project works better with pypy than with the reference cpython so I hope that one day (soon) rustpython will work as well as pypy for this code :smile:.
However, it might be a real series of issues, the next one being AttributeError: 'code' object has no attribute 'co_varnames' which is definitely more work-intensive.
If you think that rustpython is not in a "make it fully compliant" stage, I wouldn't pollute your issues when you first want to get the most-used features of python cpython compliant...)
Apart from that rfc a big thank you for your work! That was quick! Wow!

Can I open a series of issues until my code works with rustpython?
I think that would be fine! As you said, testing a real world project on RustPython would definitely be a good kind of stress-test.

AttributeError: 'code' object has no attribute 'co_varnames'
I actually just implemented that yesterday in #1834 :smile:. It should be merged soon.


Retire coronavirus-employee-risk-assessment smart answer

Retire the coronavirus-employee-risk-assessment smart answer.
:warning: This application is Continuously Deployed: :warning:

Merged changes are automatically deployed to staging and production.

Make sure you follow the guidance for deployments before you merge.

Check your branch is being deployed in the Release app, after merging.

Looks good to me 👍 Only thing I'd suggest is updating this PRs title to have the Smart Answer name so that it is easier to find if we decide to try re-instate it (as we anticipate we might)

Done - good spot - thanks


Update README.md

Updating readme with unfurl.

Should have looked at other PRs first ;__;
Dupe of

https://github.com/robre/scripthunter/pull/6
https://github.com/robre/scripthunter/blob/2a1832fc62412f4b9ba54d3a7dccac3b99409f1a/README.md


Automatic file expiration in S3 and DynamoDB

To save on costs, it should expire files based on usage statistics .e.g., most recently used files should stay and least used files should go.

ytmp3-janitor solves this issue


Add ArgsEscaped support for CRI

This PR addresses windows images that are broken when created using the "shell form" entrypoint/cmd in Dockerfile. Associated bug - https://github.com/containerd/containerd/issues/5067
The approach taken to fix this bug is as discussed by @kevpar here - https://github.com/containerd/containerd/pull/6479#discussion_r813320420
Docker uses non-OCI field called ArgsEscaped to address how the image 'ENTRYPOINT' and 'CMD' are interpreted on windows. This PR adds support for ArgsEscaped in containerd without changes to the OCI spec and also adds changes to handle cases when image ENTRYPOINT and CMD can be overriden by 'Command' and 'Args' specified in the podspec.
The fix in this PR does the following:
Reads the ArgsEscaped value from the image got from docker without making OCI spec changes (In file image.go)
Image ENTRYPOINT and CMD fields can be overriden by the container 'Command' and 'Args' fields specified through the podspec. But the ArgsEscaped field should really only affect the behavior of the image values, and not the overall evaluation of args for the container. Therefore, we need to evaluate if the first arg in our list is coming from image entrypoint/cmd and only if it is coming from the image, we should we treat the first arg as already escaped. (in file spec.go spec_windows.go)
Regression tests have also been added to this PR.

Looks like I accidentally deleted the fork that had the branch with the changes in PR #7135 .
Addressed the following comments @dmcgowan left this morning and wanted to submit new changes and realized this.
https://github.com/containerd/containerd/pull/7135#discussion_r1122602955
https://github.com/containerd/containerd/pull/7135#discussion_r1122604188
https://github.com/containerd/containerd/pull/7135#discussion_r1123617777
Closed PR #7135  and created this new one. Apologies for this!
@dmcgowan @dcantah The only changes this PR in addition to PR #7135 are the following:

Change function name WithProcessCommandLineOrArgs() to WithProcessCommandLineOrArgsForWindows()
In [pkg/cri/opts/spec_nonwindows.go] , panic() was removed from WithProcessCommandLineOrArgsForWindows() and updated to the following:

func WithProcessCommandLineOrArgsForWindows(config *runtime.ContainerConfig, image *imagespec.ImageConfig) oci.SpecOpts {
return func(ctx context.Context, client oci.Client, c *containers.Container, s *runtimespec.Spec) (err error) {
return errdefs.ErrNotImplemented
}
}
Could you please take a look at this PR instead for this work? Thanks a lot!

@kiashok Can you look at the linter issues?

@kevpar Added you as a reviewer as you were on the old one, lets try and land this for 1.7

Check failure on line 22 in pkg/cri/opts/spec_nonwindows.go
File is not `goimports`-ed (goimports)

The linter run wasn't loading for me, but the annotations did; that seems to be what the CI is whining about


[chore] add google provider documentation for wish.

Fixes issue #6
The docs for setting up google provider in wish has been added.
Kindly review.
Thank you.

Nice job @poriacodes it seems you may have copied bot the docs for GitHub OAuth flow and that of Google OAuth as well from the README

Thank you. I have fixed it now.


twotx: allow git to merge the twotx ci patch

this should hopefully mean we dont need to update the file all the time. i was starting on an experiement to have the ci script merge from a special twotx branch into monorepo master, and get rid of the patch file, and discovered you can actually have git fall back on the merge algorithm when a patch file fails to apply

looks like this. the currently broken patch file now works
hana@laptop:solana$ git am -3 ../spl/token/twoxtx.patch
Applying: Multiply packet size by 2
Using index info to reconstruct a base tree...
M       ledger/src/shred.rs
M       ledger/src/shred/legacy.rs
M       ledger/src/shred/merkle.rs
M       ledger/src/shred/shred_code.rs
M       rpc/src/rpc.rs
M       sdk/src/packet.rs
Falling back to patching base and 3-way merge...
Auto-merging sdk/src/packet.rs
Auto-merging rpc/src/rpc.rs
Auto-merging ledger/src/shred/shred_code.rs
Auto-merging ledger/src/shred/merkle.rs
Auto-merging ledger/src/shred/legacy.rs
Auto-merging ledger/src/shred.rs


Update the list of currently supported SDs using ScrapeConfig

It has been some time and the list of SDs that is supported by ScrapeConfig is not up to date with the current list of SDs offered. It needs to be updated. This is the link.

api reference will be always updated https://prometheus-operator.dev/docs/operator/api/#monitoring.coreos.com/v1alpha1.ScrapeConfig. The mentioned link is user guide but we haven't put all the examples in there as its still alpha and there can be changes in API.
But that can be updated better and navigate user to check api reference to see currently supported scrape configs


Add aria-label to the listbox for autocomplete, for accessibility

Hi there!
I'm interested in adding an aria-label field for this autocomplete tooltip to meet the guidelines of this accessibility check.
Since the autocomplete is an input field, I propose providing it with an aria-label indicating that it's the input field for the autocomplete. What do you think?

This field will be associated with the editor via an aria-haspop attribute, and is not something people will be directly navigating to. Can you describe concretely how adding a label to it improves the quality of the read content during completion?

When I'm in the CM6 editor and I type "." to get the autocomplete selections, the Mac screen reader says:
<the function name> selected
1 out of 100
main
You are currently in a text element inside of a listbox

I thought that having it read out autocomplete would be beneficial because the aria-label field seems to be strongly recommended for input fields (the listbox in question), at least according to the accessibility guidelines I'm following in the link on the OP.
It sounds like you feel that it's too chatty to also add that in. Would you say that the accessibility guidelines about listboxes needing aria-labels are inaccurate in this instance?

Attached patch does something similar, including support for internationalization.


stop the backpropagation

Hi, i have a network like this. And  i want to stop the backpropagation from CNN  to Inception. The Inception just get the gradients from LSTM. What should i do ? Thank you for your help.

input = Input(...)
inception = ....
cnn = ...
lstm = ...
inception_out = inception(input)
cnn_input = Lambda(K.stop_gradient)(inception_out)
cnn_out = cnn(cnn_input)
lstm_out = lstm(inception_out)


Multiple feeds in single application using NuGet Server

Hi Guys,
I have to create multiple NuGet feeds in single applications like proget and myget feeds. currently, am using NuGet.Server for my feed. am having separate applications for each feed. now I need a number of feeds so it leads to implementing a number of sub-applications. is there is any other options available in NuGet server?
I have found the similar requirement in this question
https://github.com/NuGet/NuGetGallery/issues/3520
as per @joelverhagen  comment in that question. I have downloaded and checked the source. as per my knowledge, only 3 feeds/application can be possible in that source. if I am wrong please correct me.

How many feeds can be created in that NuGet Server development source
is there is any document available to use that development source for multiple feeds..?

Thanks in advance

The sample provided in the dev branch has three mentioned, but you could certainly add more by following the same pattern. We have not done any testing to what the practical limit there is in a single process. Could you describe your specific scenario so we can better help you?

Hi @joelverhagen
We have nearly 8 lack customers, we are trying to provide customer specific feeds.
so one feed link will show that specific customer's packages alone. like these, we need to provide for multiple customers.
I can see in MyGet and ProGet servers provide the option to create N number of feeds. likewise, any option is available.
Or we can use any other way to achieve this in our NuGet Server itself.?

If you consume the NuGet.Server.V2 package produced by the dev build of the NuGet.Server repository (of which you'll have to build locally), it should be possible to achieve this. NuGet.Server provide basic tools to achieve this but not a ready-made "N number of feeds" implementation.

@joelverhagen  ok thanks, as per your suggestion we are going to modify the NuGet.Server source to achieve N number of feeds.
Is there is any document for this multiple feeds workflow..? or how to define packagesPath and feed links for this multiple feeds.

Nope, no such documents. The best offering is the sample project in the dev branch.


Helm install via yum

Kubernetes version changes in doc .Changed helm.tf to kubernetestools.tf as discussed.please review.

Also, rename the install kubectl null_resource to install kubernetes tools or something similar. So, we'll use only 1 null_resource and multiple file provisioners and run each script separately.

@hyder  base version changed to 1.3.3. helm variables has been removed and doc changes done.


[FLINK-8778] Migrate queryable state ITCases to use MiniClusterResource

This sits on top of #5589.

@zentol I'm fixing things on #5589 because this PR is only about the last commit.

Closing in favour of #5589.


Website option in the app leads to dead website

When clicking on the "visit our webpage" option, you'll get a timeout onto the website, as shown on the second screenshot.

I think it comes from the fact that you forked the projet and the original author has deleted the website

also, one more little thing, ther is a typo in the description of the repo, you wrote "you're" instead of "your" (no big deal, but it always triggers my ADHD when I see it :smile: )

Thanks for your feedback, the Typo should be fixed. And yes, it currently leads to a dead website, since I just adapted the URL when forking. I will remove the Website option in the next release until a Website is made.


[Traffic Status] SLAPI_API_Error 1007: Unknown API-response code encountered

Hi,
I've had since a long time an issue and couldn't see any data in the Lovelace Traffic Status card.
So i removed entirely the HASL Lovelace cards (i had also the Departure card) and the HASL integration. After a reboot of HA and a fresh install, i see the following error in the HA logs for the Traffic integration:
2022-03-17 18:30:07 DEBUG (MainThread) [custom_components.hasl3.slapi] Will call TL2 API
2022-03-17 18:30:09 DEBUG (MainThread) [custom_components.hasl3.slapi] SLAPI_API_Error 1007: Unknown API-response code encountered
I figured out by using directly SL TL2 API that error 1007 is "Too many requests per month".

It would be great to catch this error in a future release since users can define their own polling rate.
Also is the number of Traffic sensors affecting the polling  #rate, meaning the more sensors user defines, the slower the polling rate shall be ?

Here is my configuration for the Traffic integration for info:

I don't know why i still got this error 1007 since it should be below the 10k requests/month but maybe the counter also includes all the API requests falling in error. Anyhow i'll wait a couple of days (or a month) and see if i get the card again.

Request quotas are not dependent on how many boxes you check (it actually always fetches all data however discards the ones you elected not to have as a sensor). By default it should use one request every 300 seconds.
I have it running on my own machine and it seems to be working there when I look at the history. However I do see some 1007 errors occurring from time to time but recovering within a couple of minutes. I have reported this to SL but I am unable to troubleshoot.
I have done some work on the logging to make sure it "looks nicer" and so you wont need to dig into debug log to get the error codes etc. This will be available as soon as I have time to publish which most likely is today.. =)

Fixed in 3.0.6 in all essential regards.


Hardening WireCloud installation

Proposed changes
This PR improves WireCloud installation.
Types of changes
What types of changes does your code introduce to the project: Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Update only documentation, not any source code.

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

[X] I have read the CONTRIBUTING doc
[ ] I have signed the CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
N/A

Codecov Report

Merging #59 (c1a03a3) into main (baffe6e) will decrease coverage by 5.63%.
The diff coverage is 29.41%.

@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   88.67%   83.04%   -5.64%
==========================================
  Files           2        2
  Lines         636      690      +54
==========================================
+ Hits          564      573       +9
- Misses         72      117      +45

Impacted Files
Coverage Δ

lets-fiware.sh
82.13% <29.41%> (-5.89%)
:arrow_down:

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 baffe6e...c1a03a3. Read the comment docs.


radius parameter in the SuperClusterAlgorithmOptions

Hi, me again !
Do you think it is possible to add a radius parameter in the Super Cluster Algorithm Options ? I saw it is fixed to 60 in the supercluster.ts file on line 41. If I could have set my own value, I would have go with that algorithm instead of the Grid Algorithm. With the grid one, I can set a grid size.
Thanks 🙂 !

That's a mistake. Fix incoming.


[V1.5] Add TaskAddress to UI

Task Address now shows up properly in the UI

Coverage decreased (-0.008%) to 82.103% when pulling 0ceab8548ebe10c748a0cb6cae8dc6c23dd47ad4 on jeffreygohkw:master into 3e8e14d0e1f706f4960d8879301dec03f303aa75 on CS2103AUG2017-W09-B2:master.


[Hotfix] update placeholder text for tags

Reviewer: @Tanmay-97
Estimate: 5 mins

Ticket
Fixes: -
Description
Goal
Make it more obvious you can type to create a new tag with updated placeholder
Changes

Update placeholder "Find or create tags"
Update wording -- "add" -> "create" tags

Future Tasks (optional)

Why do we have create option in the landing page? Unless we can allow users to select some cards and apply new tags, it seems intuitive to only allow filtering by tags rater than adding? (@amiraliemami @lickem22 @Tanmay-97 )

How has this been tested?
To-do before merge (optional)
Checklist
Fill with x for completed.

[x] My code follows the style guidelines of this project
[x] I have reviewed my own code to ensure good quality
[x] I have tested the functionality of my code to ensure it works as intended
[x] I have resolved merge conflicts

(Delete any items below that are not relevant)

[ ] I have updated the automated tests
[ ] I have updated the scripts in scripts/
[ ] I have updated the requirements
[ ] I have updated the README file
[ ] I have updated affected documentation
[ ] I have added a blogpost in Latest Updates
[ ] I have updated the CI/CD scripts in .github/workflows/
[ ] I have updated the Terraform code

Thanks for taking this @suzinyou

As far as I understand, main page Tag filter does not allow you to create tags, and it should not. We should say Filter by tags here

Ah you are right! Fixed

On the add/edit page, find or create tags is only mildly helpful. No options should instead say No tags created. Start typing to create.

This is default MUI component and wasn't straightforward to override it, so I'll leave it as is for now..


Trailing comment blocks causes parser error

LAMS rule exemption block will cause parsing error if it's followed by a regular comment block.
Example that causes parsing error
view: some_view {

  # LAMS
  # rule_exemptions: {
  #   K1: "Doesn't need primary key"
  # }

  # Some other developer comment
}

Example without error (comments separated by non-comment contents):
view: some_view {

  # LAMS
  # rule_exemptions: {
  #   K1: "Doesn't need primary key"
  # }

  suggestions: no

  # Some other developer comment
}

Another example without error (regular comments come before LAMS):
view: some_view {
  # Some other developer comment

  # LAMS
  # rule_exemptions: {
  #   K1: "Doesn't need primary key"
  # }
}

What's expected:
Comment blocks—when separated by an empty line—should stop being meaningful for LAMS, and they shouldn't cause parser error because of that.

Hi @teng-vungle - sorry I didn't see this until just now, otherwise I would have tried to squeeze the fix in with the v3 release that just went out.
Anyway, I will take a look at this behavior and double check to make sure there isn't some obscure reason why it works this way, otherwise your expected behavior makes sense to me!

Thanks for the offer for more info.
I think the cause is pretty clear here, as the \s* part of the regex on this line: https://github.com/fabio-looker/node-lookml-parser/blob/master/lib/parse/index.js#L21
Unfortunately, I had just prioritized this lower as:

it is unexpected behavior rather than a bug per se
it has a reasonable "work around"
it could break users who depend on the current format and may have line breaks in the middle of their conditional comment blocks

I'm still a little undecided on how I would like to release this change without disrupting people... perhaps a command-line flag, although it would need to be passed down into the parser module as well


Faulty DMA Buffer Overflow in adc_trig example

Hi,
While experimenting with the ADC DMA examples, I discovered a bug in the implementation. I haven't completely root caused it, but I wanted to file an issue to keep track of it.
I assume this bug is part of the DMA implementation in #86
Currently, the DMA peripheral is set up in circular buffer mode to repeatedly transfer ADC samples into a fixed buffer. Sometimes, when the DMA peripheral reaches the end of this buffer, it causes a spurious BufferOverflow error when using the read_available() method.
This only seems to occur when the DMA transfer has reached the end of the buffer space and is about to wrap around to the start. The example adc_trig.rs uses a buffer size of 256 and a sample rate of 1Hz, so it takes a while to surface this bug. If you speed up the sample rate or decrease the buffer size, you can reproduce this issue much more quickly.
The issue seems to be caused by the function check_overrun_inner() which is responsible for checking, based on the current DMA status, if the DMA peripheral has overwritten data that has not been read yet.
It seems that if the DMA write pointer is located at position 0, but the transfer_state.complete flag is not set, this causes a spurious buffer overflow.
The DMA write pointer is calculated from the DMA_CNDTRx.NDT  register field, which is supposed to indicate the number of remaining items to transfer. It seems that if this counter has restarted, and is equal to the length of the buffer, but the transfer complete flag is not set, this error condition is triggered.
I am not certain how this can happen: I assume that the transfer complete flag gets triggered by hardware pretty close to when the NDT register reloads its value, but somehow the example code is triggering this behaviour.

Forgot to mention, I am using a 32L0538DISCOVERY dev board, which is an stm32l0x3 device. In order to get the example to build, I removed the #cfg checks in adc.rs, and the required features from Cargo.toml.
I also had to change the UART peripheral to match the dev board, but I assume these changes shouldn't affect the behavior of the code.
The ADC DMA transfers seem to be working, until the example code eventually panics due to the aforementioned BufferOverflow error.

(Offtopic, but what did you need to adjust with the UART peripheral? Did you specify the mcu-STM32L053C8Tx cargo feature?)

Thanks for the report! I'll take a look later to see if I can reproduce this with the STM32L0x2 device I developed this with.

Hi, I pushed my experiments into a new branch and will try to answer your questions:
apgoetz/stm32l0xx-hal/tree/adc-dma-testing
@dbrgn, I have a usb-uart device connected to PB6 and PB7 on my dev board, which requires using USART1 instead of USART2. Just switching the USART from USART2 to USART1 caused a compilation error though:
no method named `usart` found for struct `stm32l0::stm32l0x3::USART1` in the current scope
  --> examples/adc_trig.rs:54:10
   |
54 |         .usart(
   |          ^^^^^ method not found in `stm32l0::stm32l0x3::USART1`
   |
   = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
   |
11 | use stm32l0xx_hal::serial::Serial1Ext;

However, adding the use stm32l0xx_hal::serial::Serial1Ext; fixed the problem for me.
Could this be another issue? I noticed this trait did not need to be imported if I use USART2.

@hannobraun , Thanks for implementing this, while testing this out tonight, I got a nice picture that shows that the triggered DMA is essentially working correctly:

That's a plot of the Power spectral density of the raw ADC readings in the buffer.  You can clearly see the AC mains hum at 60Hz, as well as the first harmonic aliased at 80Hz.
In order to get this picture, I changed the sample rate to 200Hz instead of 1 Hz, and changed the analog pin to PA5, since on my dev board, PA0 is connected to a button with a pull down.
Also, in order to get these examples to build, I had to removed the required-features lines from Cargo.toml, as well as the #cfg feature flash in adc.rs. This was preventing the code from building for my stm32l0x3 device.
Unfortunately, I am still seeing the BufferOverrun errors, and especially unfortunately, it seems that the exact behavior of when the BufferOverrrun happens depends on whether or not optimizations are turned on. If -Os is used, then the dma transfer can successfully complete multiple times, but if optimization is turned off, then it almost always fails on the final data element of the first transfer.

Interestingly, if you make the adc_trig.rs example wait until the buffer is half full or completely full to drain it, the issue goes away. This is exposed in the DMA peripheral in the interrupt flags HTIF and TCIF.

HTIF means that the transfer is half complete
TCIF means the transfer is fully complete

In most use cases, I would expect higher level code to wait for one of these flags to be set true, or wait for an interrupt when these flags are set.
I added helper functions to allow higher level code to see the DMA status flags with new pub functions. I modifed adc_trig.rs to wait for the buffer to be half or completely full, and then there was no issue with running the example for a long period of time.
You can see an example of this here:  adc-dma-transfer-wait.

Thanks for digging deeper into this, @apgoetz. I haven't had a chance to take a look myself so far, but I hope I can get to it soon.

Also, in order to get these examples to build, I had to removed the required-features lines from Cargo.toml, as well as the #cfg feature flash in adc.rs. This was preventing the code from building for my stm32l0x3 device.

I added these restrictions because I didn't have an STM32L0x3 device to test with, so I figured I'd just restrict the code to what I did test with instead of giving a false sense of security. Since you confirmed that it basically works on STM32L0x3, a pull request to remove these restrictions would be a good idea (maybe after this bug is resolved?).

@apgoetz: I can reproduce the error on STM32L0x2 and can also confirm the following part of your analysis:

It seems that if the DMA write pointer is located at position 0, but the transfer_state.complete flag is not set, this causes a spurious buffer overflow.

I've modified check_overflow to return some more information: https://github.com/braun-embedded/stm32l0xx-hal/commit/3d67103960e4be0d60c094f08996c8817e6aa62b
The output I get every time is this:
panicked at 'called `Result::unwrap()` on an `Err` value: BufferOverrun(BufferOverrun { read_pos: 255, write_pos: 0, reason: ReadGreaterThanWrite })', examples/adc_trig.rs:82:34

It seems to me the issue is that the write position wraps, but transfer_complete is not set, which invalidates the assumptions of the code.
I have yet to explore this further, but it sure looks like we have a race condition in Channel::transfer_state: https://github.com/stm32-rs/stm32l0xx-hal/blob/b8147f13c455942b4374c353b33b486e23b30172/src/dma.rs#L469-L471
First we read the flags (before the write has wrapped), then the write wraps, then we read NDT (which reflects that the write has wrapped). No idea right now how to prevent this. I'll do some thinking and reading, but if anyone has an idea in the meantime, I'd love to hear it.

@hannobraun , Thanks for the background on the required-features. Once there is a solution for the underlying DMA implementation then we can change the requirements. Also, sorry for the long-winded replies: I am new to the rust language and explaining everything in detail kind of helps with my though processes.
I did some more reading on this topic today. Unfortunately, I think it will be really hard to have a sound interface for any code that accesses a dma buffer while a transfer is ongoing.
A lot of the effort so far has been on determining safe traits to use to describe the buffers that DMA acts on. The state of the art on defining these traits seems to be located at ra-kete/dma-poc.
Most of this effort focuses on non-repeating dma transfers, where the goal is usually to speed up data transfer through a peripheral. There has been much less effort on circular and double buffered dma transfers, where the end goal is to maintain strict timing requirements for real time systems.
I looked at DMA implementations located in other stm32 crates, including stm32f1xx-hal stm32l1xx-hal stm32f7xx-hal stm32l4xx-hal stm32g0xx-hal
Most of these hal crates just provide implementations around for single dma transfers. However, stm32f1xx-hal and stm32l4xx-hal do provide implementations that support circular buffers.
The basic idea is to split the receive buffer into two halves, and then only allow access to the half of the buffer that does not currently have a transfer taking place. This still does not make the code safe, because there is no guarantee that the DMA transfer won't wrap around and clobber the data in the half that you are holding, but it provides the best timing guarantees, since at least the DMA transfer is in the other half of the buffer when you access it.
A detailed explanation of this approach can be seen in ra-kete/dma-poc#1
Getting back to the topic at hand, I think maybe we should reconsider the API for the ADC-DMA interface. I don't think it really makes sense to expose an iterator over the individual samples in the buffer: Most of the time, you will want to batch up ADC samples and process them all at once. An interface that provides access to a completely filled DMA buffer that is triggered by the half-transfer or transfer complete interrupts might make more sense.  It also might make sense to provide users with the option of doing a continuous DMA transfer or a one-shot DMA transfer. It is a lot easier to reason about data races if you know the DMA is deactivated when you access the buffer.

Thanks for doing all this research, @apgoetz. There has been a lot of movement in the space since I worked on the the DMA code in this crate. It would definitely be good to incorporate all this here, although I don't know if now would be a good time, or if waiting for further progress in the working group's focus project would be beneficial.
All that said, I'm already busier than I'd like, and I'm not available to work on any larger update of the DMA and/or ADC APIs any time soon. I am interested in fixing this bug though, and I hope it can be done with a focused change to the racy method I quoted above.

I tried to fix the race condition by reading the two registers in a loop, only returning a result once two reads in a row would be the same. I did this under the assumption/hope that the race condition exists purely in the Rust code, and that the update of the registers by the DMA is atomic.
Turns out, that's not the case. It's totally possible to read the registers twice in a row, get the same result each time, and still have read an inconsistent state (i.e. NDT having wrapped, without the flag having been set).
I'll think some more about this, but right now it looks to me like the existing API can't be supported by the hardware, and we'll have to change the API, as @apgoetz suggests.

OK. Too bad the quick fix didn't work.
I think i would like a to wait a little bit longer until the best practices around this dma has settled a little bit. Once that has happened, I would be happy to work on a new implementation.

@hannobraun , I have been working on a new implementation of the dma driver that only supports "oneshot" dma transfers. The idea here is that since the DMA controller can write to the buffer while you are accessing it, it makes sense to have a driver design where a buffer is given to the ADC driver, and only returned once the dma transfer has completed.
You can still have continuous transfers by using two different buffers of samples, and the adc_dma.rs example shows how to do that.
Can you take a look at the branch and see if this is something that be integrated into the crate?
Branch is at apgoetz:adc-dma-testing

@apgoetz

I have been working on a new implementation of the dma driver that only supports "oneshot" dma transfers. The idea here is that since the DMA controller can write to the buffer while you are accessing it, it makes sense to have a driver design where a buffer is given to the ADC driver, and only returned once the dma transfer has completed.

I haven't taken a look at the code yet, but that sounds like it would mesh well with bbqueue.

Can you take a look at the branch and see if this is something that be integrated into the crate?

Can you please submit this as a pull request (mark it as a draft, if you don't think it's ready). That makes it easier for me to add comments and track changes you make in response to them.
Also, to clarify, I'm not a maintainer of this crate (although it seems I can merge pull requests, which I wasn't aware of?). In any case, @arkorobotics makes the decisions around here.

Correction: Turns out I was a maintainer all along, just nobody told me :-)

@apgoetz I took a look at it and my new working theory is that we've got an issue with non atomic reads, however we can work around this by using a stored position instead. Pull request created
With this I get absolutely ZERO improper overruns even right up to the limit where the hot loop has trouble keeping up with the ADC. In my testing it also properly generates overruns when the sampling rate is slightly faster than the loop so this doesn't loose any overruns it would have otherwise generated.

Fixed in #127.


update version

update version
Description
Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.
Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR.
e.g.

Fix #123
Related #456

Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I titled the PR using Conventional Commits.
[ ] I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[ ] All existing and new tests are passing.
[ ] The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[ ] No, this is not a breaking change.

Thanks, but this PR won't be accepted as too much things mixed up with those that really need an update (like compileSDK) with some personal preferences, like putting AGP version into a variable.
Closing and we (maintainers) will deal with such updates ourselves.


[backport] Remove unnecessary try catch

Backport of #815

jenkins, test this please.

jenkins, test this please.

LGTM!


[TC-318] Chart creation for non-cache servers such as Traffic Routers, Traffic Monitors, Influxdb

copied from https://github.com/Comcast/traffic_control/issues/1736
On the servers page in TO there is a graph icon which leads to graphs for caches. This icon is currently not present for other types of servers such as Traffic Routers, Traffic Monitors, Influxdb servers, etc. We should create some scripted dashboards and update Traffic Ops so that all server types have graphs with at least grafana data.
Author: Derek Gelinas
JIRA Link: https://issues.apache.org/jira/browse/TC-318

TO UI was deprecated long ago...closing.


es2015 compilation error for array rest arguments

$ cat .babelrc
{
  "presets": ["es2015"]
}

$ cat > script.js
function f2(x, ...y) {
  // y is an Array
  return x * y.length;
}

$ babel script.js --out-file script-compiled.js && cat script-compiled.js
"use strict";

function f2(x) {
  // y is an Array
  return x * arguments.length + 1;
}

The compiled code seems to be a optimization when the value of y is not needed; but the optimization should be
 return x * (arguments.length - 1);

Hello @yangchenyun! Thanks for reporting an issue. However, this repo is for website and documentation issues. Please see the babel/babel README for where to report issues with Babel. Thanks!

Reposted, thanks.


init first launch and dispatch activate workspace

Loom recording explaining race condition incoming

pulled in these commits, thanks!


Add a "paste from clipboard" button to adress fields

Would make mobile sending even easier

you can just long press and use the default paste functionality though right?
We could look to add something like this after public beta is launched.

Yes you can but for me I have to access the field, click in the field again to bring up the arrow, click on the arrow and then select paste. At least for me it would be more comfortable to have a paste button in the UI.


add default targets

I have no idea, how to program in golang,
but when I use RU VPN to overcome ban by IP, the docker container is dead in a couple of minutes because of panic(err)

I have taken your idea of using default targets and implemented it in the api_client package.
I've added them to the file default_targets.json and this file will be loaded and targets used if a call to the api fails


[Feature Request] flow_from_directory like for TFRecord

Would be nice to make it less tough..
AutoML CSV with labels, for example, so much easier for understanding
ImageDataGenerator.flow_from_directory() workflow is just nobrain and awesome! meanwhile TFRecord and tf.Example quality of it official docs -- makes me very unhappy

@chiboreache Sorry for late response. Is this still an issue for you.
There is a more detailed tutorial on TFRecord and tf.train.Example.  Can you please check it and let us know if there is anything missing.
Also, you can contribute to update the docs or code through PRs. Thanks!


Cannot maximize, minimize, or move the window when exported to remote X11 display on version 1.30.0-1544567151

Steps to Reproduce:

I'm running Ubuntu 18.04
I updated the code package to version 1.30.0-1544567151 via apt
I exported my X display to a remote X11 server
I then cannot maximize, minimize, or move the code window

My current solution is to downgrade:
sudo apt install code=1.29.1-1542309157

This might help:
"window.titleBarStyle": "native"

@Tyriar that works. Thanks!

Thanks @Tyriar
Those using vs code with remote x forwarding will need to change their titlebar style setting to native as @Tyriar suggested above.

added


Add support for geojson 0.21

Small update so that the latest geojson release is supported, and adds it to CI

Seems uncontroversial. =)

Sounds good! I'll go ahead and merge this and create a new release


Add Meson build support

I think it would help to add a meson.build script for Meson users. I was going to wrap your library and have it added to the WrapDB but there doesn’t seem to be any archived releases of this library.
Why?

there doesn’t seem to be any archived releases of this library.

I don't break the master branch. It's stable, and is what should be used.
I supposed I should start versioning it, just so people can redistribute without getting things mixed up.

I think it would help to add a meson.build script for Meson users.

I don't think this really helps genann users. genann is one C file. It's generally just meant to be dropped into your project and used. If I start adding build files for every build system out there, it just complicates things.

I tagged a release just now. I guess 1.0.0 is a good of place to start as any - the code has been very stable for years.

My original plan was still to provide a wrap package to avoid the need to add a script in the project. That can only be done if this library had at least one archived release.

Well get a wrap package ready for your library as soon as possible.
Thanks.

This is the proposal for the package.
https://github.com/mesonbuild/wrapdb/issues/54

cant wrap be used with a git commit Here


Upgrade dependencies and update example app UI.

Motivation
While updating the project dependencies, it made sense to cleanup the UI for the example app so it is more streamlined for developers to setup and push new contributions.
Tasks

[x] Update project dependencies and remove deprecated configuration options.
[x] Update example app UI. This makes the example app more intuitive from a workflow perspective and also allows for dynamic locale selection to accommodate for contributors that don't use the default locale.
[x] Create new .gif to replace initial .gif shown on site and documentation website.
[x] Improved accessibility.

Screenshots

ACCESSIBILITY BEFORE

ACCESSIBILITY AFTER

Gif

Very nice!!


Deploy-time value support

Is your feature request related to a problem? Please describe.
When given an unresolvable token as a define: value, the build will naively add ${Token[TOKEN.123]} token strings instead of warning the user.
Describe the solution you'd like
Ideally, unresolved token values should be detected, and the build delayed until they are somehow resolved. I don't see a simple or realistic way to do this, the user could be alerted when an unresolved/unsolvable token is detected.
Describe alternatives you've considered
I'm using the aws-cdk-lib.aws_s3_deployment Source.data/jsonData() constructs, which do support deploy-time resolution, and fetch the generated JSON file on the fly at the start of my application.
As indicated in the docs, these data/jsonData files are generated and deployed by a custom resource, after the initial deployment.
Stack:
new BucketDeployment(this, 'deployment', {
  sources: [
    new TypeScriptSource('./src/index.tsx', {
      copyDir: './static',
      buildOptions: {
        platform: 'browser',
        define: {
          ['process.env.NODE_ENV']: '"development"',
          ['process.env.REACT_APP_AWS_REGION']: `"${Stack.of(this).region}"`,
        },
      },
    }),
    Source.jsonData('deploy-time-env.json', {
      REACT_APP_USER_POOL_ID: userPool.userPoolId,
      REACT_APP_USER_POOL_CLIENT_ID: userPoolClient.userPoolClientId,
    }),
  ],
  destinationBucket,
});

Additional context
I don't think it is possible to give properly resolved define: values without outsourcing the esbuild process to Lambda/CodeBuild, after the initial deployment is completed. I doubt there is something cleaner than the alternative listed above, but please correct me if anyone can think of something better.
I'm just opening this issue to share my findings, and maybe to improve user experience with some sort of hint/warning from the construct.

Thanks for reporting this @nmussy ! I agree it's a problem, but not one I'm likely to address.
Would be open to a PR though, if the required code isn't too complicated.
In the meantime I'm closing this as not planned.


Publish CoreRT Framework Libs on Nuget/Myget and remove AppDepSDK

Today CoreRT framework libs are included in the AppDepSDK NuGet package. This only includes a small subset of libraries, and does not provide any functionality for a user to opt in or out of specific libraries.
We should instead publish these libraries on nuget/myget and allow them to be referenced like other framework libraries in the project.json
The resolution of this is heavily tied to the resolution of #402 and is another step in unblocking #255
/cc @schellap @gkhanna79 @weshaggard
P.S.: a move of dotnet/cli#404

@blackdwarf You can actually build these for yourself, should you ever need to. To do so, clone dotnet/corefx and run init-tools.cmd from within that repo. Then, you can go into any of the project src directories and run msbuild *.csproj /p:TargetGroup=netcore50aot and it will create a CoreRT framework lib for you. Note that most of the time these are the same as the "regular" CoreFX libs; there is a difference only when the lib in question directly forwards into mscorlib.
Also, please see #1499 and #1504, which were filed when I ran into this problem.

Tracked by https://github.com/dotnet/corert/issues/309


Archive LGPU repo

Before submitting
Please complete the following checklist when submitting a PR:

[x] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
tests directory!

[x] All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running make docs.

[x] Ensure that the test suite passes, by running make test.

[x] Add a new entry to the .github/CHANGELOG.md file, summarizing the
change, and including a link back to the PR.

[x] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

Context: This PR adds the archival notice to LGPU, in preparation of of making the repo read-only at v0.32.0.
Description of the Change:
Benefits:
Possible Drawbacks:
Related GitHub Issues:

Thanks! Will the warning show up in the docs too?

If the docs build succeeds, it will show up in latest. Will try to fix the failure, as not much info is given.


update build component and application labels

Fixes
Related to work done on the services side: https://issues.redhat.com/browse/HACBS-1331
Description
Dropped the build. prefix from the following PLR labels:
`build.appstudio.openshift.io/component'
'build.appstudio.openshift.io/application'
Builds were not recognized in the lifecycle visualization or on the components page.
Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Screen shots / Gifs for design review

before:

after:

How to test or reproduce?

Browser conformance:

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

/lgtm


Omit should throw error if not existing key try to remove

Search Terms
 Omit inexistent key
Suggestion
Let's consider next code where we omit inexistent key from interface Todo :
interface Todo {
    title: string;
    description: string;
    completed: boolean;
}

type TodoPreview = Omit<Todo, 'not_existed_key'>; // currently error is not thrown

Use Cases
Let's imagine that previously interface Todo had property not_existed_key and we had variable such as
const todoItem: TodoPreview = {...}

but then not_existed_key was removed and developer forgot to remove TodoPreview because it became redundant.
Examples
From my point of view will be better to have more strictly behavior of Omit.
Checklist
My suggestion meets these guidelines:

[ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

See discussion at #30825

Thanks @RyanCavanaugh !


"Copy as Markdown Issue" doesn't reflect current selections in compiler options without reload

I found this when looking at the lib.d.ts issues, and thought for a second that it was related, but I think it's a red herring.  Didn't test every option, but it appears that the generated compiler options in the markdown only reflect the state at page load.
Seems like this could be problematic potentially when using this awesome feature to file issues.  The playground link should be good, but incorrect compiler options int the new issue could cause confusion.
Side note, when you load the playground without the code in the URL, the generated playground link matches, which (not likely a practical concern) doesn't match what's actually in the window.  Maybe replace the URL on load if you read from localStorage would fix that?  Not sure if that's a good idea or not.

orta-bot please label "Playground"  🚎

good bot

Agree - I'd also like to cut down the example tsconfig - but the defaults for typescript are not the defaults for the playground (strict mode for example)


lowercase, snake_case and PascalCase don't work!

It's a bit weird that this bug exists or there were some discussions about it.
As you can see in the source code, lowercase and snake_case do nothing for structs, since they assume fields are always lowercase already. And with the same logic PascalCase doesn't work for structs.
Here is a testing case.

The other rename rules do not work either in that situation; all of these assume that the Rust name of the type or field conform with Rust convention. This is the intended behavior. Inferring word boundaries from names written in arbitrary case is out of scope for serde_derive.


Not creating useless files

I believe that
https://github.com/popbr/abstract_doi_finder/blob/c3435a4f567db752b2d550258bbdc6248ec01eaf/abstract_doi_finder/src/main/java/popbr/AbstractDoiFinder.java#L273-L275
is not needed, and could be replaced by
XSSFWorkbook wb = new XSSFWorkbook(new File(SourceFile));

directly, but may be wrong. If that is the case, please edit my CreateOutput method.

This is probably actually not true, but I believe I am quite inconsistent / careless with the creation / manipulation of XSSFSheet / File / FileInputStream / XSSFWorkbook.
This probably need some cleaning.

After review, this seems fine.


mark double click event as consumed after toggling footstep widget

i broke this when splitting view behaviors into robot view behaviors

the double click was activating the footstep widget, but then the double click event triggered a second time in the view behaviors base class, toggling the frame off.  oops.


New demos needed

I already have several demos showing the various possibilities with my Public Domain HTML 3D Library.
I would like people to suggest or make new demos to add to the list.  This is also a very good opportunity for you to test the library and see if everything works.  If you make a new demo, you must release it to the Public Domain before I can add it.

Hey peter. I was just trying to look through those demos but actually none of them are working.
The console in chrome shows
Uncaught SyntaxError: Unexpected token <<              glutil_min.js:53
Uncaught ReferenceError: Scene3D is not defined     obj.html:33
when trying the first one (demos/simple.html) and the rest show similar.

@philwilson:
The issue should be resolved by now.  Next time, open a separate issue if you have problems with this library or its demos.

Closing this.  This library's focus is going to change.


fix iter

(I can't run tests yet, but I don't think this would break anything)

Thanks for fix, odd that the bug made it way in (probably auto complete from PyCharm + being a little careless). I should find a way to run tests automatically, but it looks good to me.

Also cut a new release on pip 0.1.4 since the bug broke iter.

I should find a way to run tests automatically

I can try getting Travis going later tomorrow.


Badge: falsche Icons Size/Position in Expressive/Functional

Which design system content is impacted? * (PLEASE SELECT THE LIBRARY)

[ ] Figma Core Foundations
[X] Figma Core Components
[ ] Figma Core Patterns
[ ] Figma Core Icons
[ ] Sketch Core (Foundations/Components/Patterns)
[ ] Sketch Core Icons

Which version is impacted?
v0.4.1
Reproduction case
In der Badge Icon Variant hat das Icon in Expressive & Functional eine falsche Position & Size.
Expected
In der Icon Variant sind die Icons in allen Densities in der korrekten Größe.
Screenshots

Add any other context about the problem here.
No response

fix Branch


Best choice parameters

Hello,
I'm using epic 0.2.9 to compare two mapping samples against a mapping reference, and I have some questions for you.
I'm looking for enriched regions of unknown size comparing two experimental groups (GROUP1: sample1 and sample2) (GROUP2: reference). But it's essential that no reads of one of the groups map on the enriched sequence.
At first, I mapped the 3 samples sequences (sample 1, sample 2 and reference) against the same reference genome using bowtie2. Then I used epic to compare sample1_mapping/reference_mapping and  sample1_mapping/reference_mapping. I created a chromosome-size-file.
When I compared the samples with default parametres, I get large enriched regions and logically a lot of reads of both groups mapped on each enriched region.
I extracted a little test_sample of each sample. Speciffically I extracted known enriched region from genome. Then I reproduce the same steps.
I make a lot of executions with high and low FDR, proving combinations of windows size and gap allowed through some loops.
When I checked the epic results I realized that in sample1/reference comparison, the program return the exactly region.
But in sample2/reference comparison it returns:
-One very large region whith high FDR and logically both samples reads mapped in it.
-A lot of very short regions with no reads mapped from one of the samples, with very low FDR, but there are a lot of little gaps between them.
-No enriched regions.
When I graph the coverage map of these comparison I can see a clear enriched region in both comparisons.
Here are the graphics:

The most notable difference between sample1 and sample2 mappings is the coverage deep, how you can see in the graphs.
I could test a combination of parametres for tune up the program for the test-files. But in the case of the real samples, I don't think it work because I'm looking for unknown size sequences, from 3 pb to largest possible.
FIRST QUESTION:
Which combination of parameters do you recommend for that kind of experiment?
SECOND QUESTION:
In what degree does the coverage deep diference between mappings affect?
THIRD QUESTION:
In what degree does the definition of the samples as control (-c) or as treatment (-t) affect?
I'm waiting for an answer.
Thanks you very much,
Jose.

The recommendations are for specific histone/protein marks.

The sample differences should not matter much as the data are pooled if analyzed together. Library differences can be due to one poor quality experiment though. Perhaps you should investigate the data with deeptools?

You should only use ChIP samples as -t. I guess using ChIP as -c can work, but it is much better to use actual input data.

Thanks for trying epic. I’d love to be of help, but I suspect you’d get much better answers at biostars.


OS X retina hdpi fullscreen glitches

Operating system or device - Godot version:
OS X 10.11 El Captain - v2.1.alpha.custom_build
Issue description (what happened, and what was expected):
With allow_hdpi settings project in fullscreen mode causes glitches.
Screenshot
Window Mode
Steps to reproduce:
Simply set allow_hdpi and fullscreen enabled with portrait resolution. (640x1136)

Can someone reproduce this issue on OSX, and/or on another OS?

Testing in OSX with retina and I can't reproduce it. Maybe it was fixed by something else?

I'm even using the same OSX version..

Moving to the next milestone as we haven't had any user confirming this issue so far, so it should not be blocking for 2.1.

Any status here? It seems like we need more testers for this one :smiley:

Assuming fixed as there have been many improvements to macOS hidpi support, and no new confirmation of this specific bug either.


Add example for configuring JS collocation in _Layout.cshtml

Description
[Enter feedback here]
Add example for configuring JS collocation in _Layout.cshtml
Page URL
https://learn.microsoft.com/en-us/aspnet/core/mvc/views/tag-helpers/built-in/script-tag-helper?branch=pr-en-us-28802&view=aspnetcore-7.0#asp-src
Content source URL
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/views/tag-helpers/built-in/script-tag-helper.md
Document ID
5c95e5dc-dc10-8658-91fd-1d55d3959c37
Article author
@Rick-Anderson

Fixed in #33697


Option to change commit author for push mirrors

Feature Description
I have a GitHub mirror setup for one of my Gitea repositories (direction push). So, every time I push commits to my Gitea repository they are mirrored to the GitHub repository. I just started using this feature for the first time and I figured that in GitHub it shows my Gitea user as commit author (including my Gitea user's email address; checked it with adding .patch to the GitHub commit URL.
However, I would prefer the GitHub commit author to be my GitHub user (and associated GitHub user email address) rather than my Gitea user. So, my feature request is an additional setting for push mirrors to determine the commit author. I read a similar request in the GitLab forum and here are some possible approaches about how to change the author for multiple commits. So, in theory this should be possible. Just not sure about performance implications though. Still, would love to see this feature realized to keep more privacy on GitHub.
Screenshots
No response

Changing the commit author would change the git history and then the source and target repositories are different (no mirror anymore). You could use a git hook to execute a script outside of Gitea which does that job but I don't see much need for this to be build into Gitea.

I think you can do that with Gitea Actions. It's more flexible than making it a feature of Gitea.


.blend / .glb animation interpolation error

Tested versions
Godot v4.2.2.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; <IP_ADDRESS>98) - AMD Ryzen 7 5800U with Radeon Graphics (16 Threads)
System information
Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; <IP_ADDRESS>98) - AMD Ryzen 7 5800U with Radeon Graphics (16 Threads)
Issue description
The animation imported in godot is not correct.
I created a simple animation using cube in blender[v3.6 lts] and make interpolation of each frame be Constant.
Then convert to .glb format. Import both .blend and .glb file into godot.

To import correctly, set FPS in godot to 15, same with blender.

godot

blender

The interpolation mode in blender is Constant but in godot is not. And the key frames are weird.
Steps to reproduce
See mrp.
Minimal reproduction project (MRP)
anim_test.zip

I modified the mr-project and reuploaded it since I referenced a blog, which told me to set the fps of godot and blender to a same value. But it does not work.

I just find it out and update the content.
The correct way is to turn off the Optimizer of AnimationTree.
For Godot 4.3, I dont think this internal frames should be "optimized" in Constant/Nearest mode.
And for Godot 4.2.2, the engine just ignored the Constant interpolation mode and just use Linear.


Add feature for scale cluster worker node in openstack

/kind feature
Now cloud-provider-openstack can provide Loadbalance/PersistentVolume/router for k8s, but if k8s want to scale up worker nodes, now cloud-provider-openstack can do nothing. As we all know, openstack can provide VM, so why not provide VMs to k8s for cloud-provider-openstack. I think it's a very useful function, and also there are a project called machine-controller, which has implement the function of asking openstack VMs and let the VMs join k8s cluster, so we can integrate the machine-controller project with cloud-provider-openstack.
main function for this feature:
add/delete/update worker nodes to k8s cluster from openstack

@adsl123gg we are working on such stuff here : https://github.com/kubernetes-sigs/cluster-api-provider-openstack
Also see https://github.com/kubernetes-sigs/cluster-api
Hope you can join the work there

@dims as I know, there are two ways to autoscale k8s nodes in cloud provider(such as openstack, AWS), first is cloud provider autoscale cluster nodes according to k8s resource utilizing, in this situation, cloud provider know k8s is running in cloud, cloud provider is initiator. Then the second way is k8s ask VM from cloud provider and then the VMs join k8s, in this situation, k8s is initiator and cloud provider doesn't know k8s is running on it.
so how about cluster-api project, what's it position?
Also there is another project https://github.com/kubernetes/autoscaler, it implement auto scale function with the first way.

You should read all the materials for cluster-api as its a still early stage, auto scaling based on utilization will hopefully be a part of it.
for kubernetes/autoscaler, there has been talk but not much work, please see https://github.com/kubernetes/autoscaler/pull/1226

@dims for kubernetes/autoscaler, there is a more detail discussions in https://github.com/kubernetes/autoscaler/issues/734, from what ricolin say, I think they want to create another openstack component project to auto scale k8s.

@dims after using cluster-api-provider-openstack and reading the materials of cluster-api, I this cluster-api aiming to do autoscale in cloud provider position, from the architecture diagram in https://github.com/kubernetes-sigs/cluster-api, cluster-api has several components such as bootstrapping CLI, upgrade trigger and autoscaling,  as we can see from the diagram, the initiator is cluster-api, not k8s cluster, although autoscaling is not finish. If you're working on autoscaling in cluster-api-provider-openstack, so what's your thinking to finish autoscaling?

@adsl123gg cluster-api is responsible for handling the cluster lifecycle, including creation and destruction of control plane (master) and worker nodes.
cluster-autoscaler is responsible for determining when the cluster needs to add or remove worker nodes, which it could do in conjunction with cluster-api by modifying MachineDeployments, MachineSets or by creating and destroying Machine resources.
The intent of cluster-api is to encapsulate the provider-specific (i.e. OpenStack) details, and enable tooling such as cluster-autoscaler to manage cluster resources in an abstracted, provider-agnostic manner.
A generalised workflow for autoscaling using cluster-api would be:

Autoscaler determines more nodes are required to handle current workloads.
Autoscaler increases a specified MachineDeployment replica count to satisfy the required number of work loads.
Cluster API MachineDeploymentController is informed of the change in replicas via the watch mechanism.
Cluster API MachineDeploymentController scales the current MachineSet as indicated by the MachineDeployment.
Cluster API MachineSetController is informed of the change in replicas via the watch mechanism.
Cluster API MachineSetController creates Machines from the MachineSet``spec.template to satisfy the number of requested replicas.

Note that steps 1-6 are provider-agnostic and have no interaction with the provider (i.e. OpenStack)

Cluster API Provider (i.e. Cluster-API Provider Openstack) is informed of the newly created Machines via the watch mechanism.
Cluster API Provider interacts with the OpenStack APIs to create the requested Machines, and to configure them to become worker nodes.
Cluster API Provider, once the Machine has joined the cluster as a Node, sets a reference between the Machine and the Node.

Downscaling a cluster will occur in a similar fashion, with the MachineDeployment replica count being decremented, Machine objects being deleted, and Cluster-API Provider triggering deletion of the applicable resources via the Provider (i.e. OpenStack APIs)
As the above indicates, this follows a very similar patter to how the Horizontal Pod Autoscaler behaves, allowing the HPA to be pod-agnostic.

/close


https://www.sendspace.com/file/qhgyw0 Aimware crack

https://www.sendspace.com/file/qhgyw0 Aimware crack

Yikes. Deleted and blocked.