Enable non-SpatialExperiment inputs

Update input arguments to allow non-SpatialExperiment inputs, i.e. matrices of logcounts and spatial coordinates.
This will make the method more broadly accessible, e.g. by Seurat or Python users.

Done (in latest development version available from GitHub or Bioc-devel)


 Praise AGIMUS!

starboard functionality is in and seems to be functioning well enough!
it does seem a bit slow, i think mostly because it has to do an async call to get all the users of each reaction.  if there's a way to speed that up i would love it!


tests/poisson_2d example diverging when useStrongDirichletConstraints==True

I am probably not setting all of the correct flags, but when I derive a local dummy flux and set the class variable useStrongDirichletConstraints==True, the newton solve diverges for the linear poisson 2d example in tests/poisson_2d . This is with all Dirichlet boundaries or partial Dirichlet boundaries.
One thing that may or may not be an possible issue is that the
self.dirichletConditions[cj].DOFBoundaryConditionsDict has no keys (dofs), which I believe follows from the fact that useWeakDirichletConditions==True in the MultilevelTransport initialization by default when we use a numerical flux.
When I check the residual calculation with forceStrongConditions==True the loop at the start of the getResidual routine in OneLevelTransport
    def getResidual(self,u,r):
        """
        Calculate the element residuals and add in to the global residual
        """
        #cek debug
        #u.tofile("u"+`self.nonlinear_function_evaluations`,sep="\n")
        r.fill(0.0)
        for cj in range(self.nc):
            for dofN,g in self.dirichletConditions[cj].DOFBoundaryConditionsDict.iteritems():
                self.u[cj].dof[dofN] = g(self.dirichletConditions[cj].DOFBoundaryPointDict[dofN],self.timeIntegration.t)
        if self.forceStrongConditions:
            for cj in range(len(self.dirichletConditionsForceDOF)):
                for dofN,g in self.dirichletConditionsForceDOF[cj].DOFBoundaryConditionsDict.iteritems():
                    u[self.offset[cj]+self.stride[cj]*dofN] = self.u[cj].dof[dofN]#load the BC value directly into the global array

The self.u[cj].dof isn't set to the Dirichlet value because the iteritems is empty and that follows for the u array. The self.dirichletConditionsForceDOF dictionary is used later on to set the residual and jacobian values. It has the complete list of Dirichlet degrees of freedom.

You're, right,  that last line should call the g function directly to set the u array, like this:
u[self.offset[cj]+self.stride[cj]*dofN] = g(self.dirichletConditionsForceDOF[cj].DOFBoundaryPointDict[dofN],self.timeIntegration.t)

I think I must have done that at the last minute working on cleaning up and optimizing, thinking I was eliminating a second call to g, but it only gets called once anyway because the first  list of  BC's is empty.
I suspect if you set the initial conditions consistent with the boundary conditions it hides this bug.  Could you add this test directory to https://github.com/erdc-cm/proteus/blob/master/.travis.yml#L35 and maybe add the case with forceStrongConditions=True to the tests/poisson_2d? These tests run quickly so there's no reason why they shouldn't be part of the tests travis runs.


Error: 12

Describe the bug
Reth built correctly in the system, I'm using ARM based OrangePi 5 with a 2TB NVMe disk.
When trying to run the node it errors with the cryptic Error: 12
When looking to the said line, it looks like it's unable to open the db. Maybe it's something obvious I'm not doing correctly but I tried several things, including replacing/upgrading the db source files and rebuilding with the same result.
It works well on MacOS ARM M1
Steps to reproduce

run the node reth node --chain goerli

Node logs
2023-04-12T14:54:04.346135Z  INFO reth 0.1.0 starting
2023-04-12T14:54:04.349436Z  INFO Configuration loaded path=/home/vcastellm/.config/reth/goerli/reth.toml
2023-04-12T14:54:04.349562Z  INFO Opening database path=/home/vcastellm/.local/share/reth/goerli/db
Error: 12

Location:
    /home/vcastellm/reth/crates/staged-sync/src/utils/init.rs:15:14 vcastellm@orangepi5:~$ reth node --chain goerli
2023-04-12T14:54:04.346135Z  INFO reth 0.1.0 starting
2023-04-12T14:54:04.349436Z  INFO Configuration loaded path=/home/vcastellm/.config/reth/goerli/reth.toml
2023-04-12T14:54:04.349562Z  INFO Opening database path=/home/vcastellm/.local/share/reth/goerli/db
Error: 12

Location:
    /home/vcastellm/reth/crates/staged-sync/src/utils/init.rs:15:14

### Platform(s)

Linux (ARM)

### What version/commit are you on?

ca28b37a742ccad0c387e69121ffb842190151fa

### Code of Conduct

- [X] I agree to follow the Code of Conduct

Thanks @Rjected can you point to the PR with the change to data dirs?

ARM based OrangePi 5 with a 2TB NVMe disk.

Do you mind giving some more system information? What's uname -a? I have not tested MDBX on such a device before, so unsure myself - maybe @erthink knows?

Sure:
Linux orangepi5 5.10.110-rockchip-rk3588 #23.02.2 SMP Fri Feb 17 23:59:20 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
I'm using Armbian distro for this board, I can try anything at this point, thinking in trying with a different distro.

Yeh other distro would be helpful, but I suspect it's got to do with the Pi..

Same error using Debian bullseye but in this case the error message is present:
2023-04-13T07:35:02.601874Z  INFO Opening database path=/root/.local/share/reth/goerli/db
Error: Failed to open database: 12

Location:
    /root/reth/crates/staged-sync/src/utils/init.rs:15:14

Looks like it should have something to do with mem and MDBX lib compilation.

Thanks for the suggestion @mattsse, I tried playing with these values, I reduced it a little didn't work, then come with a combination that "works", I don't know if the values can be higher, I'm going to try a bit more:
.set_geometry(Geometry {
                    size: Some(0..(1024 * 1024 * 1)), // TODO: reevaluate (4 tb)
                    growth_step: Some(1024 * 1024 * 128),           // TODO: reevaluate (256 mb)
                    shrink_threshold: None,

ty this is very valuable feedback,
@rkrasiuk or @rakita probably have more insight into these settings

Thanks @mattsse
It works with 4gb:
.set_geometry(Geometry {
                    size: Some(0..(1024 * 1024 * 1024 * 4)), // TODO: reevaluate (4 tb)
                    growth_step: Some(1024 * 1024 * 256),           // TODO: reevaluate (256 mb)

So would be great to know more about that 4 tb mark.

looks like this hasn't been touched in a while, so now is a good time to "reevaluate" the todo,
not exactly sure what the size field refers to but if this is the expected size of the db, then 4tb is way too high

Hi,
I ran into the same issue as described above (except that the piece of code is now available here).
After a bit of research, it seems that the error has indeed something to do with memory allocation.
The same error is also raised in libmdbx here:
MDBX_env *env = osal_calloc(1, sizeof(MDBX_env));
if (unlikely(!env))
    return MDBX_ENOMEM;

From what I have understood, it goes like this:

In reth's open method, a call is made to the open_with_permissions method.
Then, an FFI call is made to the C implementation of mdbx_env_create.
MDBX fails to allocate memory based on the provided configuration.
The error is propagated back to Reth.

So it seems that depending on the MDBX_env's content, the allocation can fail and cause the issue.
On my setup - OrangePi 5 / 16GB RAM / Armbian - I can set the geometry size field up to 342GB, and then the error appears.
My plan is to investigate on why the allocation fails - maybe something related to the MDBX_env's structure content ? - but if someone has an idea or suggestion I'm definitely open to it !

The upper bound of size in Geometry governs how big the database can get. It also defines the linear address space reservation in each process that opens the database.
Changing the upper bound is costly according to MDBX docs, so a reasonably large value had to be chosen. Since we are at 2tb, the assumption here was that we would probably grow to 3tb "relatively soon", so 4tb was chosen.
If the size is set to only 342gb, then reth cannot store more than 342gb of data. This is not sufficient to sync.
As far as I can tell, [x86_64] has a 48-bit address space that is divided in half, which means that user-space and kernel each have 128TB of address space.
On [AArch64] however, it seems that the address space is only 512GB for user space and 256TB for the kernel.
In the linked document above, it seems that some newer version of ARM has support for Large Virtual Address space, but it requires running with a 64KB page size. I am not sure how (or if) you can enable this.

Looking at the above doc again, it looks like AArch64 does actually support 4-level paging, so I checked out the board you are using to see if it is restricted to 3 levels, but it seems like there isn't a reason it should be - the OrangePi 5 uses a Rockchip RK3588S, which according to their datasheet is based on ARMv8-A. ARMv8-A should support 4 level paging.
I wonder if it is due to the distros used/the config used to build the kernel?

I've seen a similar issue in the erigon repo where it was due to kernel config problem as @onbjerg mentioned. Tagging it here for reference
https://github.com/ledgerwatch/erigon/issues/4871#issuecomment-1229275707

Quick update, I was able to fix the issue by recompiling Armbian and setting a 64KB page size in the process.
I am finishing a blog post describing the entire process, but I think it might be relevant to document it somewhere close to the source code, wdyt @onbjerg ? If so, where should be the most appropriate place ?
The process is "fast" on Armbian as it provides an easy-to-use build framework, but might be a bit more tedious on other distros.

@0xpanoramix amazing. we can maybe add a subsection on https://paradigmxyz.github.io/reth/installation/installation.html?
https://github.com/paradigmxyz/reth/tree/main/book/installation

@0xpanoramix does the process involves modifying the source and recompiling?

@vcastellm Not at all, it just involves building a new Armbian image (if you're using an SD card on the Orange Pi, the flash part will be automatically made by the build framework). Then, the default binary from the releases will work.
@gakonst Can I take the task about writing the new subsection in the documentation ? I already have most of the content from my article, I just need to make it more "formal".

@gakonst Can I take the task about writing the new subsection in the documentation ? I already have most of the content from my article, I just need to make it more "formal".

By all means!

Closing this as the instructions in docs allows for successful building of the project in ARM SoCs

Thanks a lot for tracking down this bug and working on that doc (https://github.com/paradigmxyz/reth/blob/v0.1.0-alpha.10/book/installation/build-for-arm-devices.md).
For what it's worth, I did also get the issue with the official Orange Pi Ubuntu image, but not with thirdparty Ubuntu one from https://github.com/Joshua-Riek/ubuntu-rockchip.
To be more precise, I'm now using the ubuntu-22.04.3-preinstalled-desktop-arm64-orangepi-5-plus.img.xz image from https://github.com/Joshua-Riek/ubuntu-rockchip/releases/tag/v1.27
And the official image with the issue was Orangepi5plus_1.0.6_ubuntu_jammy_desktop_gnome_linux<IP_ADDRESS>z from https://drive.google.com/drive/folders/1wOmKUla8CwUPTfxvfCGutj8lbMZFtFCm


Add proof of UTxO difference property and other stuff

This PR includes the following changes:

A proof for the UTxO difference property.
Removal of the generated PDF file.
Some refactoring and polishing.

Thanks for the good work Javier!


Keras_Data_Creation.py

Since the output of Instance_Creation.py (step 3) is "Revised_InstanceCreation+NoJerkOutlier+NOSmoothing.pickle",
and the input of Keras_Data_Creation.py (step 4) is "Revised_KerasData+NoJerkOutlier+NoSmoothing.pickle", It is not Iinconsistency. When I run the code of step 4, it show a error of "No such file 'Revised_KerasData+NoJerkOutlier+NoSmoothing.pickle' ". How can I fix it? thanks a lot.

The output of Instance_Creation.py should be the input for the Keras_Data_Creation.py. So whatever name is used for the pickle dump in the last line of Instance_Creation.py should be exactly the same as the pickle name in the first line of Keras_Data_Creation.py. This is the general rule.
By the way, I am going to make names consistent.

@sinadabiri  I have some questions please...


upgrade to go 1.19

Signed-off-by: Augustin Husson<EMAIL_ADDRESS>

I will just go ahead on this, so I can update the PR #497.
If someone is not agree with this change, we can talk and revert if necessary


[cf-tables] Tables can't be sorted down on page load

Tables can't be sorted down on page load.
Current behavior
Sortable tables like this:

  ...

      <button class="sortable sortable__start-down">Column Name</button>

  ...

are not sorted on page load. However, replacing sortable__start-down with sortable__start-up will correctly sort the table on page load.
Expected behavior
The table should sort down by the indicated column on page load.
Steps to replicate behavior

Create a sortable table with one column marked as sortable__start-down on a page.
Load the page.
Note that the table is not sorted until you click on a sortable column.

Fix
I think this should be a quick fix. Right now, https://github.com/cfpb/capital-framework/blob/canary/src/cf-tables/src/cf-tables.js#L32 is
$table.find( '.sortable__start-up, .sortable__start-up' ).click();

Pretty sure that should be
$table.find( '.sortable__start-up, .sortable__start-down' ).click();

Good find -- having that duplicate selector there is likely a mistake. cc'ing @mistergone to confirm.

@mistergone is this a simple fix, or should it be backlogged till after the atomic work is completed?

@mistergone this was fixed with the v4 version of cf-tables correct?

This was indeed fixed in the v4 release and is in use in cfgov on production.


sql, import: add metrics for max_row_size guardrails

https://github.com/cockroachdb/cockroach/pull/69457 --- Release note (ops change): New variables sql.mutations.max_row_size.{log|err} were renamed to sql.guardrails.max_row_size_{log|err} for consistency with other variables and metrics.

Duplicate of https://github.com/cockroachdb/docs/issues/11485


Support decimal type

(you don't have to strictly follow this form)

Support decimal type.
In TPCDS sql, there is cast(xxx as decimal).

A clear and concise description of what is the intended usage scenario is.

Describe the solution you'd like

A clear and concise description of what you want to happen.

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

https://github.com/Kyligence/ClickHouse/pull/128

duplicated with https://github.com/Kyligence/ClickHouse/issues/123


Early onset of Inf error on a certain self supervised learning method in distributed training mode

Thanks a lot for your work, I am a big fan and constantly enjoy and engage with your twitter posts, regardless of topic.
I just wanted to bring to your notice that when I tried to use the Barlow Twins method with a vit-small (with registers), and applied the approach, the method quickly returns infinity as loss value when in distributed mode. For now I am trying to mitigate it by switching to Feed Forward only, and switching off is_distributed, so I am running on pure DDP, with the entire model reproduced on a single machine (A100). Will post on the outcome later.
Another interesting thing I noticed is that, unlike a vanilla vit, the covariance loss of the Barlow Twins method fluctuates rapidly in early training stages. Not sure how to interpret it.
I am not ready yet to prepare a reproducible code, but will soon provide if the infinite loss problem persists. I just brought this to your attention to see if this is some familiar issue.

Never mind.


Roll Packages from d862279f291f to cc7b5fc79cd3 (12 revisions)

https://github.com/flutter/packages/compare/d862279f291f...cc7b5fc79cd3
2024-08-27<EMAIL_ADDRESS>Remove matan from codeowners (flutter/packages#7511)
2024-08-27<EMAIL_ADDRESS>[shared_preferences] Add test to enforce mutable lists (flutter/packages#7369)
2024-08-27<EMAIL_ADDRESS>[google_sign_in_ios] Fix "callee requires a non-null parameter" analyzer warning (flutter/packages#7513)
2024-08-27<EMAIL_ADDRESS>[in_app_purchase_storekit] Allows 'localizedDescription' to be nullable to handle occasional nulls in Storekit objects (flutter/packages#7515)
2024-08-27<EMAIL_ADDRESS>Cupertino icons golden tests (flutter/packages#7421)
2024-08-26<EMAIL_ADDRESS>[pigeon]: Bump org.jetbrains.kotlin:kotlin-gradle-plugin from 2.0.10 to 2.0.20 in /packages/pigeon/platform_tests/test_plugin/android (flutter/packages#7500)
2024-08-26<EMAIL_ADDRESS>[video_player] Updates minimum supported SDK (flutter/packages#7498)
2024-08-26<EMAIL_ADDRESS>[url_launcher] Ignore new unreachable_switch_default warning. (flutter/packages#7487)
2024-08-26<EMAIL_ADDRESS>Revert "[video_player] Relands #6456: Uses SurfaceProducer, this time with setCallback for suspend/resume lifecycles" (flutter/packages#7497)
2024-08-24<EMAIL_ADDRESS>[video_player] Relands #6456: Uses SurfaceProducer, this time with setCallback for suspend/resume lifecycles. (flutter/packages#6989)
2024-08-23<EMAIL_ADDRESS>[google_maps_flutter_android] Convert PlatformTileOverlay to Pigeon (flutter/packages#7467)
2024-08-23<EMAIL_ADDRESS>[go_router] Fixes issue so that the parseRouteInformationWithContext … (flutter/packages#7337)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages-flutter-autoroll
Please CC flutter-ecosystem<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


provide possibility to run headless mode tests from scratch

need easy way to run headless tests from infrastructure. maybe improve carina as well to have access to the browser drivers on the fly when needed

related ticket for carina: https://github.com/qaprosoft/carina/issues/1082

no changes expected on zebrunner side. carina has new "headless" boolean configuration parameter. So custom "headless" boolean checkbox might be generated by jobdsl steps to be able to track this feature

no need to test something on zebrunner side


[#noissue] Explicitly set curator zk34CompatibilityMode to true

Currently zookeeper version 3.4.14 is used in Pinpoint, so explicitly setting zk34CompatibilityMode to true has no effect on Pinpoint while fixes java.lang.NoSuchMethodError: 'void org.apache.zookeeper.server.quorum.flexible.QuorumMaj.<init>(java.util.Map)' error (possibly due to environment configuration issue) during initiating flink jobs.

 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.Ga Lam Choi seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


News Website added

🛠 Fixes Issue (#429)

✅ Check List (Check all the applicable boxes)

[x] My code doesn't break any part of the project (Zero Octave-Javascript-Projects).
[x] This PR does not contain plagiarized content.
[x] My Addition/Changes works properly and matches the overall repo pattern.
[x] The title of my pull request is a short description of the requested changes.

Add your website on index.html and cardsdata page of the website

@NOiR-07 I have added the website to index and cardsdata

resolve the conflict in cardsdata.js file (first try to update your forked repo)

I have resolved the conflicts. @NOiR-07

Hii! @NOiR-07 its been 12days since I make this PR, kindly check and merge this. And if there is any error please inform me, I will definitely try to resolve that as soon as possible.

Hii! @NOiR-07 its been 12days since I make this PR, kindly check and merge this. And if there is any error please inform me, I will definitely try to resolve that as soon as possible.

sorry for the delay!! there is some conflict in index.html file, try to update your forked repo once again

@NOiR-07 conflict has resolved. Please Check now

We've changes the files for the website, so i suggest you to update your forked repo and add your project in cards.json and readme instead of index and cardsdata file

@NOiR-07  I have some conflict in my repo so I have to make a new a new PR and thats why I am closing this PR and will make a new one.


EMNIST images mirrored and rotated

Hello,
When trying to generate the adversarial dataset for the EMNIST+ARDIS setting I noticed that the honest (EMNIST) images and the ARDIS images have a different orientation. Specifically, the images from torchvision EMNIST dataset are 90 degrees rotated and mirrored (in generating_poisoned_DA.py), whereas the ARDIS-7's have a normal orientation. The images are then saved together into one attacker dataset. Therefore, it seems that you are training a model on 90deg+mirrored EMNIST while inserting an edge-case ARDIS backdoor that is not rotated/flipped.
Am I missing something here (are you correcting these EMNIST images later somewhere)?
Thanks,
Hidde

That is possible. I didn't explicitly try to visualize the images after loading them into pytorch. If anything, that is hurting our results since the 7's will stand out in the clean data. Can you check and see if that is indeed the case? If not, I will get to it soon :)

Thank you for raising the issue!


Sticker Design Change

Hello hello!  You know our regular sticker design?  @rebeccalendl & I were thinking of printing some new ones with "i love to share" instead of "some rights reserved" but I know nothing of design.  Help?  I have the ai file if you can't find (github doesn't support the file type so wouldn't let me drop it in here).

Any thought given to letting our community help come up with designs? We used to swag logo contests. See: https://creativecommons.net/contest/.

@rebeccalendl see the note above from @peterspdx

Please send the AI file to me directly, and I'll get this figured out in the next couple days.

@peterspdx and @mmoreshead love the idea of community support around the new shop items. we are gonna invite affiliate network and anyone to send their tshirt design files to us and we'll set up an item in the shop where customers can download and DIY their own prints from these files. trying to keep the other items fairly streamlined just due to limited capacity for merch program.

A slide note: I've been thinking about this and it would be a great idea to reach the CC community on this. In the future, maybe we should think about ways to engage with people from our affiliated list who have in-house designers to collaborate in a more formal way with us. I don't know exactly how, but maybe in the same way we have been developing translations in the past?

I agree with Claudio, this seems like a great way to engage our global
talent pool and engage our community in forging our visual identity .
On a similar vein Sarah and I have been thinking we'd reach out to see if
anyone is interested in designing the cover for our open business models
book.
Paul
On Thu, Apr 7, 2016 at 5:57 AM, Claudio Ruiz<EMAIL_ADDRESS>wrote:

A slide note: I've been thinking about this and it would be a great idea
to reach the CC community on this. In the future, maybe we should think
about ways to engage with people from our affiliated list who have in-house
designers to collaborate in a more formal way with us. I don't know exactly
how, but maybe in the same way we have been developing translations in the
past?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/creativecommons/creativecommons.org/issues/241#issuecomment-206882775

--
Paul Stacey
Associate Director of Global Learning
Vancouver, Canada
We're hiring! Help us make the Commons more discoverable, usable, and
connected. Opportunities in tech, communications, and fundraising:
http://bit.ly/1OZ46OF

Sticker file sent to @mattl
This instance is a quick one-off special thing.  Like @rebeccalendl said, something with community involvement is on the books!

Hey @mattl - just the gentlest nudge here :)

@mattl let us know if you can tackle by Wed. or if you're too swamped, please let us know and we'll go another route.

One hundred thousand thank you's!

i-love-to-share-sticker.pdf
Here's the print quality file


Possibility to open browser in incognito mode

I want to run my test in incognito mode, is it possible using this library.

@john-doherty - Thank you for your response, I used it but the browser still opens up in normal mode and not incognito. could you please advise.


Merge remote-tracking branch 'apache-github/2.6' into 2.6

Minor conflict in build.gradle
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Did you see https://github.com/confluentinc/kafka/pull/336 ?


Added support for orders with non default currency

If the Currency is allowed for the store it will be set on the order, if the store doesn't allow the currency the default is used instead. This stops needing a storeview for every currency you sell products in. After the order is placed the currency is set back to the default to stop any potential issues because of caching.

Fixes #96


(Windows) iTunes re-opening itself

If you close iTunes while AppleMusicRP is running, it will reopen itself.
The code that handles this and causes this is here

Was scrolling through GitHub and found this issue,
When integrating win32com to iTunes, it will always attempt to find that process, even if it is closed. This causes the effect of reopening the program.
Fixing it should be easy enough.  Simply killing it will make sure it doesn't spawn again. Implementation is as easy as setting a flag for hooking to iTunes for the first time since the program is ran, and then killing the win32com variable as soon as iTunes is not detected.

Was scrolling through GitHub and found this issue,
When integrating win32com to iTunes, it will always attempt to find that process, even if it is closed. This causes the effect of reopening the program.
Fixing it should be easy enough.  Simply killing it will make sure it doesn't spawn again. Implementation is as easy as setting a flag for hooking to iTunes for the first time since the program is ran, and then killing the win32com variable as soon as iTunes is not detected.

Thank you for this! I'll try it soon

Thank you for this!

Set WshShell = CreateObject("WScript.Shell") WshShell.Run "taskkill /f /im AppleMusicRP.exe"
save as stopAppleMusicRP.vbs

that would be a good idea to bodge, but it would probably be easier to just implement it directly into the script. i haven't been here for a while as ive been working on my own version, but we use the same library.


Add S3 Bucket Uploading

Add code to the upload file endpoint that will allow for the given file to be uploaded to an S3 bucket given the right credentials.

 📝 Indexing
I'm indexing your repository.


Add spkopn, spkw09, spkcls

Hey! First of all, thank you so much for this crate! I was pleasantly surprised to find such a nice wrapper for such a niche C library.
This PR adds everything necessary to construct basic SPK files (with type 9 segments) and corresponding tests. As the tests for each function require all other functions (you need to open a file and write to it to be able to close it, etc) and I wanted to make sure to only test one generated wrapper function in each test, I wrote quite a lot of code in rust-spice/core/tests/mod.rs. Of course, this could be simplified by testing all methods in one test, let me know if you'd prefer that. Some of the helper functions could be useful for testing other writer functions in the future though, so it's not all for just these three functions.
I only started learning Rust pretty recently and this is my first real PR, please don't hesitate to criticize me (even harshly) as I seriously want to get the hang of all this. I'd be happy to try and make any adjustments you request.
Have a nice day!

Hi @pixldemon, a true pleasure to read your message and work on your PR.
I really like how you added these 3 functions with their tests. And especially, congrats to have found your way in my procedural macro to add the Slice. To be honest, I'm both proud and not proud of the macro, I think it can be better written. If you're interested in working on that with me I'd enjoy it.
Thank you for this great PR! I add few comments below but I'm very happy.
Btw SPICE toolkit has been upgraded to 067 last week, I havn't checked it yet but it might be interesting to switch soon.
I checked out to each of your commit to test them. The commit [0ce5cec][https://github.com/GregoireHENRY/rust-spice/pull/6/commits/0ce5cec10982a9b98aaa444bce0bd64a6c96e19c] could not pass due to this error.
Toolkit version: N0066

SPICE(FILEOPENFAIL) --

Attempt to create new file, '/tmpspkopntestkernel.bsp' failed. IOSTAT was 13.

A traceback follows.  The name of the highest level module is first.
spkopn_c --> SPKOPN --> DAFONW --> ZZDDHOPN

I changed the call to get_temp_filepath in both tests spkopn & spkw09 from,
let filepath = get_temp_filepath("spkw09testkernel.bsp");

to,
let filepath = get_temp_filepath("/spkw09testkernel.bsp");

which was how you did it in the first commit [8fabc32][https://github.com/GregoireHENRY/rust-spice/pull/6/commits/8fabc329754ea89fb7525014f56cb846479d276c].
Also, I had to add #[allow(clippy::too_many_arguments)] inside the definition in raw.rs,
cspice_proc! {
    /// ...
    #[allow(clippy::too_many_arguments)]
    pub fn spkw09(...) {}
}

so clippy is happy. A cool idea would be to create inside a "neat" function (inside neat.rs) to call this function as a build pattern function, so that the call in the tests would look like,
    spice::spkw09(handle)
        .body(399)
        .center(10)
        ....
        .epoch(&mut (0..N_STATES).map(|i| i as f64).collect::<Vec<f64>>());

Plus, I added documentation in the table of developed functions in src/mod.rs.

Thank you so much for the feedback! My first PR got merged, yay! :)
I don't know why I didn't run into any errors with the missing '/' in the get_temp_filepath call, good on you for finding & fixing it. And sorry for the missing docs, never really worked with them before.
I like the idea with the builder pattern, I'll try my hand at it! Unfortunately, I have never really worked with macros before so I don't think I'd be able to contribute much to your (in my opinion awesome) macro just yet. Macros are definitely high on my list of things I need to learn, so perhaps in the near future. Thanks again for your time, feedback and the crate!


fix: instance label according to kubernetes recommendations unique name

See https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

The value can be changed to tekton-pipelines-default if preferred.
Would you be interested in changing the label "app.kubernetes.io/name" to tekton-pipelines in all files? The label app.kubernetes.io/component has the same value and it's ok.

This chart is fetching the kubernetes manifests from upstream and packaging as a helm chart. See the fetch target of the Makefile. So any changes to the default labels should be made upstreams in the tekton project.


TestDeploymentOrderServiceEndpointClient failed on Azure

Failure Logs
https://circleci.com/gh/networkservicemesh/networkservicemesh/114198?pipelines-ui-opt-out

Have not seen this test broken for a while


Client not ping & disconnect after 10 seconds

EDIT: gevent-websocket (enabling server websockets) partially resolve the issue. The client remain connected with ping/pong but "connect" event is fired twice. Polling transport option not work, like other options...
Make sure to check the existing issues in this repository

issue are different

Which platform(s) does your issue occur on?

Android device

Please, provide the following version numbers that your issue occurs with:

nativescript 6.7.8 (vue version)

CLI: (run tns --version to fetch it)

Cross-platform modules: 6.6.0-next-2020-05-08-112112-01

Runtime(s): ^6.5.0

Plugin(s): "nativescript-socketio": "^3.3.1"

Please, tell us how to recreate the issue in as much detail as possible.
My socket.io server is a Flask application with this packages installed:

python-engineio    3.14.2
python-socketio    4.6.1
Flask-SocketIO     4.3.2
My Flask app work fine with socket.io-client (browser version)

This is what append:

The app connect the server
The app receive twice "connect" event, one with "undefined" data and the second with correct data
The app doesn't ping the server (like waiting for server ping?!)
After 10 seconds app send a disconnection event
All emits works fine, but app can't maintain the connection

this is the flask log with client disconnection :
WebSocket transport not available. Install eventlet or gevent and gevent-websocket for improved performance.
 * Debugger is active!
 * Debugger PIN: 639-488-643
41bd89624c3447639ceb889fcf34c50b: Sending packet OPEN data {'sid': '41bd89624c3447639ceb889fcf34c50b', 'upgrades': [], 'pingTimeout': 60000, 'pingInterval': 25000}
--------- User connected
emitting event "connect" to 41bd89624c3447639ceb889fcf34c50b [/]
41bd89624c3447639ceb889fcf34c50b: Sending packet MESSAGE data 2["connect",{"data":"Connected"}]
41bd89624c3447639ceb889fcf34c50b: Sending packet MESSAGE data 0
<IP_ADDRESS> - - [27/Jul/2021 16:06:34] "GET /socket.io/?platform=android&EIO=3&transport=polling HTTP/1.1" 200 -
41bd89624c3447639ceb889fcf34c50b: Received packet CLOSE data None
--------- User disconnected
<IP_ADDRESS> - - [27/Jul/2021 16:06:44] "POST /socket.io/?EIO=3&transport=polling&platform=android&sid=41bd89624c3447639ceb889fcf34c50b HTTP/1.1" 200 -
<IP_ADDRESS> - - [27/Jul/2021 16:06:44] "GET /socket.io/?EIO=3&transport=polling&platform=android&sid=41bd89624c3447639ceb889fcf34c50b HTTP/1.1" 200 -
97a2465155564f51ae970b3719a159da: Sending packet OPEN data {'sid': '97a2465155564f51ae970b3719a159da', 'upgrades': [], 'pingTimeout': 60000, 'pingInterval': 25000}

This is the Flask log whit browser client, OPTIONS call with ping and all work fine
<IP_ADDRESS> - - [27/Jul/2021 16:29:31] "OPTIONS /socket.io/?EIO=3&transport=polling&t=NheNkLe HTTP/1.1" 200 -
0d780ef647cf480097868fdc4f0219ae: Sending packet OPEN data {'sid': '0d780ef647cf480097868fdc4f0219ae', 'upgrades': [], 'pingTimeout': 60000, 'pingInterval': 25000}
--------- User connected
emitting event "connect" to 0d780ef647cf480097868fdc4f0219ae [/]
0d780ef647cf480097868fdc4f0219ae: Sending packet MESSAGE data 2["connect",{"data":"Connected"}]
0d780ef647cf480097868fdc4f0219ae: Sending packet MESSAGE data 0
<IP_ADDRESS> - - [27/Jul/2021 16:29:31] "GET /socket.io/?EIO=3&transport=polling&t=NheNkLe HTTP/1.1" 200 -
<IP_ADDRESS> - - [27/Jul/2021 16:29:31] "OPTIONS /socket.io/?EIO=3&transport=polling&t=NheNkYF&sid=0d780ef647cf480097868fdc4f0219ae HTTP/1.1" 200 -
<IP_ADDRESS> - - [27/Jul/2021 16:29:56] "OPTIONS /socket.io/?EIO=3&transport=polling&t=NheNqeu&sid=0d780ef647cf480097868fdc4f0219ae HTTP/1.1" 200 -
0d780ef647cf480097868fdc4f0219ae: Received packet PING data None
0d780ef647cf480097868fdc4f0219ae: Sending packet PONG data None
<IP_ADDRESS> - - [27/Jul/2021 16:29:56] "GET /socket.io/?EIO=3&transport=polling&t=NheNkYF&sid=0d780ef647cf480097868fdc4f0219ae HTTP/1.1" 200 -
<IP_ADDRESS> - - [27/Jul/2021 16:29:56] "POST /socket.io/?EIO=3&transport=polling&t=NheNqeu&sid=0d780ef647cf480097868fdc4f0219ae HTTP/1.1" 200 -
<IP_ADDRESS> - - [27/Jul/2021 16:29:56] "OPTIONS /socket.io/?EIO=3&transport=polling&t=NheNqf4&sid=0d780ef647cf480097868fdc4f0219ae HTTP/1.1" 200 -

This is the app log event
JS: connected
JS: undefined
JS: connected
JS: connect
JS: error
JS: null
JS: disconnected
JS: transport error
JS: connected
JS: undefined
JS: connected
JS: connect

Is there any code involved?
The app is really basic:
        const socket = new SocketIO('http://<IP_ADDRESS>:5000?platform=android');

        socket.on("connect", (data)=>{
          console.log("connected")
          console.log(data)
        })
        socket.on("disconnect", (data)=>{
          console.log("disconnected")
          console.log(data)
        })

        socket.on("error", (data)=>{
          console.log("error")
          console.log(data)
        })

        socket.connect()

try @triniwiz/nativescript-socketio@4 an lmk

@triniwiz/nativescript-socketio@4

@triniwiz/nativescript-socketio requires at least version 7.0.0 of platform android. Currently installed version is 6.5.0.


Instructions for using the ScanNet dataset

Dear author, thanks for your amazing work！ How long will it take for you to release instruction for data preparation of ScanNet dataset. Your answer will be greatly appreciated

Sorry that I was busy with all kind of things after finished this project. But I may get time after the CVPR deadline and when I work on my final PhD thesis. If you are working on implementing this and encounter any problem. Please let me know and we could discuss to solve it.

Sorry that I was busy with all kind of things after finished this project. But I may get time after the CVPR deadline and when I work on my final PhD thesis. If you are working on implementing this and encounter any problem. Please let me know and we could discuss to solve it.

Dear author, the reason why I asked about the Scannet dataset is that I want to know whether your work could achieve multi-target point cloud completion in the same scene. I now have multiple depth cameras, but there is still a large part of missing after multi-camera point cloud fusion. I want to know whether your work could meet my needs. I am a novice in this area and don't know much . I would be most grateful if you could provide an answer.

Self supervised completion may heavily rely on priors about an object. Such a case is difficult for even supervised method. I think my method will also struggle. Also, my methods seem not good at scene level completion as some brought up by some issues.
If you have further questions to discuss, such as detailed research idea, it might be better to discuss via email instead of in public.


[Visibility] Lazy loading responsive images (srcset)

It should be possible to use the visibility module/behavior to lazy load not only img element src but also  srcset for responsive image support.

Would be nice to have that indeed. In the meantime, one can use Lozad.js.


How we can integrate this in apex22.1 so that our apex app works offline

Hi Vincent,
I have requirement that my apex app also should run offline.
I came to know about Service workers , but don't how to implement
I would love to implement some PWA features.
Thanks

I'm having the same issue.


Multi Point Paths

I might be doing something wrong but when using multi point paths on each segment the timestamp is reset counting from zero. Also not sure if this is intended behavior but when using the SplineGenerator::generate with Pose on each segment the starting velocity and ending velocities are zero.

@baylessj bump

@baylessj bump

Thanks for testing this out and opening an issue! The time plot is definitely wrong, that shouldn't reset between halves of the path.
I don't think the second graph is ideal either, although it's currently working as designed. squiggles::Pose points currently set the velocity and acceleration to 0, so having a pose as the middle waypoint will get you a velocity like you show above. I would prefer the default behavior to be a trapezoidal velocity graph above, but that's a bit harder to pull off in reality.
I'm wondering if it would be possible to do the path parameterization across the whole path rather than each segment and see if that remedies the issue. I can take a look at that sometime in the next week or two.
Would you be interested in opening a PR for the time incrementing issue? That should hopefully be a much easier fix than the change in parameterization of the paths.

Thanks for testing this out and opening an issue! The time plot is definitely wrong, that shouldn't reset between halves of the path.
I don't think the second graph is ideal either, although it's currently working as designed. squiggles::Pose points currently set the velocity and acceleration to 0, so having a pose as the middle waypoint will get you a velocity like you show above. I would prefer the default behavior to be a trapezoidal velocity graph above, but that's a bit harder to pull off in reality.
I'm wondering if it would be possible to do the path parameterization across the whole path rather than each segment and see if that remedies the issue. I can take a look at that sometime in the next week or two.
Would you be interested in opening a PR for the time incrementing issue? That should hopefully be a much easier fix than the change in parameterization of the paths.

Yeah I'll start on a PR

Yeah I'll start on a PR

I'm done with the time reset issue but looking at the code it seems like full path parameterization would also fix the time issue. Once I figure out the build system and make sure all tests pass I'll submit a PR.

I'm done with the time reset issue but looking at the code it seems like full path parameterization would also fix the time issue. Once I figure out the build system and make sure all tests pass I'll submit a PR.

Sounds good, thanks!
I took a look back at your discord message with the build errors. Building with ./pleasew build is the preferred method, I need to remove the CMake script from the project. I think that the error with --system might be a result of running the build in WSL, WSL has some interesting permissions issues sometimes. I'm running Linux primarily but I can boot into Windows and check out that error if you hit a roadblock with it.

Sounds good, thanks!
I took a look back at your discord message with the build errors. Building with ./pleasew build is the preferred method, I need to remove the CMake script from the project. I think that the error with --system might be a result of running the build in WSL, WSL has some interesting permissions issues sometimes. I'm running Linux primarily but I can boot into Windows and check out that error if you hit a roadblock with it.

@Dr-Danimal Is everything going alright for you with the PR for this issue? Happy to help any way I can.

@Dr-Danimal Is everything going alright for you with the PR for this issue? Happy to help any way I can.

The time fix is done in my testing env. I'll pr it in the next few days. Been kinda busy with FRC starting up.

The time fix is done in my testing env. I'll pr it in the next few days. Been kinda busy with FRC starting up.

No worries, the FRC season start is important! Are you planning to try to use Squiggles for an FRC bot or just for VEX?

No worries, the FRC season start is important! Are you planning to try to use Squiggles for an FRC bot or just for VEX?

Just for VEX, I'm not on software for FRC.

Hi @Dr-Danimal! Don't mean to pester you about this issue, but this is the last issue left before merging into Okapilib. It's totally fine if you don't have everything ready for a PR, could you open a PR in "draft" status and give me edit access instead? I can pick up where you've left off.

@baylessj Thanks for the reminder, went ahead and made a working PR for the time fix . I never got the build to work on WSL so I have only tested the PR on my own environment. If there are issues I believe you should have edit access.
I don't really have anything to PR for the full parameterization yet as most of my work has been just passing the full raw path to SplineGenerator::parameterize and seeing what happens/understanding why it happens. It seems to just work except for the position interpolation in SplineGenerator::get_point_at_time . I see 3 ways to handle the interpolation with the full raw path being passed to SplineGenerator::parameterize.

You could pass all ControlVector 's with their corresponding segments and interpolate with the existing get_point_at_time
You could generate the interpolation spline with ProfilePoint's instead of ControlVector's
You could interpolate position without generating a spline (I believe this is how WPILib does it)

I'm currently trying to generate the interpolation spline with ProfilePoint's. If you want me to try something else let me know.


Add a reference to YScope Docs for API documentations.

References

Description

Validation performed

How about:
README: Add link to API reference docs.

lgtm


Bug

Describe the bug
When joining a pool and clicking the Token Address link you are taken directly to the etherscan page rather than bringing it up in a new tab.. Because of this, when clicking back in the browser you will now have lost your page and be returned to the main page.
To Reproduce
Steps to reproduce the behavior:

Join any pool
Agree and continue
Click the Token Address
Click back on browser window.

Expected behavior
Any external links should open in a new tab or window.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

MacOS 10.12.6
Chrome
87.0.4280.88 (Official Build) (x86_64)

Additional context
Connected via MetaMask using Rinkeby
Wallet address
0x1C69ac5509e5fac81e1636f03F9AAa3EB56CdbE6

https://github.com/The-Poolz/Poolz-Back/issues/44
Its the same issue - will be done with one fix

https://github.com/The-Poolz/Poolz-Back/issues/44
Its the same issue - will be done with one fix


Path to keyfile is no longer available

If you unlock keepass, the path to the keyfile is no longer rememberd by keepass. In the dropdown field for the path is only Quickunlock selectable, so you have to search manually for the keyfile every time. Any ideas?
These options are active:
Remember key sources
Automatically search key files

See here:
https://github.com/KN4CK3R/KeePassQuickUnlock/issues/10#issuecomment-247460958
and here:
https://github.com/KN4CK3R/KeePassQuickUnlock/issues/7#issuecomment-232715543


Added to README info about gotests integration in Intellij Goland

Original discussion https://github.com/cweill/gotests/issues/24

Coverage remained the same at 96.358% when pulling 974dd725ddd146b5151fdbe17f31d30c553fe2aa on mekegi:intellij_goland into 4e853b3c92e5ff7449d711362fa52b3f329dfe17 on cweill:master.


task "syncdb for graphite" fails

First it fails with No module named settings:
TASK [graphite : syncdb for graphite] ******************************************
fatal: [graphite]: FAILED! => {"changed": true, "cmd": "export PYTHONPATH=/opt/graphite/webapp/; /opt/graphite/bin/python /opt/graphite/bin/django-admin.py syncdb --noinput --settings=graphite.settings", "delta": "0:00:00.048871", "end": "2017-02-02 07:17:52.495623", "failed": true, "rc": 1, "start": "2017-02-02 07:17:52.446752", "stderr": "Traceback (most recent call last):\n  File \"/opt/graphite/bin/django-admin.py\", line 5, in <module>\n    management.execute_from_command_line()\n  File \"/opt/graphite/local/lib/python2.7/site-packages/django/core/management/__init__.py\", line 353, in execute_from_command_line\n    utility.execute()\n  File \"/opt/graphite/local/lib/python2.7/site-packages/django/core/management/__init__.py\", line 302, in execute\n    settings.INSTALLED_APPS\n  File \"/opt/graphite/local/lib/python2.7/site-packages/django/conf/__init__.py\", line 55, in __getattr__\n    self._setup(name)\n  File \"/opt/graphite/local/lib/python2.7/site-packages/django/conf/__init__.py\", line 43, in _setup\n    self._wrapped = Settings(settings_module)\n  File \"/opt/graphite/local/lib/python2.7/site-packages/django/conf/__init__.py\", line 99, in __init__\n    mod = importlib.import_module(self.SETTINGS_MODULE)\n  File \"/usr/lib/python2.7/importlib/__init__.py\", line 37, in import_module\n    __import__(name)\nImportError: No module named settings", "stdout": "", "stdout_lines": [], "warnings": []}

and then after changing graphite.settings to graphite.settings_local (not sure if that's actually correct but it fixes the error) it fails with Unknown command: 'syncdb'
TASK [graphite : syncdb for graphite] ******************************************
fatal: [graphite]: FAILED! => {"changed": true, "cmd": "export PYTHONPATH=/opt/graphite/webapp/; /opt/graphite/bin/python /opt/graphite/bin/django-admin.py syncdb --noinput --settings=graphite.local_settings", "delta": "0:00:00.131501", "end": "2017-02-02 07:23:35.019818", "failed": true, "rc": 1, "start": "2017-02-02 07:23:34.888317", "stderr": "Unknown command: 'syncdb'\nType 'django-admin.py help' for usage.", "stdout": "", "stdout_lines": [], "warnings": []}

Changing syncdb to migrate works.  Although I'm not sure why; syncdb was deprecated in Django 1.7 and as far as I can see the playbook installs django<1.7.

Fixed in https://github.com/DandyDev/graphite-statsd-ansible-vagrant/commit/ae6e7d28a8051eeca08cd7d16112712f35475273


Can we use a shared onnx model with different components, without performance penalty?

The need is to create two components "e5-1" and "e5-2" sharing the same model.
Each component is deployed independently for the need of two schemas schema1.sd and schema2.sd.
When an application does not require schema1.sd , it can remove it with component "e5-1", without impacting the application managing schema2.sd
(This example is more useful with tens of schemas managed by tens of applications)
<container id="default" version="1.0">
    <component id="e5-1" type="hugging-face-embedder">
        <transformer-model path="shared_path_to_onnx"/>
    </component>
    <component id="e5-2" type="hugging-face-embedder">
        <transformer-model path="shared_path_to_onnx"/>
    </component>
    ...
</container>

I love the many-to-many relationship between schema and embedder.

If you define multiple embedder components, they can share the same path file, but that will still consume resources (e.g GPU memory) as it will be separate instances.

Basically, each embedder component (sharing model or not, configured in a schema or not) will consume its own resources?

Basically, each embedder component (sharing model or not, configured in a schema or not) will consume its own > >resources? No lazy loading?

Yes, each declared component becomes an instance that will consume resources regardless of pointing to the same file/URL/path resources.

Thanks.


Update scala3-library, ... to 3.1.1-RC2

Updates

org.scala-lang:scala3-library
org.scala-lang:scala3-library_sjs1

from 3.1.1-RC1 to 3.1.1-RC2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (3.1.1-RC1).
You might want to review and update them manually.
.github/workflows/ci.yml

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang" } ]

labels: library-update, early-semver-pre-release, semver-spec-pre-release, old-version-remains, commit-count:1

@scala-steward why wasn't this workflow re-generated?

@armanbilge It only regenerates the workflow if the project depends on one of these plugins and you are using "io.vasilev" % "sbt-spiewak-sonatype" which is not in the above list. I would accept a PR that adds this plugin to the above list.

Ah, I completely forgot about that switch! We were testing out some changes we want to make to sbt-spiewak. Thanks for the follow-up, much appreciated :)


add flags for include paths and files

Fixes: https://github.com/iovisor/bpftrace/issues/143

Thanks! Should be mentioned in the reference guide as well.

@ajor done :)


After using the playbook can't using S3

I tried to run the  playbook and after all finished,Swift worked correctly and S3 not with the error 403 Access  Denied when tried to create new bucket.
Any ideas?
Thank you

can you share more logs?

In the logs I saw sync_user() failed error
This it the only error I found

sync_user() failed is not really an error and I agree this is a bit misleading :). I need more info


Wrong regexp in art file search

Case:

Project called test is placed in /opt/projects/test directory
I have two files in ./arts directory: logo and test
When trying to draw test art climate prints out logo instead

The problem is in Art helper having wrong regexp:
$regex = '~' . preg_quote($art) . $pattern . '~';

It searches in full path of art file so /opt/projects/test/arts/logo is considered acceptable when searching test because of project name in its path.
File's directory should be removed before applying regexp.

This has been fixed in version 3.5.0


19043.1348

Rdpwrap stopped working after OS update to 19043.1348 yesterday. Will the updated .ini for 19041.1348 work on this version of OS?

Yes. Very necessary. The work is worth it.

[10.0.19041.1348-SLInit]
bInitialized.x64      =107108
bServerSku.x64        =10710C
lMaxUserSessions.x64  =107110
bAppServerAllowed.x64 =107118
bRemoteConnAllowed.x64=107120
bMultimonAllowed.x64  =107124
ulMaxDebugSessions.x64=107128
bFUSEnabled.x64       =10712C
bInitialized.x86      =D1A04
bServerSku.x86        =D1A08
lMaxUserSessions.x86  =D1A0C
bAppServerAllowed.x86 =D1A14
bRemoteConnAllowed.x86=D1A1C
bMultimonAllowed.x86  =D1A20
ulMaxDebugSessions.x86=D1A24
bFUSEnabled.x86       =D1A28

Duplicate of https://github.com/stascorp/rdpwrap/issues/1595#issuecomment-964643800

I'm on 19043.1348 and config seams ok but I always get: Another user is signed in, if you continue, they'll be disconnected...
I restarted pc multiple times.

It works, thank you.


[Sync] kserve/modelmesh-serving-main to main branch

Motivation
This is Release Sync. Detail information is here:
Sync Date: 20230825
odh/modelmesh-serving branch: main
related task : https://github.com/opendatahub-io/modelmesh-serving/issues/175

/test unit

/test unit


BIN/IIN 🚀

Summary of the new feature / enhancement
Sure, here are the proposed technical implementation details:

User inputs a BIN/IIN number into a designated search field within the app.
The app processes the input and retrieves detailed information such as card brand, card type, issuing bank, and country details from a secure and reliable database.
The app displays the retrieved information in a user-friendly format, ensuring clarity and ease of understanding.

Example Experience:

User opens the app and navigates to the BIN/IIN search feature.
User enters a specific BIN/IIN number into the search field and clicks the search button.
The app quickly processes the input and displays detailed information about the BIN/IIN number, including card brand, card type, issuing bank, and country of issuance.
Expected Result: The user sees all relevant BIN/IIN information without needing to navigate away from the app, providing a seamless and efficient experience.

Remember, contributions to this repository should follow its contributing guidelines, security policy, and code of conduct.
Proposed technical implementation details (optional)
Issue: Feature Request / Idea 🚀
Suggest a new feature or improvement (this does not mean you have to implement it) If this doesn't look right, choose a different type.
Add a title
Title
Summary of the new feature / enhancement
A clear and concise description of what the problem is that the new feature would solve. Try formulating it in user story style (if applicable).
'As a user I want X so that Y...' with X being the being the action and Y being the value of the action.
Proposed technical implementation details (optional)
A clear and concise description of what you want to happen. Consider providing an example experience with expected result.
Remember, contributions to this repository should follow its contributing guidelines, security policy, and code of conduct.
1.118202238676.104e4.Pdf.pdf

Fill out forms automatically in Chrome
You can let Chrome fill out forms automatically with saved info, like your addresses or payment info. Additionally, when you enter info in a new form online, Chrome might ask you if you’d like to save it to your Google Account.
Chrome never shares your info without your permission. Learn how Chrome protects your autofill and password data.
If you would like to save your password info to Chrome, learn how to manage saved passwords.
If you're having issues with your saved info, learn how to fix issues with info saved to Chrome.
Android ComputeriPhone & iPad
Add, edit, or delete payment & address info you saved in Chrome
On your Android device, open Chrome Chrome.
To the right of the address bar, tap More More and then Settings.
Tap Addresses and more or Payment methods.
Add, edit, or delete info:
Add:
At the bottom, tap Add address or Add card.
When you've entered your info, at the bottom, tap Done.
Edit:
Tap the entry.
When you're done changing your info, at the bottom, tap Done.
Delete:
Tap the entry.
At the top, tap Delete Delete.
If you add, edit, or delete an address and you’re signed in to Chrome with your Google Account, your changes show up on your other devices where you’re signed in to Chrome with the same account.
If your payment method is saved in Google Pay, you'll need to edit or delete it in Google Pay.
Nickname your payment method in Chrome
Important: These steps won't work if you saved the payment method in Google Pay.
On your Android device, open Chrome Chrome .
To the right of the address bar, tap More More and then Settings and then Payment methods.
Tap an existing payment method.
At the bottom, tap Nickname.
Enter a nickname for the payment method and tap Done.
The nickname appears whenever you use a saved payment method.
Tips:
If you rename a payment method, it appears when you select a form that uses a saved payment method.
Chrome's payment method nicknames don't transfer to Google Pay. If you save your payment information in Google Pay, you must update it separately.
Use your fingerprint or face to fill out forms
Use your fingerprint or device lock to verify your identity. You must still follow instructions and enter your security code at least once per payment method.
On your Android device, open Chrome Chrome.
To the right of the address bar, tap More More and then Settings and then Payment methods.
Turn “Screen lock” on or off.
The first time you enter info for a card, you must manually enter the security code. After that, you can use your fingerprint to fill the form.
Save your payment information in Google Pay
When you’re signed in to Chrome and you enter your payment method into an online form, Chrome may ask if you want to save your payment info in Google Pay. If you accept, your payment information is saved in Google Pay. If Google Pay doesn’t support your payment method, Chrome may offer to save it locally on your device.
Payment methods saved in Google Pay show up as suggestions in most online forms.
If Chrome doesn't offer to save your payment info in Google Pay, learn how to fix issues with saved payment info.
Tip: If you enroll a virtual card in autofill in Chrome, it appears as a suggested payment method in forms. You can either enter the virtual card CVV or verify your identity with your phone, such as with your fingerprint.
Edit or delete a payment method in Google Pay
Stop syncing payment info in Google Pay
“GOOGLE *TEMPORARY HOLD” appears on my card statement
Stop saving info in Chrome
On your Android device, open Chrome Chrome.
To the right of the address bar, tap More More and then Settings and then Payment methods or Addresses and more.
To stop saving payment info, turn off Save and fill payment methods.
To stop saving addresses and contact info, turn off Save and fill addresses.
If you want to stop saving passwords in Chrome, learn how to manage saved passwords.
Manage card security codes in Chrome
When you enter your payment information on a merchant site for the first time, you'll be asked if you want to save your security code, in addition to your payment information. Once saved, the CVV code will be filled in automatically along with your payment information when you make a purchase online.
Turn setting on or off
On your Android device, open Chrome Chrome.
At the top right, tap Settings and then Payment Methods.
Turn Save security codes on or off.
Tip: When you turn off this setting, all the saved security codes for all cards will be removed from your Google Account and your devices, and no new security codes will be saved.
Edit security codes
Delete security codes
Manage “Always verify when using autofill” setting
Important: This is a device-level setting. You must turn it on for each device that you want this setting on.
To prevent others from using your payment info when you share your device, you can turn on verification when you use autofill. With this setting, you can increase your security and protect yourself from fraudulent activities.
Turn “Always verify when using autofill” on or off
Troubleshoot “Always verify when using autofill” setting
If you have issues with Chrome not suggesting your saved info
To confirm that you’ve saved the info that doesn’t auto populate: Tap More More and then Settings.
The website might not be secure enough to get this info from Chrome.
If the website is secure, Chrome might not detect certain fields in the form.
Delete your saved autofill form info in Chrome
To delete your addresses, payment methods, or other saved info in Chrome at the same time:
On your Android device, open Chrome Chrome.

Tap Privacy and security and then Delete browsing data.
Choose a time range, like "Last hour" or "All time."
Under "Advanced," choose Autofill form data.
Tap Delete data.
This method doesn't delete payment info and addresses stored in Google Pay. Learn how to remove a payment method from Google Pay.
Related resources
Manage saved passwords
Edit or remove a payment method in Google Pay
Fix issues with saved info
Was this helpful?
YesNo
``


⚠ Bofrost.at has degraded performance

In 00940ea, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1199 ms

Resolved: Bofrost.at performance has improved in b14fa5e.


Accept multiple database names by the connector and divide them between multiple tasks

Acceptance criteria

Replace the database.dbname configuration parameter with database.names which accepts a comma-separated list of database names.
Rework SqlServerConnector#taskConfigs() to return up to N configurations instead of one, where N = max(number of database names, maxTasks).
Each task configuration should contain a task.database.names parameter.
The list of database names is divided between the tasks in a round-robin fashion. For instance, given the list of database names [a, b, c, d, e] and maxTasks = 2, the connector should produce the following list of configurations: [[a, c, e], [b, d]].
When connecting to the database, instead of using the value of database.dbname, each task should use the first value from its database list. Iteration over the list of the databases is out of the scope of this case.
Demonstrate the ability of the connector to process two databases in parallel by scheduling one task per database (database.names = foo,bar; max.tasks = 2).

@morozov was it resolved?

The last time @sugarcrm-jgminder and I synced up, it was close to being done.

This has been resolved and merged with this PR: https://github.com/sugarcrm/debezium/pull/24


godu: init at 1.3.0

Motivation for this change
godu: init at 1.3.0
Things done

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

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

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

First pass refactor to buildGoModule has some issues on build:
nix-build -A godu
   these derivations will be built:
  /nix/store/z1bv6zv4x7vdpm4f5h3jchpgz76y6z4w-godu-1.3.0.drv
building '/nix/store/z1bv6zv4x7vdpm4f5h3jchpgz76y6z4w-godu-1.3.0.drv'...
unpacking sources
unpacking source archive /nix/store/2z4g0z26rrcj5y87w0bgi098jw6j4fag-source
source root is source
patching sources
configuring
building
Building subPackage .
godu.go:13:2: cannot find package "." in:
        /build/source/vendor/github.com/gdamore/tcell
state_presenter.go:7:2: cannot find package "." in:
        /build/source/vendor/github.com/gdamore/tcell/views
godu.go:14:2: cannot find package "." in:
        /build/source/vendor/github.com/gosuri/uilive
builder for '/nix/store/z1bv6zv4x7vdpm4f5h3jchpgz76y6z4w-godu-1.3.0.drv' failed with exit code 1
error: build of '/nix/store/z1bv6zv4x7vdpm4f5h3jchpgz76y6z4w-godu-1.3.0.drv' failed

Seems related to: https://github.com/NixOS/nixpkgs/issues/91374 and https://github.com/NixOS/nixpkgs/pull/88909.
Not too sure how buildGoModule works, but believe has something to do with vendoring of dependencies and sub package setup.

Not too sure how buildGoModule works, but believe has something to do with vendoring of dependencies and sub package setup.

Since the sources do not contain a vendor directory, you need to set a hash for vendorSha256:
  vendorSha256 = "1zq7b0zn24cbrjssk4g03i90szp1ms7ila4khwcm7hp9n1py245s";

It seems though that upstream's go.mod is not up to date:
go: inconsistent vendoring in /build/source:
<EMAIL_ADDRESS>is marked as explicit in vendor/modules.txt, but not explicitly required in go.mod

Please file an issue upstream to fix this. In the meanwhile you can modify the derivation like this:
diff --git a/pkgs/tools/misc/godu/default.nix b/pkgs/tools/misc/godu/default.nix
index f25f483fc60..77f5a6eee4a 100644
--- a/pkgs/tools/misc/godu/default.nix
+++ b/pkgs/tools/misc/godu/default.nix
@@ -11,7 +11,9 @@ buildGoModule rec {
     sha256 = "1fp8iq4x0qiswksznnd6qh7c6g5pwglzz6ga11a7vgic0201wsvb";
   };

-  vendorSha256 = null;
+  patches = [ ./go-mod.patch ];
+
+  vendorSha256 = "1zq7b0zn24cbrjssk4g03i90szp1ms7ila4khwcm7hp9n1py245s";

   doCheck = false;

diff --git a/pkgs/tools/misc/godu/go-mod.patch b/pkgs/tools/misc/godu/go-mod.patch
new file mode 100644
index<PHONE_NUMBER>0..c74ad98e9ff
--- /dev/null
+++ b/pkgs/tools/misc/godu/go-mod.patch
@@ -0,0 +1,33 @@
+diff --git a/go.mod b/go.mod
+index cf8f2fb..e405e03 100644
+--- a/go.mod
++++ b/go.mod
+@@ -5,5 +5,6 @@ go 1.14
+ require (
+ 	github.com/gdamore/tcell v1.1.1
+ 	github.com/gosuri/uilive v0.0.0-20170323041506-ac356e6e42cd
++	github.com/mattn/go-isatty v0.0.12 // indirect
+ 	github.com/stretchr/testify v1.3.0
+ )
+diff --git a/go.sum b/go.sum
+index 23c1232..e25c87e 100644
+--- a/go.sum
++++ b/go.sum
+@@ -8,6 +8,8 @@ github.com/gosuri/uilive v0.0.0-20170323041506-ac356e6e42cd h1:1e+0Z+T4t1mKL5xxv
+ github.com/gosuri/uilive v0.0.0-20170323041506-ac356e6e42cd/go.mod h1:qkLSc0A5EXSP6B04TrN4oQoxqFI7A8XvoXSlJi8cwk8=
+ github.com/lucasb-eyer/go-colorful v0.0.0-20181028223441-12d3b2882a08 h1:5MnxBC15uMxFv5FY/J/8vzyaBiArCOkMdFT9Jsw78iY=
+ github.com/lucasb-eyer/go-colorful v0.0.0-20181028223441-12d3b2882a08/go.mod h1:NXg0ArsFk0Y01623LgUqoqcouGDB+PwCCQlrwrG6xJ4=
++github.com/mattn/go-isatty v0.0.12 h1:wuysRhFDzyxgEmMf5xjvJ2M9dZoWAXNNr5LSBS7uHXY=
++github.com/mattn/go-isatty v0.0.12/go.mod h1:cbi8OIDigv2wuxKPP5vlRcQ1OAZbq2CE4Kysco4FUpU=
+ github.com/mattn/go-runewidth v0.0.4 h1:2BvfKmzob6Bmd4YsL0zygOqfdFnK7GR4QL06Do4/p7Y=
+ github.com/mattn/go-runewidth v0.0.4/go.mod h1:LwmH8dsx7+W8Uxz3IHJYH5QSwggIsqBzpuz5H//U1FU=
+ github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
+@@ -16,6 +18,8 @@ github.com/stretchr/objx v0.1.0 h1:4G4v2dO3VZwixGIRoQ5Lfboy6nUhCyYzaqnIAPPhYs4=
+ github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
+ github.com/stretchr/testify v1.3.0 h1:TivCn/peBQ7UY8ooIcPgZFpTNSz0Q2U6UrFlUfqbe0Q=
+ github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
++golang.org/x/sys v0.0.0-20200116001909-b77594299b42 h1:vEOn+mP2zCOVzKckCZy6YsCtDblrpj/w7B9nxGNELpg=
++golang.org/x/sys v0.0.0-20200116001909-b77594299b42/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
+ golang.org/x/text v0.3.0 h1:g61tztE5qeGQ89tm6NTjjM9VPIm088od1l6aSorWRWg=
+ golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
+ gopkg.in/DATA-DOG/go-sqlmock.v1 v1.3.0 h1:FVCohIoYO7IJoDDVpV2pdq7SgrMH6wHnuTyrdrxJNoY=

Since the sources do not contain a vendor directory, you need to set a hash for vendorSha256:

Confused as to how you got this hash, can you show me the workflow?
Added the patch and vendoring deltas, can squash for final pull in if required.

Since the sources do not contain a vendor directory, you need to set a hash for vendorSha256:

Confused as to how you got this hash, can you show me the workflow?
Added the patch and vendoring deltas, can squash for final pull in if required.

You can use lib.fakeSha256 or stdenv.lib.fakeSha256 as the hash and build the derivation. It will then complain of a hash mismatch and give you the correct hash.

Added the patch and vendoring deltas, can squash for final pull in if required.

Yep, please squash the commits into two. One one where you add yourself to the maintainers list with the message
maintainers: add rople380

The other where you add the derivation with the message (at least the first line):
godu: init at 1.3.0

Rebased and squashed commits as specified.


[SPARK-41558][PYTHON][TESTS] Disable Coverage in python.pyspark.tests.test_memory_profiler

What changes were proposed in this pull request?
This PR is a followup of https://github.com/apache/spark/pull/38677 that disables Coverage in their tests for now.
Why are the changes needed?
To recover the coverage. These tests look consistently failing:
https://github.com/apache/spark/actions/runs/3712125552/jobs/6293347848
======================================================================
FAIL [13.173s]: test_memory_profiler (pyspark.tests.test_memory_profiler.MemoryProfilerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/__w/spark/spark/python/pyspark/tests/test_memory_profiler.py", line 56, in test_memory_profiler
    self.assertTrue("plus_one" in fake_out.getvalue())
AssertionError: False is not true

======================================================================
FAIL [3.986s]: test_profile_pandas_function_api (pyspark.tests.test_memory_profiler.MemoryProfilerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/__w/spark/spark/python/pyspark/tests/test_memory_profiler.py", line 87, in test_profile_pandas_function_api
    self.assertTrue(f_name in fake_out.getvalue())
AssertionError: False is not true

======================================================================
FAIL [3.722s]: test_profile_pandas_udf (pyspark.tests.test_memory_profiler.MemoryProfilerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/__w/spark/spark/python/pyspark/tests/test_memory_profiler.py", line 69, in test_profile_pandas_udf
    self.assertTrue(f_name in fake_out.getvalue())
AssertionError: False is not true

----------------------------------------------------------------------
Ran 3 tests in 20.882s

Does this PR introduce any user-facing change?
No, test-only
How was this patch tested?
Manual tests.

cc @zhengruifeng @xinrong-meng FYI

Merged to master.


Circular dependency error with service generated with --module in 6.0.0-rc.0

Versions
Angular CLI: 6.0.0-rc.0
Node: 8.11.0
OS: darwin x64
Angular: 6.0.0-rc.1
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 6.0.0-rc.0
@angular-devkit/architect: 0.0.10
@angular-devkit/build-angular: 0.0.10
@angular-devkit/build-optimizer: 0.4.9
@angular-devkit/core: 0.4.9
@angular-devkit/schematics: 0.5.0
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 6.0.0-beta.9
@schematics/angular: 0.5.0
@schematics/update: 0.5.0
typescript: 2.7.2
webpack: 4.1.0

Repro steps

ng new hello
ng g module world --module app
ng g service world/data --module world
ng g component world/page
inject the service in the component constructor

Observed behavior
WARNING in Circular dependency detected:
src/app/world/data.service.ts -> src/app/world/world.module.ts -> src/app/world/page/page.component.ts -> src/app/world/data.service.ts

Desired behavior
CLI v6 ng g service command now provides the service in a tree-shakeable way, using the providedIn option of Injectable decorator.
Without the --module option, it uses providedIn: 'root', which seems OK.
But with the --module option, CLI v1 was providing the service directly inside the NgModule. Now in CLI v6, the module is configured via providedIn. But then the service is not usable in components, which is a serious problem.
I see 2 options :

either it is an Angular issue, which should be resolved ;
either it is a known limitation of providedIn, then the CLI should keep its old behavior of providing the service directly in the NgModule when using --module.

It's worth noting that the circular dependency detection was introduced in the past because there were cases where it broke bundling. Perhaps it is not actually needed anymore.

Please, "don't shoot the messenger". In fact it seems to me the circular dependency warning is a life-saver here, pointing out on an otherwise very hard to detect problem. Dropping the message won't solve the problem:

Now in CLI v6, the module is configured via providedIn. But then the service is not usable in components [...].

The service is obviously not being injected in case of a circular dependency. Actually, that sounds like a problem with the angular compiler who reasons about decorator metadata for dependency injection and who seems to have issues to properly resolve those circular dependencies.
I would expect much more people to run into this once tree-shakable providers will be released for two reasons:

service--[provides itself to]-->module--[declares]-->component--[depends on]-->service is going to be a very common pattern because in the majority of cases it makes just sense that modules and their components consume their own services

there will be many people who will think gaining tree-shaking efficiency withDI means to just do things "the other way around" now. So many will probably begin to scan their NgModule providers arrays and systematically add @Injectable({providedIn: MyNgModule}) to any service they find before dropping the array.

Unless there's a solution to this problem providedIn: 'root' will mostly be the only viable option to choose when using tree-shakable providers, I guess.

service--[provides itself to]-->module--[declares]-->component--[depends on]-->service is going to be a very common pattern because in the majority of cases it makes just sense that modules and their components consume their own services

Please stop teaching or telling pepole to use this pattern

@hansl I think we think pretty much the same about the issue. I didn't intent to teach people to use this pattern nor should above "pattern" be understood as a recommendation. Maybe I should have called it anti-pattern

People [...] need to see the circular dependency error and tell themselves "that's odd", and search and find that they shouldn't use it.

In fact that's what I argued for, too. My comment was meant as a response to the thoughts of @filipesilva who thought whether it were possible to drop the circular dep. detection alltogether. I think it provides an invaluable hint on the cause of @cyrilletuzi's issue and points at code smells which are unpleasant and unintended most of the time.
By the current typings and docs it is at least technically possible to use providedIn with a module type which I think will look to many people that optimizing for tree-shakability means you can make things work by just doing them the other way around, compared to v5 which is obviously not the case.
Therefore I am afraid there will be many people who attempt to migrate their existing code yielding the (anti-)pattern I described. Without any warning they would only find out that "for some reason" the service simply won't be provided to some components and left with a problem which is very hard to debug. Seeing the circ. dep. from just the code is not any easier. And therefore I came to the same conclusion as you. The circular dependency warning might not tell people directly that they've used @Injectable the wrong way, but it indicates that there's something's fishy and given the dependency path it provides it is not that hard to see what the problem is.

providedIn: 'root' is the 99% of cases.

That was my impression, too. Given the docs 'root' should be default if providedIn was not declared at all. So if any collegue of mine would ask me about any recommendation regarding providedIn I would probably recommend to only use it if not using it doesn't work ;-)

You might wanna strip the following from the docs, to not give people any good ideas:
import { Injectable } from '@angular/core';
import { HeroModule } from './hero.module';
import { HEROES }     from './mock-heroes';

@Injectable({
  // we declare that this service should be created
  // by any injector that includes HeroModule.

  providedIn: HeroModule,
})
export class HeroService {
  getHeroes() { return HEROES; }
}

Source: https://angular.io/guide/dependency-injection#injectable-providers
I recommend having a very big fat warning box next to it.

I'm experiencing this problem as well, but am unconvinced that providedIn: 'root' is a good longterm solution for every service. For instance, I was under the impression that lazy-loaded modules bundled their provided services with them, meaning this new method would swell the app or common bundle considerably. If that's not the case, then I guess I'm on board, but I'd be surprised to learn that.
Since 'root' is a string Token to look up the root module, why not allow us to declare module selectors in the same vein? That way you could do providedIn: 'UsersModule' without the explicit import of UsersModule which trips the circular dependency detection?

Encountered this as well.
Api service imports module, module imports ngrx/effect, ngrx/effects imports api service.
So I should just use provideIn: 'root' no matter what?

Whoa Nellie!
I have a large number of services that are scoped to  modules (lazy modules) or even to components within those (lazy modules).
This pattern has worked GREAT for a very long time.
I understand the desire to make LIBRARIES treeshakable. A library often includes tons of code that many consumers will not need or want.
However, APPLICATIONS typically contain very few treeshakable services. If I write a service for my app, it's because I expect the app to need it. I don't write app services that someone might NOT need.
Therefore, treeshaking is of very little benefit to application code.
If you think I'm wrong, show me (us) please.

People using --module without knowing what they're doing need to see the circular dependency error and tell themselves "that's odd", and search and find that they shouldn't use it.

Well you totally busted me right now.

Since 'root' is a string Token to look up the root module, why not allow us to declare module selectors in the same vein? That way you could do providedIn: 'UsersModule' without the explicit import of UsersModule which trips the circular dependency detection?

+1 for this idea.
@NgModule({ selector: 'heroes' })
export class HeroModule {}

@Injectable({ providedIn: 'heroes' })
export class HeroService {}

I think that's a nice way to do it. This should be possible, right?

Tree shaking providers are opt-in.  The classic method of providing the services via NgModule metadata is still viable if desired (just remove { providedIn: 'root' } if doing so).

As an update to my last post: it does appear that even when providedIn: 'root' webpack will bundle the service with the correct lazy module bundle, so no concern there.

I stumbled upon the same issue @fxck described when using services in ngrx effects:
service--[provides itself to]-->module--[declares]-->effect--[depends on]--service
In my case, both service and effect are within a lazy-loaded module. I used providedIn: LazyLoadedModule on my service and got the circular dependency warning.
Then I found this thread, telling me...

providedIn: 'root' is the 99% of cases.

Alright. So I changed my service to be provided by root. But now, I get an error when my lazy-loaded module is loaded during runtime:
Error: Uncaught (in promise): Error: StaticInjectorError(AppModule)[HttpClient]:
  StaticInjectorError(Platform: core)[HttpClient]:
    NullInjectorError: No provider for HttpClient!

My LazyLoadedModule has an import on HttpClientModule, but  AppModule doesn't. Why should it? AppModule in my case doesn't do anything (for the most part) besides being a shell for lazy-loaded modules. Why should I declare a dependency here that is required by a service in a lazy-loaded module?
I'm lost on what is the best practice here... 🤔

I'm lost on what is the best practice here... 🤔

I think re-export HttpClientModule from your lazy-loaded module (but don't shoot me if I'm wrong).
@NgModule({
    imports: [HttpClientModule],
    exports: [HttpClientModule]
})
export class LazyLoadedModule {
}

@Injectable({ providedIn: 'root' })
export class LazyService {
}

@StevenLiekens no, that didn't help :-/

@luchsamapparat I can not provide some "official" recommendation but I think the best practice in cases where tree-shakable providers don't work is to continue providing things as they have been provided prior to tree-shakable providers. The v5 mechanics haven't been deprecated.
Nevertheless, did you try the pattern shown by @manfredsteyer in https://github.com/angular/angular/issues/23715. It's far from pretty but might help with tree-shakable providers.

Since 'root' is a string Token to look up the root module, why not allow us to declare module selectors in the same vein? That way you could do providedIn: 'UsersModule' without the explicit import of UsersModule

@swimmadude66 @StevenLiekens  Your proposals wouldn't be statically analyzable and Angular would pretty much undermine its choice for TypeScript if it followed your proposal. 'root' is a string token, yes, but it's not a class name. In contrast UsersModule in your proposal is meant to refer to class. Then just rename the class and you wouldn't get any hint from TypeScript that somewhere between all your services there's the malicious one who keeps on referring to it by a string. This error would certainly bite you (or your customers) at runtime.
A class name isn't a sufficient qualifier,  either. The Angular compiler would also not be able to find out the actual class token. For this to work your string would have to be a file path pointing to the module file, at least. But such a path would certainly not be valid at runtime after all the bundling and stuff. So the Angular compiler would have to come up with some replacement token anyway - e.g. the actual class token. You may see, there's no win with a string.

After playing with this for the last hour, I have come to the following conclusion that for services used across the application, then it is only useful to have providedIn: 'root'.  Do not bother putting these into the providers array of the AppModule.
However, if you want to provide a service in any feature module (not the root), then you are better off using the providers array in the feature module's decorators, otherwise you will be plagued with circular dependency warnings.

My LazyLoadedModule has an import on HttpClientModule, but AppModule doesn't. Why should it?

Here's why that breaks providedIn: 'root':

When the Angular router lazy-loads a module, it creates a new injector. This injector is a child of the root application injector.

https://angular.io/guide/providers#limiting-provider-scope-by-lazy-loading-modules
Okay so what this means is that your lazy module gets its own private copy of HttpClient. The root module doesn't know about your private HttpClient so the injector shits all over the console when you try to get an instance of a service that depends on HttpClient.
I do feel like re-exporting the HttpClientModule should have added HttpClient to the root injector but maybe my expectations are wrong.

For me it feels like this feature, while nice in theory, isn't thought through…

From reading lots of things about the topic, what I understand is the following:
Like @hansl wrote: "Always use providedIn: 'root'
Like @swimmadude66 wrote:  it will still be bundled in the right bundle (so they the build does the job for you if it's only used in the lazy loaded bundle)
And just like in this issue #23715 - If you really want to limit the scope, you can do it with a separate module for services which gets loaded by the lazy loaded module.
The only thing missing is to update the docs and I think it'll be better to remove the section that shows you can use providedIn with specific modules (or just hide it in a "super rare cases" section).
I think that will reduce the confusion and will promote the better practice. (FYI @jenniferfell )
CONCLUSION:
Always use the providedIn: 'root', (for both eager + lazy loaded modules' services)

it's better,
it solves the "duplicated services instance" problem on shared lazy loaded modules
It's easier to learn and to use

So back on topic: what should the --module flag do? Old or new behavior? And what about the issues with providedIn: 'root' discovered by luchsamapparat ?

@StevenLiekens --module adds the service to the referenced module's providers array and doesn't include the providedIn: 'root'?
I have a feature module and I was trying to specify the module name in the providedIn and encountered circular dependency warnings like everyone else. Until you can tokenize module names as strings like what root references then just use the v5 method. That's what I'm going to do >.>
Sounds like we need a feature request to tokenize a module name to be used by services preventing the circular dependency warning. If this was implemented THEN --module could specify the module selector in the providedIn option.

If it should be providedIn: 'root' in virtually all cases then having to specify it only serve the purpose of confusing people.

@cedvdb I'm with you, if that was the only way to define providers.
But I guess they made us configure it this way not to break existing projects,
because the providedIn way does change the functionality slightly.

add here for notation purpose. I take 3 hours to invest about this, and this blog: The New Treeshakable Providers API In Angular: Why, How And Cycles
 explain for me very well.
the problem is:

we can resolve it by creating new api module for that service:

that all I need.
@Injectable({
    providedIn: FlightApiModule
})
export abstract class AbstractFlightService  {
}

In addition, the lazy module also needs to import the new service module:
@NgModule({
    imports: [
        [...]
        FlightApiModule
    ],
    [...]
})
export class FlightBookingModule {
}

Has everyone read the updated documentation yet? Also there is the FAQ providing tons of informations how it works (probably better than the article on softwarearchitect.io ?)
If i get this right:

providedIn: UserModule is only needed for developing libraries: When someone is using your library he cant provide your service if he didn't import UserModule
Mostly always use 'root'. The service is available application wide. If the service is only used within a lazy loaded module it will be lazy loaded with that module, if it is never used it will be tree shaked.
If you want to limit the scope of a service, remove providedIn and provide it within your lazy loaded module as before (preferred) or provide it within a component
Note: Don't provide services by a shared module
Note: If you provide your service within a sub-module, it will by available application wide unless the sub-module is lazy loaded.

Can someone confirm?

With "5." i mean provide with the providers array. Do not use providedIn: LazySubModule.

@MickL I see that, so then it is a true statement to say that these two are equivalent?
@NgModule({ providers: [SomeService] })
export class SomeModule {}

old style

service will be global singleton if SomeModule is imported eagerly

service will be instantiated per lazy module if SomeModule is loaded lazily

injecting SomeService in eager part of application will result in error  if SomeModule is loaded lazily

DISADVANTAGE - mixing of the old providers: [] and the new providedIn syntaxes

@Injectable({ providedIn: SomeSubModule })
export class SomeService {}

@NgModule({ imports: [SomeSubModule]})
export class SomeModule

new provided In syntax

service will be global singleton if SomeModule is imported eagerly

service will be instantiated per lazy module if SomeModule is loaded lazily

injecting SomeService in eager part of application will result in error  if SomeModule is loaded lazily

DISADVANTAGE - extra module to prevent circular deps

anybody knows

You might wanna strip the following from the docs, to not give people any good ideas:
import { Injectable } from '@angular/core';
import { HeroModule } from './hero.module';
import { HEROES }     from './mock-heroes';

@Injectable({
  // we declare that this service should be created
  // by any injector that includes HeroModule.

  providedIn: HeroModule,
})
export class HeroService {
  getHeroes() { return HEROES; }
}

Source: https://angular.io/guide/dependency-injection#injectable-providers
Or keep it, and put a very big fat warning box next to it.

This has just happend to me using this page:
https://angular.io/guide/providers#providing-a-service
Come on guys remove it from de docs please

Please correct me if I'm missing something, but it seems to me that adding the providedIn: 'root' syntax breaks the link between the service and the module it nominally lives in?
The service doesn't know about the module anymore, and the module doesn't know about the service, so the service is no longer really "in" the module. Instead, the service will just get bundled with whatever references it?
The result of this seems to be that we can no longer guarantee that the service's dependencies (as defined by the module it "lives in") will be loaded when the service is injected, hence - I think - the problem described by @luchsamapparat?
It seems to me this could be fixed using the providedIn: 'UserModule' idea, suggested by swimmadude66 (which allows the module to be specified, without causing a circular reference).
Alternatively though, wouldn't it have been simpler not to have introduced the providedIn syntax in the first place? Tree shaking of components is already performed, even when they are referenced in the declarations and exports arrays, so couldn't this have been done for providers as well - before they're added (or not) to the injector - instead of introducing a new syntax...?

Most probably you wanted to have a service in 1 particular component/module. You can do it by doing the following:
@Injectable()
export class FooService {
  ...
}

And in your component:
import { FooService } from 'PATH_TO_THE_SERVICE';
@Component({
  selector: 'app-lazy',
  templateUrl: './lazy.component.html',
  styleUrls: ['./lazy.component.scss'],
  providers: [FooService]
})

Do not make it this way:
@Injectable({
  providedIn: LazyModule
})

It will show warnings about circular dependencies. Also do not import this in the providers array in the LazyModule, combined with the last code snippet will show the same warnings. Alternatively you can simply do the following:
@Injectable({
  providedIn: 'root'
})

Angular will then detect automatically in which component it has been used. If it wouldn't be used it will be tree shaked.

Angular contributor says make all your service instances Root scoped Singletons? Regardless of the programming language or framework this can't be a serious mindset.
Being able to control the scope and lifetime of an injected dependency instance is very important, I hope the Angular Team is not planning on taking this capability away for tree shaking improvements. What you end up with is a small file bundle that quickly becomes bloated in memory at run time.
I don't use 'providedIn' because I like being able to control scope and lifetime of my service instances, and when a developer has this mindset then there is no need for tree shaking since I intend for my services to be used else I would not go to the trouble of providing them only where they are needed.
Since the CLI defaults to providedIn when generating a service class I see teams of Angular newbies using it everywhere in their apps for services that are written to work only with a single component instance. I would like to see the providedIn technique be Opt In and remove the {providedIn: 'root'} snippet from CLI generated services.

Why would you handle the scope of your services when providedIn already choses the perfect usage? If the service is used only with a single component then it is bundled with this component. If it is used as a app wide singleton then it is. The CLI always handles it perfectly no need to think about it again. I think this is great for newbies and for professionals. Still it is optional and you can handle it manually too so i dont see the problem.


r/Playboy_Albums blacklist

Due the post´s diversity in r/Playboy_Albums a post could be:

An album´s request.
An album´s fullfilled request.
Discussion.

We just want the fullfilled request (Playboy complete album).

It needed to create a blacklist functionality in monitor(self, submissions_found):.

The picture below shows which posts should be blacklisted.

Flair blacklist functionality added on monitor(self, submissions_found):.
Config json´s structure changed:

Added a BLACKLIST key.

{
  "BLACKLIST": [
    "Request",
    "Discussion"
  ]
}